• AD DS – Выбор DC для операции ввода в домен с помощью PowerShell командлета Add-Computer

    03.02.2011 Автор:Алексей Максимов
    14 725 Просмотров 3 комментария

    imageВ большой доменной инфраструктуре AD DS с большим количеством сайтов можно столкнуться с ситуацией, когда при вводе в домен новых компьютеров в сайте с единственным контроллером RODC операция ввода в домен происходит не на ближайшем RWDC а на отдалённом. Это приводит к тому, что перед тем как можно будет начать использовать в домене такой компьютер, потребуется выждать репликацию от удалённого DC до местного RODC. Избежать данной ситуации можно используя утилиту NETDOM, явным образом указывая ближайший контроллер домена, на котором мы хотим произвести процедуру джойна:

    image

    Но так как по умолчанию в клиентских системах этой утилиты нет, хочется воспользоваться каким-то подручным средством без выполнения дополнительным манипуляций. И тут нам на помощь приходит PowerShell с командлетом Add-Computer… но когда я решил воспользоваться им на практике, то выяснилось что встроенный хелп PowerShell об этом командлете (равно как и сайт TechNet Script Center) о чём-то нам не договаривает.

    Попытка выполнить ввод в домен строго по описанию не сработала, то есть при использовании командлета в виде…

    Add-Computer -DomainName 'MYDOM' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -Server 'MYDOMBestDC' -PassThru –Verbose

    … приводила к ошибке, которая фиксировалась в логе NetSetup.LOG (расположен в каталоге C:Windowsdebug) примерно в следующем виде:

    02/03/2011 11:43:51:403 ----------------------------------------------------

    02/03/2011 11:43:51:403 NetpDoDomainJoin

    02/03/2011 11:43:51:403 NetpMachineValidToJoin: 'MyWS001'

    02/03/2011 11:43:51:403    OS Version: 6.1

    02/03/2011 11:43:51:403    Build number: 7600 (7600.win7_gdr.100618-1621)

    02/03/2011 11:43:51:403    SKU: Windows 7 Профессиональная

    02/03/2011 11:43:51:403 NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0

    02/03/2011 11:43:51:403 NetpGetLsaPrimaryDomain: status: 0x0

    02/03/2011 11:43:51:403 NetpMachineValidToJoin: status: 0x0

    02/03/2011 11:43:51:403 NetpJoinDomain

    02/03/2011 11:43:51:403    Machine: MyWS001

    02/03/2011 11:43:51:403    Domain: MYDOMBestDCMYDOM

    02/03/2011 11:43:51:403    MachineAccountOU: OU=Clients,OU=Branch,DC=mydom,DC=com

    02/03/2011 11:43:51:403    Account: MYDOMadmin

    02/03/2011 11:43:51:403    Options: 0x23

    02/03/2011 11:43:51:403 NetpLoadParameters: loading registry parameters...

    02/03/2011 11:43:51:403 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2

    02/03/2011 11:43:51:403 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2

    02/03/2011 11:43:51:403 NetpLoadParameters: status: 0x2

    02/03/2011 11:43:51:403 NetpValidateName: checking to see if 'MYDOM' is valid as type 3 name

    02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid for MYDOM returned 0x54b, last error is 0x0

    02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid [ Exists ] for 'MYDOM' returned 0x54b

    02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Domain name is invalid, NetpValidateName returned: 0x54b

    02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Function exits with status of: 0x54b

    02/03/2011 11:43:53:697 NetpDoDomainJoin: status: 0x54b

    Как видно из лога, имя домена формируется как то не совсем адекватно. Немного поигравшись с использованием разных вариантов передачи параметров и проведя аналогию с использованием утилиты NETDOM, был найден работающий вариант, а именно:

    Add-Computer -DomainName 'mydom.comBestDC' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -PassThru –Verbose

    То есть вместо параметра Server можно использовать передачу имени DC в параметре DomainName. Данный способ проверен и работает как на Windows 7, так и на Windows XP SP3.

    Если у кого-то есть комментарии по поводу того, как можно ещё обуздать механизм ввода в домен для компьютеров в сайте с RODC будет интересно их здесь услышать.

    Дополнительная информация для размышления:

    Windows Server TechCenter Forums - Selection of DC during a workstation join to domain operation

    Blog Jorge 's Quest For Knowledge! - DC Locator Process in W2K, W2K3(R2) and W2K8 - PART 1

  • PowerShell - Поиск неиспользуемых учетных записей пользователей и компьютеров в домене

    23.01.2011 Автор:Алексей Максимов
    17 408 Просмотров 7 комментариев

    Для быстрого поиска в домене давно не используемых учетных записей пользователей можно использовать оснастку ‘Active Directory Users and Computers’ (dsa.msc), создав в ней запрос.

    image

    Читать далее...

  • PowerShell – Поддержание групп безопасности политики репликации паролей RODC в актуальном состоянии

    20.01.2011 Автор:Алексей Максимов
    3 879 Просмотров 4 комментария

    imageПри использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.

    Читать далее...

  • PowerShell – Поддержание группы безопасности для Password Settings objects (PSOs) в актуальном состоянии

    19.01.2011 Автор:Алексей Максимов
    3 631 Просмотров 1 Комментарий

    imageПо мотивам применения Password Settings objects (PSOs) с нацеливанием объектов PSO на доменные группы безопасности встаёт вопрос о поддержании состава этих групп в актуальном состоянии. В моём окружении все учетные записи, находящиеся в определённом OU, должны быть включены в доменную группу безопасности, к которой применяется PSO, что само по себе уже есть критерий, по которому можно автоматизировать задачу поддержания группы в актуальном состоянии с помощью PowerShell. Представляю соответствующий скрипт.

    Читать далее...

  • AD DS - Создание нескольких политик паролей Password Settings objects (PSOs) в домене Windows Server 2008/2008 R2

    17.01.2011 Автор:Алексей Максимов
    13 332 Просмотров 7 комментариев

    imageВ службах AD DS Windows Server 2008 появился новый механизм AD DS Fine-Grained Password and Account Lockout Policy, позволяющий в рамках домена создавать несколько разных политик паролей, применяемых к конкретным доменным пользователям или доменным глобальным группам безопасности. Такой механизм может быть полезен в случае, если, например, необходимо для определенной группы пользователей иметь ослабленные/усиленные политики безопасности, отличающиеся от тех, что заданы на уровне всего домена в Default Domain Policy.

    Рассмотрим сценарий создания объекта PSO в домене соответствующего следующим критериям:

    clip_image001

    clip_image002

    Для начала создадим в домене глобальную группу безопасности, в которую будут включены все пользователи, для которых необходимо переопределить политики безопасности паролей:

    clip_image003

     

    Создание объекта PSO с помощью MMC-оснастки Active Directory Services Interface editor (ADSI Edit)

    Откроем оснастку ADSIEDIT.MSC и подключимся к контексту именования по умолчанию нашего домена указав в поле Name FQDN имя нашего домена

    clip_image004

    Перейдём в контейнер DC=holding, DC=com -> CN=System -> CN=Password Settings Container

    clip_image005

    И в контекстном меню на контейнере Password Settings Container выберем создание нового объекта PSO (msDC-PasswordSettings)

    clip_image006

    Укажем имя нашего нового объекта PSO

    clip_image007

    Укажем значение атрибута msDS-PasswordSettingsPrecedence. Значение этого атрибута определяет приоритет в случае конфликта нескольких PSO, применяемых к одной и той же группе безопасности или пользователю.

    clip_image008

    Значение атрибута msDS-PasswordReversibleEncryptionEnabled определяет возможность обратимого шифрования пароля для учетных записей пользователей. Устанавливаем его в false как рекомендуемое.

    clip_image009

    Зададим значение атрибута msDS-PasswordHistoryLength определяющего количество неповторяемых паролей для учетных записей пользователей.

    clip_image010

    Значение атрибута msDS-PasswordComplexityEnabled, установленное нами в true, определяет включение требования соблюдения сложности паролей и является рекомендуемым.

    clip_image011

    Значение атрибута msDS-MinimumPasswordLength, установленное нами в 8, определяет минимальную длину паролей учетных записей пользователей.

    clip_image012

    Значение атрибута msDS-MinimumPasswordAge, установленное нами в 1:00:00:00 (1 день), определяет минимальный срок действия паролей учетных записей пользователей.

    clip_image013

    Значение атрибута msDS-MaximumPasswordAge, установленное нами в 90:00:00:00 (90 дней), определяет максимальный срок действия паролей учетных записей пользователей.

    clip_image014

    Значение атрибута msDS-LockoutThreshold, установленное нами в 5, определяет порог блокировки учетных записей пользователей (после 5 неудачных попыток авторизации срабатывает механизм блокировки учетной записи).

    clip_image015

    Значение атрибута msDS-LockoutObservationWindow, установленное нами в 0:00:30:00 (30 минут), определяет период сброса счетчика блокировок учетных записей пользователей.

    clip_image016

    Значение атрибута msDS-LockoutDuration, установленное нами в 0:00:30:00 (30 минут), определяет продолжительность блокировки заблокированных учетных записей пользователей.

    clip_image017

    На этом работа мастера создания PSO завершается.

    clip_image018

    После того как только что созданный объект PSO появляется в консоли, открываем его свойства.

    clip_image019

    Среди списка атрибутов находим атрибут msDS-PSOAppliesTo и убедившись в том что его значение не определено, открываем его редактирование.

    clip_image020

    В окне редактирования Multi-valued Distinguished Name With Security Principal Editor нажимаем Add Windows Account и выбираем соответствующую доменную глобальную группу безопасности, которую мы создали ранее.

    clip_image021

    clip_image022

    Сохраняем свойства объекта PSO и убеждаемся в том, что привязка к соответствующей группе безопасности произведена (для этого можно проверить значение атрибута msDS-PSOApplied в свойствах самой группы безопасности).

    clip_image023

    Теперь на всех пользователей, включенных в эту группу безопасности, будут действовать параметры, заданные в нашем объекте PSO независимо от текущих настроек в Default Domain Policy.

    Создание объекта PSO с посмощью CLI-утилиты LDIF Directory Exchange (LDIFDE)

    Помимо создания объекта PSO через оснастку ADSIEDIT.MSC, мы можем создать его с помощью утилиты командной строки LDIFDE. В некоторых сценариях это может быть более быстро и удобно. Для этого нам предварительно нужно подготовить файл в формате *.LDF (LDAP Data Interchange Format) следующего содержания:

    dn: CN=KOM-SRV-PSO-Users,CN=Password Settings Container,CN=System,DC=holding,DC=com
    changetype: add
    objectClass: msDS-PasswordSettings
    msDS-MaximumPasswordAge: -77760000000000
    msDS-MinimumPasswordAge:-864000000000
    msDS-MinimumPasswordLength:8
    msDS-PasswordHistoryLength:5
    msDS-PasswordComplexityEnabled:TRUE
    msDS-PasswordReversibleEncryptionEnabled:FALSE
    msDS-LockoutObservationWindow:-18000000000
    msDS-LockoutDuration:-18000000000
    msDS-LockoutThreshold:5
    msDS-PasswordSettingsPrecedence:1
    msDS-PSOAppliesTo:CN=KOM-SRV-PSO-Users,CN=Users,DC=holding,DC=com

    Обратите внимание на то, что значения атрибутов связанных со временем указываются в формате I8 (интервалы по -100 наносекунд). Преобразование в данный формат производится по следующей схеме

    Единица времени

    Множитель

    1 минута

    -60*(10^7) = - 600000000

    1 час

    -60*60* (10^7) = -36000000000

    1 день

    -24*60*60*(10^7) = -864000000000

    То есть, например, чтобы установить значение атрибута msDS-LockoutDuration равным 30 минутам, для получения значения в формате I8 нужно умножить 30 на -600000000 (в этом примере значение равно -18000000000). Более подробную информацию по этому поводу можно получить в приложении Appendix B: PSO Attribute Constraints

    После того как мы подготовили LDF файл, произведём импорт указанной в нём информации командой:

    LDIFDE -i -f NewPSO.ldf

    clip_image024

    Более подробную информацию об использовании утилиты LDIFDE можно найти в статье KB237677 - Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory

    Дополнительные источники информации:

    Windows Server TechCenter - AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

    TechDays.ru - Active Directory: политика паролей

  • PowerShell – Поиск пользователей домена с устаревшими паролями

    15.12.2010 Автор:Алексей Максимов
    5 740 Просмотров 1 Комментарий

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

    Для этой задачи как отправную точку я использовал PS-скрипт User Counting and Password Age Checking с блога Steve Tibbetts, несколько переработав его. В частности была убрана ненужная мне в данной ситуации зависимость от командлетов Quest, добавлена возможность управления выводом отключенных учетных записей, изменён вывод  в удобоваримый вид с сортировкой по дате установки пароля, добавлена возможность установки признака смены пароля для учетных записей с «прокисшими» паролями. Вот что получилось:

    # Блок переменных

    # $LDAPPath - ADSI путь к контейнеру с доменными учетными записями пользователей (в формате LDAP://distinguishedName)

    # $CountDisabledUsers - Признак вывода сведений об отключенных учетных записях (1 или 0)

    # $PWAgeDaysLimit - Максимально возможный период действия пароля в днях

    # $PWDMustChange - Признак необходимости форсированной установки атрибута требующего смену пароля (1 или 0)

    #

    $LDAPPath = 'LDAP://OU=Domain Users,DC=mydom,DC=com'

    $CountDisabledUsers = 0

    $PWAgeDaysLimit = 90

    $PWDMustChange = 0

    #

    # Блок поиска

    #

    $RootDomainOU = [ADSI]$LDAPPath

    $Searcher = New-Object System.DirectoryServices.DirectorySearcher($RootDomainOU)

    $Filter = '(objectCategory=person)(objectClass=user)'

    If ($CountDisabledUsers -eq 0) { $Filter = $Filter + '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' }

    $Filter = '(&' + $Filter + ')'

    $Searcher.Filter = $Filter

    $Searcher.PageSize = 5000

    [Void]$Searcher.PropertiesToLoad.Add("cn")

    [Void]$Searcher.PropertiesToLoad.Add("sAMAccountName")

    [Void]$Searcher.PropertiesToLoad.Add("pwdLastSet")

    $Users = $Searcher.findall()

    #

    # Блок основного вывода

    #

    $PWDays = (Get-Date).AddDays(-$PWAgeDaysLimit)

    $UsersOldPWD = $Users | Where-Object {[datetime]::FromFileTime(($_.properties.pwdlastset)[0]) -le $PWDays}

    $UsersOldPWD | Select `

    @{label='User Full Name';expression={$_.properties.cn}},`

    @{label='sAMAccountName';expression={$_.properties.samaccountname}},`

    @{label='Last Password Set';expression={[datetime]::FromFileTime(($_.properties.pwdlastset)[0])}}`

    | Sort -Property 'Last Password Set'`

    | Format-Table –AutoSize

     

    Write-Host '---------------------------------------------------'

    write-host 'Total user accounts in OU: ' $Users.Count

    write-host 'Users with passwords not changed in' $PWAgeDaysLimit 'days: ' $UsersOldPWD.Count

    Write-Host '---------------------------------------------------'

    #

    # Блок смены атрибута учетных записей

    #

    If ($PWDMustChange -eq 1) {

    Write-Host 'Set for users with old password - Change PWD at next Logon'

    If ($UsersOldPWD.Count -eq $null)

    { Write-Host 'Ops...No account needs to be changed.'}

    Else

    {

                ForEach ($User in $UsersOldPWD)

                {

                Write-Host 'Modify user:' $User.Properties.cn

                $Account=[ADSI]$User.Path

                $Account.put("pwdLastSet", 0)

                $Account.setinfo()

                }    

    }

    Write-Host '---------------------------------------------------'

    }

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

    image

  • Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

    19.08.2010 Автор:Алексей Максимов
    13 416 Просмотров 3 комментария

    На этапе внедрения RODC на базе Windows Server 2008 R2 была замечена проблема связанная с увеличением времени входа в систему на клиентских ПК. Проблема была выявлена на всех площадках где для авторизации в домене и применения групповых политик клиенты использовали RODC. После ввода учетных данных процесс входа в систему на несколько минут «замерзал» на этапе «Applying Group Policy Drive Maps policy». Разумеется, подозрение сразу пало на обработку Group Policy Preferences (GPP) в части обработки подключения сетевых дисков, так как в одной из групповых политик, применяемых в части User Configuration у меня было n-ное количество таких подключаемых дисков через механизмы GPP с использованием для каждого подключения нацеливания (Item-level targeting)

    clip_image001

    Для подключения разных дисков использовались три вида нацеливания: по членству пользователя в доменной группе, по NetBios имени компьютера и по вхождению пользователя в определенный OU в домене.
    Для того чтобы выяснить то, обработка какого именно подключения являлась корнем проблемы пришлось прибегнуть к включению трейсов для обработки параметров GPP. Для этого пришлось в групповой политике применяемой к испытуемому клиентскому компьютеру в разделе Computer Configuration активировать и настроить параметр Policies > Administrative Templates > System > Group Policy >Logging and tracing > Drive Maps Policy Processing.

    clip_image002

    По умолчанию ведение трейсов выключено и параметры для определения размещения лог файлов ссылаются на каталог %COMMONAPPDATA%GroupPolicyPreferenceTrace.

    Как ни странно, я не обнаружил в своих испытуемых системах Windows 7/Windows Server 2008 R2 переменной окружения %COMMONAPPDATA% и поэтому изменил путь для хранения логов с использованием существующей переменной окружения - %programDATA%. В данном случае меня интересовал параметр User trace и его значение получилось у меня таким: %programDATA%GroupPolicyPreferenceTraceUser.log

    Уровень логирования пришлось использовать максимальный, чтобы получить весь доступный объем информации о происходящем в процессе обработки GPP. И на всякий случай увеличено было значение максимального размера лог-файла.

    clip_image003

    После того как новая политика, включающая логирование применения GPP была применена на клиенте с помощью команды gpupdate, был сделано logoff/logon чтобы спровацировать обработку GPP в части подключения сетевых дисков пользователю. Теперь на испытуемом клиентском компьютере в указанном каталоге (C:ProgramDataGroupPolicyPreferenceTrace) был обнаружен файл трассировки User.log

    После изучения лога стало понятно, что обработка GPP всех сетевых дисков проходила «на одном дыхании» и заметный провал во времени обработки (более 1 минуты) происходил именно на одном определенном диске - “H:”

    clip_image004

    Оказалось что это единственный сетевой диск, в котором для нацеливания использовался признак вхождения пользователя в определенный OU в домене. Было принято решение для пробы изменить нацеливание для данного сетевого диска по признаку членства пользователя в доменной группе… Каково же было моё удивление когда время входа в систему сократилось в разы :) Даже покажу лог обработки после внесённых изменений, чтобы не быть голословным

    clip_image005

    Причем повторюсь, - проблема наблюдалась только на клиентах, которые сидели в сайте с RODC, на клиентах же имеющих в сайте полноценные DC такой «бяки» замечено не было.
    Исходя из этой истории, напрашивается вывод о том, что к применению Item-Level targeting нужно подходить с аккуратностью и предварительной обкаткой разных вариантов, тем более GPP предоставляет нам хороший выбор таких вариантов.

  • Проблема репликации групповых политик (Event ID 13568 Source NtFrs)

    07.04.2010 Автор:Алексей Максимов
    16 249 Просмотров 7 комментариев

    imageНарвался на ситуацию когда в домене Windows Server 2008 на одном из контроллеров домена перестали обновляться групповые политики после некорректного выключения ОС. При этом с логе File Replication Service периодически фиксировались события с кодом 13568

    image

    Читать далее...

  • Интересный параметр GPO: Удалить команду "Выполнить" из меню "Пуск"

    16.02.2010 Автор:Алексей Максимов
    4 322 Просмотров 1 Комментарий

    В процесс настройки ужесточенной групповой политики для применения на терминальных серверах наткнулся на интересное поведение одного из параметров GPO.

    Путь в GPO:
    Конфигурация пользователя/Административные шаблоны/Меню "Пуск" и панель задач

    Параметр:
    Удалить команду "Выполнить" из меню "Пуск"

    image 

    Cуть в том, что при включении данного параметра, как выяснилось, в системе перестает корректно работать переход по UNC пути не только в Explorer и IE но и во всех других приложениях, например в той же 1С…т.е. переход с диска на диск в GUI путём клацанья мышкой как бы работает, но например из командного интерпретатора Cmd.exe при попытке подключения сетевого диска утилитой net – возникают ошибки по типу ограничения доступа…что само по себе не очень логично, и мне пришлось убить почти час времени чтобы среди кучи выставленных параметров GPO на терминальном сервере найти виновника странного поведения системы…
    В описании к данному параметру GPO конечно есть какая-то далеко неоднозначная фраза что-то типа «перестает работать интерфейс»…но что она значит на деле приходиться узнавать путем хождения по граблям …

Предыдущая страница