Windows Server с нуля 05. Пользователи, группы и подразделения (OU)

На клиентской Windows пользователи и группы хранятся на самом компьютере: их показывает оснастка «Локальные пользователи и группы» в «Управлении компьютером» (Computer Management). В домене учётные записи лежат в каталоге Active Directory на контроллерах домена, и все компьютеры видят один и тот же список. Порядок в каталоге — основа прав на папки, групповых политик и делегирования. В этой статье вы:

• создадите подразделения (OU, organizational unit), пользователей (вручную и из CSV-файла) и группы;
• научитесь сбрасывать пароли, снимать блокировки и ограничивать права помощников;
• включите корзину Active Directory и восстановите случайно удалённый объект.

Задача	Клиентская Windows	Домен Active Directory
Учётные записи	«Локальные пользователи и группы»	dsa.msc и модуль PowerShell ActiveDirectory
Где действует учётная запись	только на этом компьютере	на компьютерах домена
Требования к паролю	локальная политика	политика домена и fine-grained-политики
Права на папки	отдельным пользователям	группам по схеме AGDLP

Что нужно знать заранее

• Windows Server с нуля 03: домен, контроллер домена, вход под доменной учётной записью, группы для разовых задач уровня леса.
• Основы PowerShell: командлеты, переменные, конвейер.
• Среда статьи: домен lab.example, контроллер DC1, клиент PC1, ваша личная учётная запись администратора домена admin-lab (она состоит в Domain Admins). Команды рассчитаны на Windows PowerShell 5.1 (см. Windows Server с нуля 02); выполняйте их на DC1 или на PC1 с установленными RSAT (Remote Server Administration Tools, средства удалённого администрирования сервера).

Объекты каталога и контейнеры по умолчанию

Каталог хранит объекты: пользователей, компьютеры, группы, подразделения (OU) и служебные контейнеры.

После установки домена в нём уже есть контейнеры Users и Computers (в записи DN, distinguished name, «различающееся имя», это CN=Users,DC=lab,DC=example), встроенное подразделение Domain Controllers и контейнер Builtin со встроенными группами. Новые пользователи, созданные без указания места, попадают в Users, а компьютеры, которые вводят в домен, — в Computers. К этим контейнерам нельзя привязать групповую политику (действуют только политики уровня домена и выше), а к OU можно: поэтому свои объекты раскладывают по подразделениям, а стандартные контейнеры оставляют как есть.

OU — самый низкий контейнер, к которому можно привязать групповую политику; на уровне OU же делегируют права. Отсюда и правило проектирования.

Структура OU: по задачам, а не по оргсхеме

Заводите OU там, где вы собираетесь (а) применять разные групповые политики или (б) отдавать управление разным людям. Копировать оргсхему отдел за отделом не нужно: глубокая вложенность усложняет наследование политик. Полезно разделять объекты по типу: если в OU лежат только пользователи или только компьютеры, ненужную половину политики можно отключить, и обработка идёт быстрее.

Для lab.example хватит такой схемы:

lab.example
├── Domain Controllers   встроенное, контроллеры домена
├── Staff                пользователи-сотрудники
├── Groups               группы безопасности
├── Servers              FS1, WSUS1 и другие серверы-члены домена
├── Workstations         PC1, PC2 и другие рабочие станции
└── Service              служебные учётные записи (svc-dhcp-dns)

Принадлежность к отделу (бухгалтерия) выражается группой GG-Accounting, а не отдельным OU: доступ к ресурсам даётся через группы, а OU отвечает за политики и делегирование. Служебные учётные записи (под которыми работают службы, а не люди) держат отдельно от сотрудников: правила паролей у них другие.

Практика: создаём OU

В консоли «Пользователи и компьютеры Active Directory» (dsa.msc) выберите домен, затем «Действие» → «Создать» → «Подразделение» (Organizational Unit; название по русскому интерфейсу, в документации не подтверждено). Оставьте включённым флажок «Защита от случайного удаления» (в английском интерфейсе — Protect object against accidental deletion). То же самое в PowerShell, с проверкой, чтобы повторный запуск ничего не дублировал:

$base = (Get-ADDomain).DistinguishedName
$names = 'Staff', 'Groups', 'Servers', 'Workstations', 'Service'
foreach ($name in $names) {
    $found = Get-ADOrganizationalUnit -Filter "Name -eq '$name'" `
        -SearchBase $base -SearchScope OneLevel
    if (-not $found) {
        New-ADOrganizationalUnit -Name $name -Path $base
    }
}

New-ADOrganizationalUnit по умолчанию создаёт OU под защитой от случайного удаления. Проверка:

Get-ADOrganizationalUnit -Filter "Name -ne 'Domain Controllers'" `
    -Properties ProtectedFromAccidentalDeletion |
    Format-Table Name, ProtectedFromAccidentalDeletion -AutoSize

Пример вывода:

Name         ProtectedFromAccidentalDeletion
----         -------------------------------
Staff                                   True
Groups                                  True
Servers                                 True
Workstations                            True
Service                                 True

Пользователи

Вручную: оснастка dsa.msc

Выберите OU Staff, затем «Действие» → «Создать» → «Пользователь». На первой странице обязательны «Полное имя» и «Имя входа пользователя», на второй задают пароль и флажки: «Пользователь должен изменить пароль при следующем входе» (оставьте включённым для временного пароля), «Срок действия пароля никогда не истекает», «Учётная запись отключена».

PowerShell: одна учётная запись

Пароль не пишем в команду: Read-Host -AsSecureString спросит его при запуске и не покажет на экране.

$base = (Get-ADDomain).DistinguishedName
$dns  = (Get-ADDomain).DNSRoot
$pw   = Read-Host -AsSecureString 'Временный пароль для ivanov'
$params = @{
    Name                  = 'Ivan Ivanov'
    GivenName             = 'Ivan'
    Surname               = 'Ivanov'
    SamAccountName        = 'ivanov'
    UserPrincipalName     = "ivanov@$dns"
    Path                  = "OU=Staff,$base"
    AccountPassword       = $pw
    ChangePasswordAtLogon = $true
    Enabled               = $true
}
New-ADUser @params

Здесь три разных имени: два имени входа и имя объекта. SamAccountName — короткое имя для формы LAB\ivanov (для совместимости со старыми системами не длиннее 20 символов), UserPrincipalName (UPN) — запись вида ivanov@lab.example, Name — имя объекта в каталоге. Параметр -Enabled $true нужен обязательно: учётная запись с паролем, но без этого параметра остаётся отключённой. Если пароль не прошёл политику, учётная запись всё равно создаётся (без пароля и отключённой), и пароль задают позже командой Set-ADAccountPassword. Проверка:

Get-ADUser -Identity ivanov |
    Format-List Name, SamAccountName, UserPrincipalName, Enabled,
        DistinguishedName

Пример вывода:

Name              : Ivan Ivanov
SamAccountName    : ivanov
UserPrincipalName : ivanov@lab.example
Enabled           : True
DistinguishedName : CN=Ivan Ivanov,OU=Staff,DC=lab,DC=example

Пакетное создание из CSV

Список сотрудников удобно вести в таблице. Файл users.csv (CSV, значения через запятую; кодировка UTF-8) без паролей:

GivenName,Surname,SamAccountName,Department
Ivan,Ivanov,ivanov,Sales
Maria,Petrova,petrova,Accounting
Petr,Sidorov,sidorov,Sales

Скрипт читает файл, пропускает уже существующих пользователей и спрашивает временный пароль один раз при запуске. Параметр WhatIf в списке сделан «предохранителем»: с ним команда только показывает, что она сделала бы.

$base = (Get-ADDomain).DistinguishedName
$dns  = (Get-ADDomain).DNSRoot
$pw   = Read-Host -AsSecureString 'Временный пароль для новых учётных записей'
Import-Csv -Path .\users.csv -Encoding UTF8 | ForEach-Object {
    if (Get-ADUser -Filter "SamAccountName -eq '$($_.SamAccountName)'") {
        Write-Host "Уже есть: $($_.SamAccountName)"
        return
    }
    $params = @{
        Name                  = "$($_.GivenName) $($_.Surname)"
        GivenName             = $_.GivenName
        Surname               = $_.Surname
        SamAccountName        = $_.SamAccountName
        UserPrincipalName     = "$($_.SamAccountName)@$dns"
        Department            = $_.Department
        Path                  = "OU=Staff,$base"
        AccountPassword       = $pw
        ChangePasswordAtLogon = $true
        Enabled               = $true
        WhatIf                = $true   # после проверки уберите эту строку
    }
    New-ADUser @params
}

Сначала запустите скрипт как есть и прочитайте сообщения What if, затем удалите строку с WhatIf и запустите снова: ivanov уже создан, скрипт его пропустит, а petrova и sidorov добавит. Все новые сотрудники получают один временный пароль, и пока они его не сменили, любой, кто его знает, может войти под чужой записью. Передавайте пароль лично или по защищённому каналу. Надёжнее создавать записи отключёнными (Enabled = $false) и включать в день выдачи: Enable-ADAccount -Identity petrova.

Служебная учётная запись

Службы (например, DHCP, которая обновляет записи в DNS) работают под отдельной учётной записью, а не под записью человека или администратора домена. Создадим svc-dhcp-dns в OU Service; зачем она нужна, объясняет Windows Server с нуля 07:

$base = (Get-ADDomain).DistinguishedName
$pw = Read-Host -AsSecureString 'Пароль для svc-dhcp-dns'
New-ADUser -Name 'svc-dhcp-dns' -SamAccountName 'svc-dhcp-dns' `
    -Path "OU=Service,$base" -AccountPassword $pw `
    -PasswordNeverExpires $true -Enabled $true

«Срок действия пароля не ограничен» (-PasswordNeverExpires) допустим только для служебной записи: в день истечения пароля служба иначе перестала бы работать. Взамен задайте длинный случайный пароль и храните его в менеджере паролей. Для обычных сотрудников этот флажок не включают.

Политика паролей

Требования к паролю домена задаёт политика, привязанная к домену, — по умолчанию Default Domain Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy (в русской консоли разделы переведены). Действующие значения покажет командлет:

Get-ADDefaultDomainPasswordPolicy |
    Format-List ComplexityEnabled, MinPasswordLength, PasswordHistoryCount,
        MaxPasswordAge, LockoutThreshold

Пример вывода при значениях по умолчанию из документации Microsoft (страницы относятся к Windows 10 и 11, на Windows Server 2025 проверьте командлетом):

ComplexityEnabled    : True
MinPasswordLength    : 7
PasswordHistoryCount : 24
MaxPasswordAge       : 42.00:00:00
LockoutThreshold     : 0

Порог блокировки 0 означает, что учётные записи не блокируются никогда; блокировки разбирает Windows Server с нуля 12. Как открыть Default Domain Policy и сделать копию перед правкой, описывает Windows Server с нуля 06.

Для особых случаев есть fine-grained password policy (FGPP, гранулярная политика паролей): объект, который применяется к пользователям и глобальным группам безопасности. Важные свойства:

• к OU политику напрямую привязать нельзя; для OU заводят «теневую» глобальную группу;
• если пользователю подходит несколько политик, побеждает назначенная ему напрямую; если прямых нет, из политик его глобальных групп выбирается та, у которой значение Precedence меньше. Настройки разных политик не суммируются;
• в политике нужно задать все параметры (пароль и блокировка), а домен должен работать на функциональном уровне не ниже Windows Server 2008.

Попробуем на учебной группе, а не на реальных администраторах (значения иллюстративные):

$base = (Get-ADDomain).DistinguishedName
if (-not (Get-ADGroup -Filter "Name -eq 'GG-PSO-Test'")) {
    New-ADGroup -Name GG-PSO-Test -GroupScope Global `
        -GroupCategory Security -Path "OU=Groups,$base"
}
Add-ADGroupMember -Identity GG-PSO-Test -Members sidorov
$pso = @{
    Name                        = 'PSO-Strict'
    Precedence                  = 10
    ComplexityEnabled           = $true
    ReversibleEncryptionEnabled = $false
    MinPasswordLength           = 14
    PasswordHistoryCount        = 24
    MinPasswordAge              = '1.00:00:00'
    MaxPasswordAge              = '60.00:00:00'
    LockoutThreshold            = 10
    LockoutObservationWindow    = '0.00:30:00'
    LockoutDuration             = '0.00:30:00'
}
New-ADFineGrainedPasswordPolicy @pso
Add-ADFineGrainedPasswordPolicySubject -Identity PSO-Strict `
    -Subjects GG-PSO-Test
Get-ADUserResultantPasswordPolicy -Identity sidorov

Последняя команда показывает итоговую политику пользователя. Откат — по строке на шаг: Remove-ADFineGrainedPasswordPolicySubject -Identity PSO-Strict -Subjects GG-PSO-Test, затем Remove-ADFineGrainedPasswordPolicy -Identity PSO-Strict.

Для реальных администраторов политику применяют к группе Domain Admins, но осторожно: порог блокировки позволяет злоумышленнику намеренно блокировать учётные записи (документация описывает такую атаку), поэтому заранее продумайте запасной вход.

Блокировки, сброс пароля, увольнение

Если порог блокировки включён, неверные пароли блокируют учётную запись, и пользователь звонит вам. Найдите заблокированных и разблокируйте:

Search-ADAccount -LockedOut | Select-Object Name, SamAccountName
Unlock-ADAccount -Identity ivanov

В dsa.msc те же действия — «Действие» → «Сброс пароля…», где есть флажок разблокировки учётной записи. Забытый пароль сбрасывают так (старый пароль не нужен благодаря -Reset):

$new = Read-Host -AsSecureString 'Новый временный пароль'
Set-ADAccountPassword -Identity ivanov -Reset -NewPassword $new
Set-ADUser -Identity ivanov -ChangePasswordAtLogon $true

Уволенного сотрудника не удаляют сразу: Disable-ADAccount -Identity ivanov отключает вход, а данные и членство в группах остаются. Удаляют позже, когда убедились, что учётная запись не нужна.

Группы

Каталог знает два типа групп: группы безопасности (на них выдают права на ресурсы и права пользователей) и группы рассылки (только для почты, в списки доступа не входят). Для прав всегда используйте группы безопасности. Помимо типа, у группы есть область действия:

Область	Кто может быть членом	Где можно выдавать права
Domain Local (локальная в домене)	учётные записи и группы Global/Universal из любого домена леса и доверенных доменов; другие Domain Local того же домена	только в своём домене
Global (глобальная)	учётные записи своего домена и другие Global того же домена	в любом домене леса и доверенных доменах
Universal (универсальная)	учётные записи, Global и Universal любого домена леса	в любом домене леса

В одном домене, как наш lab.example, Universal-группы почти не нужны.

Схема AGDLP

Из таблицы вытекает правило, которое в профессиональной среде сокращают до AGDLP: Accounts (учётные записи) входят в Global-группы по ролям, те — в Domain Local-группы по ресурсам, а Permissions (права) выдают именно доменным локальным группам. Сокращения AGDLP в документации Microsoft нет, но сама практика описана в спецификации протоколов Windows (там она названа AGLP). В нашей сети:

• petrova входит в глобальную группу GG-Accounting (роль «бухгалтерия»); ivanov — обычный сотрудник и в GG-Accounting не входит;
• все сотрудники (ivanov, petrova и остальные из OU Staff) входят в глобальную группу GG-Staff;
• GG-Accounting входит в доменную локальную группу DL-Accounting-Modify, а GG-Staff — в DL-Public-Modify;
• этим двум доменным локальным группам в Windows Server с нуля 08 выдают права на D:\Shares\Accounting и D:\Shares\Public.

Новый бухгалтер добавляется в одну группу, и всё работает. Группа GG-Staff собирает именно сотрудников: встроенная Domain Users включает все учётные записи пользователей, в том числе служебные.

Создадим все группы в OU Groups (GG-HelpDesk понадобится ниже, для делегирования):

$base = (Get-ADDomain).DistinguishedName
$groups = @(
    @{ Name = 'GG-Accounting';        Scope = 'Global' },
    @{ Name = 'GG-Staff';             Scope = 'Global' },
    @{ Name = 'GG-HelpDesk';          Scope = 'Global' },
    @{ Name = 'DL-Accounting-Modify'; Scope = 'DomainLocal' },
    @{ Name = 'DL-Public-Modify';     Scope = 'DomainLocal' }
)
foreach ($g in $groups) {
    if (-not (Get-ADGroup -Filter "Name -eq '$($g.Name)'")) {
        New-ADGroup -Name $g.Name -GroupScope $g.Scope `
            -GroupCategory Security -Path "OU=Groups,$base"
    }
}
Add-ADGroupMember -Identity GG-Accounting -Members petrova
Add-ADGroupMember -Identity GG-Staff `
    -Members (Get-ADUser -Filter * -SearchBase "OU=Staff,$base")
Add-ADGroupMember -Identity DL-Accounting-Modify -Members GG-Accounting
Add-ADGroupMember -Identity DL-Public-Modify -Members GG-Staff

Проверка: Get-ADGroupMember -Identity GG-Accounting | Select-Object Name, SamAccountName должна показать только petrova.

Встроенные группы

Группы по умолчанию лежат в контейнерах Builtin и Users и уже наделены правами. В русскоязычной системе они называются по-русски (Domain Admins — «Администраторы домена», Enterprise Admins — «Администраторы предприятия»), и команды с английским именем такую группу не найдут.

Самая опасная — Domain Admins: её участники управляют всем доменом, и по умолчанию они администраторы на каждом компьютере домена. Для больших сред Microsoft описывает идеал так: группа почти пуста, а нужные люди добавляются в неё временно. В небольшой фирме достаточно одной-двух личных административных учётных записей вроде admin-lab, которыми пользуются только для администрирования, а не для почты и браузера. Не добавляйте в Domain Admins помощников и службы: для узких задач есть делегирование. Состав группы проверяйте: Get-ADGroupMember 'Domain Admins' | Select-Object Name. Для некоторых разовых операций уровня леса (авторизация DHCP, возможно, включение корзины AD) может понадобиться больше прав, чем у Domain Admins; как получить их безопасно, объясняет врезка «Кто чем может» в Windows Server с нуля 03.

Делегирование прав на OU

Помощнику, который сбрасывает пароли, не нужны права администратора домена. Схема: объекты лежат в OU, помощники входят в группу, а нужные задачи на этом OU делегируют группе. Для проверки создайте тестового помощника helper1 в OU Staff по образцу раздела «PowerShell: одна учётная запись» и добавьте его в уже созданную GG-HelpDesk:

Add-ADGroupMember -Identity GG-HelpDesk -Members helper1

Затем группе дают сброс паролей в Staff мастером:

1. В dsa.msc выберите OU Staff, затем «Действие» → «Делегирование управления…» (Delegate Control). Запустится мастер делегирования элементов управления.
2. На странице «Пользователи или группы» добавьте GG-HelpDesk.
3. На странице «Задачи для делегирования» выберите «Сброс паролей пользователей и принудительная смена пароля при следующем входе в систему» и нажмите «Готово».

Права действуют на все объекты внутри Staff, а в других OU помощник бессилен. Проверьте: войдите на PC1 (с RSAT) как helper1; сброс пароля у petrova должен получиться, а у учётной записи вне Staff — закончиться отказом. Итоговые права видны в свойствах OU на вкладке Security (если её нет, включите Advanced Features в меню «Вид»); откатить делегирование можно, удалив оттуда записи группы GG-HelpDesk. Встроенную группу Account Operators в «помощники» не берите: её участники создают и меняют большинство учётных записей и входят локально на контроллеры домена.

Корзина Active Directory и защита от удаления

Без корзины удалённый объект восстановить непросто: нужна резервная копия, а «реанимированный» объект теряет часть атрибутов и членство в группах. Корзина Active Directory (Recycle Bin) хранит удалённые объекты со всеми атрибутами, так что пользователь возвращается и в свои группы. Что важно знать:

• корзина по умолчанию выключена, требует функциональный уровень леса не ниже Windows Server 2008 R2 и включается необратимо; файл базы данных AD (NTDS.DIT) на контроллерах после этого растёт;
• восстановить можно только объект, удалённый после включения и пока не истёк срок хранения: его задаёт атрибут msDS-deletedObjectLifetime, по умолчанию равный tombstoneLifetime (180 дней в лесах, созданных на Windows Server 2003 SP1 и новее; проверьте оба значения у себя);
• это не замена резервной копии: когда срок вышел, объект можно вернуть только из бэкапа (Windows Server с нуля 11).

Включение выполняют на контроллере с ролью Domain Naming Master (одна из ролей FSMO; у нас это DC1). Какая группа нужна, Microsoft указывает по-разному: статья про включение корзины требует Domain Admins, более старая статья про Active Directory Administrative Center (ADAC, центр администрирования AD, dsac.exe) — Enterprise Admins. Начните под admin-lab; при отказе в доступе действуйте по врезке в Windows Server с нуля 03. Сначала пробный прогон, затем боевой запуск; если команда запросит подтверждение, прочитайте предупреждение о необратимости:

$params = @{
    Identity = 'Recycle Bin Feature'
    Scope    = 'ForestOrConfigurationSet'
    Target   = 'lab.example'
    Server   = 'DC1'
}
Enable-ADOptionalFeature @params -WhatIf
Enable-ADOptionalFeature @params

При ошибке соберите роли schema master и domain naming master на одном контроллере (у нас — DC1) и запустите команду с него.

Репетиция на тестовой учётной записи (без пароля она отключена, это не мешает):

$base = (Get-ADDomain).DistinguishedName
New-ADUser -Name 'Test Restore' -SamAccountName test-restore `
    -Path "OU=Staff,$base"
Remove-ADUser -Identity test-restore
Get-ADObject -Filter 'samAccountName -eq "test-restore"' `
    -IncludeDeletedObjects | Restore-ADObject
Get-ADUser -Identity test-restore | Select-Object Name, DistinguishedName

Remove-ADUser может запросить подтверждение. Если вернулась запись в OU=Staff, корзина работает; тестовую учётную запись можно удалить. Удалённый OU с содержимым восстанавливают по порядку: сначала сам OU, потом вложенные объекты, ведь потомка нельзя вернуть раньше родителя, а ADAC не умеет восстанавливать дерево одним действием.

Второй рубеж — защита от случайного удаления: пока она включена, OU не удалить. Снять её можно так: Set-ADOrganizationalUnit -Identity "OU=Staff,$base" -ProtectedFromAccidentalDeletion $false. Осторожно: Remove-ADOrganizationalUnit -Recursive удаляет и вложенные объекты, даже если они защищены.

Компьютеры в нужных OU

Компьютер, введённый в домен штатным способом, попадает в контейнер Computers, к которому нельзя привязать групповую политику. Переместите его в подходящее OU:

$base = (Get-ADDomain).DistinguishedName
Get-ADComputer -Identity PC1 |
    Move-ADObject -TargetPath "OU=Workstations,$base"

Заранее создать учётную запись компьютера (она не вводит компьютер в домен) можно командой New-ADComputer -Name PC3 -Path "OU=Workstations,$base". Серверы FS1 и WSUS1 аналогично переместите в Servers; контроллеры остаются в Domain Controllers. Перенос в другое OU меняет набор применяемых политик: перед массовым перемещением проверьте, какие политики привязаны к OU назначения.

Необязательно: новые компьютеры сразу в нужное OU

Командой redircmp контейнер для новых компьютеров перенаправляют в Workstations: так попадают компьютеры, созданные старыми способами, например мастером ввода в домен.

Get-ADDomain | Select-Object ComputersContainer

Затем в консоли PowerShell с повышенными правами под администратором домена (команда вносит изменение на контроллере с ролью эмулятора PDC, он должен быть доступен):

redircmp "OU=Workstations,$((Get-ADDomain).DistinguishedName)"

Для возврата повторите redircmp с записанным значением (примера для CN=Computers в документации нет, проверьте на тестовом домене).

Типичные ошибки и недоразумения

• Пользователь создан, но не может войти. Скорее всего, учётная запись отключена: не задан -Enabled $true или пароль не прошёл политику.
• Права на папку выданы отдельным людям. Через год никто не помнит, кому что можно: выдавайте права группам по схеме AGDLP.
• Удалили OU, а корзина не включена. Объекты, удалённые до включения корзины, из неё не вернуть; включите её заранее, а при восстановлении начинайте с родителя.
• Перенесли компьютер, и пропал сетевой диск или принтер. Он оказался под другими политиками; разберётесь по Windows Server с нуля 06.

Проверьте себя

1. Почему свои учётные записи и компьютеры лучше хранить в OU, а не в контейнерах Users и Computers? К OU можно привязывать групповые политики и делегировать права, к контейнерам Users и Computers политику привязать нельзя.
2. Что означает схема AGDLP и кому выдают права на папку? Accounts → Global groups → Domain Local groups → Permissions: учётные записи входят в глобальные группы по ролям, те — в доменные локальные по ресурсам, а права на папку выдают доменной локальной группе (у нас DL-Accounting-Modify).
3. Какую группу выберете для помощника, который только сбрасывает пароли в Staff, и как дадите ему права? Отдельную группу (например, GG-HelpDesk), без Domain Admins; права выдаёт мастер делегирования на OU Staff, задача «Сброс паролей пользователей…».
4. Что нужно сделать до того, как случайное удаление пользователя станет обратимым, и можно ли отключить корзину обратно? Включить корзину Active Directory (Enable-ADOptionalFeature, уровень леса не ниже 2008 R2): вернуть можно только объекты, удалённые после включения. Отключить корзину нельзя: включение необратимо.
5. Какая политика побеждает, если пользователю подходят несколько fine-grained-политик, и можно ли применить такую политику к OU Staff? Побеждает политика, назначенная пользователю напрямую; если прямых нет, берётся политика его глобальных групп с меньшим Precedence. К OU напрямую нельзя: политика действует на пользователей и глобальные группы, для OU заводят «теневую» группу.

Что дальше

• Групповые политики (GPO): основы и типовые настройки — настройки для созданных OU.
• Файловый сервер: общие папки, права NTFS, квоты — права для доменных локальных групп из этой статьи.
• Резервное копирование Windows Server и контроллера домена — что делать, когда корзины уже недостаточно.
• Безопасность и обслуживание — блокировки, отдельные учётные записи администратора, аудит.

Источники

• Управление учётными записями пользователей в «Пользователи и компьютеры Active Directory» (ru-ru) — создание пользователей, сброс пароля, вкладки свойств, Advanced Features; русские названия окон и флажков (машинный перевод)
• New-ADUser — параметры AccountPassword, Enabled, Path, SamAccountName, PasswordNeverExpires, метод с Import-Csv
• New-ADOrganizationalUnit — защита от случайного удаления по умолчанию
• Remove-ADOrganizationalUnit — защита OU и поведение -Recursive
• Active Directory Security Groups — типы и области групп, таблица членства, встроенные группы
• MS-AUTHSOD: Group Scope — группа на ресурс, схема AGLP
• Minimum password length — расположение параметра и значение по умолчанию (страница для Windows 10 и 11; соседние страницы раздела — для истории, срока, сложности)
• Account lockout threshold — смысл порога блокировки, значение 0 по умолчанию, риск отказа в обслуживании
• AD DS: Fine-Grained Password Policies (архив, WS 2008) — применимость, Precedence, итоговая политика
• Delegation of control in AD DS — шаги мастера делегирования, список задач, принцип «OU + группа»
• Implementing Least-Privilege Administrative Models — Domain Admins и минимальные привилегии
• Enable and use Active Directory Recycle Bin — требования, включение, восстановление, действия при ошибке
• Advanced AD DS Management Using Active Directory Administrative Center — сроки хранения, рост NTDS.DIT, порядок восстановления родителей и потомков
• Redirect the users and computers containers in Active Directory domains — redircmp, защита OU, ограничения
• PowerShell 7 module compatibility in Windows Server 2025 — статус модуля ActiveDirectory