В этой статье мы рассмотрим особенности делегирования полномочий в домене Active Directory. Делегирование позволяет предоставить право на выполнение некоторых задач управления AD обычным пользователям домена, не включая их в привилегированные доменные группы, такие как Domain Admins, Account Operators и т.д.. Например, с помощью делегирования вы можете предоставить определённой группе пользователей (допустим, Helpdesk) право на добавление пользователей в группы, заведение новых пользователей в AD и сброс пароля.
Особенности делегирования прав в 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 для этой группы. Если вам понадобится предоставить такие же права в домене еще одному пользователю, вам будет достаточно добавить его в группу безопасности;
- Старайтесь не использовать запрещающих разрешений, т.к. они имеют приоритет над разрешающими;
- Периодически выполняйте аудит делегированных полномочий в домене (отчет с текущими списками разрешений на OU можно сгенерировать с помощью PowerShell).
- Не делегируйте права на управление OU с административными аккаунтами. Иначе легко может произойти ситуация, когда любой сотрудник службы поддержки может сбросить пароль администратора домена. Все чувствительные пользователи и группы с повышенными привилегиями нужно размещать в отдельной OU, на которую не распространяется правила делегирования.
Делегирование прав на сброс паролей и разблокировку учетных записей
Представим, наша задача – предоставить группе 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.
Предоставление права на добавление компьютеров в домен AD
По умолчанию любой пользователь домена может присоединить в домен 10 компьютеров. При добавлении в домен 11-го компьютера появится ошибка:
Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased.
Вы можете изменить это ограничение на уровне всего домена, увеличив значение в атрибуте 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
На любую OU в AD можно назначить любое количество правил делегирования. Вы можете получить список групп и делегированные им права в свойствах OU в консоли ADUC. Перейдите на вкладку Security.
Здесь содержится список объектов AD, которым предсоатвлены разрешения на этот контейнер. Список предоставленных полномочий можно посмотреть на вкладке Advanced. Как вы видите для группы HelpDesk разрешен сброс паролей.
Вы можете лишить определенную группу администраивных прав, назначенных ранее через делегирование. В списке разрешений найдите группу, который вы делегировали права и нажмите Remove.
Также со вкладки Security -> Advanced вы можете самостоятельно настроить делегирование полномочий, назначая нестандартные разрешений различным группам безопасности.
Делегирование прав в Active Directory с помощью PowerShell
С помощью PowerShell вы можете вывести список прав, которые делегированы на OU или изменить текущие разрешения. Для получения и изменения прав в Active Directory используются командлеты
Get-ACL
и
Set-ACL
(эти же командлеты PowerShell используются для управления NTFS разрешения на файлы и папки).
Следующий простой скрипт выведет список нестандартных разрешений, которые делегированы на определенное организационное подразделение в AD:
# Получаем OU
$OUs = Get-ADOrganizationalUnit -Filter 'DistinguishedName -eq "OU=Users,OU=NSK,DC=winitpro,DC=ru"'| Select-Object -ExpandProperty DistinguishedName
$schemaIDGUID = @{}
$ErrorActionPreference = 'SilentlyContinue'
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(schemaIDGUID=*)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)" -LDAPFilter '(objectClass=controlAccessRight)' -Properties name, rightsGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}
$ErrorActionPreference = 'Continue'
ForEach ($OU in $OUs) {
$report += Get-Acl -Path "AD:\$OU" |
Select-Object -ExpandProperty Access |
Select-Object @{name='organizationalUnit';expression={$OU}}, `
@{name='objectTypeName';expression={if ($_.objectType.ToString() -eq '00000000-0000-0000-0000-000000000000') {'All'} Else {$schemaIDGUID.Item($_.objectType)}}}, `
@{name='inheritedObjectTypeName';expression={$schemaIDGUID.Item($_.inheritedObjectType)}}, `
*
}
# отчет с назначенными правами на OU
Вы можете получить отчет с разрешениями в виде графической таблицы Out-GridView:
$report| where {($_.IdentityReference -notlike "*BUILTIN*") -and ($_.IdentityReference -notlike "*NT AUTHORITY*") }| 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 (в этом примере делегируются права на сброс пароля):
$ou = "AD:\OU=test,DC=test,DC=com"
$group = Get-ADGroup helpdesk
$sid = new-object System.Security.Principal.SecurityIdentifier $group.SID
$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$UserObjectType = "bf967aba-0de6-11d0-a285-00aa003049e2"
$ACL = get-acl $OU
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($sid, "ExtendedRight", "Allow", $ResetPassword, "Descendents", $UserObjectType)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OU -AclObject $ACL
По аналогии с помощью PowerShell можно делегировать и другие права на организационные контейнеры AD.
Спасибо за статью! Расскажите как настроить делегирование полномочий для переименования ПК.
Вам нужно предоставить права на создание, удаление и модификацию объектов AD в OU с компьютерами.
DSA.msc запускается только на контроллере домена, UAC разрешает запускать только администраторам, но на контроллере домена, администратор — это администратор домена, т.к. встроенная группа администраторы отключена DC и включена быть не может, и соответственно кому попало давать права доменного админа, это как бы не очень хорошая идея, как быть в этом случае?
Вы можете установить и использовать dsa.msc нет только на DC. Установите RSAT на любую рабочую станцию и сервер. Для использования консоли ADUC права администартора домена не нужны. По умолчанию просматривать структуру AD и объекты есть у любого пользователя домена.
Допустим незнакомый домен. Как с помощью Powershell узнать пользователей/группы которым делегировано право, например разблокировать пользователей?
Вот небольшой PowerShell скрипт для получения отчета с текущими разрешениями на OU (укажите имя OU и путь к файлу экспорта):
$schemaIDGUID = @{}
#ignore duplicate errors if any#
$ErrorActionPreference = 'SilentlyContinue'
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(schemaIDGUID=*)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)" -LDAPFilter '(objectClass=controlAccessRight)' -Properties name, rightsGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}
$ErrorActionPreference = 'Continue'
# Получаем OU
$OUs = Get-ADOrganizationalUnit -Filter 'Name -like "Moscow"'| Select-Object -ExpandProperty DistinguishedName
# retrieve OU permissions.
# Add report columns to contain the OU path and string names of the ObjectTypes.
ForEach ($OU in $OUs) {
$report += Get-Acl -Path "AD:\$OU" |
Select-Object -ExpandProperty Access |
Select-Object @{name='organizationalUnit';expression={$OU}}, `
@{name='objectTypeName';expression={if ($_.objectType.ToString() -eq '00000000-0000-0000-0000-000000000000') {'All'} Else {$schemaIDGUID.Item($_.objectType)}}}, `
@{name='inheritedObjectTypeName';expression={$schemaIDGUID.Item($_.inheritedObjectType)}}, `
*
}
# Export report out to a CSV file for analysis in Excel.
$report | Export-Csv -Path "C:\ps\ADOU_Permissions.csv" -NoTypeInformation
Как определить в домене кому хоть что-то делегировано? Подопытный OU неизвестен.
Делегирование по сути напоминает установку NTFS разрешений. После того, как кому-то дали (делегировали) права на объект или OU в AD, вы можете увидеть текущие разрешения в его ACL.
Выше есть пример Powershell скрипта с выводом текущих разрешений на OU — можно начать анализ прав с него. Выгрузить все разрешения, отсеять в списке (в excel например) стандартные и останутся, те который были добавлены.
Здраствуйте! Подскажите, как сделать, чтобы определенный пользователь мог создавать и перемещать пользователей только внутри определенной рабочей группы?
Под рабочей группой вы имеете в виду контейнер AD? Какова структура OU?
Добрый день! Возможно ли дать права только на создание учетной записи и сброс пароля, но без права удаления учетных записей.
Доброго утра!
Да, можно. Создайте кастомное правило делегирования для обьектов user object. Разрешите create selected object in this folder. Затем внимательно просмотрите список permissions и дайте только те права, которые нужный.
В вашем случае нужно длоReset password, create all child objects, write all properties (если надо)
Добрый день! Спасибо, получилось.
Как в дополнительных параметрах безопасности юзеров отключить унаследованные разрешения от унаследованных подразделений — OU? При удалении выходит сообщение «Необходимо запретить наследование разрешений этим объектом. Отключите параметр наследований разрешений и прорубайте удалить субъект еще раз»
Какое разрешение нужно выставить для группы, чтобы ее члены могли выводить машины из домена? Разрешение на ввод в домен есть, а вот вывести из домена получается не всегда. Есть несколько OU, после ввода в домен компьютеры раскидываются из «Computers» по этим OU.
Делегируйте следующие разрешения на нужную OU с компьтерами: Create Computer Objects и Delete Computer Objects
Указанных привилегий достаточно для присоединения к домену только компьютеров с ОС Windows. Для успешного присоединения к домену для компьютеров с Windows и Linux требуются разные наборы минимальных прав.
Нужно отобразить разрешения General и Property-specific и выбрать следующие наборы.
Стандартные разрешения (для компьютеров с Linux и Windows):
-Reset password
-Read and write account restrictions
-Validated write to DNS host name
-Validated write to service principal name
-Read and write DNS host name attributes
Дополнительные разрешения (для компьютеров с Linux):
-Read dNSHostName
-Write dNSHostName
-Read msDS-AddtionalSamAccountName
-Write msDS-AddtionalSamAccountName
-Read msDS-SupportedEncryptionTypes
-Write msDS-SupportedEncryptionTypes
-Read Operating System
-Write Operating System
-Read Operating System Version
-Write Operating System Version
-Read OperatingSystemServicePack
-Write OperatingSystemServicePack
-Read servicePrincipalName
-Write servicePrincipalName
-Read userAccountControl
-Write userAccountControl
-Read userPrincipal Name
-Write userPrincipal Name
Здравствуйте, коллеги, прошу помочь. Настроена терминальная ферма в домене, есть необходимость дать возможность программистам подключаться из Консоли управления серверами посредством (тень) к пользователям терминальной фермы, но, для этого им необходимо дать права администратора что бы эту консоль как минимум настроить в их учётных записях, но получив права администратора они могут попасть на контроллер домена, его не очень хочется. Как настроить такое разграничение?
Спасибо.
Про предоставление прав на теневое подключение не-админам здесь https://winitpro.ru/index.php/2014/02/12/rds-shadow-v-windows-2012-r2/
Спасибо за ответ, я читал эту статью, но это больше касается Standalone сервера, вне фермы, а вот как получить доступ к управлению пользователями из консоли фермы терминалов, что бы зайдя увидеть список пользователей в коллекциях и от туда уже подключиться. Ну, хотя бы посмотреть какой пользователь на каком сервере. Я перепробовал разные права назначать, но это доступно только администратору домена. Спасибо.
Добрый день! Подскажите пожалуйста каким образом вы организовали смену даты публикации в статье, после ее актуализации. Вижу, что комментарии от 2019 года, а дата статьи 2022. Был бы очень признателен.
Иван, для этого нужно поправить код в вашем шаблоне wordpress. Заменить дату поста на дату последнего обновления. это встроенные атрибуты.
Выберите из списка один из преднастроенных наборов привилегий (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.
Слышь, любитель ангийского — ты напиши перевод ? в скобочках.
Подскажите есть сервер он котроллер домена и терминальный сервер. Когда пользователь подключается по RDP и пытается запустить диспетчер задач у него система просит права администратора. как запускать диспетчер задача без прав админа?
Вот тут описано как подавить запрос UAC на повышение привелегий:
https://winitpro.ru/index.php/2018/06/28/zapusk-programmy-bez-prav-admina-i-zaprosa-uac/
Существует ли способ сделать учетную запись администратором для рабочих станций, при этом ограничив эту запись обычными правами на серверах?
Сделай через GPO, создай политику на контейнер, а в ней сделай чтобы учетка или группа учеток попадала в группу локальных админов на компах в этом контейнере.
+ Главное, разнести сервера и рабочие станции по разным OU. Либо если это не получится, сделать для политики wmi фильтр, чтобы политика применяласт только к рабочим станциям.
Добавление в админы через GPO: https://winitpro.ru/index.php/2019/11/27/gpo-dobavit-v-gruppu-lok-admins/
WMI фильтры: https://winitpro.ru/index.php/2012/01/13/filtraciya-gruppovyx-politik-s-pomoshhyu-wmi-filtrov/
Добрый день!
Что можно сделать с следующем случае:
Я делегирую права на создание пользователей и ввод их в определенную доменную группу простому юзеру (без прав администратора домена).
В таком случае этот юзер сможет добавить сам себя в администраторы домена? Как это запретить?
И такой вопрос — самое простое, как создать юзера со стандартными правами доступа — это создать новую учетку копированием с уже существующей. При этом новая учетка будет входить во все группы, в которые входила существующая. Для это потребуется выдавать отдельные разрешения (на создание учетки копированием)?
Не проще ли добавить юзера, которому мы хотим делегировать полномочия в стандартную доменную группу Account Operators? По сути, она предоставит все наиболее часто используемые права: создать, заменить пароль, разблокировать учетку, удалить юзера (если требуется переименование учетки или просто удалить).
Как делегировать работу с ДХЦП? Только удалять ПК из нее, создавать резервирование, удалять резервирование.
Добрый день. Как можно дать доступ обычному пользователю домена запускать PowerShell от имени админа домена? Нужно для тестировщика, чтобы запускать команды в PowerShell для проверки работы терминалов (команды проходят только при запуске от имени админа, но постоянно сидеть рядом с ним не очень то хочется).
Нужно ли это делать через групповые политики для конкретного юзера или есть какой-то другой способ?
Подскажите, пожалуйста
Заранее спасибо
Вам скорее всего поможет PowerShell Just Enough Administration (JEA). Он позволяет разрешить запуск только определенных команд с правами админа для нужного пользователя.
https://winitpro.ru/index.php/2020/09/29/powershell-just-enough-administration-jea-delegirovaniye-admin-prav-polzovatelyam/
пользователей тех поддержки(создал заранее и внес туда человека) права с доступом к определённому OU с компьютерами,чтобы он мог там их перемещать. Не понимаю ,что за права надо дать» Delete User objects, Write Distinguished Name, Write name (**), Create User (или Computer) objects. » в русской версии как это будет называться? и где это находится
Вот нашел список прав, которые нужно предоставить для переещения компьютеров, групп и пользователей между OU:
_https://social.technet.microsoft.com/wiki/contents/articles/20747.delegate-moving-user-group-and-computer-accounts-between-organizational-units-in-active-directory.aspx
Разрешения задаютсяна вкладке Permissions (Разрешения), скрин https://winitpro.ru/wp-content/uploads/2018/12/read-lockouttime-i-write-lockouttime.png
На русский язык переведите уж самостоятельно.
Это требуется сделать для объектов компьютера?Если да,у меня отсутствуют данные разрешения почему то
Да, нужно делегировать права на обхекты Cmputers в OU.
Почему нет прав — смотрите вкладку Security в свойствах OU, анализируйте текущие права, смотрите результирующие для себя.
Подскажите что выполяют эти команды и требуется ли вообще их выполнение ?
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter ‘(schemaIDGUID=*)’ -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
Get-ADObject -SearchBase «CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)» -LDAPFilter ‘(objectClass=controlAccessRight)’ -Properties name, rightsGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}
Это кусок скрипта для поиска и вывода нестандартных разрешение на OU в AD
Добрый день. Ситуация такая, есть очень ненадежный сотрудник (замечался в пакостях), но так как уволить мы не в силах его, но и давать полные права админа мы не хотим. А у него отмазка у меня нету прав пусть другие работают я ничо не могу потому что мы забрали права ит.д.. Так вот, можно ли сделать ему урезанную учетку с разрешенными действиями на примере наших задач:
— переименовывать компьютеры пользователей
— вводить пользователей в локальные админы ПК
— вводить пользователей и компьютеры в домен
— и иметь некий доступ до ldap, чтобы мы могли из ад подгружать списки лдап в тандэрбёрд, обычные пользователи не могут этого делать, а там нужна авторизация чтобы в клиенте подгружался список электронных адресов из ад.
1) это делегируется на уровне AD как описано в статье
2) Может лучше доверить это политике? Если политики нет, то для добавления в админы других людей ему придется дать самому права лок админа на компьютерах
3) аналогично 1
4) вот это странно, обычные пользователи должны видеть любые стандартные атрибуты. Возможно там что то с реализацией в thunderbird
Здравствуйте. Дальше что? Я делегировал. Как пользователю начать работать? Ему надо предоставить теперь RDP доступ к домену или как это происходит?
достаточно установить ему RSAT.
Публикую здесь в продолжении темы данной страницы, может кому пригодится.
Найти группу или пользователя в разрешения AD, в которых она применяется. Поиск ведется в заданной OU и всех дочерних OU:
$OUs=Get-ADOrganizationalUnit -Filter * -SearchBase 'OU=01-ZZZ,OU=COMPANY,DC=ИМЯДОМЕНА,DC=ru' -SearchScope Subtree
foreach ($OU in $OUs) {
(Get-Acl -Path "AD:$(($OU).distinguishedname)").Access | Select-Object @{name="organizationalUnit";expression={$OU}}, IdentityReference | Where-Object {$_.IdentityReference -Like "ИМЯДОМЕНА\имя_учетки"}}
При делегировании прав, может быть ситуация, что не все атрибуты/разрешения отображаются, они скрыты/отфильтрованы. Здесь статься, как показывать нужные атрибуты через редактирование файла dssec.dat:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/modify-filtered-properties-of-object
Это не обязательно делать на контроллерах домена, достаточно на том компе, на котором установлен RSAT.
Стоит это добавить в вашу статью.
Пример. Я потерял кучу времени на то, чтобы дать право ИТ поддержке на переименование компов, но атрибут displayName не менялся, потому что на это не было прав и в графическом интерфейсе его не было.