Доверительные отношения между доменами и firewall

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

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

Windows NT

Порты клиентов	Порт сервера	Служба
1024-65535/TCP	135/TCP	RPC *
137/UDP	137/UDP	Служба имен NetBIOS
138/UDP	138/UDP	Вход в сеть и обзор сети NetBIOS
1024-65535/TCP	139/TCP	Сеанс NetBIOS
1024-65535/TCP	42/TCP	Репликация WINS

Настройка точного времени в домене Windows 2003 / 2008 / 2008 R2

обновлено 30.03.2010

Все хотят видеть на компьютере точное время, кроме того, это очень важно для нормального функционирования домена Windows и AD. Казалось бы, чего проще, настраиваешь PDC эмулятор на синхронизацию с каким-нибудь ntp и все становится на места само собой … Но нет, уже несколько раз, наблюдалась рассинхронизация контроллеров домена между собой и жалобы пользователей на то, что наше время отличается от точного на пару минут.

Казалось бы, смешная проблема – пару минут, но для некоторой работы и пара минут важно. Особенно, если это редактора новостной ленты www.korrespondent.net. Правда были еще и шуточные жалобы, что они из-за этой проблемы целых 2, 3 или 5 минут перерабатывают :-)

Стандартные “танцы с бубнами”, которые делал я, а потом и наш сетевой инженер, по руководству от Microsoft помогали, но не долго. Т.е. время сходится, ошибки из лога исчезают, а через пару часов, или, через сутки все начинается заново. А потом, через пару-тройку недель, или месяц-другой, ошибка снова достигает размера более 2-х минут и все заново.

WSUS - сверка списка компьютеров с AD

обновлено 25.03.2010

На блоге Ильи Сазонова обнаружил очень интересный материал: WSUS - сверка списка компьютеров с AD. Да и вообще, там регулярно появляется любопытная информация.

Позволю себе перенести то, что он выложил к себе с некоторыми моими комментариями и модификациями.

Что это и зачем это нужно? В каждой уважающей себя организации используется Active Directory как единый каталог и WSUS для централизованной установки обновлений. Но, по разным причинам, некоторые компьютеры могут не обновляться со WSUS. Причины тому могут быть самые разные: сбой агента обновления, файрволл, еще что-то … Главное – это то, что такие случае нужно выявлять и разбираться с ними индивидуально.

Итак

Текущая версия WSUS имеет API, который позволяет удаленное управление сервером. Чтобы его задействовать, необходимо установить на компьютер клиентскую часть сервера. После чего запускаем оболочку Powershell 2.0 и загружаем WSUS API:

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

   Теперь надо подключаемся к удаленному серверу по имени «WSUS»:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false)

   Второй параметр $false говорит о том, что будет использоваться HTTP протокол, а не HTTPS, т.е. не будет шифрования.

Скрипт Ильи работает, если у вас WSUS висит на стандартном порту. У меня же он висит на другом, нестандартном. Как поступить? А вот как (спасибо коллеге, нашел):

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false,port_number)

Где port_number – номер нестандартного порта WSUS

   Теперь получаем список всех компьютеров зарегистрированных на WSUS-сервере:

$WSUScomps = $wsus.GetComputerTargets()

   Каждый элемент массива $WSUScomps это объект, а нам нужны только имена компьютеров. Получаем FQDN имена компьютеров:

$WSUSCompNames = $WSUScomps | ForEach { $_.FullDomainName.ToUpper() }

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

   Следующий шаг – получение списка учетных записей компьютеров из Active Directory:

$ADcomps = (new-object System.DirectoryServices.DirectorySearcher([ADSI]”LDAP://ou=DEPS,dc=DOMAIN,dc=com”,"(&(objectCategory=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2))")).findAll()

   Тут конструкция !userAccountControl:1.2.840.113556.1.4.803:=2 исключает запрещенные (disabled) учетные записи компьютеров. LDAP://ou=DEPS,dc=DOMAIN,dc=RU задает корень поиска в дереве AD. objectCategory=computer – выбираем только учетные записи компьютеров.

   Из объектов учетных записей компьютеров извлекаем имена компьютеров (также формально переводим их в верхний регистр):

$ADCompNames = $ADcomps | ForEach {$_.GetDirectoryEntry().dNSHostName.ToString().ToUpper()}

   И последний шаг – получаем имена компьютеров, которые есть в Active Directory, но отсутствуют в WSUS:

$NoWSUSCompNames = $ADCompNames | Where { $WSUSCompNames -notcontains $_ }

   Теперь нам остается проанализировать полученный список и разобраться почему выявленные компьютеры не получают обновления с WSUS. Для получения списка просто выведу на экран значения

$NoWSUSCompNames

В отдельной записи представлены скрипты, с помощью которых мы “чиним” агентов WSUS на клиентских компьютерах и серверах.

WMI фильтры в групповой политике

Ни для кого не секрет, что групповые политики являются одной из самых полезных технологий Microsoft Active Directory. Если у вас компьютеров более 10 штук, то Active Directory и групповые политики помогут вам сэкономить массу сил и позволят избежать кучи ошибок.

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

Есть несколько решений этой задачи. Из новых, достаточно удобных решений – это Group Policy Preferences. У item-level targeting есть и такие параметры как операционная система, разрядность и т.д. Но, к сожалению, такой функционал есть только в разделе Preferences, а других разделов групповой политики это не касается.

Кроме того, есть такая чудная вещь, как WMI filtering. Что особенно удобно, фильтры готовятся заранее, а затем только выбираются в свойствах нужной вам политики.

Как именно это делается? Запускаю Group Policy Management, на панели навигации выбираю WMI Filters, там правая кнопка мышки и New. В поле Name набираю Windows 7 и нажимаю Add. В поле Query набираю:

select * from Win32_OperatingSystem where Version like "6.1" and ProductType = "1"

После этого нажимаю Ok, а затем Save.

Возможные значения для OperatingSystem и ProductType:

1. Windows Server 2008 R2 или Windows 7 - 6.1%
2. Windows Server 2008 или Windows Vista - 6.0%
3. Windows Server 2003 - 5.2%
4. Windows XP - 5.1%
5. Windows 2000 - 5.0%

1. Клиентские версии Windows – 1
2. Серверные версии Windows, выступающие в роли контроллера домена – 2
3. Серверные версии Windows, не выступающие в роли контроллера домена (отдельные серверы) - 3

Кстати, если есть желание отобрать Vista и Windows 7, то можно записать правило отбора так:

select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"

Есть еще одно свойство, которое может выступать в качестве параметра отбора, это Caption. Ранее я использовал именно его, но, к сожалению, у меня с новыми версиями OS, почему-то, есть проблемы с его считыванием. Но его, по прежнему можно использовать с более ранними версиями:

Select * from Win32_OperatingSystem where Caption = "Microsoft Windows XP Professional"

Возможные значения:

1. Microsoft Windows 2000 Professional
2. Microsoft Windows 2000 Server
3. Microsoft(R) Windows(R) Server 2003 Enterprise x64 Edition
4. Microsoft(R) Windows(R) Server 2003, Standard Edition
5. Microsoft(R) Windows(R) Server 2003 Standard x64 Edition
6. Microsoft® Windows Server® 2008 Standard without Hyper-V
7. Microsoft® Windows Vista™ Business
8. Microsoft Windows XP Professional

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

Установка DC на Windows Server 2008 R2 – новые сюрпризы

После того, как оказалось, что контроллер домена на Windows Server 2008 R2 не поддерживает Network Team меня поджидал и второй, куда более странный сюрприз. После установки контроллера домена и перезагрузки оказалось, что не запускаются несколько служб: Intersite Messaging, DNS Server и WINS. Если стартовать вручную, то все работало. Я, понятное дело, такое поведение списывал на то, что у меня был network team. DC я снова понизил до рядового сервера, снес team, отключил одну из сетевых и снова повысил до DC. Но проблема не исчезла! По прежнему, эти сервисы сами не стартуют!

Ситуацию спасает замена для этих сервисов замена параметра Startup Type с Automatic на Automatic (Delayed Start)

Почему всегда работавший automatic не работает, и почему они сами не смогли этого сделать – непонятно. Факт в том, что после смены этого параметра проблем пока нету.

Windows 2008 R2 DC & network Team

Сегодня получил сюрприз от Microsoft. Оказывается, Domain Controller на Windows 2008 R2 не будет работать, если сетевые карты там объединены в Network Team …

Причем, все это выглядит очень оригинально, повышаю уже существующий сервер до контроллера домена, все проходит нормально. Затем вижу, что есть ошибки и не стартовал Wins, DNS и еще пару служб. Стартую их вручную – они запускаются. Но в event log ошибки.

Запускаю

dcdiag /test:dns

от результата просто офигеваю:

Starting test: Connectivity
      Message 0x621 not found.
      Got error while checking LDAP and RPC connectivity. Please check your
      firewall settings.
      ......................... dc02 failed test Connectivity

отключаю firewall – не помогает. При этом, те сервисы, которые запускаются вручную – после перезагрузки – снова не работают, ошибки в event log по прежнему идут.

Начинаю искать причины и обнаруживаю, что единственная рекомендация – снести network team! Офигеть, т.е. теперь у меня контроллеры домена будут без горячего резерва по подключению к сети. Т.е. это позиция от Microsoft – Windows Server 2008 R2 – не поддерживает конфигурации с балансировкой сетевой нагрузки или сетевой отказоустойчивостью, если она реализована средствами драйверов сетевой карты!

В общем-то, еще с Windows Server 2003 тоже были свои интересные проблемы, но уже другого характера. Дело в том, что установка network team предполагает, что программа вначале удаляет обе сетевые, а затем добавляет, но уже три, одна из которых виртуальная. Ну а контроллер домена не может ни на секунду оставаться без сетевой :-) Т.о. сделать network team можно только до того, как сервер повышен до контроллера домена.

AD Mappings for the Active Directory Users and Computers Snap-in

Наткнулся в сети на интересный блог Ильи Сазонова.  А там чудная статья, в которой он описывает соответствия параметров оснастки Active Directory Users and Computers со свойствами AD. Мне много раз приходилось разыскивать соотношение этих параметров а скриншоты, которые он сделал - просто находка

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

 Полное описание соответствия полей и атрибутов можно найти в документации по ссылке Mappings for the Active Directory Users and Computers Snap-in.

 1.       Описание соответствия атрибутов для объекта Пользователь (User Object User Interface Mapping):

 

 

2.       Описание соответствия атрибутов для объекта  Компьютер (Computer Object User Interface Mapping):

 

 

3.       Описание соответствия атрибутов для объекта  Группа (Group Object User Interface Mapping):