Посвященную использования PowerShell для администрирования AD. В качестве исходного пункта автор решил взять 10 типичных задач администрирования AD и рассмотреть то, как их можно упростить, используя PowerShell:
- Сбросить пароль пользователя
- Активировать и деактивировать учетные записи
- Разблокировать учетную запись пользователя
- Удалить учетную запись
- Найти пустые группы
- Добавить пользователей в группу
- Вывести список членов группы
- Найти устаревшие учетные записи компьютеров
- Деактивировать учетную запись компьютера
- Найти компьютеры по типу
Помимо этого автор ведет блог (по PowerShell, конечно), рекомендуем заглянуть - jdhitsolutions.com/blog . А самое актуальное Вы можете получить из его твиттера twitter.com/jeffhicks .
Итак, ниже приводим перевод статьи “Top 10 Active Directory Tasks Solved with PowerShell”.
Управление Active Directory (AD) с помощью Windows PowerShell – это проще, чем Вы думаете, и я хочу доказать Вам это. Вы можете просто взять приведенные ниже скрипты и с их помощью решить ряд задач по управлению AD.
Требования
Чтобы использовать PowerShell для управления AD, нужно соблюсти несколько требований. Я собираюсь продемонстрировать, как командлеты для AD работают на примере компьютера на Windows 7.
Чтобы использовать командлеты, контроллер домена у Вас должен быть уровня Windows Server 2008 R2, или же Вы можете скачать и установить Active Directory Management Gateway Service на наследуемых контроллерах домена (legacy DCs). Внимательно прочитайте документацию перед установкой; требуется перезагрузка КД.
На стороне клиента, скачайте и установите (RSAT) либо для Windows 7 , либо для Windows 8 . В Windows 7, Вам необходимо будет открыть в Панели управления (Control Panel)
раздел Программы (Programs)
и выбрать Включить или выключить функции Windows (Turn Windows Features On or Off)
. Найдите Remote Server Administration Tools
и раскройте раздел Role Administration Tools
. Выберите подходящие пункты для AD DS and AD LDS Tools, особенно обратите внимание на то, что должен быть выбран пункт Active Directory Module for Windows PowerShell
, как показано на рисунке 1. (В Windows 8 все инструменты выбраны по умолчанию). Теперь мы готовы работать.
Рис.1 Включение AD DS и AD LDS Tools
Я вошел в систему под учетной записью с правами доменного администратора. Большинство командлетов, которые я буду показывать, позволят Вам уточнить альтернативные полномочия (credentials). В любом случае я рекомендую прочитать справку (Get-Help
) и примеры, которые я буду демонстрировать ниже.
Начните сессию PowerShell и импортируйте модуль:
PS C:\> Import-Module ActiveDirectory
В результате импорта создается новый PSDrive, но мы не будем использовать его. Однако, Вы можете посмотреть, какие команды имеются в импортированном модуле.
PS C:\> get-command -module ActiveDirectory
Прелесть этих команд в том, что если я могу использовать команду для одного объекта AD, то ее можно использовать для 10, 100 и даже 1000. Посмотрим, как некоторые из этих командлетов работают.
Задача 1: Сброс пароля пользователя
Давайте начнем с типичной задачи: сброс пароля пользователя. Сделать это легко и просто можно через командлет Set-ADAccountPassword
. Сложная часть заключается в том, что новый пароль должен быть уточнен как защищенная строка: фрагмент текста, который зашифрован и хранится в памяти на протяжении PowerShell сессии. Во-первых, создадим переменную с новым паролем:
PS C:\> $new=Read-Host "Enter the new password" -AsSecureString
Затем, введем новый пароль:
Теперь мы можем извлечь учетную запись (использование samAccountname – лучший вариант) и задать новый пароль. Вот пример для пользователя Jack Frost:
PS C:\> Set-ADAccountPassword jfrost -NewPassword $new
К сожалению, в случае с этим командлетом наблюдается баг: -Passthru , -Whatif , и –Confirm не работают. Если Вы предпочитаете короткий путь, попробуйте следующее:
PS C:\> Set-ADAccountPassword jfrost -NewPassword (ConvertTo-SecureString -AsPlainText -String "P@ssw0rd1z3" -force)
В итоге мне необходимо, чтобы Jack сменил пароль при следующем входе в систему, и я модифицирую учетную запись используя Set-ADUser .
PS C:\> Set-ADUser jfrost -ChangePasswordAtLogon $True
Результаты выполнения командлета не пишутся в консоль. Если это необходимо сделать, используйте –True . Но я могу узнать, успешно или нет прошла операция, произведя извлечения имени пользователя с помощью командлета Get-ADUser и уточнив свойство PasswordExpired , как показано на рисунке 2.
Рис. 2. Результаты работы командлета Get-ADUser Cmdlet со свойством PasswordExpired
Итог: сбросить пароль пользователя с помощью PowerShell совсем не сложно. Признаюсь, что сбросить пароль также просто через оснастку Active Directory Users and Computers консоли Microsoft Management Console (MMC). Но использование PowerShell подходит в том случае, если Вам необходимо делегировать задачу, Вы не хотите разворачивать вышеупомянутую оснастку или сбрасываете пароль в ходе большого автоматизированного ИТ-процесса.
Задача 2: Активировать и деактивировать учетные записи
А теперь давайте деактивируем учетную запись. Продолжим работать с Jack Frost. Этот код использует параметр –Whatif , который Вы можете встретить в других комадлетах, которые осуществляют изменения, чтобы проверить мою команду не запуская ее.
PS C:\> Disable-ADAccount jfrost -whatif What if: Performing operation "Set" on Target "CN=Jack Frost, OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".
А теперь деактивируем по-настоящему:
PS C:\> Disable-ADAccount jfrost
А когда настанет время активировать учетную запись, какой командлет нам поможет?
PS C:\> Enable-ADAccount jfrost
Эти командлеты могут быть использованы в конвейерном выражении (pipelined expression), позволяя активировать или деактивировать столько учетных записей, сколько душе угодно. Например, этот код деактивирует все учетные записи в отделе продаж (Sales)
PS C:\> get-aduser -filter "department -eq "sales"" | disable-adaccount
Конечно, писать фильтр для Get-ADUser довольно-таки сложно, но именно здесь использование параметра –Whatif вместе с командлетом Disable-ADAccount приходит на помощь.
Задача 3: Разблокировать учетную запись пользователя
Рассмотрим ситуацию, когда Jack заблокировал свою учетную запись, пытаясь ввести новый пароль. Вмест того, чтобы пытаться найти его учетную запись через GUI, процедуру разблокировки можно осуществить с помощью простой команды.
PS C:\> Unlock-ADAccount jfrost
Командлет также поддерживает параметры -Whatif и -Confirm .
Задача 4: Удалить учетную запись
Неважно, сколько пользователей Вы удаляете, - это просто осуществить с помощью командлета Remove-ADUser . Мне не хочется удалять Jack Frost, но если бы я захотел, то использовал бы такой код:
PS C:\> Remove-ADUser jfrost -whatif What if: Performing operation "Remove" on Target "CN=Jack Frost,OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".
Или я могу ввести несколько пользователей и удалить их с помощью одной простой команды:
PS C:\> get-aduser -filter "enabled -eq "false"" -property WhenChanged -SearchBase "OU=Employees, DC=Globomantics,DC=Local" | where {$_.WhenChanged -le (Get-Date).AddDays(-180)} | Remove-ADuser -whatif
С помощью этой команды будут найдены и удалены все деактивованные учетные записи подразделения (OU) Employees, которые не менялись в течение 180 и более дней.
Задача 5: Поиск пустых групп
Управление группами – занятие бесконечное и неблагодарное. Существует множество способов найти пустые группы. Некоторые выражения могут работать лучше, чем другие, в зависимости от Вашей организации. Код, приведенный ниже, позволит найти все группы в домене, включая встроенные (built-in).
PS C:\> get-adgroup -filter * | where {-Not ($_ | get-adgroupmember)} | Select Name
Если у Вас есть группы с сотнями членов, тогда использование этой команды может занять много времени; Get-ADGroupMember
проверяет каждую группу. Если Вы можете ограничить или настроить, это будет лучше.
Вот еще один подход:
PS C:\> get-adgroup -filter "members -notlike "*" -AND GroupScope -eq "Universal"" -SearchBase "OU=Groups,OU=Employees,DC=Globomantics, DC=local" | Select Name,Group*
Эта команда находит все универсальные группы (Universal groups), которые не имеют членство в OU Groups и выводит некоторые из свойств. Результат приведен на рисунке 3.
Рис. 3. Поиск и фильтрация универсальных групп
Задача 6: Добавление пользователей в группу
Давайте добавим Jack Frost в группу Chicago IT:
PS C:\> add-adgroupmember "chicago IT" -Members jfrost
Да, все так просто. Вы можете также легко добавлять сотни пользователей в группы, хотя, на мой взгляд, это слегка неудобно:
PS C:\> Add-ADGroupMember "Chicago Employees" -member (get-aduser -filter "city -eq "Chicago"")
Я использовал вводное конвейерное выражение (parenthetical pipelined expression), чтобы найти всех пользователей, у которых имеется свойство City в Chicago. Код в скобках выполняется, и полученные объекты передаются в параметр –Member. Каждый пользовательский объект добавляется в группу Chicago Employees. Неважно, имеем ли мы дело с 5 или 5000 пользователей, обновление членства в группах занимает всего несколько секунд. Это выражение может также быть написано с использованием ForEach-Object , что может быть удобнее:
PS C:\> Get-ADUser -filter "city -eq "Chicago"" | foreach {Add-ADGroupMember "Chicago Employees" -Member $_}
Задача 7: Выводим список членов группы
Вы возможно захотите узнать, кто находится в определенной группе. Например, Вы должны периодически узнавать, кто входит в группу доменных администраторов (Domain Admins):
PS C:\> Get-ADGroupMember "Domain Admins"
На рисунке 4 приведен результат.
Рис. 4. Члены группы Domain Admins
Командлет выводит объект AD для каждого члена группы. А что делать с вложенными группами? Моя группа Chicago All Users является коллекцией вложенных групп. Чтобы получить список всех учетных записей, я всего лишь должен использовать параметр –Recursive .
PS C:\> Get-ADGroupMember "Chicago All Users" -Recursive | Select DistinguishedName
Если Вы хотите пойти другим путем – найти, в каких группах пользователь состоит, - используйте свойство пользователя MemberOf :
PS C:\> get-aduser jfrost -property Memberof | Select -ExpandProperty memberOf CN=NewTest,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Test,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago IT,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Sales Users,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local
Я использовал параметр -ExpandProperty , чтобы вывести имена MemberOf как строки.
Задача 8: Найти устаревшие учетные записи компьютеров
Мне часто задают этот вопрос: “Как найти устаревшие учетные записи компьютеров?”. И я всегда отвечаю: “А что для вас является устаревшим?” Компании по-разному определяют то, когда учетная запись компьютера (или пользователя, неважно), признается устаревшей и не подлежит дальнейшему использованию. Что касается меня, то я обращаю внимание на те учетные записи, у которых пароли не менялись в течение определенного периода времени. Этот период для меня составляет 90 дней – если компьютер не сменил пароль вместе с доменом за этот период, скорее всего он находится оффлайн и является устаревшим. Используется командлет Get-ADComputer :
PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Select name,passwordlastset
Фильтр замечательно работает с жестким значением, но этот код будет обновляться для всех учетных записей компьютеров, которые не изменили своих паролей с 1 января 2012 года. Результаты приведены на рисунке 5.
Рис. 5. Находим устаревшие учетные записи компьютеров
Другой вариант: предположим, вы хотя бы на функциональном уровне домена Windows 2003. Поставьте фильтр по свойству LastLogontimeStamp . Это значение – число 100 наносекундных интервалов с 1 января, 1601 года, и храниться в GMT, поэтому работа с этим значением слегка сложно:
PS C:\> get-adcomputer -filter "LastlogonTimestamp -gt 0" -properties * | select name,lastlogontimestamp, @{Name="LastLogon";Expression={::FromFileTime ($_.Lastlogontimestamp)}},passwordlastset | Sort LastLogonTimeStamp
Рис. 6. Конвертируем значение LastLogonTimeStamp в привычный формат
Чтобы создать фильтр, мне необходимо конвертировать дату, например, 1 января 2012, в корректный формат. Конвертация осуществляется в FileTime:
PS C:\> $cutoff=(Get-Date "1/1/2012").ToFileTime() PS C:\> $cutoff 129698676000000000
Теперь я могу использовать эту переменную в фильтре для Get-ADComputer :
PS C:\> Get-ADComputer -Filter "(lastlogontimestamp -lt $cutoff) -or (lastlogontimestamp -notlike "*")" -property * | Select Name,LastlogonTimestamp,PasswordLastSet
Приведённый код находит те же самые компьютеры, что были показаны на рисунке 5.
Задача 9: Деактивировать учетную запись компьютера
Возможно, когда Вы найдете неактивные или устаревшие учетные записи, Вы захотите деактировать их. Сделать это довольно просто. Мы будем использовать тот же командлет, что использовали в работе с учетными записями пользователей. Вы можете уточнить его, использовав samAccountname учетной записи.
PS C:\> Disable-ADAccount -Identity "chi-srv01$" -whatif What if: Performing operation "Set" on Target "CN=CHI-SRV01, CN=Computers,DC=GLOBOMANTICS,DC=local".
Или же использовав конвейерное выражение:
PS C:\> get-adcomputer "chi-srv01" | Disable-ADAccount
Я также могу использовать мой код, чтобы найти устаревшие учетные записи и все их деактивировать:
PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Disable-ADAccount
Задача 10: Найти компьютеры по типу
Мне также часто задают вопрос, как найти учетные записи компьютеров по типу, например, серверы или рабочие станции. С вашей стороны это требует определенной креативности. В AD нет ничего такого, чтобы отличало сервер от клиента, разве что ОС. Если Ваш компьютер работает под Windows Server 2008, придется слегка сделать несколько дополнительных действий.
Для начала необходимо получить список ОС, а затем осуществляем фильтрацию учетных записей по имеющимся ОС.
PS C:\> Get-ADComputer -Filter * -Properties OperatingSystem | Select OperatingSystem -unique | Sort OperatingSystem
Результаты показаны на рисунке 7.
Рис. 7. Извлечение списка ОС
Я хочу найти все компьютеры, на которых стоит серверная ОС:
PS C:\> Get-ADComputer -Filter "OperatingSystem -like "*Server*"" -properties OperatingSystem,OperatingSystem ServicePack | Select Name,Op* | format-list
Результаты приведены на рисунке 8.
Как и другими командлетами AD Get, Вы можете настроить поисковые параметры и ограничить запрос отдельными OU, если это необходимо. Все выражения, которые я показал, могут быть интегрированы в большие PowerShell выражения. Например, Вы можете сортировать, группировать, применять фильтры, экспортировать в CSV или создавать и отправлять на почту HTML отчеты – и все это из PowerShell! При этом Вам не придется писать ни единого скрипа.
Вот Вам бонус: отчет о возрасте пароля пользователя (user password-age report), сохраненный в HTML файле:
PS C:\> Get-ADUser -Filter "Enabled -eq "True" -AND PasswordNeverExpires -eq "False"" -Properties PasswordLastSet,PasswordNeverExpires,PasswordExpired | Select DistinguishedName,Name,pass*,@{Name="PasswordAge"; Expression={(Get-Date)-$_.PasswordLastSet}} |sort PasswordAge -Descending | ConvertTo-Html -Title "Password Age Report" | Out-File c:\Work\pwage.htm
Хотя это выражение может выглядеть слегка пугающим, при минимальном знании PowerShell им легко воспользоваться. И остается лишь последний совет: как определить кастомное свойство под названием PasswordAge . Значение представляет собой промежуток между сегодняшним днем и свойством PasswordLastSet. Затем я сортирую результаты для моего нового свойства. На рисунке 9 показан выход для моего небольшого тестового домена.
Upd:
В посте приведен перевод статьи на портале
После установки Active Directory можно приступить к созданию объектов и управлению ими.
6.5.1. Создание подразделений и объектов в них
6.5.1.1. Создание организационных подразделений (ОП)
ОП можно создать в рамках домена, объекта Domain Controller или другого ОП (рис. 6.3). В созданное ОП можно добавлять объекты.
Для создания ОП необходимо обладать полномочиями по добавлению подразделений в родительское ОП, домен или узел Domain Controller, где будет создаваться ОП. По умолчанию такими полномочиями наделена группа Administrators (Админи-
страторы).
Нельзя создавать ОП в большинстве стандартных контей-
неров, таких как Computers или Users.
Рис. 6.3. ОП Кафедра ОТЗИ в узле Domain Controller
ОП создаются для упрощения администрирования сети. Структура ОП должна основываться на конкретных задачах ад-
министрирования. Вы можете легко изменять структуру ОП или перемещать объекты между ОП.
ОП создаются в следующих случаях:
чтобы предоставить административные полномочия другим пользователям или администраторам;
для группирования объектов, над которыми выполняются сходные административные операции; это облегчает поиск сходных сетевых ресурсов и их обслуживание - так, можно объединить в одном ОП все объекты User для временных служащих;
для ограничения видимости сетевых ресурсов в хранилище Active Directory пользователи увидят только те объекты, к которым имеют доступ; разрешения для ОП можно легко изменить, ограничив доступ к конфиденциальной информации.
6.5.1.2. Добавление объектов в ОП
Для добавления объектов в ОП Вы должны обладать в нем соответствующими полномочиями. По умолчанию такие права предоставлены группе Administrators . Разновидности создаваемых объектов зависят от правил схемы, используемого мастера или оснастки. Некоторые атрибуты объекта можно определить только после его создания.
6.5.2. Управление объектами Active Directory
Управление объектами Active Directory включает поиск объектов, их изменение, уничтожение или перемещение. В двух последних случаях надо иметь соответствующие разрешения для объекта или для ОП, куда Вы перемещаете объект. По умолчанию данными полномочиями обладают все члены группы Administrators .
6.5.2.1. Поиск объектов
Глобальный каталог (ГК) содержит частичную реплику всего каталога и хранит информацию обо всех объектах в дереве доменов или лесе. Поэтому пользователь может найти объект независимо от его расположения в домене или лесе. Содержание ГК автоматически генерируется по сведениям из доменов, составляющих каталог.
Для поиска объектов откройте оснастку , ярлык которой находится в группе программAdministrative Tools . В дереве консоли щелкните правой
кнопкой мыши домен или ОП и выберите в контекстном меню команду Find (Найти). Откроется диалоговое окноFind
(Поиск) (рис. 6.4).
Рис. 6.4. Диалоговое окно Find (Поиск)
Если Вы раскроете контекстное меню объекта Shared folder (Общая папка) и выберете командуFind
(Найти) , будет запущена функция поиска Windows Explorer, и Вы сможете искать в общей папке файлы и подпапки.
Диалоговое окно Find включает параметры поиска в ГК, позволяющие находить учетные записи, группы и принтеры.
6.5.2.2. Изменение значений атрибутов
и удаление объектов
Чтобы изменить значения атрибута, откройте оснастку Ac-
tive Directory Users And Computers и выберите экземпляр объек-
та. В меню Action (Действие) выберите командуProperties (Свойства) . В диалоговом окне свойств объ-
екта измените нужные атрибуты объекта. Затем внесите поправки в описание объекта, например, модифицируйте объект User , чтобы изменить имя, местоположение и электронный адрес пользователя. Если объекты больше не нужны, удалите их в целях безопасности: открыв оснасткуActive Directory Users And
Computers , выделите экземпляр удаляемого объекта, а затем в менюAction (Действие) выберите командуDelete
(Удалить).
6.5.2.3. Перемещение объектов
В хранилище Active Directory можно перемещать объекты, например между ОП, чтобы отразить изменения в структуре предприятия при переводе сотрудника из одного отдела в дру-
гой. Для этого, открыв оснастку Active Directory Users And Com-
puters , выделите перемещаемый объект, в менюAction (Действие) выберите командуMove (Переместить) и
укажите новое местоположение объекта.
6.5.3. Управление доступом к объектам Active Directory
Для контроля доступа к объектам Active Directory применяется объектно-ориентированная модель защиты, подобная модели защиты NTFS.
Каждый объект Active Directory имеет дескриптор безопасности, определяющий, кто имеет право доступа к объекту и тип этого доступа. Windows Server использует дескрипторы безопасности для управления доступом к объектам.
Для упрощения администрирования можно сгруппировать объекты с одинаковыми требованиями безопасности в ОП и назначить разрешения доступа для всего ОП и всех объектов в нем.
6.5.3.1. Управление разрешениями Active Directory
Разрешения Active Directory обеспечивают защиту ресурсов, позволяя управлять доступом к экземплярам объектов или атрибутам объектов и определять вид предоставляемого доступа.
Защита Active Directory
Администратор или владелец объекта должен назначить объекту разрешения доступа еще до того, как пользователи смогут получать доступ к этому объекту. Windows Server хранит список управления доступом (access control list, ACL ) для каждо-
го объекта Active Directory.
ACL объекта включает перечень пользователей, которым разрешен доступ к объекту, а также набор допустимых над объектом действий.
Можно задействовать разрешения для назначения административных полномочий конкретному пользователю или группе в отношении ОП, иерархии ОП или отдельного объекта без назначения административных разрешений на управление дру-
гими объектами Active Directory.
Разрешения доступа к объекту
Зависят от типа объекта - например, разрешение Reset Password допустимо для объектовUser , но не для объектов
Computer.
Пользователь может быть членом нескольких групп с разными разрешениями для каждой из них, обеспечивающих разные уровни доступа к объектам. При назначении разрешения на доступ к объекту члену группы, наделенной иными разрешениями, эффективные права пользователя будут складываться из его разрешений и разрешений группы.
Можно предоставлять или аннулировать разрешения. Аннулированные разрешения для пользователей и групп приоритетнее любых выданных разрешений.
Если пользователю запрещено обращаться к объекту, то он не получит доступ к нему даже как член полномочной группы.
Назначение разрешений Active Directory
Настроить разрешения объектов и их атрибутов позволяет оснастка Active Directory Users And Computers . Назначить раз-
решения также можно на вкладке Security (Безопасность) диалогового окна свойств объекта.
Для выполнения большинства задач администрирования достаточно стандартных разрешений.
В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.
Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.
Стандартизация
Планирование Active Directory следует начать с разработки своих стандартов назначения имен объектов и их расположения в каталоге. Необходимо создать документ, в котором определить все необходимые стандарты. Конечно, это довольно частая рекомендация для ИТ специалистов. Принцип «сначала пишем документацию, а потом по данной документации строим систему» является очень хорошим, но он редко реализуем на практике по многим причинам. Среди этих причин - простая человеческая лень или отсутствие соответствующей компетенции, остальные причины являются производными от первых двух.
Рекомендую - сначала напишите документацию, все обдумайте и только потом приступайте к инсталляции первого контроллера домена.
Для примера приведу раздел документа по стандартам названия объектов Active Directory.
Именование объектов.
- Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
- Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
- Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
- Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
- Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
- Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
- Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.
Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.
Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.
- Группы пользователей (GRUS_)
- Группы администраторов (GRAD_)
- Группы делегирования (GRDL_)
- Группы политик (GRGP_)
- Группы серверов (GRSR_)
- Группы клиентских компьютеров (GRCP_)
- Группы доступа к общим ресурсам (GRRS_)
- Группы доступа к принтерам (GRPR_)
Соблюдайте принцип равновесия, ограничьте количество ролей для групп и помните, что название группы должно в идеале полностью описывать ее роль.
Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.
Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:
- С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
- С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.
Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.
Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)
Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.
Копирование ADMX-шаблонов
Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.
Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:
- Audit Computer Account Management - Success, Failure
- Audit Other Account Management Events - Success, Failure
- Audit Security Group Management - Success, Failure
- Audit User Account Management - Success, Failure
- Audit Kerberos Authentication Service - Failure
- Audit Other Account Logon Events - Failure
- Audit Audit Policy Change - Success, Failure
Расширенные настройки аудита
Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.
Скрипты администрирования и уборки
Все однотипные и часто повторяемые действия необходимо выполнять при помощи скриптов администрирования. Среди таких действий: создание аккаунтов пользователей, создание аккаунтов администраторов, создание групп, создание OU и так далее. Создание объектов при помощи скриптов позволит соблюдать вашу логику названия объектов Active Directory, встроив проверки синтаксиса прямо в скрипты.
Также стоит написать скрипты уборки, которые будут в автоматическом режиме контролировать составы групп, выявлять пользователей и компьютеры, которые давно не подключались к домену, выявлять нарушение другие ваших стандартов так далее.
Я не встречал в качестве явной официальной рекомендации использование скриптов администрирования для контроля соблюдения стандартов и выполнения фоновых операций. Но сам предпочитаю проверки и процедуры в автоматическом режиме при помощи скриптов, так как это очень сильно экономит время и избавляет от большого количества ошибок и, конечно, здесь сказывается мой немного юниксовый подход к администрированию, когда проще набрать пару команд, чем щелкать мышкой по окнам.
Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.
Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.
Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.
Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.
Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.
Заключение
Сегодня утром я думал о том, почему человеческий эгоизм не приветствуется в обществе и где-то на глубинном уровне восприятия вызывает крайне отрицательные эмоции. И единственный ответ, который пришел мне в голову, это то, что человеческая раса не выжила бы на этой планете, если бы не научилась совместному использованию физических и интеллектуальных ресурсов. Именно поэтому я и делюсь данной статьей с вами и, надеюсь, что мои рекомендации помогут вам улучшить свои системы, и вы станете значительно меньше тратить времени на поиск и устранение неисправностей. Все это приведет к освобождению большего количества времени и энергии для творчества. Гораздо приятнее жить в мире творческих и свободных людей.
Хорошо, если в комментариях вы по возможности поделитесь своими знаниями и практиками построения Active Directory.
Всем мира и добра!
Вы можете помочь и перевести немного средств на развитие сайта
Любой начинающий пользователь, сталкиваясь с аббревиатурой AD, задается вопросом, что такое Active Directory? Active Directory — это служба каталогов, разработанная Microsoft для доменных сетей Windows. Входит в большинство операционных систем Windows Server, как набор процессов и сервисов. Первоначально служба занималась только доменами. Однако, начиная с Windows Server 2008, AD стала наименованием для широкого спектра служб, связанных с идентификацией, основанных на каталогах. Это делает Active Directory для начинающих более оптимальной для изучения.
Базовое определение
Сервер, на котором работают доменные службы каталогов Active Directory, называется контроллером домена. Он аутентифицирует и авторизует всех пользователей и компьютеры в сетевом домене Windows, назначая и применяя политику безопасности для всех ПК, а также устанавливая или обновляя программное обеспечение. Например, когда пользователь входит в компьютер, включенный в домен Windows, Active Directory проверяет предоставленный пароль и определяет, является ли объект системным администратором или обычным пользователем. Также он позволяет управлять и хранить информацию, предоставляет механизмы аутентификации и авторизации и устанавливает структуру для развертывания других связанных сервисов: службы сертификации, федеративные и облегченные службы каталогов и управления правами.
В Active Directory используются протоколы LDAP версии 2 и 3, версия Kerberos от Microsoft и DNS.
Active Directory — что это? Простыми словами о сложном
Отслеживание данных сети — трудоемкая задача. Даже в небольших сетях пользователи, как правило, испытывают трудности с поиском сетевых файлов и принтеров. Без какого-либо каталога средними и крупными сетями невозможно управлять, и часто приходится сталкиваться с трудностями при поиске ресурсов.
Предыдущие версии Microsoft Windows включали службы, помогающие пользователям и администраторам находить данные. Сетевое окружение полезно во многих средах, но явным недостатком являются неудобный интерфейс и его непредсказуемость. WINS Manager и Server Manager могут использоваться для просмотра списка систем, но они не были доступны конечным пользователям. Администраторы использовали User Manager для добавления и удаления данных совершенно другого типа сетевого объекта. Эти приложения оказались неэффективными для работы в крупных сетях и вызывали вопрос, зачем в компании Active Directory?
Каталог, в самом общем смысле, представляет собой полный список объектов.
Телефонная книга — это тип каталога, в котором хранится информация о людях, предприятиях и правительственных организациях, и
обычно в них записывают имена, адреса и номера телефонов.
Задаваясь вопросом, Active Directory — что это, простыми словами можно сказать, что эта технология похожа на справочник, но является гораздо более гибкой.
AD хранит информацию об организациях, сайтах, системах, пользователях, общих ресурсах и любом другом сетевом объекте
.
Введение в основные понятия Active Directory
Зачем организации нужна Active Directory? Как уже упоминалось во введении в Active Directory, служба хранит информацию о сетевых компонентах. В пособии «Active Directory для начинающих» говорится о том, что это позволяет клиентам находить объекты в своем пространстве имен. Этот термин (также называемый деревом консоли) относится к области, в которой может располагаться сетевой компонент. Например, оглавление книги создает пространство имен, в котором главы могут быть соотнесены к номерам страниц.
DNS — это дерево консоли, которое разрешает имена узлов IP-адресам, как т елефонные книги предоставляют пространство имен для разрешения имен для номеров телефонов. А как это происходит в Active Directory? AD предоставляет дерево консоли для разрешения имен сетевых объектов самим объектам и может разрешить широкий спектр объектов, включая пользователей, системы и службы в сети.
Объекты и атрибуты
Все, что отслеживает Active Directory, считается объектом. Можно сказать простыми словами, что этим в Active Directory является любой пользователь, система, ресурс или служба. Общий объект терминов используется, поскольку AD способен отслеживать множество элементов, а многие объекты могут совместно использовать общие атрибуты. Что это значит?
Атрибуты описывают объекты в активный каталог Active Directory, например, все пользовательские объекты совместно используют атрибуты для хранения имени пользователя. Это касается и их описания. Системы также являются объектами, но у них есть отдельный набор атрибутов, который включает имя хоста, IP-адрес и местоположение.
Набор атрибутов, доступных для любого конкретного типа объекта, называется схемой. Она делает классы объектов отличными друг от друга. Информация о схеме фактически хранится в Active Directory. Что такое поведение протокола безопасности очень важно, говорит тот факт, что схема позволяет администраторам добавлять атрибуты к классам объектов и распределять их по сети во всех уголках домена без перезапуска любых контроллеров домена.
Контейнер и имя LDAP
Контейнер - это особый тип объекта, который используется для организации работы службы. Он не представляет собой физического объекта, как пользователь или система. Вместо этого он используется для группировки других элементов. Контейнерные объекты могут быть вложены в другие контейнеры.
У каждого элемента в AD есть имя. Это не те, к которым вы привыкли, например, Иван или Ольга. Это отличительные имена LDAP. Различающиеся имена LDAP сложны, но они позволяют идентифицировать любой объект внутри каталога однозначно, независимо от его типа.
Дерево терминов и сайт
Дерево терминов используется для описания набора объектов в Active Directory. Что это? Простыми словами это можно объяснить при помощи древовидной ассоциации. Когда контейнеры и объекты объединены иерархически, они имеют тенденцию формировать ветви — отсюда и название. Связанным термином является непрерывное поддерево, которое относится к неразрывному основному стволу дерева.
Продолжая метафорию, термин «лес» описывает совокупность, которая не является частью одного и того же пространства имен, но имеет общую схему, конфигурацию и глобальный каталог. Объекты в этих структурах доступны всем пользователям, если это позволяет безопасность. Организации, разделенные на несколько доменов, должны группировать деревья в один лес.
Сайт — это географическое местоположение, определенное в Active Directory. Сайты соответствуют логическим IP-подсетям и, как таковые, могут использоваться приложениями для поиска ближайшего сервера в сети. Использование информации сайта из Active Directory может значительно снизить трафик в глобальных сетях.
Управление Active Directory
Компонент оснастки Active Directory — пользователи. Это самый удобный инструмент для администрирования Active Directory. Он напрямую доступен из группы программ «Администрирование» в меню «Пуск». Он заменяет и улучшает работу диспетчера сервера и диспетчера пользователей из Windows NT 4.0.
Безопасность
Active Directory играет важную роль в будущем сетей Windows.
Администраторы должны иметь возможность защищать свой каталог от злоумышленников и пользователей, одновременно делегируя задачи другим администраторам.
Все это возможно с использованием модели безопасности Active Directory, которая связывает список управления доступом (ACL) с каждым атрибутом контейнера и объекта в каталоге.
Высокий уровень контроля позволяет администратору предоставлять отдельным пользователям и группам различные уровни разрешений для объектов и их свойств.
Они могут даже добавлять атрибуты к объектам и скрывать эти атрибуты от определенных групп пользователей.
Например, можно установить ACL, чтобы только менеджеры могли просматривать домашние телефоны других пользователей.
Делегированное администрирование
Концепцией, новой для Windows 2000 Server, является делегированное администрирование. Это позволяет назначать задачи другим пользователям, не предоставляя дополнительных прав доступа. Делегированное администрирование может быть назначено через определенные объекты или непрерывные поддеревья каталога. Это гораздо более эффективный метод предоставления полномочий по сетям.
Вместо назначения кому-либо всех глобальных прав администратора домена, пользователю могут быть даны разрешения только в рамках определенного поддерева.
Active Directory поддерживает наследование, поэтому любые новые объекты наследуют ACL своего контейнера.
Термин «доверительные отношения»
Термин «доверительные отношения» по-прежнему используется, но имеют разную функциональность. Не существует различия между односторонними и двусторонними трастами. Ведь все доверительные отношения Active Directory двунаправлены. Кроме того, все они являются транзитивными. Итак, если домен A доверяет домену B, а B доверяет C, тогда существует автоматические неявные доверительные отношения между доменом A и доменом C.
Аудит в Active Directory — что это простыми словами? Это функция безопасности, которая позволяет определить, кто пытается получить доступ к объектам, а также насколько эта попытка успешна.
Использование DNS (Domain Name System)
Система по-другому DNS, необходима для любой организации, подключенной к Интернету. DNS предоставляет разрешение имен между общими именами, такими как mspress.microsoft.com, и необработанные IP-адреса, которые используют компоненты сетевого уровня для связи.
Active Directory широко использует технологию DNS для поиска объектов. Это существенное изменение в сравнении с предыдущими операционными системами Windows, которые требуют, чтобы имена NetBIOS были разрешены IP-адресами, и полагаются на WINS или другую технику разрешения имен NetBIOS.
Active Directory работает лучше всего при использовании с DNS-серверами под управлением Windows 2000. Microsoft упростила для администраторов переход на DNS-серверы под управлением Windows 2000 путем предоставления мастеров миграции, которые управляют администратором через этот процесс.
Могут использоваться другие DNS-серверы. Однако в этом случае администраторы должны будут тратить больше времени на управление базами данных DNS. В чем заключаются нюансы?
Если вы решите не использовать DNS-серверы под управлением Windows 2000, вы должны убедиться, что ваши DNS-серверы соответствуют новому протоколу динамического обновления DNS.
Серверы полагаются на динамическое обновление своих записей, чтобы найти контроллеры домена. Это неудобно. Ведь, е
сли динамическое обновление не поддерживается, обновлять базы данных приходится вручную.
Домены Windows и интернет-домены теперь полностью совместимы. Например, имя, такое как mspress.microsoft.com, будет определять контроллеры домена Active Directory, ответственные за домен, поэтому любой клиент с DNS-доступом может найти контроллер домена. Клиенты могут использовать разрешение DNS для поиска любого количества услуг, поскольку серверы Active Directory публикуют список адресов в DNS с использованием новых функций динамического обновления. Эти данные определяются как домен и публикуются через записи ресурсов службы. SRV RR следуют формату service.protocol.domain.
Серверы Active Directory предоставляют службу LDAP для размещения объекта, а LDAP использует TCP как базовый протокол транспортного уровня. Поэтому клиент, который ищет сервер Active Directory в домене mspress.microsoft.com, будет искать запись DNS для ldap.tcp.mspress.microsoft.com.
Глобальный каталог
Active Directory предоставляет глобальный каталог (GC) и предоставляет единственный источник для поиска любого объекта в сети организации.
Глобальный каталог — это сервис в Windows 2000 Server, который позволяет пользователям находить любые объекты, которым был предоставлен доступ.
Эта функциональность намного превосходит возможности приложения Find Computer, включенного в предыдущие версии Windows. Ведь пользователи могут искать любой объект в Active Directory: серверы, принтеры, пользователей и приложения.
Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT.
Данная служба позволяет администраторам использование групповых политик для обеспечения единообразия настроек пользовательской рабочей среды, установки ПО , обновлений и пр.
В чем суть работы Active Directory и какие задачи она решает? Читайте дальше.
Принципы организации одноранговых и многоранговых сетей
Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.
Еще один пример: у нас есть 20 рабочих станций с 20-ю учетными записями, которым мы хотим предоставить доступ к некоему , для этого мы должны создать 20 учетных записей на файловом сервере и предоставить доступ к необходимому ресурсу.
А если их будет не 20 а 200?
Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.
Поэтому подход с использованием рабочих групп подходит для небольших офисных сетей с количеством ПК не более 10 единиц.
При наличии в сетке более 10 рабочих станций, рационально оправданным стает подход, при котором одному узлу сети делегируют права выполнения аутентификации и авторизации.
Этим узлом и выступает контролер домена - Active Directory.
Контролер домена
Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2.
Теперь все учетные записи прописываются один раз на контролере, а необходимость в локальных учетных записях теряет смысл.
Теперь, когда пользователь заходит на ПК, вводя свой логин и пароль , эти данные передаются в закрытом виде на контролер домена, который выполняет процедуры аутентификации и авторизации.
После контролер выдает пользователю, осуществившему вход, что-то вроде паспорта, с которым он в дальнейшем работает в сети и который он предъявляет по запросу других компьютеров сетки, серверов к чьим ресурсам он хочет подключиться.
Важно! Контролер домена - это компьютер с поднятой службой Active Directory, который управляет доступом пользователей к ресурсам сети. Он хранит ресурсы (например, принтеры , папки с общим доступом), службы (например, электронная почта), людей (учетные записи пользователей и групп пользователей), компьютеры (учетные записи компьютеров).
Число таких сохраненных ресурсов может достигать миллионов объектов.
В качестве контролера домена могут выступать следующие версии MS Windows : Windows Server 2000/2003/2008/2012 кроме редакций Web-Edition.
Контролер домена помимо того, что является центром аутентификации сети, также является центром управления всеми компьютерами.
Сразу после включения компьютер начинает обращаться к контролеру домена, задолго до появления окна аутентификации.
Таким образом, выполняется аутентификация не только пользователя, вводящего логин и пароль, но и аутентификация клиентского компьютера.
Установка Active Directory
Рассмотрим пример установки Active Directory на Windows Server 2008 R2. Итак для установки роли Active Directory, заходим в «Server Manager»:
Добавляем роль «Add Roles»:
Выбираем роль Active Directory Domain Services:
И приступаем к установке:
После чего получаем окно уведомления, об установленной роли:
После установки роли контролера домена, приступим к установке самого контролера.
Нажимаем «Пуск» в поле поиска программ вводим название мастера DCPromo, запускаем его и ставим галочку для расширенных настроек установки:
Жмем «Next» из предложенных вариантов выбираем создание нового домена и леса.
Вводим имя домена, например, example.net.
Пишем NetBIOS имя домена, без зоны:
Выбираем функциональный уровень нашего домена:
Ввиду особенностей функционирования контролера домена, устанавливаем также DNS-сервер .
Расположения базы данных, файла логов, системного тома оставляем без изменений:
Вводим пароль администратора домена:
Проверяем правильность заполнения и если все в порядке жмем «Next».
После этого пойдет процесс установки, в конце которого появится окно, которое сообщает, об успешной установке:
Введение в Active Directory
В докладе рассматриваются два типа компьютерных сетей, которые можно создать при помощи операционных систем Microsoft: рабочая группа (workgroup) и домен Active Directory.
