Powershell – автоматизируем построение организационной структуры в Active Directory. Часть 2.


 

Как-то я публиковал статью  Powershell – автоматизируем построение организационной структуры в Active Directory. Очень удобно, когда можно для  любого пользователя видеть его руководителя и подчиненных. Видеть это можно в Outlook, Sharepoint и Lync. А еще можно использовать визард в Visio, с помощью которого автоматически построить графическое отображение организационной структуры, и опубликовать его на сайте Sharepoint!

Недавно столкнулся с более сложной ситуацией: несколько филиалов и несколько доменов, GAL синхронизируется с помощью FIM (т.е. кроме учетных записей пользователей надо обрабатывать контакты), организационная структура включает в себя филиалы, имена которых внесены в атрибут Company учетных записей, сотрудники одного филиала могут подчиняться руководителю другого филиала.

Ниже приведен скрипт, который автоматизирует построение нижнего уровня организационной иерархии, а именно делает привязку подчиненных начальникам отделов. В моем случае более верхние уровни оказались плохо формализуемыми, поэтому в скрипте их нет, и вы можете сделать доработки сами под свою ситуацию при необходимости.

 

#
#   Заполнение полей Manager для учетных записей сотрудников
#   Непосредственный начальник определяется по имени филиал+подразделение и списку должностей начальников
#

$SearchBase = "OU=GALContacts,DC=domain,DC=ru"

$adusers = Get-ADObject -LDAPFilter "(&(&(&(objectCategory=user)(objectClass=user)(department=*)(!userAccountControl:1.2.840.113556.1.4.803:=2)) ))" `
                -Properties department,manager,title,Company

#
# Кроме пользователей нам нужны контакты GAL
#
$adcontacts = Get-ADObject -LDAPFilter "(&(&(&(objectCategory=contact)(objectClass=contact)(department=*)) ))" `
                -Properties department,manager,title,Company -SearchBase $SearchBase

$adusers += $adcontacts

$bossTitleList = @("Нач. цеха","Глав.бух.","Начальник отдела", "Начальник службы", "Начальник центра")

#
#   Для каждого подразделения составляем список его сотрудников
#
$deps = @{}
$adusers | % { $deps[$_.Company + $_.Department] += @($_) }

#
#   Для каждого подразделения находим его начальника
#
$depboss = @{}
foreach ( $dep in $deps.keys ) {

   $deps[$dep] | ? {$bossTitleList -contains $_.title} | % {$depboss[$dep] = $_ }

}

#
#   Для каждого начальника берем его подразделение и каждому сотруднику заполняем поле Manager
#
foreach ( $dep in $depboss.keys ) {

   $boss = $depboss[$dep]
   $deps[$dep] | ? {$_ -ne $boss} | ? {$_.manager -ne $boss.DistinguishedName} | % { Set-ADObject -Identity $_ -Replace @{manager=$boss.DistinguishedName} }

}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, «Courier New», courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Что полезно знать прежде, чем начать борьбу со спамом?


 

Очевидное. Спам и вирусы неразрывно связаны.

1.       Невозможно представить, чтобы сегодня сколько-нибудь заметное количество спама могло распространяться без заражения многочисленных компьютеров в сети Интернет образующих ботовые сети.

Но возможно ли такое, невирусное, распространение спама (не вирусов!)? Да, конечно. Это можно назвать «легальным» распространением спама. Для этого нужно рассылать спам с собственных или арендованных серверов, иметь выгодные контракты с интернет-провайдерами (выгодные для последних) и, безусловно, хороших адвокатов. В США были судебные процессы против подобных компаний, но в моей памяти не отложилось, чтобы их деятельность запретили!

2.       Другая сторона более независима (вирусы сегодня могут успешно распространяться без почты – есть другие более эффективные способы). Причина в том, что установка антивирусных программ на почтовых серверах стала даже не нормой, а обязательным делом.

Тем не менее угроза остается актуальной: антивирусная программа не может поймать новый для нее вирус, могут быть ошибки в ПО или настройках – поэтому вирусы как рассылались по почте, так и будут рассылаться.

Очевидное, но невероятное

Панацеи в борьбе против спама нет! Одни придумывают новые способы преодоления защиты. Другие придумывают новую защиту.

Теперь не всегда очевидное.

На мой взгляд есть основной принцип противостояния спаму: какую цену вы готовы заплатить и какое количество спама терпеть за эти затраты?

Например, ваше руководство не хочет тратить деньги на коммерческий анти-спам продукт. Хорошо — настройте встроенные средства анти-спама и ждите реакции пользователей: если их устроит, что спама стало значительно меньше, то вопрос решен; если им в тягость десятки спам-писем, то руководству придется раскошелиться.

Вместо покупки коммерческого продукта есть другой вариант траты денег на борьбу со спамом: выделяется человек, который будет мониторить спам и подкручивать анти-спам фильтры ручками.

Надо еще отметить, что скорее всего вы купите антивирусный фильтр, а производители антивирусов, как правило, предлагают антиспам защиту – стоит ли отказываться от этого дополнения?

Совсем неочевидное.

Второй принцип: вы или «хозяин», или «слуга» — вы или готовы принимать письма только на своих условиях или принимать все анонимные письма.

Первое не является общепринятым в отношении эл. почты. Но общепринято в отношении сайтов  и форумов: размещение комментариев только после регистрации или ввода анти-спам кода. И вас могут легко заблокировать за нарушение правил форума. Почему бы не требовать этого от всех, кто хочет нам отправить почтовое сообщение? Отправляете новичкам NDR с ссылкой на вэб-форму регистрации домена или адреса отправителя в вашей системе. Успешно прошедших регистрацию вносим в белый список. Мечта J Но вести свой «белый» список вы вполне можете.

 

