Автоматический перенос компьютеров из ou computers
Вы можете использовать redirusr и redircmp для перенаправления учетных записей пользователей, компьютеров и групп, созданных API более ранней версии. Поэтому они помещаются в контейнеры организационного подразделения, заданные администратором.
Применяется к: Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 324949
Делегирование прав на сброс паролей и разблокировку учетных записей
Представим, наша задача – предоставить группе HelpDesk право на сброс пароля и разблокировку аккаунтов пользователей в домене. Итак, создадим новую группу в AD с помощью PowerShell:
New-ADGroup "HelpDesk" -path 'OU=Groups,OU=Moscow,DC=corp,dc=winitpro,DC=ru' -GroupScope Global
Добавьте в группу нужных пользователей:
Add-AdGroupMember -Identity HelpDesk -Members ivanovaa, semenovvb
Запустите консоль Active Directory Users and Computers (ADUC), щелкните ПКМ по OU с пользователями (в нашем примере это ‘OU=Users,OU=Moscow,DC=corp,dc=winitpro,DC=ru’) и выберите пункт меню Delegate Control.
Выберите группу, которой вы хотите предоставить административные полномочия.
Выберите из списка один из преднастроенных наборов привилегий (Delegate the following common tasks):
- Create, delete, and manage user accounts;
- Reset user passwords and force password change at next logon;
- Read all user information;
- Create, delete and manage groups;
- Modify the membership of a group;
- Manage Group Policy links;
- Generate Resultant Set of Policy (Planning);
- Generate Resultant Set of Policy (Logging);
- Create, delete, and manage inetOrgPerson accounts;
- Reset inetOrgPerson passwords and force password change at next logon;
- Read all inetOrgPerson information.
Либо создайте собственное задание делегирования (Create a custom task to delegate). Я выберу второй вариант.
Выберите тип объектов AD, на которые нужно предоставить права. Т.к. нам нужно предоставить права на учетные записи пользователей, выберите пункт User Object. Если вы хотите предоставить право на создание и удаление пользователей в этом OU, выберите опции Create/Delete selected objects in this folder. В нашем примере мы не предоставляем таких полномочий.
В списке разрешений нужно выбрать те привилегий, которые вы хотите делегировать. В нашем примере мы выберем право на разблокировку (Read lockoutTime и Write lockoutTime) и сброс пароля (Reset password).
Для поиска источника блокировки аккаунтов в домене службой поддержки пользователей нужно предоставить право поиска по журналам на контроллерах домена.
Нажмите Next и на последнем экране подтвердите назначение выбранных полномочий.
Теперь под учетной записью пользователя из группы HelpDesk попробуйте из PowerShell сбросить пароль пользователя из OU Users, например из PowerShell:
Set-ADAccountPassword petricdb -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “PPPPa$$w0rd1” -Force -Verbose) –PassThru
Пароль должен сброситься успешно (если он соответствует доменной политике паролей).
Теперь попробуйте создать пользователя в данной OU с помомью командлета New-ADUser:
New-ADUser -Name kalininda -Path 'OU=Users,OU=Moscow,OU=winitpro,OU=DC=ru' -Enabled $true
Должна появится ошибка доступа, т.к. вы не делегировали полномочий на создание учетных записей.
Для контроля действий пользователей, которым вы делегированными административные права, вы можете использовать журналы контроллеров домена. Например, вы можете отследить кто сбросил пароль пользователя в домене, узнать кто создал учетную запись пользователя в AD или отследить изменения в определённых группах AD.
Делегирование прав в Active Directory с помощью PowerShell
С помощью PowerShell вы можете вывести список прав, которые делегированы на OU или изменить текущие разрешения. Для получения и изменения прав в Active Directory используются командлеты Get-ACL и Set-ACL (эти же командлеты PowerShell используются для управления NTFS разрешения на файлы и папки).
Следующий простой скрипт выведет список нестандартных разрешений, которые делегированы на определенное организационное подразделение в AD:
Вы можете получить отчет с разрешениями в виде графической таблицы Out-GridView:
Или экспортировать права в CSV файл для дальнейшего анализа в Excel (из скрипта PowerShell можно писать строки напрямую в Excel файл):
$report | Export-Csv -Path "C:\ps\ADOU_Permissions.csv" –NoTypeInformation
В полученном отчете сразу видно, что для группы HelpDesk делегированы права на сброс паролей пользователей в OU.
Для делегирования прав на OU можно использовать утилиту dsacls. Например:
dsacls "ou=users,ou=msk, dc=winitpro,dc=ru" /I:S /G "WINITPRO\HELPDESK:CA;Reset Password;user" "WINITPRO\HELPDESK:WP;pwdLastSet;user" "WINITPRO\HELPDESK:WP;lockoutTime;user
Также вы можете назначить права на организационный контейнер с помощью PowerShell (в этом примере делегируются права на сброс пароля):
По аналогии с помощью PowerShell можно делегировать и другие права на организационные контейнеры AD.
В Active Directory вновь созданные учетные записи пользователей и учетные записи компьютеров помещаются в контейнеры (CN,Containers) по умолчанию. Для компьютеров это контейнер Computers, для пользователей — Users. Недостатком такого подхода является то, что в отличие от подразделения (OU,Organization Unit) к контейнерам применить отдельную политику безопасности нельзя, только дефолтную политику домена. Поскольку это не очень удобно, попробуем изменить существующий порядок вещей.
Итак, ADSIEdit нам не поможет, поэтому воспользуемся утилитой AD Explorer, которая предназначена для просмотра и редактирования Active Directory. Утилита абсолютно бесплатна и не требует установки, достаточно просто скачать ее, запустить и подключиться к домену.
Так выглядит содержимое атрибута wellKnownObjects. А вот и значения контейнеров по умолчанию.
Найдя нужные параметры попробуем их изменить. Как уже было сказано, атрибут wellKnownObjects защищен от изменения и вручную отредактировать его не удастся. Для его изменения в Windows есть специальные утилиты redircmp.exe и redirusr.exe , находящиеся в папке C:\Windows\System32. Как видно из их названия, первая служит для перенаправления компьютеров, а вторая — пользователей.
Примечание. Перед использованием утилит надо не забыть создать новые OU, которые будут назначены по умолчанию. Для примера я создал OU Workstations для компьютеров и Peoples для пользователей.
redircmp OU=Workstations, DC=contoso, DC=com
Для назначения OU Peoples по умолчанию вводим:
redirusr OU=Peoples, DC=contoso, DC=com
Еще раз откроем атрибут wellKnownObjects и посмотрим, как изменились его свойства.
Ну и проверим на практике внесенные изменения. Я взял компьютер WKS1 и добавил его в домен. Как видите, он оказался в подразделении Workstations.
Теперь добавим пользователя c помощью командлета New-ADUser из оснастки Powershell, в этом случае он должен попасть в контейнер по умолчанию. Проверяем — так и есть, он в OU Peoples.
Чтобы операция перенаправления прошла успешно, надо соблюсти следующие требования:
• Функциональный уровень домена не ниже Windows Server 2003;
• Должен быть доступен контролер домена с ролью PDC Emulator;
• Все действия должны производится с правами администратора домена.
Предоставление права на добавление компьютеров в домен AD
По умолчанию любой пользователь домена может присоединить в домен 10 компьютеров. При добавлении в домен 11-го компьютера появится ошибка:
Вы можете изменить это ограничение на уровне всего домена, увеличив значение в атрибуте ms-DS-MachineAccountQuota (ссылка). Либо (гораздо правильнее и безопаснее), делегировав право на ввод компьютеров в домен в определенной OU конкретной группе пользователей (helpdesk). Для этого нужно предоставить право создавать объекты типа (Computer objects). В мастере делегирования выберите Create selected objects in this folder.
А в секции Permissions выберите Create All Child Objects.
Если вы хотите делегировать права на перемещение объектов между организационными подразделениями в AD, нужно предоставить следующие расрешения: Delete User objects, Write Distinguished Name, Write name (**), Create User (или Computer) objects.
Особенности делегирования прав в Active Directory
Для делегирования прав в AD используется мастер Delegation of Control Wizard в графической оснастке Active Directory Users and Computers (DSA.msc).
Административные права в AD можно делегировать на довольно детальном уровне. Одной группе можно предоставить право на сброс пароля в OU, другой – на создание и удаление аккаунтов, третьей на сброс пароля. Можно настроить наследование разрешений на вложенные OU. Вы можете делегировать права в AD на четырех уровнях:
- Сайта AD;
- Всего домена;
- Конкретной OU в Active Directory;
- Конкретного объекта AD.
Несколько рекомендаций по правильному использованию делегирования администраивных полномочий в AD:
- Не рекомендуется делегировать разрешения непосредственно для кокретных учетных записей пользователей. Вместо этого создайте в AD новую группу безопасности, добавьте в нее пользователя и делегируйте полномочия на OU для этой группы. Если вам понадобится предоставить такие же права в домене еще одному пользователю, вам будет достаточно добавить его в группу безопасности;
- Старайтесь не использовать запрещающих разрешений, т.к. они имеют приоритет над разрешающими;
Сводка
При установке по умолчанию домена Active Directory учетные записи пользователей, компьютеров и групп помещались в контейнеры cn=objectclass вместо более желательного контейнера класса OU. Аналогичным образом учетные записи, созданные с помощью API более ранней версии, помещались в контейнеры CN=Users и CN=computers.
Некоторые приложения требуют, чтобы определенные принципы безопасности располагались в контейнерах по умолчанию, таких как CN=Users или CN=Computers. Убедитесь, что у приложений есть такие зависимости, прежде чем переместить их из контейнеров CN=users и CN=computes.
Дополнительные сведения
Например, в следующих операциях используются API более ранней версии, которые отвечают на пути, определенные в атрибуте WellKnownObjects:
Windows XP Professional
Windows XP Ultimate
Windows Server 2003
Windows Server 2003 R2
Windows Server 2008
Полезно сделать контейнер по умолчанию для групп пользователей, компьютеров и безопасности OU по нескольким причинам, в том числе:
Групповые политики можно применять в контейнерах OU, но не в контейнерах класса CN, где по умолчанию ставятся основные принципы безопасности.
Передовая практика — упорядочность принципов безопасности в иерархию OU, которая отражает организационную структуру, географическое расположение или модель администрирования.
При перенаправлении папок CN=Users и CN=Computers следует помнить о следующих проблемах:
Целевой домен должен быть настроен для запуска на уровне Windows Server 2003 или выше. Для функционального уровня Windows Server 2003 это означает:
- Windows Server 2003 ADPREP /FORESTPREP или более новый
- Windows Server 2003 ADPREP /DOMAINPREP или более новый
- Все контроллеры домена в целевом домене должны работать Windows Server 2003 или более новые.
- Windows server 2003 должен быть включен функциональный уровень домена или более высокий.
В отличие от CN=USERS и CN=COMPUTERS, контейнеры OU подвергаются случайным удалениям привилегированных учетных записей пользователей, в том числе администраторов.
Контейнеры CN=USERS и CN=COMPUTERS — это объекты, защищенные системой, которые не могут и не должны удаляться для обратной совместимости. Но их можно переименовать. Организационные подразделения могут быть удалены администраторами случайно.
Windows Server 2003 версии приложения Active Directory Users & Computers snap-in могут следовать шагам в "Защита организационного подразделения от случайного удаления".
Windows Server 2008 и более новые версии оснастки пользователей и компьютеров Active Directory имеют функцию защиты объекта от случайного удаления, которое можно выбрать при создании нового контейнера OU. Вы также можете выбрать его на вкладке Объект в диалоговом окне Свойства для существующего контейнера OU.
Exchange Server 2000 и 2003 setup /domainprep годах с ошибками.
Перенаправление CN=Computers на указанный администратором OU
Войдите в систему с учетными данными администратора домена в домене, куда перенаправляется контейнер CN=computers.
Переход домена на домен Windows Server 2003 в оснастке пользователей и компьютеров Active Directory (Dsa.msc) или в snap-in доменов и трастов (Domains.msc). Дополнительные сведения об увеличении функционального уровня домена см. в дополнительных сведениях о повышении функциональных уровней домена и леса.
Создайте контейнер OU, в котором требуется, чтобы компьютеры, созданные с API более ранней версии, находились, если нужного контейнера OU не существует.
Выполнить Redircmp.exe по командной подсказке с помощью следующего синтаксиса. В команде контейнер-dn — это отличительное имя OU, которое станет расположением по умолчанию для вновь созданных компьютерных объектов, созданных с помощью API на уровне ниже:
Когда Redircmp.exe для перенаправления контейнера CN=Computers на OU, заданный администратором, контейнер CN=Computers больше не будет защищенным объектом. Это означает, что контейнер Computers теперь можно перемещать, удалять или переименовывать. Если вы используете ADSIEDIT для просмотра атрибутов в контейнере CN=Computers, вы увидите, что атрибут systemflags был изменен с -1946157056 на 0. Данное поведение является особенностью продукта.
D:>redirusr OU=userOU,DC=udc,dc=jkcertcontoso,dc=loc com
Ошибка, не удалось найти контроллер основного домена для текущего домена: указанный домен либо не существует, либо не может быть связаться. Перенаправление не было успешным.
D:>redircmp OU=computerOU,DC=contoso,dc=com DC=udc,dc=jkcert,dc=loc
Ошибка, не удалось найти контроллер основного домена для текущего домена: указанный домен либо не существует, либо не может быть связаться. Перенаправление не было успешным.
C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена является по крайней мере Windows Server 2003: не желают выполнять перенаправление не удалось.
C:>REDIRCMP ou=computersou,DC=contoso,dc=comdc=company,dc=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена по крайней мере Windows Server 2003: не желают выполнять
C:>REDIRCMP OU=computersou,DC=contoso,dc=comDC=company,DC=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена по крайней мере Windows Server 2003: недостаточное перенаправление прав не было успешным.
C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена по крайней мере Windows Server 2003: недостаточное перенаправление прав не было успешным.
C:>REDIRCMP OU=nonexistantou,DC=contoso,dc=com dc=rendom,dc=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена является по крайней мере Windows Server 2003: не было успешного перенаправления таких объектов.
C:>redirusr OU=nonexistantou,DC=contoso,dc=com DC=company,DC=com
Ошибка, не удается изменить атрибут wellKnownObjects. Убедитесь, что функциональный уровень домена является по крайней мере Windows Server 2003: не было успешного перенаправления таких объектов.
Установка не удалось при установке разрешений на уровне домена на подкомпонентном уровне с помощью кода ошибки 0x80072030) (подробные сведения см. в журналах установки). Вы можете отменить установку или повторить неудачный шаг. (Retry / Cancel)
Следующие данные появляются в журнале установки Exchange Server 2000, который размастеризовка журнала. Exchange Server 2003 год должен быть аналогичным.
18.07.2019
itpro
Вопросы и ответы
Комментариев пока нет
Есть список имен компьютеров в xls файле. Нужно перенести их в отдельный контейнер (OU) домена Active Directory. Как я понимаю, проще всего это сделать с помощью PowerShell. Нашел командлет для переноса объектов в AD — Move-ADObject, но как ему скормить Excel файл – не пойму. Как я понял можно как-то подать на вход команды Move-ADObject конвейер из имен компьютеров в csv файле. Подскажите, пожалуйста.
Ответ
Создайте простой текстовый файл со списком компьютеров (в столбец), которые нужно перенести (просто скопируйте столбец из Excel).
Получим содержимое текстового файла и присвоим его переменной.
$PCs = gc "C:\ps\buh-pc.txt"
Зададим целевую OU, в которую нужно переместить учетные записи компьютеров.
Затем в цикле для каждой строки из текстового файла найдем объект компьютера в AD с помощью командлета Get-ADComputer и конвейером переместим его в целевую OU с помощью командлета Move-ADObject.
foreach ($PC in $PCs) Get-ADComputer -Identity $PC | Move-ADObject -TargetPath $TargetOU
>
Чтобы посмотреть, что получится, но не переносить объекты в AD, у комадлета Move-ADObject можно добавить параметр –WhatIf.
21.02.2017
itpro
Active Directory
комментариев 12
При включении компьютера в домен Active Directory при помощи GUI Windows или команды NETDOM.EXE,по умолчанию вновь созданный объект попадает в контейнер (OU) Computers, который является контейнером по-умолчанию для всех вновь созданный объектов типа «Computer».
Недостаток такого подхода заключается в том, что вы не можете назначить ни одной доменной групповой политики на OU Computers, и получается, что на новых компьютерах домена (потенциально небезопасных) вы просто не сможете применить специальные параметры безопасности (помимо стандартных для всего домена).
Разберемся, где же хранятся настройки, определяющие OU по-умолчанию для компьютеров домена. Откройте консоль Active Directory Users and Computers (как установить оснастку Active Directory в Windows 7), или же консоль ADSI Edit, при помощи контекстного меню перейдите в свойства домена, а затем перейдите на вкладку Attribute Editor.
Контейнер AD, в который попадают по-умолчанию новые компьютеры, определяются в атрибуте wellKnownObjects.
Атрибут wellKnownObjects содержит примерно такую информацию:
98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=redircomp.exeNTDS Quotas,DC=LABHOME,DC=local
244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local
9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local
34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local
24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local
47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local
171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local
171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local
163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local
170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, CN=Computers,DC=LABHOME,DC=local
169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local
Теперь, когда мы поняли, где хранится нужный нам параметр, попробуем изменить его. Как я уже говорил, атрибут wellKnownObjects нельзя отредактировать при помощи консолей AD, наверное, это и к лучшему )). Для модификации этого параметра Microsoft разработала специальную утилиту, которая называется redircmp.exe, которая хранится в папке %SystemRoot%\System32 (на системах Windows Server 2003/2008).
Перед использованием утилиты redircmp.exe, создадим новый Organizational Unit, в который в дальнейшем будут попадать объекты Computer. Для примера я создал OU StagedComputers. Выполним следующую команду:
А затем при помощи Active Directory Explorer просмотрим содержимое атрибута wellKnownObjects (как вы увидите, оно изменилось):
170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, OU=StagedComputers,DC=LABHOME,DC=local
98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=NTDS Quotas,DC=LABHOME,DC=local
244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local
9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local
34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local
24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local
47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local
171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local
171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local
163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local
169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local
И наконец, с целью тестирования, я попробовал включить Windows XP (имя ПК VMXP-001) в домен LABHOME, действительно новый объект типа Computer появился в контейнере StagedComputers.
Предыдущая статья Следующая статья
Запрос к Active Directory из Excel
Создание WMI фильтров для групповых политик (GPO) в домене AD
Установка программ с помощью групповых политик в домене Active Directory
Добрый день.
Можно это сделать намного проще. Достаточно воспользоваться командой «redircmp %DN%». Для пользователей есть аналогичная команда «redirusr %DN%». Присутствует во всех версиях Windows Server, начиная с 2003
А как сделать так, чтобы новые компы попадали в определенные OU в соответсвии с принадлежностью к определенному сайту (принадлежащие определенному диапазону IP-адресов)?
Во народ глумиться!
А нужно ли это вообще нам админам?
Точно, я понял — здесь попахивает конвеером по вводу компов в домен…
11.03.2022
itpro
Active Directory, PowerShell, Windows Server 2019
комментария 22
В этой статье мы рассмотрим особенности делегирования полномочий в домене Active Directory. Делегирование позволяет предоставить право на выполнение некоторых задач управления AD обычным пользователям домена, не включая их в привилегированные доменные группы, такие как Domain Admins, Account Operators и т.д.. Например, с помощью делегирования вы можете предоставить определённой группе пользователей (допустим, Helpdesk) право на добавление пользователей в группы, заведение новых пользователей в AD и сброс пароля.
Просмотр и удаление назначенных прав в Active Directory
На любую OU в AD можно назначить любое количество правил делегирования. Вы можете получить список групп и делегированные им права в свойствах OU в консоли ADUC. Перейдите на вкладку Security.
Здесь содержится список объектов AD, которым предсоатвлены разрешения на этот контейнер. Список предоставленных полномочий можно посмотреть на вкладке Advanced. Как вы видите для группы HelpDesk разрешен сброс паролей.
Вы можете лишить определенную группу администраивных прав, назначенных ранее через делегирование. В списке разрешений найдите группу, который вы делегировали права и нажмите Remove.
Также со вкладки Security -> Advanced вы можете самостоятельно настроить делегирование полномочий, назначая нестандартные разрешений различным группам безопасности.
Перенаправление CN=Users на указанный администратором OU
Войдите в систему с учетными данными администратора домена в домене Z, куда перенаправляется контейнер CN=Users.
Переход домена на функциональный уровень Windows Server 2003 или более новый в оснастке пользователей и компьютеров Active Directory (Dsa.msc) или snap-in доменов и трастов (Domains.msc). Дополнительные сведения об увеличении функционального уровня домена см. в дополнительных сведениях о повышении функциональных уровней домена и леса.
Создайте контейнер OU, в котором должны быть размещены пользователи, созданные с API более ранней версии, если нужного контейнера OU не существует.
Выполнить Redirusr.exe по командной подсказке с помощью следующего синтаксиса. В команде container-dn — это отличительное имя OU, которое станет расположением по умолчанию для вновь созданных пользовательских объектов, созданных интерфейсами API на уровне ниже:
Читайте также: