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?