• Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Установка и настройка издающего центра сертификации

     

    Степан Москалев

    Леонид Шапиро

     

    В этой части нашего цикла мы рассмотрим развертывание издающего удостоверяющего центра в двухуровневой иерархии. В отличие от корневого, этот сервер должен быть постоянно доступен клиентам, причем здесь мы имеем в виду не только возможность получения сертификатов, но и что важней, их отзыва при компрометации. Точно также, как и с корневым УЦ, перед установкой понадобится подготовить файл capolicy.inf [1] и разместить его правильном месте расположения [2].

     

    Пример структуры capolicy.inf может выглядеть следующим образом:

    [Version]

    Signature=”$Windows NT$”

    [PolicyStatementExtension]

    Policies=InternalPolicy

    [InternalPolicy]

    OID=1.2.3.4.1455.67.89.5

    URL=http://pki.nwtraders.msft/PKI/cps.txt

    [certsrv_server]

    RenewalKeyLength=2048

    RenewalValidityPeriodUnits=5

    RenewalValidityPeriod=Years

    CRLPeriodUnits=1

    CRLPeriod=Weeks

    CRLOverlapUnits=1

    CRLOverlapPeriod=Days

    CRLDeltaPeriodUnits=1

    CRLDeltaPeriod=Days

    LoadDefaultTemplates=0

    AlternateSignatureAlgorithm=1

     

    Познакомиться с синтаксисом файла capolicy.inf можно в первой статье этого цикла [2].

    На следующем шаге можно переходить к установке самого сервиса Active Directory Certificate Services. Установка может быть выполнена как с помощью графического интерфейса, так и с помощью команд PowerShell [3]. Второй вариант обычно проще и занимает меньше времени.

    Install-AdcsCertificationAuthority –CAType EnterpriseSubordinateCA –CACommonName “IssuingCA01” –KeyLength 2048 –HashAlgorithmName SHA256 –CryptoProviderName “RSA#Microsoft Software Key Storage Provider”

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

    С точки зрения безопасности, следует использовать внешний защищенный носитель информации для обмена и не подключать корневой центр сертификации к сети. Непосредственно для запроса сертификата можно воспользоваться утилитой certreq [4] уже на самом корневом центре сертификации.

    Certreq -submit C:\test\ICA01.Nwtraders.msft_IssuingCA01.req, где test папка, в которой был сохранен файл запроса.

    Далее запрос одобряется администратором и выдается сертификат для подчиненного центра сертификации.

    certutil -resubmit 2

    certreq –Retrieve 2 C:\test\ICA01.crt

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

    certutil -installCert C:\test\ICA01.crt [5]

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

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

    certutil –addstore –f root C:\test\RootCA_ROOTCA.crt

    Второе – обеспечить доступность CRL корневого центра и его сертификата, хотя бы по одному пути указанному сертификате.

    После этого службу надо запустить

    Start-Service CertSvc

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

    Поскольку мы не еще проводили публикацию сертификата корневого УЦ и его списка отзыва в службе каталога Active Directory Domain Services, это можно будет сделать теперь, для чего выполняются команды:

    certutil –dspublish –f C:\test\ROOTCA_ROOTCA.crt – публикация сертификата;

    certutil –dspublish –f C:\test\ROOTCA.crl ROOTCA – публикация списка отзыва сертификатов;

    ROOTCA в данной команде это имя центра сертификации.

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

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

    Удалите настройки CrlDistributionPoint, заданные по-умолчанию.

    Значения, которые предлагает система не предусматривают использование собственного центра распространения на внешнем WEB сервере, да и порядок публикации списка отзыва сертификатов будет не очень удачным, поскольку ссылка ведет не сам сервер сертификатов, что нельзя считать удачным решением.

    Разумное решение – использование именно внешнего WEB сервера клиентами для получения сертификатов и списков отзыва.

    HTTP путь рекомендуется ставить первым, поскольку это дает возможность клиентам, не имеющим доступ к службе каталога, выполнить проверку списка отзыва сертификатов.

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

    Удаление путей можно выполнить с помощью PowerShell

    $crllist = Get-CACrlDistributionPoint

    foreach ($crl in $crllist) { Remove-CACrlDistributionPoint $crl.uri -Force }

     

    Для добавления новых путей публикации CrlDistributionPoint выполните следующие команды:

    Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force

    Add-CACRLDistributionPoint -Uri http://pki.nwtraders.msft/PKI/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl -Force [6]

    Add-CACRLDistributionPoint -Uri “ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10” -PublishToServer -AddToCrlCdp -AddToFreshestCrl -AddToCertificateCDP -PublishDeltaToServer -Force [6]

    Если с основными компонентами приведенных команд все понятно, то ряд параметров под знаком % могут вызывать вопросы. На самом деле здесь нет ничего сложного и познакомиться с тем что обозначает какая из переменных можно по приведенной ссылке [6]

     

    Для обеспечения автоматической публикации CRL добавьте:

    Add-CACRLDistributionPoint -Uri \\pki.nwtraders.msft\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force

    По сравнению с корневым центром сертификатов добавляется переменная %9 (<DeltaCRLAllowed>) так как в ROOTCA список DeltaCRL отсутствует. [7]

     

    Тоже самое следует проделать для AIA путей, то есть надо удалите настройки CAAuthorityInformationAccess, заданные по-умолчанию:

    $aialist = Get-CAAuthorityInformationAccess

    foreach ($aia in $aialist) { Remove-CAAuthorityInformationAccess $aia.uri -Force }

    Добавить локальный путь при помощи команды PowerShell не получится, для этого придется воспользоваться графическим интерфейсом или командой certutil.

    certutil -setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n1:\\pki.nwtraders.msft\pki\%3%4.crt”

    Добавить пути публикации http и ldap при помощи команд PowerShell.

    Add-CAAuthorityInformationAccess http://pki.nwtraders.msft/PKI/%3%4.crt -AddToCertificateAia -Force

    Add-CAAuthorityInformationAccess “ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11” -AddToCertificateAia -Force

     

    Для настройки срока действия сертификата и периодичности публикации CRL используется команда certutil, мы подробно рассмотрели постустановочную настройку на примере корневого центра сертификации в предыдущей статье [7].

    certutil -setreg CA\ValidityPeriodUnits 5

    certutil -setreg CA\ValidityPeriod “Years”

    certutil -setreg CA\CRLPeriodUnits 1

    certutil -setreg CA\CRLPeriod “Weeks”

    certutil -setreg CA\CRLOverlapUnits 1

    certutil -setreg CA\CRLOverlapPeriod “Days”

    certutil -setreg CA\CRLDeltaPeriodUnits 1

    certutil -setreg CA\CRLDeltaPeriod “Days”

     

    Для настройки параметров аудита выполните следующую команду:

    certutil -setreg CA\AuditFilter 127

    Перезагрузите службу сертификатов:

    Restart-Service CertSvc

     

    Опубликуйте списки CRL:

    certutil -CRL

    Далее нужно скопировать сертификат издающего центра сертификации центр распространения (Distribution Point).

    Установка и настройка издающего центра сертификации на этом завершена, остается проверить все ли прошло успешно. Для этого используется несколько инструментов.

    Графическая консоль сервера сертификатов позволит удостовериться в том, что пути к спискам отзыва и самим сертификатам УЦ изменены, параметры аудита заданы. Также следует удостовериться что клиенты получают доступ по указанным путям и могут загрузить сертификаты и списки отзыва. В нашем примере это проверка HTTP пути http://pki.nwtraders.msft/PKI/.

     

    Дополнительно можно обратиться к реестру в разделе

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\IssuingCA01\

    Где IssuingCA01 – это введенное нами при установке имя УЦ. и посмотреть значение ключей реестра:

     

    CRLPublicationURLs

    CACertPublicationURLs

    ValidityPeriodUnits

    ValidityPeriod

    CRLPeriodUnits

    CRLPeriod

    CRLOverlapUnits

    CRLOverlapPeriod

    CRLDeltaPeriodUnits

    CRLDeltaPeriod

    AuditFilter

    DSConfigDN

    DSDomainDN

     

    Наконец, воспользоваться консолью EnterprisePKI, запустив из командной строки утилиту pkiview.msc, в столбце «Status» для всех путей должно быть статус «OK».

     

    Кроме этого, можно воспользоваться ADSI Edit для проверки информации в службе каталога.

     

    Перейдите по пути CN=Public Key Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft.

    AIA – Содержит сертификаты центров сертификации, которые клиенты могут извлекать при проверке цепочки сертификатов.

    CDP – Содержит CRL (базовый и дельта), которые опубликованы в AD.

    Certificate Templates – cодержит шаблоны сертификатов.

    Certification Authorities – cодержит сертификаты корневых центров сертификации (Root CA для нашего случая).

    Enrollment Services – cодержит сертификаты центров сертификации, которые могут выдавать сертификаты в данной службе каталогов.

    KRA – Содержит сертификаты (key recovery agents) агентов восстановления.

    OID – Содержит информацию о OID используемых службой сертификации (Certification Authorities).

     

    Только теперь можно говорить о том, что издающий центр сертификации установлен и практически готов к работе.

    В следующей статье мы поговорим о работе с центрами распространения (Distribution Points)

    Продолжение следует…

     

    Литература

    [1] Prepare the CAPolicy.inf File – https://technet.microsoft.com/en-us/
    library/jj125373(v=ws.11).aspx.

    [2] Шапиро Л. Внедрение инфраструктуры открытых ключей
    на основе Windows Server 2016. Часть 1. Предварительный
    этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27.
    URL: http://samag.ru/archive/article/3576.

    [3] Утилита Certreq – https://docs.microsoft.com/en-us/windowsserver/
    administration/windows-commands/certreq_1.

    [4] PowerShell Documentation – https://docs.microsoft.com/en-us/
    powershell/.

    [5] Certutil – https://docs.microsoft.com/en-us/windows-server/
    administration/windows-commands/certutil.

    [6] Certification Authority Guidance – https://docs.microsoft.com/
    en-us/previous-versions/windows/it-pro/windows-server-2012-R2-
    and-2012/hh831574(v=ws.11).

    [7] PKI Design Considerations: Certificate Revocation
    and CRL Publishing Strategies – https://blogs.technet.
    microsoft.com/xdot509/2012/11/26/pki-design-considerationscertificate-
    revocation-and-crl-publishing-strategies/.

    [8] Москалев С., Шапиро Л. Инфраструктура открытых ключей
    в Windows Server 2016. Часть 2. RootCA. //«Системный адми-
    нистратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/
    article/3605.http://samag.ru/archive/article/3605

    • Установка и настройка корневого центра сертификации (RootCA)

      Степан Москалев

      Леонид Шапиро

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

      • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016

        Внедрение собственной инфраструктуры открытых ключей часто становится одной их задач, которую приходится решать ИТ отделам предприятия. Причины этого вполне объяснимы: тут и вопросы безопасной аутентификации, защиты передаваемых и хранимых данных, потребность в использовании электронной цифровой подписи, и другое. Далеко не всегда эти задачи могут быть решены средствами внешних поставщиков, несмотря на очевидную тенденцию развития облачных решений.

        • Доверие в сфере информационных технологий

          • Рубрика: Security,Windows
          • Автор: Леонид Шапиро
          • Дата: Friday 09 Mar 2018

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

          • Публикация виртуальных машин в UAG

            Microsoft Forefront Unified Access Gateway (UAG) 2010 – очень интересное средство для публикации внутренних ресурсов для внешних (да и внутренних тоже) пользователей. Но вот есть в нем очень серьезный недостаток – нет никаких средств автоматизации процесса управления. Точнее так, средства автоматизации есть, в виде COM-интерфесов, но они недокументированы и понять, как они работают и какие параметры принимают, мне так и не удалось.
            • Microsoft DirectAccess 2012: DirectAccess и Windows 8

              ed31_earth_in_my_room

              В прошлой статье я постарался в понятной форме рассказать о технологии DirectAccess, о ее плюсах и минусах. Теперь, как и обещал, расскажу о том, каким образом настроить сервер DirectAccess в базовой конфигурации для работы только с клиентами Windows 8. Что значит в базовой конфигурации? Это когда у вас есть Windows Server 2012 на котором будет поднята роль для DirectAccess и  клиенты (с операционной системой Windows 8 Enterprise) имеющие  прямое подключение к интернету . В базовой конфигурации не будет использоваться инфраструктура открытых ключей (PKI) и  используется только одна входная точка (сервер DirectAccess), подключенная в одном сайте Active Directory. Так же в базовую конфигурацию не могут входить дополнительные опции, такие как двухфакторная аутентификация (OTP Auth), проверка доступа к сети (NAP). Ну и самое важное – в ней не могут использоваться клиенты Windows 7.

              • Microsoft DirectAccess 2012: Введение

                ed31_earth_in_my_room

                Время не стоит на месте, и мы, что бы не отставать от современного ритма, должны быть активными и мобильными. Для организаций любого уровня становится все  более важным иметь простой и  безопасный способ подключения удаленных и мобильных клиентов к внутренней сети предприятия. Одной из распространенных технологий удаленного доступа  является  VPN, хотя можно было обойтись и без него, используя  прямые подключения средствами RDP, Radmin, Ammyy и тому подобных вещей. Теперь в списке появляется значимая альтернатива – Microsoft DirectAccess 2012. Число 2012 говорит нам о том, что это сервис включенный в новую редакция сервера Windows Server 2012. Это важно, потому что DirectAccess уже был реализован в 2008 R2, но с кучей нюансов и серьезных требований к инфраструктуре предприятия, где внедряли DirectAccess 2008 R2. Именно поэтому  я специально сказал, что только теперь появилась альтернатива для удаленного подключения клиентов, и сейчас объясню почему.

              • Главная Windows, Без рубрики, Новое Windows Server 2012
                • Windows Server 2012: новые возможности (Часть1)

                  До последнего момента не доходили руки пощупать Windows Server 2012, но все же нужда заставила и пришлось развернуть тестовый стенд. Ощущения не однозначные, но скажу честно, появилось множество возможностей, значительно упрощающих жизнь. В рамках небольшой заметки хотелось бы познакомить читателей с основными изменениями операционной системы, которые бросились в глаза. Можно не пугаться, революции не произошло, домены на месте,  все изменения больше качественные, хотя есть и совсем новые технологии, но обо всем по порядку.

                • Главная Windows, Без рубрики, Новое Active Directory, PowerShell, Windows 2008 R2
                  • Типовые задачи администрирования AD с использованием PowerShell

                    monolisa-ascii_thumbВсем администраторам Active Directory периодически приходится сталкиваться с рутинными задачами, которые хотелось бы так или иначе автоматизировать. Как правило, это делается с использованием скриптов на наиболее известных языках программирования: VBScript, Jscript, PowerShell. Последний я считаю наиболее удобным. Благодаря некоторым из его особенностей те же процедуры, которые занимают в VBScript десяток строк и требуют понимания работы WMI, LDAP и еще многих китайских слов – в PowerShell занимает всего пять строк и требуют всего лишь знания программирования на уровне школьных уроков информатики. В настоящей статье мы рассмотрим типовые задачи администрирования Active Directory, и их автоматизацию с помощью PowerShell.

                    P.S. Статья рассчитана на полных, или почти полных «чайников», пару раз видевших или где-то слышавших о PowerShell. На звание Терминатора не претендую, по сему просьба ногами не пинать.

                     

                    Общие положения

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

                    В первую очередь, необходимо заметить, что для того, чтобы все нормально работало – необходимо иметь хотя бы один контроллер домена Windows Server 2008 R2 с установленной компонентой ActiveDirectory Web Services. Увы и ах, Windows Server 2003 уходит на свалку истории. Для работы с модулем ad_powershell необходимо установить Remote Server Administration Tools, его так же можно установить на рабочем компьютере и запускать скрипты оттуда. Разумеется, ОС на компьютере должна быть не ниже Windows 7. На контроллерах домена Windows Server 2008 R2 необходимые компоненты уже установлены.
                    Перед тем, как выполнять скрипты – необходимо установить политику выполнения скриптов. По умолчанию, в целях безопасности включена политика Restricted, что означает, что на данном компьютере вообще запрещен запуск любых PowerShell-скриптов. О том, какие еще бывают политики выполнения – можно почитать в мануале:

                    Get-Help Set-ExecutionPolicy –Detailed

                    В нашем случае я рекомендую установить политику RemoteSigned, что позволит запускать любые собственноручно написанные скрипты, при этом запуск скриптов, скачанных из Интернета будет возможен только при наличии цифровой подписи с доверенным сертификатом. Запустите оболочку PowerShell с правами администратора (Run as Administrator) и выполните команду

                    Set-ExecutionPolicy RemoteSigned

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

                    Теперь можно проверить работу скриптов – написать простейший скрипт «Hello World!». Я предпочитаю пользоваться PowerShell ISE, хотя можно писать и в простейшем Notepad’е. PowerShell ISE – удобная среда програмирования для PowerShell с возможностью отладки. Входит в состав ОС Wondows 7 и 2008 R2. Вобщем, рекомендую.

                    image

                    Теперь переходим непосредственно к автоматизации. Для того, чтобы создать объекты в Active Directory, или изменить какие-либо свойства, нам необходим список объектов со всеми необходимыми параметрами. Например, список пользователей может содержать следующие парамеры: Имя, Фамилия, Логин, Пароль. Проще всего для этого использовать CSV-файл. CSV – это текстовый файл, содержащий список объектов (например – пользователей), с разделением параметров каким-либо символом (как правило, это запятая «,», хотя может быть и точка с запятой, знак табуляции и т.д.). Каждый объект обозначается одной строчкой. Так же, первая строчка может содержать список параметров.

                     

                    Пример:

                     

                    Name;Surname;Login;Password

                    Ivan,Ivanov;i.ivanov;p@ssw0rd1

                    Petr,Petrov;p.petrov;p@ssw0rd2

                    Sidor;Sidorov;s.sidorov;p@ssw0rd3

                     

                    Чтобы получить список объектов из CSV-файла, используется командлет Import-CSV:

                    $Users = Import-CSV “c:\temp\users.csv”

                    Такой файл можно создать и в блокноте, но проще всего будет использовать Microsoft Excel. В Excel необходимо при сохранении файла выбрать формат CSV. Интересно, что Excel при сохранении в формат CSV в качестве разделителя использует знак “;”, хотя вроде бы написано «CSV (разделители – запятые)». PowerShell же по умолчанию считает, что в качестве разделителя используется запятая («,»). Чтобы наш скрипт работал корректно – необходимо либо заменить в CSV-файле все точки с запятой на запятые (используя автозамену в блокноте) либо же, что на мой взгляд правильнее – указать в скрипте использовать точку с запятой в качестве разделителя:

                    $Users = Import-CSV “c:\temp\users.csv” –Delimiter “;”

                    Чтобы проверить, как прошел импорт – можно посмотреть, что хранится в переменной $Users.

                    image

                    Как видим, в переменной $Users теперь хранится массив объектов с параметрами Name, Surname, Login, Password. Эти параметры можно использовать для создания учетных записей пользователей в AD.

                    Прежде чем приступить к работе с Active Directory, необходимо произвести импорт соответствующего модуля в PowerShell. Только после этого появятся команды для работы с AD:

                    Import-Module ActiveDirectory

                    Эту строку можно (и даже нужно) вставлять в начало всех скриптов – чтобы не вводить эту команду вручную.

                     

                    Создание учетных записей пользователей

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

                    Для нашего примера, в качестве списка пользователей будем брать CSV-файл со следующими полями:

                     

                    • Name – имя пользователя
                    • Surname – фамилия пользователя
                    • Password – пароль
                    • OU – организационное подразделение, где будет находиться пользователь (вида Contoso_Users/Fin/Accounting)

                     

                    Вначале нам нужно импортировать пользователей из списка:

                    $Users = Import-CSV $1 –Delimiter “;”

                    Параметр $1 означает, что в качестве пути к CSV-файлу будет использоваться первый по счету параметр командной строки. Запускаться скрипт будет следующим образом:

                    PS C:\Users\admin > Add_Users.ps1 c:\temp\users.csv

                    Далее нам нужно пройтись по всему массиву пользователей из списка:

                    Foreach($CurrentUser in $Users) {

                    Знак открытой фигурной скобки означает начало цикла. Этот цикл проходит по всем объектам списка, и прискаивает текущий объект переменной $CurrentUser.

                    Затем, для упрощения – присвоим значения соответствующих полей отдельным переменным:

                     

                    $Name = $CurrentUser.Name

                    $Surname = $CurrentUser.Surname

                    $Password = $CurrentUser.Password

                    $OU = $CurrentUser.OU

                     

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

                    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

                    Так же, OU нам нужно перевести в формат, соответствующий стандарту LDAP (для примера выше: “OU=Accounting,OU= Fin,OU= Contoso_Users,DC=contoso,DC=com”).

                     

                    Для этого вначале разделим строку $OU на отдельные составляющие:

                    $OUTmp = $OU –Split “/”

                     

                    В результате переменная $OUTmp будет содержать массив из всех элементов пути:

                    PS C:\Users\admin> $OUTmp

                    Contoso_Users

                    Fin

                    Accounting

                     

                    Далее, используя командлет Foreach-Object, получим из нашего массива первую часть LDAP-пути:

                     

                    $Path = “” #незабудьте проинициализировать переменную!

                    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

                     

                    В переменной $Path появляется первая часть LDAP-пути:

                     

                    PS C:\Users\admin> $Path

                    OU=Accounting,OU=Fin,OU=Contoso_Users,

                     

                    Теперь нам нужно получить полный путь, добавив к пути домен:

                     

                    $Path += “DC=contoso,DC=com”

                    Получили полный LDAP-путь:

                    PS C:\Users\admin> $Path

                    OU=Accounting,OU=Fin,OU=Contoso_Users,DC=contoso,DC=com

                     

                    Теперь сформируем дисплейное имя пользователя, его логин, User Principal Name.

                     

                    $Login = $Name[0] + “.” + $Surname #логин формируется из первой буквы имени и фамилии, например: i.ivanov

                    $Displayname = $Name + “ “ + $Surname #Дисплейное имя: Ivan Ivanov

                    $UserPrincipalName = $Login + “@contoso.com

                     

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

                     

                    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

                    Здесь, в принципе, все параметры понятны. Параметр -ChangePasswordAtLogon 1 означает, что пользователю будет предложено сменить пароль сразу после логина.

                    По умолчанию в PowerShell, в отличие от стандартного визарда в оснастке ActiveDirectory Users And Computers учетные записи только что созданных пользователей будут отключены (Disabled). Поэтому сразу после создания учетные записи нужно включить:

                    Enable-ADAccount $Login

                    Теперь нужно закрыть цикл знаком «}». Можно сохранять скрипт и пробовать.

                    Готовый скрипт будет выглядеть следующим образом:

                     

                    Import-Module ActiveDirectory

                    $Users = Import-CSV $1 –Delimiter “;”

                    Foreach($CurrentUser in $Users) {

                    $Name = $CurrentUser.Name

                    $Surname = $CurrentUser.Surname

                    $Password = $CurrentUser.Password

                    $OU = $CurrentUser.OU

                    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

                    $OUTmp = $OU –Split “/”

                    $Path = “” #незабудьте проинициализировать переменную!

                    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

                    $Path += “DC=contoso,DC=com”

                    $Login = $Name[0] + “.” + $Surname

                    $Displayname = $Name + “ “ + $Surname #в кавычках – пробел!

                    $UserPrincipalName = $Login + “@contoso.com”

                    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

                    Enable-ADAccount $Login

                    }

                     

                    Создание учетных записей компьютеров

                    Как известно, для работы с Active Directory перво-наперво необходимо вводить компьютеры в домен. Сделать это можно двумя способами:

                    · Мышкой – самый известный способ, через «Свойства» «Моего компьютера». Легко и просто.

                    · Командой netdom join. Тоже несложно, и можно использовать в скриптах.

                    У первого способа есть существенный недостаток: учетные записи компьютеров создаются в дефолтном OU Computers. В организациях же, как правило имеются разные OU для разных типов компьютеров (сервер, десктоп, ноутбук), а так же отдельные OU для разных отделов/департаментов/и т.д., с различными групповыми политиками, действующими для разных OU. Поэтому после ввода компьютеров в домен необходимо переносить учетные записи компьютеров вручную в соответствующий OU, а затем перезагружать компьютер еще раз, чтобы на нем применились все необходимые политики. При использовании команды netdom можно указать нужное OU, но набирать все это с клавиатуры – та еще задачка, особенно – когда компьютеров много, и особенно, что часто бывают – задачку эту поручают простым эникейщикам. Где-то в какой-то букве обязательно ошибется.

                    Самый лучший выход из этой ситуации – создать учетные записи компьютеров заранее, в соответствующих OU. Тогда компьютер сразу после ввода в домен и перезагрузки применит все соответствующие политики.

                    Разумеется, учетные записи компьютеров, как и пользователей, можно создавать и вручную. Но, поскольку мы – админы, а не эникейщики – будем использовать PowerShell.

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

                    ComputerName;OU

                    Server1;Cnotoso_Computers/Servers

                    Server2;Cnotoso_Computers/Servers

                    Desktop1;Cnotoso_Computers/Desktops

                    Desktop2;Cnotoso_Computers/Desktops

                    Desktop3;Cnotoso_Computers/Desktops

                    Laptop1;Cnotoso_Computers/Laptops

                     

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

                     

                    Import-Module ActiveDirectory

                    $Computers = Import-CSV $1 –Delimiter “;”

                    Foreach($CurrentComputer in $Computers) {

                    $ComputerName = $CurrentComputer.ComputerName

                    $OU = $CurrentComputer.OU

                    $OUTmp = $OU –Split “/”

                    $Path = “” #незабудьте проинициализировать переменную!

                    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

                    $Path += “DC=contoso,DC=com”

                    New-ADComputer –Name $ComputerName –Path $Path

                    }

                     

                    Массовый сброс паролей

                    Иногда бывает необходимо массово сбросить пароли у множества пользователей.

                    Структура CSV-файла:

                    • Login – логин пользователя
                    • NewPassword – новый пароль

                    Import-Module ActiveDirectory

                    $Users = Import-CSV $1 –Delimiter “;”

                    Foreach($CurrentUser in $Users) {

                    $Login = $CurrentUser.Login

                    $NewPassword = $CurrentUser.NewPassword

                    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

                    Set-ADAccountPassword –Identity $Login –Reset –NewPassword $SecurePwd

                    }

                     

                    Массовое изменение параметров

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

                     

                    • Имя
                    • Фамилия
                    • E-Mail
                    • Телефон
                    • Организация (у компании несколько юр.лиц)
                    • Должность

                     

                    Из нее мы создаем CSV-файл с полями:

                     

                    • Name
                    • Surname
                    • E-Mail
                    • Phone
                    • Organization
                    • JobTitle

                     

                    Скрипт будет следующего вида:

                     

                    Import-Module ActiveDirectory

                    $Users = Import-CSV $1 –Delimiter “;”

                    Foreach($CurrentUser in $Users) {

                    $Name = $CurrentUser.Name

                    $Surname = $CurrentUser.Surname

                    $Email = $CurrentUser.E-Mail

                    $Phone = $CurrentUser.Phone

                    $Organization = $CurrentUser.Organization

                    $JobTitle = $CurrentUser.JobTitle

                    $Login = (Get-ADuser –Filter {GivenName –eq $Name –and Surname –eq $Surname}).SamAccountName #ищем юзера с заданным именем и фамилией и возвращаем его логин

                    Set-ADUser $Login –EmailAddress $Email –MobilePhone $Phone –Company $Organization –Title $JobTitle

                    }

                     

                    Заключение

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

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

                    Например:

                     

                    • Добавить обработку ошибок (например, если пользователь с таким именем уже существует, или наоборот – не существует) – конструкции типа try… catch…
                    • Автоматическую генерацию паролей заданной длины и сложности
                    • Вывод логинов с автоматически сгенерированными праолями для только что созданных учетных записей в CSV-файл – командлет Export-CSV

                     

                    Ресурсы

                    Эти ресурсы очень сильно помогут в изучении PowerShell. Во всяком случае мне они помогли.

                    Надеюсь, эта статья была вам полезна, и кто-то, кто раньше боялся консоли – перестанет ее бояться. Улыбка

                    Александр Косивченко

                    • Как не нужно называть домены Active Directory

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