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

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

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

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

    Процедура самой установки службы сертификатов не отличается от установки любой другой роли Windows Server 2016, и знакома системному администратору. Добавляется новая роль – Active Directory Certificate Service. Перед установкой следует разместить файл capolicy.inf [1], содержимое которого мы обсуждали в предыдущей статье [3] в папке systemroot. См. рис. 1.

    рис. 1.

    Это позволит нам выполнить начальную конфигурацию сервера сертификатов. В процессе установки сервиса, вернее будет сказать послеустановочной настройки см. рис. 2., потребуется задать учетную запись, от имени которой будет работать служба, тип развертывания – «Stand Alone CA», роль удостоверяющего центра – «RootCA».

    рис. 2.

    Также будет необходимо создать новый частный ключ, указать требуемый криптоалгоритм и длину ключа, алгоритм хеширования, срок жизни сертификата. После этого может сложится впечатление, что настройка завершена, однако это не так. Дело в том, что многие параметры работы сервера сертификатов останутся в состоянии «по-умолчанию», что приведет к неверной работе. Так, например, точки публикации сертификатов (AIA) см. рис. 3 и списков отзыва (CDP) см. рис. 4, порядок их опроса не будут соответствовать нашим потребностям, параметры логирования не будут заданы вовсе.

    рис. 3.

    рис. 4.

     

    AIA расшифровывается как Authority Information Access и определяет место хранение актуальных сертификатов нашего сервера. CDP – дает нам возможность определить место хранения списков отзывов, подписанных нашим сервером сертификатов. Оба эти расширения содержаться во всех выданных удостоверяющим центром сертификатах и, соответственно, должно быть доступны всем потребителям.

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

    Изменение этих настроек может быть выполнено разными способами. Может быть использован графический интерфейс (GUI), утилита certutil [4], с помощью которой можно полностью выполнять любые задачи из командной строки, наконец воспользоваться командлетами powershell.

    Certutil.exe – программа командной строки, которая устанавливается как часть служб сертификации. Используется для сбора информации о конфигурации удостоверяющего центра, настройки служб сервиса, резервного копирования и восстановления компонентов ЦС и проверки сертификатов, пар ключей и цепочек сертификатов.

    Администратор может вносить изменения в AIA и CDP расширения, однако на уже выданные сертификаты это никак не повлияет, они содержат предыдущие значения, соответственно, надо учитывать этот факт, и не лишать обладателей ранее выданных сертификатов возможности работы. Порядок строк в CDP, определяет последовательность проверки списка отзыва сертификатов. Получается, что, при наличии внешних клиентов, надо учесть, что проверка, скажем LDAP пути, который по-умолчанию стоит раньше в списке, будет для них просто невозможна. То есть будут возникать задержки [5] пока получится добраться до «рабочего» варианта. В этой ситуации, будет целесообразно, первым разместить HTTP путь. Это же будет относится и к не Windows клиентам, которые не будут использовать LDAP для поиска сертификатов и списков отзыва.

    Вообще, наиболее часто используемым будет именно HTTP вариант, поскольку он универсален и подходит любому типу клиента независимо от его членства в домене AD DS и типа.

    Стоит отметить, что у нас нет возможности частичной корректировки уже внесенной строки. Также невозможно изменить порядок следования строк. И, поскольку указанный по-умолчанию вариант в большинстве случаем не подходит, то ничего не остается, как только удалить эти строки полностью и внести новые значения, соответствующие требованиям. На этом этапе должны быть уже определены места хранения сертификатов и списков отзыва и подготовлен веб сервер, что уже обсуждалось в предыдущей статье [3].

    Еще один важный момент – как выполнить эти настройки? Конечно, это может быть сделано «вручную» с помощью графического интерфейса, однако при таком способе вероятность ошибок из-за невнимательности возрастает, поэтому лучше будет воспользоваться заранее подготовленным и отлаженным скриптом, который и выполнит все необходимые модификации реестра и настроит CA.

    Для настройки параметров CDP будем применять утилиту certutil и воспользуемся следующей командой:

     

    CertUtil [Options] -setreg [{ca|restore|policy|exit|template|enroll|chain|PolicyServers}[ProgId]]RegistryValueName Value+ ,

    с помощью, которой и назначим точки публикации CRL.

     

    Определимся с тем, каких результатов нам требуется добиться.

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

    C:\Windows\system32\CertSrv\CertEnroll.

    Он нам вполне подойдет. Следует понимать, что клиенты его получить не смогут, поскольку наш корневой сервер сертификатов для них недоступен. RootCA отключен от сети, да и вообще выключен. Значит файл его списка отзыва должен храниться где-то еще. То есть на сервере распространения – это наш веб сервер, который мы раньше установили. Нам придется его туда скопировать. Мы вернемся к вопросу переноса данных чуть позже в следующих статьях этого цикла.

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

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

    Значит список отзыва RootCA должен быть включен в выданные им сертификаты.

    Какие пути надо включить? Первым будет HTTP, а вторым LDAP путь для клиентов AD. Вероятней всего, до проверки LDAP дело не дойдет, но мы все-таки дополнительно внесем и этот путь.

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

    certutil -setreg CA\CRLPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:http://pki.nwtraders.msft/PKI/%3%8.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10”

    Сам сертификат УЦ тоже должен где-то храниться, мы используем путь по-умолчанию: C:\Windows\system32\CertSrv\CertEnroll.

    Теперь то, что касается проверки цепочки доверия сертификатов, клиенты будут проверять сами сертификаты, то есть надо включить информацию о их месте нахождения. Точно также мы воспользуемся http и ldap путями.

    Настройку AIA выполним таким образом:

    certutil -setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n2:http://pki.nwtraders.msft/PKI//%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11”

     

    Для настройки срока действия сертификата и периодичности публикации CRL, если нам требуется изменить уже внесенные с помощью capolicy.inf значения, с помощью все той же утилиты certutil делается нижеследующее:

     

    certutil -setreg CA\ValidityPeriodUnits 20

    certutil -setreg CA\ValidityPeriod “Years”

    certutil -setreg CA\CRLPeriodUnits 26

    certutil -setreg CA\CRLPeriod “Weeks”

    certutil -setreg CA\CRLOverlapUnits 2

    certutil -setreg CA\CRLOverlapPeriod “Weeks”

    certutil -setreg CA\CRLDeltaPeriodUnits 0

    certutil -setreg CA\CRLDeltaPeriod “Hours”

    Последовательно здесь настраиваются:

     

    • Период действия сертификата центра сертификации
    • Единицы измерения для ValidityPeriodUnits
    • Периодичность выпуска списков CRL и Delta CRL, а также срок продленного действия списков CRL

     

    Последнее, что осталось сделать – настроить аудит.

    certutil -setreg CA\AuditFilter 127

    Наконец, для определения значения переменной %6 -<ConfigurationContainer> выполните следующую команду:

    certutil -setreg ca\DSConfigDN “CN=Configuration,DC=nwtraders,DC= msft”

    Вот теперь мы можем считать, что корневой центр сертификации развернут.

     

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

    Статья опубликована в журнале “Системный Администратор № 3, 2018  стр.  16-19

    Литература

    [1] How CA Certificates Work. Overview of Capolicy.inf. https://technet.microsoft.com/en-us/library/cc737264(WS.10).aspx.

    [2] Prepare the Capolicy.inf https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file

    [3] Леонид Шапиро Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016 Часть № 1. Предварительный этап /Системный Администратор № 1-2, 2018  стр.  23-27

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

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

    • Внедрение Инфраструктуры Открытых Ключей на основе 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С открывается. Но увы есть ряд ситуаций, когда генерация случайным образом имени, если не выйдет вам боком, то хлопот однозначно добавит. В этой небольшой заметке я попытаюсь рассказать о том, как не стоит именовать ваши домены и почему. Информация хоть и известная, но реальная жизнь показывает, что ошибки в именовании просто повальные.  А поскольку процедура переименования домена это ит-шное садо-мазо, лучше все делать изначально правильно.

                    • Главная → Virtualization, Windows, Без рубрики, Новое → Hyper-V, Windows Server 2012, вебинар

                    • Вебинар TechNet: Windows Server 2012 Hyper-V Replica

                      Presentation_RightBox210 мая сего года в 17:00 по московскому времени пройдет вебинар TechNet, в рамках которого я расскажу о новой технологии, которая появляется в Windows Server 2012: Hyper-V Replica. Эта технология позволяет осуществлять репликацию виртуальных машин между географически разнесенными площадками, что позволяет повысить отказоустойчивость. При этом не требуется покупки какого-либо дополнительного оборудования или программного обеспечения, в отличие от существующих решений вроде Veeam Backup & Replication или репликации на уровне СХД.

                    1 2 3 … 13