Какие средства нам доступны для самозащиты?

 

·         Real-time Blackhole List (RBL)

·         Sender Policy Framework (SPF), или Sender ID в терминах Microsoft.

·         DomainKeys Identified Mail (DKIM)

·         Domain-based Message Authentication, Reporting & Conformance (DMARC)

 

1.       Про RBL нет смысла говорить подробно. Замечу только, что их эффективность нынче довольно низкая, т.к. много спама рассылается через бот-сети.

2.       DMARC это развитие SPF и DKIM. Если кратко, то DMARC позволяет легитимным владельцам почтовых доменов устанавливать политики и получать отчеты от легитимных получателей, тем самым еще более контролируя использование своего почтового домена.

3.       Все три стандарта поддерживаются Microsoft. Но Microsoft реализует все три только в облачном сервисе; для локальных Exchange доступен только SPF – все остальное как продукты третьих фирм.

4.       SPF и DKIM не являются полной защитой от спама! Они только говорят о том, какие серверы могут отправлять почту определенных доменов – не более того!

Иначе говоря, спамер имеет две возможности: зарегистрировать свой домен и SPF записи к нему, либо для зараженных компьютеров создавать SPF записи в своем домене (например, 4-го, 5-го уровня вперемешку с легитимными доменами)

Нужно ли использовать SPF и DKIM, если они не гарантируют полную защиту от спама?

Да, нужно обязательно. Во-первых, они все же защищают от части спама и не только вас, но и других (SPF и DKIM защищают от спуфинга и фишинга).  Во-вторых, защищают репутацию почтового домена и его владельца. В-третьих, упрощают защиту от спама.

Представьте, что все владельцы почтовых доменов зарегистрируют SPF записи. В результате спамеры практически полностью потеряют возможность отправки сообщений от имени легитимных доменов!

Если вы можете позволить вести себя как «хозяин», то включите требование обязательного SPF (Sender ID) и всем говорите (NDR): хотите нам отправлять письма – сделайте себе SPF! И крайний вариант при очень сильном недовольстве руководства: внести домен (лучше адрес) партнера без SPF записи в белый список.

Полезные ссылки:

1.       Real-time Blackhole List (RBL)

2.       Sender Policy Framework (Sender ID)

3.       Domain-based Message Authentication, Reporting & Conformance (DMARC)

4.       DomainKeys Identified Mail (DKIM)

5.       Outlook.com increases security with support for DMARC and EV certificates

Все, что нужно знать о Outlook Provider


Речь о том, когда нужно настраивать пресловутый msstd с помощью командлетов Set-OutlookProvider и New-OutlookProvider.

Собственно все, что нужно, описано в статьях:

All about Set-OutlookProvider

The Autodiscover Service and Outlook Providers — how does this stuff work?

When, if and how do you modify Outlook Providers?

Что нужно учесть перед миграцией на Exchange Server 2013


Несколько моментов актуальных на текущий момент:

1. Нужно создать на Exchange 2010 новую OAB для почтовых ящиков, которые еще не мигрировали. Причина: при установке Exchange 2013 в существующую организацию Exchange 2010 на новом сервере 2013 будет создана новая Default OAB и все клиенты будут перенаправляться на нее, это сразу заставит всех клиентов выполнить полную загрузку новой OAB, что может быть нежелательно из-за высокой пиковой нагрузки на серверы.

2. Public Folders невозможно мигрировать частями – только все сразу: редиректы для PF не работают с 2013 на 2010.

3. Новая технология Public Folders еще недостаточно отработана и в вопросах миграции, и в вопросах эксплуатации. Поэтому я бы рекомендовал не спешить с миграцией на 2013 тем, кто (активно) использует Public Folders: подождите еще несколько месяцев до момента, когда Exchange 2013 исполнится хотя бы год (до CU3 ?). За это время будут исправлены самые неприятные баги и выпущена более подробная документация.

4. Почтовые ящики, которые мигрировали на 2013, будут доступны внутри, но не будут доступны снаружи, если не сделан перевод Интернет трафика на 2013 (т.е. внешние DNS все еще указывают на серверы 2010)

 

Учитывая, как постепенно накапливался опыт миграции на Exchange Server 2010, этот список будет расти и расти!

Sharepoint 2010 – проверка вводимых данных.


Мне, как человеку, который не так уж часто создает какие-то решения на Sharepoint, приятно делать некоторые открытия на этом поприще.

Вот на днях собирал приложение для учета служебных телефонных номеров (возможно позже опишу создание этого чрезвычайно полезного приложения) и обнаружил достаточно удобный способ контроля вводимых значений.

Читать далее

Forefront Identity Manager и файл CSV


Настраивал в FIM агент для импорта информации из файла CSV. При запуске процесса импорта и синхронизации внезапно получил статус завершения с ключевым словом:

stopped-file-embedded-nulls

Сильно подивился, т.к. это был не первый мой агент и исходный файл был заполнен информацией.

После протирания фар и прочего шаманства обнаружил тривиальную ошибку в настройках агента:

clip_image001

clip_image002

— всего-то надо было выставить правильную кодировку для исходного файла в Unicode!

Век живи – век учись… все одно: человеческий фактор – источник всех проблем.

Полезные ссылки:

1. http://setspn.blogspot.com/2011/01/fim-2010-stopped-file-embedded-nulls.html

2. Management Agent for Delimited Text File