Блог Виталия Лещенко
Виталий Лещенко

Windows Server для самых маленьких. Часть 23: Открываем доступ через доверие на практике

Все части серии «Windows Server для самых маленьких»

Доверие из прошлой части позволяет пользователю partner аутентифицироваться в corp. Дальше начинается обычная выдача прав — с одной поправкой: не каждая группа corp примет его в члены, и от этого зависит, как выстроить цепочку от пользователя до папки. Эта часть — четыре типовых задачи, которые возникают при каждом доверии, и порядок проверки, когда всё сделано, а не работает.

Стенд тот же, что в прошлой части: наш лес corp.example.com с контроллерами dc1, dc2, dc3 и dc4, партнёрский лес partner.example.net, между ними двустороннее доверие без выборочной аутентификации; команды выполняются с рабочей станции ws1 в PowerShell 7 с RSAT (часть 15), а то, что работает только на сервере, — через Invoke-Command (часть 14). Всё, что читает каталог, журналы и права, показано с настоящим выводом. Команды, которые создают группы, общие ресурсы и права, приведены по документации, без вывода.

Кто кого принимает

Правила областей групп из части 3, в применении к чужому лесу:

Группа Пользователи и глобальные группы чужого леса Доменно-локальные группы своего домена
Доменно-локальная принимает принимает (из того же домена)
Глобальная не принимает: только субъекты своего домена не принимает
Универсальная не принимает: только субъекты своего леса не принимает
Встроенная (CN=Builtin: Administrators, Remote Desktop Users, Backup Operators — это и есть локальные группы контроллеров) принимает не принимает
Локальная на рядовом сервере (SAM) принимает принимает

Отсюда единственная рабочая схема для чужого леса: субъекты партнёра → доменно-локальная группа нашего домена → права на ресурс. Схема называется AGDLP: учётные записи (Accounts) — в глобальные группы (Global) своего домена, глобальные — в доменно-локальные (Domain Local) домена ресурса, а права (Permissions) выдаются доменно-локальным. Глобальная группа здесь — группа партнёра, её ведёт его администратор; наша универсальная группа в этой цепочке не участвует вовсе.

Встроенные группы — особый случай. Модуль показывает их как доменно-локальные, но в groupType у них есть ещё бит 0x1 — BUILTIN_LOCAL_GROUP:

PS C:\> Get-ADGroup Administrators -Properties groupType | Format-List Name, GroupScope, GroupCategory, @{n='groupType';e={'0x{0:X8}' -f $_.groupType}}, DistinguishedName

Name              : Administrators
GroupScope        : DomainLocal
GroupCategory     : Security
groupType         : 0x80000005
DistinguishedName : CN=Administrators,CN=Builtin,DC=corp,DC=example,DC=com

0x80000005 — группа безопасности (0x80000000), доменно-локальная (0x4) и встроенная (0x1). По документации доменно-локальная группа может входить в локальные группы компьютеров своего домена, кроме встроенных групп с известными SID; контроллер на такую попытку отвечает ошибкой 8520 ERROR_DS_LOCAL_CANT_HAVE_CROSSDOMAIN_LOCAL_MEMBER («A local group cannot have another cross domain local group as a member.»). Поэтому в Administrators и Remote Desktop Users контроллеров субъекты партнёра попадают только напрямую — пользователем или его глобальной группой. Но чужие администраторы на контроллерах — это вопрос не областей групп, а того, нужны ли они там вообще.

Что происходит, когда пользователь чужого леса попадает в нашу группу: контроллер получает от клиента ссылку на член группы в виде SID (<SID=S-1-5-21-…>), не находит такого объекта у себя и, раз домен этого SID не принадлежит нашему лесу, создаёт в контейнере CN=ForeignSecurityPrincipals объект класса foreignSecurityPrincipal с именем, равным SID. Членом группы становится именно он. Сам объект хранит только SID; имя для показа инструменты каждый раз запрашивают через доверие, и если доверие сломано или удалено, в группе останется голый SID.

Создание группы и добавление в неё глобальной группы партнёра — по документации:

PS C:\> New-ADGroup -Name 'FS1-Project-RW' -GroupScope DomainLocal -Path 'OU=Groups,DC=corp,DC=example,DC=com' -Description 'Partner: чтение и запись \\fs1\project'
PS C:\> Add-ADGroupMember -Identity 'FS1-Project-RW' -Members (Get-ADGroup 'Partner Project Team' -Server partner.example.net)

Глобальную группу партнёра модуль читает -Server partner.example.net — через доверие, с нашими учётными данными. Если модуль откажется принять объект из другого леса, тот же результат даёт запись ссылки по SID напрямую через ADSI — объект foreignSecurityPrincipal контроллер создаст так же:

PS C:\> $sid = ([System.Security.Principal.NTAccount]'PARTNER\Partner Project Team').Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> ([ADSI]'LDAP://CN=FS1-Project-RW,OU=Groups,DC=corp,DC=example,DC=com').Add("LDAP://<SID=$sid>")

Как это выглядит в каталоге, видно на группе, где чужой субъект уже есть. У нас это встроенная Administrators: в ней администратор PARTNER\alice.admin, у которого учётные записи в обоих лесах. Атрибут member хранит ссылку на foreignSecurityPrincipal:

PS C:\> (Get-ADGroup Administrators -Properties member).member
CN=S-1-5-21-1711390224-2037633311-3961243089-1105,CN=ForeignSecurityPrincipals,DC=corp,DC=example,DC=com
CN=Administrator,CN=Users,DC=corp,DC=example,DC=com
CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com
CN=Enterprise Admins,CN=Users,DC=corp,DC=example,DC=com

А Get-ADGroupMember показывает не его, а сам объект партнёра — служба веб-интерфейса каталога (ADWS) на нашем контроллере разрешает SID через доверие и читает объект из каталога партнёра:

PS C:\> Get-ADGroupMember Administrators | Select-Object Name, ObjectClass, DistinguishedName

Name              ObjectClass DistinguishedName
----              ----------- -----------------
Alice Admin       user        CN=Alice Admin,OU=Members,DC=partner,DC=example,DC=net
Administrator     user        CN=Administrator,CN=Users,DC=corp,DC=example,DC=com
Domain Admins     group       CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com
Enterprise Admins group       CN=Enterprise Admins,CN=Users,DC=corp,DC=example,DC=com

Поэтому Get-ADGroupMember зависит от доверия: когда SID не разрешается, командлет может завершиться ошибкой вместо списка, а атрибут member читается всегда.

Общая папка

Задача: проектная группа партнёра читает и пишет в \\fs1\project. Цепочка: PARTNER\Partner Project Team (глобальная) → CORP\FS1-Project-RW (доменно-локальная, создана выше) → права на папку. По документации:

PS C:\> Invoke-Command fs1 {
    New-Item C:\Shares\Project -ItemType Directory -Force | Select-Object FullName
    $acl = Get-Acl C:\Shares\Project
    $acl.SetAccessRuleProtection($true, $false)
    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule('CORP\Domain Admins', 'FullControl', 'ContainerInherit,ObjectInherit', 'None', 'Allow')))
    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule('CORP\FS1-Project-RW', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')))
    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule('NT AUTHORITY\SYSTEM', 'FullControl', 'ContainerInherit,ObjectInherit', 'None', 'Allow')))
    Set-Acl C:\Shares\Project $acl
    (Get-Acl C:\Shares\Project).Access | Select-Object IdentityReference, FileSystemRights
    New-SmbShare -Name Project -Path C:\Shares\Project -FullAccess 'CORP\Domain Admins' -ChangeAccess 'CORP\FS1-Project-RW'
}

Права и на общий ресурс, и на NTFS — на доменно-локальную группу; партнёрская группа в ACL не фигурирует и не должна: при смене состава проекта меняют членство в FS1-Project-RW, а не права на тысяче папок. SetAccessRuleProtection($true, $false) отключает наследование и выбрасывает унаследованные записи — вместе с ними из ACL уходят Users и Authenticated Users с диска C:, а Authenticated Users при доверии без выборочной аутентификации включает весь чужой лес. По той же причине у New-SmbShare права перечислены явно: без них ресурс получает Everyone на чтение.

Права на общий ресурс читает Get-SmbShareAccess; так выглядит его вывод на настоящем ресурсе — NETLOGON контроллера:

PS C:\> Get-SmbShareAccess -CimSession dc1 -Name NETLOGON

Name     ScopeName AccountName            AccessControlType AccessRight PSComputerName
----     --------- -----------            ----------------- ----------- --------------
NETLOGON *         Everyone               Allow             Read        dc1
NETLOGON *         BUILTIN\Administrators Allow             Full        dc1

У Project в нём будут две строки: CORP\Domain Admins с Full и CORP\FS1-Project-RW с Change. Через -CimSession в вывод добавляется колонка PSComputerName.

Если у доверия включена выборочная аутентификация, нужен ещё один шаг — право Allowed to Authenticate на объекте компьютера fs1 для группы партнёра, как в прошлой части. Без него пользователь партнёра не пройдёт аутентификацию на fs1, а ошибка будет ERROR_AUTHENTICATION_FIREWALL_FAILED (1935): «The computer you are signing into is protected by an authentication firewall. The specified account is not allowed to authenticate to the computer.»

Администрирование сервера

Задача: инженеры партнёра администрируют app1, на котором стоит их приложение. Цепочка: PARTNER\Partner Engineers → CORP\App1-Admins (доменно-локальная) → локальная группа Administrators на app1.

Локальную группу можно пополнить напрямую — Invoke-Command app1 { Add-LocalGroupMember -Group Administrators -Member 'CORP\App1-Admins' }, — но правильный способ — групповой политикой на OU серверов, чтобы состав локальных администраторов был задан централизованно и восстанавливался при ручной правке: Restricted Groups или Group Policy Preferences → Local Users and Groups, с действием «добавить CORP\App1-Admins в Administrators». К этому мы придём в части 24. Состав группы читает Get-LocalGroupMember; так он выглядит на нашем рядовом сервере до добавления:

PS C:\> Invoke-Command app1 { Get-LocalGroupMember Administrators } | Format-Table ObjectClass, Name, PrincipalSource -AutoSize

ObjectClass Name               PrincipalSource
----------- ----               ---------------
User        APP1\Administrator Local
Group       CORP\Domain Admins ActiveDirectory

После добавления в списке появится строка Group CORP\App1-Admins ActiveDirectory. Колонки здесь перечислены явно: объекты из Invoke-Command приходят десериализованными, без представления по умолчанию, и без Format-Table таблица покажет все свойства вместе с SID, PSComputerName и RunspaceId.

Доменно-локальная группа на рядовом сервере работает так: KDC нашего домена, выдавая сервисный билет на app1, добавляет в PAC доменно-локальные группы corp, в которые входит пользователь или его группы, — в том числе группы партнёра, лежащие в них через foreignSecurityPrincipal. Сервер видит в билете SID CORP\App1-Admins и разворачивает по нему членство в своей локальной группе.

Что получают инженеры партнёра: полные права на app1 и, через них, возможность извлечь из его памяти учётные данные всех, кто на него входил, — поэтому администраторы corp входят на app1 с Remote Credential Guard или не входят вовсе (часть 15), а app1 живёт на уровне доверия партнёра, а не нашего. Для контроллеров домена этот сценарий не рассматривается; если партнёру нужно что-то на контроллере — это JEA из части 14 с ограниченным набором команд, и роль в конфигурации сеанса выдаётся группе, в которой состоит группа партнёра.

RDP

Задача: пользователи партнёра подключаются к app1 по удалённому рабочему столу. Нужны два условия: право входить по RDP — членство в локальной группе Remote Desktop Users (через ту же цепочку: CORP\App1-RDP доменно-локальная) — и, при выборочной аутентификации, Allowed to Authenticate на app1. Аутентификация на уровне сети (NLA, Network Level Authentication — проверка пользователя до того, как сервер создаст сеанс) работает через доверие: клиент получает билет на TERMSRV/app1.corp.example.com по направляющему билету, как на любую другую службу. По документации:

PS C:\> New-ADGroup -Name 'App1-RDP' -GroupScope DomainLocal -Path 'OU=Groups,DC=corp,DC=example,DC=com'
PS C:\> Add-ADGroupMember 'App1-RDP' -Members (Get-ADGroup 'Partner Engineers' -Server partner.example.net)
PS C:\> Invoke-Command app1 { Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'CORP\App1-RDP'; Get-LocalGroupMember 'Remote Desktop Users' }

На рабочей станции партнёра пользователь вводит PARTNER\bob или bob@partner.example.net, и клиент RDP сам находит нужный KDC. Отдельный вопрос — лицензии RDS: каждый пользователь или устройство, подключающиеся к серверу с ролью Remote Desktop Session Host, нуждаются в клиентской лицензии (CAL). Чтобы сервер лицензирования выдавал лицензии на пользователя (Per User) пользователям другого леса, между лесами нужно двустороннее доверие, а сервер лицензирования должен состоять в группе Terminal Server License Servers домена этих пользователей — то есть в домене партнёра, куда его добавляет администратор партнёра. Для административных подключений к серверу без роли Session Host (два сеанса) лицензии не нужны.

SQL Server

Задача: приложение партнёра, работающее под учётной записью PARTNER\svc-app, или его аналитики со своими учётными записями ходят в SQL Server на sql1. SQL Server принимает Windows-имена из доверенных доменов, и группа тут удобнее отдельных имён. По документации:

CREATE LOGIN [CORP\SQL1-Analysts] FROM WINDOWS;
USE Sales;
CREATE USER [CORP\SQL1-Analysts] FOR LOGIN [CORP\SQL1-Analysts];
ALTER ROLE db_datareader ADD MEMBER [CORP\SQL1-Analysts];
EXEC xp_logininfo 'PARTNER\bob', 'all';

xp_logininfo показывает, через какую группу пользователь получает вход, — удобно для проверки цепочки. Аутентификация к SQL через доверие идёт по Kerberos, если у sql1 зарегистрирован SPN MSSQLSvc/sql1.corp.example.com:1433 (часть 6) и клиент может получить направляющий билет; иначе — по NTLM, который через доверие между лесами тоже работает, но без делегирования и с проверкой каждого входа через защищённые каналы контроллеров обоих лесов. При выборочной аутентификации право Allowed to Authenticate для Kerberos выдаётся на учётной записи, под которой работает SQL Server (если это доменная учётная запись, а не сам компьютер), для NTLM — на объекте компьютера sql1. Чем вошёл клиент, видно в SQL:

SELECT c.session_id, s.login_name, c.auth_scheme
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s ON c.session_id = s.session_id;

auth_scheme = KERBEROS — всё правильно; NTLM у пользователя из доверенного леса обычно значит, что клиент не достаёт до KDC по порту 88, SPN не зарегистрирован или суффикс corp.example.com не маршрутизируется в лесу партнёра.

Когда не пускает

Доступ выдан, а пользователь партнёра получает отказ. Порядок, в котором проверять, — от сети к правам:

  1. Доверие живо? nltest /server:dc1 /sc_query:partner.example.net — состояние защищённого канала к партнёру на нашем контроллере (только читает, часть 18); то же у партнёра в обратную сторону. nltest /sc_verify и netdom trust … /verify проверяют доверие активно и при неработающем канале пересоздают его — их запускают, когда уже ясно, что сломано.
  2. Клиент партнёра находит наш лес? На его машине nltest /dsgetdc:corp.example.com — если нет, DNS партнёра не знает _msdcs.corp.example.com или файрвол закрыл 88 и 389 от его сети к нашим контроллерам. Отсюда же откат на NTLM.
  3. Выборочная аутентификация. Есть ли право Allowed to Authenticate для группы, в которой пользователь действительно состоит. Право может быть выдано отдельно (ObjectType = GUID права) или входить в полный доступ (GenericAll) и во «все расширенные права» (ExtendedRight с пустым ObjectType). Так это выглядит на нашем сервере, где выборочной аутентификации нет и отдельных записей нет:
PS C:\> (Get-Acl 'AD:\CN=APP1,OU=Servers,DC=corp,DC=example,DC=com').Access |
    Where-Object { $_.ObjectType -eq '68b1d179-0d15-4d4f-ab71-46152e79a7bc' -or ($_.ActiveDirectoryRights -match 'ExtendedRight|GenericAll' -and $_.ObjectType -eq [Guid]::Empty) } |
    Format-Table IdentityReference, AccessControlType, IsInherited, @{n='Rights'; e={"$($_.ActiveDirectoryRights)"}} -AutoSize

IdentityReference         AccessControlType IsInherited Rights
-----------------         ----------------- ----------- ------
NT AUTHORITY\SYSTEM                   Allow       False GenericAll
S-1-5-32-548                          Allow       False GenericAll
CORP\Domain Admins                    Allow       False GenericAll
CORP\Enterprise Admins                Allow        True GenericAll
BUILTIN\Administrators                Allow        True CreateChild, Self, WriteProperty, ExtendedRight, Delete, GenericRead, WriteDacl, WriteOwner

Право есть только у администраторов — через полный доступ и все расширенные права. S-1-5-32-548 — Account Operators: это встроенная группа домена, на рабочей станции такой нет, и SID остаётся неразрешённым. При выборочной аутентификации здесь должна появиться строка с группой партнёра и ExtendedRight.

  1. Цепочка групп. Пользователь в глобальной группе партнёра? Группа — в нашей доменно-локальной? Наша — в правах ресурса? На каждом шаге Get-ADGroupMember, для группы партнёра — с -Server partner.example.net. Отдельная ловушка: группа партнёра должна быть глобальной или универсальной; доменно-локальную группу партнёра наша группа не примет — она видна только в его домене.
  2. Билет устарел. Членство добавлено после того, как пользователь получил билет. Наши доменно-локальные группы добавляет в PAC наш KDC при выдаче сервисного билета, поэтому klist purge на клиенте и новое подключение к ресурсу их подтянут. Группы партнёра — в TGT, который выдал KDC партнёра, и здесь нужен выход и вход.
  3. Фильтрация SID. Если права выданы на SID из sIDHistory (после миграции), событие 4675 на нашем контроллере покажет, что он вычеркнут.
  4. Сам ресурс. Get-SmbShareAccess, Get-Acl, и на ресурсе — whoami /groups от имени пользователя, когда он всё-таки вошёл: есть ли в токене наша доменно-локальная группа.

Журнал Security на ресурсе: 4624 — вошёл, значит, дело в правах; 4625 с кодом состояния — не вошёл, и код скажет почему: 0xC000015B — пользователю не выдано право на этот тип входа (например, нет членства в Remote Desktop Users), 0xC0000413 — authentication firewall, то есть выборочная аутентификация, 0xC000006D — неверное имя или данные аутентификации. Поле Account Domain у 4624 зависит от протокола: при входе по Kerberos в нём realm партнёра заглавными буквами (PARTNER.EXAMPLE.NET), при NTLM — NetBIOS-имя (PARTNER), и фильтр по одному из них пропустит половину входов.

Смотрим руками

Все чужие субъекты, которым что-то выдано в нашем домене, и где именно:

PS C:\> Get-ADObject -SearchBase 'CN=ForeignSecurityPrincipals,DC=corp,DC=example,DC=com' -Filter 'objectClass -eq "foreignSecurityPrincipal"' -Properties memberOf |
    ForEach-Object {
        $name = try { (New-Object System.Security.Principal.SecurityIdentifier $_.Name).Translate([System.Security.Principal.NTAccount]).Value } catch { '<не разрешается>' }
        [PSCustomObject]@{ SID = $_.Name; Name = $name; MemberOf = ($_.memberOf -replace '^CN=([^,]+),.*', '$1') -join ', ' }
    } | Format-Table -AutoSize

SID                                            Name                                       MemberOf
---                                            ----                                       --------
S-1-5-21-1711390224-2037633311-3961243089-1105 PARTNER\alice.admin                        Administrators
S-1-5-17                                       NT AUTHORITY\IUSR
S-1-5-11                                       NT AUTHORITY\Authenticated Users           Users, Pre-Windows 2000 Compatible Access, Certificate Service DCOM Access
S-1-5-9                                        NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Windows Authorization Access Group
S-1-5-20                                       NT AUTHORITY\NETWORK SERVICE               IIS_IUSRS
S-1-5-4                                        NT AUTHORITY\INTERACTIVE                   Users

Пять из шести объектов — штатные: известные SID вроде Authenticated Users и INTERACTIVE тоже хранятся здесь, когда входят во встроенные группы домена, а объект без членства, как IUSR, просто лежит. Чужой субъект один — администратор партнёра в Administrators, то есть администратор на всех наших контроллерах. Имя разрешилось через доверие без всяких учётных данных: Translate спрашивает LSA рабочей станции, а та — контроллер, у которого есть доверие. Строка с <не разрешается> означала бы субъект, которого у партнёра больше нет (или сломанное доверие), — голый SID в нашей группе, его нужно убрать; Translate на таком SID бросает «Some or all identity references could not be translated.». Отчёт стоит получать регулярно: это полный список того, что чужой лес может у нас.

Сеансы на файловом сервере показывает Get-SmbSession; у пользователя партнёра в ClientUserName будет PARTNER\…. Так выглядит вывод на нашем контроллере:

PS C:\> Get-SmbSession -CimSession dc1 | Select-Object ClientComputerName, ClientUserName, NumOpens

ClientComputerName                     ClientUserName   NumOpens
------------------                     --------------   --------
[2001:db8:10:6c01:7288:e2bc:80b1:f718] CORP\alice.admin        0
[fe80::215:5dff:fe00:10]               CORP\alice.admin        0
[2001:db8:10:6c01:7288:e2bc:80b1:f718] CORP\WS1$               1
[::1]                                  CORP\alice.admin        0

Здесь только свои: администратор с рабочей станции, с другой машины и с самого контроллера ([::1]), и учётная запись компьютера WS1$ с открытым файлом. Адрес клиента по IPv6 команда показывает в квадратных скобках.

Входы из леса партнёра на наших серверах — события 4624, где Account Domain — партнёр. Отбирать их удобно фильтром XPath по имени поля, а не по номеру в Properties (часть 18), и разбирать внутри Invoke-Command: десериализованные события приходят на рабочую станцию без значений Properties:

PS C:\> Invoke-Command dc1, dc2, dc3, dc4 {
    $xp = "*[System[EventID=4624] and EventData[Data[@Name='TargetDomainName']='PARTNER.EXAMPLE.NET' or Data[@Name='TargetDomainName']='PARTNER']]"
    Get-WinEvent -LogName Security -FilterXPath $xp -ErrorAction SilentlyContinue | ForEach-Object {
        $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [PSCustomObject]@{ Domain = $d.TargetDomainName; Package = $d.AuthenticationPackageName; LogonType = $d.LogonType; Computer = $d.TargetUserName.EndsWith('$') }
    } | Group-Object Domain, Package, LogonType, Computer -NoElement
} | Sort-Object PSComputerName | Format-Table PSComputerName, Count, Name -AutoSize

PSComputerName Count Name
-------------- ----- ----
dc2                1 PARTNER.EXAMPLE.NET, Kerberos, 3, True
dc3                4 PARTNER.EXAMPLE.NET, Kerberos, 3, True
dc4               10 PARTNER.EXAMPLE.NET, Kerberos, 3, True

Все входы — сетевые (тип 3), по Kerberos, и все — компьютеры партнёра (имя на $): это те же обращения его контроллеров к нашим, у которых в прошлой части фильтрация SID вычёркивала S-1-5-9. Account Domain в них — realm PARTNER.EXAMPLE.NET, а не NetBIOS-имя: фильтр только по PARTNER не нашёл бы ничего. На dc1 за время, которое хранит его журнал, таких входов нет. Пользователь партнёра, открывший \\fs1\project, дал бы в журнале fs1 такую же строку с False в последней колонке.

Его токен на сервере, если он войдёт по RDP и выполнит whoami /groups, собирается из трёх частей: группы его домена (PARTNER\Domain Users, PARTNER\Partner Engineers) из TGT, который выдал KDC партнёра; доменно-локальные группы corp (CORP\App1-RDP, CORP\App1-Admins), которые добавил наш KDC в сервисный билет; и локальные группы app1, в которые они входят (BUILTIN\Remote Desktop Users, BUILTIN\Administrators). При выборочной аутентификации в нём будет NT AUTHORITY\Other Organization (S-1-5-1000), без неё — NT AUTHORITY\This Organization (S-1-5-15). Если CORP\App1-Admins в токене нет — цепочка оборвана на нашей стороне, и смотреть нужно шаг 4 из списка выше.

Источники

Группы и foreignSecurityPrincipals:

  • Active Directory security groups — области групп и кого они принимают, область Builtin Local, доменно-локальные группы и встроенные группы с известными SID;
  • MS-ADTS: Foreign Security Principals Container — контейнер ForeignSecurityPrincipals и объекты foreignSecurityPrincipal;
  • MS-ADTS: Processing Specifics — контроллер создаёт foreignSecurityPrincipal, когда в member записывают ссылку <SID=…>;
  • MS-SAMR: member — условия создания объекта (SID не из нашего леса) и ограничения членства по groupType;
  • MS-KILE: Domain Local Group Membership — доменно-локальные группы добавляет в PAC KDC домена ресурса при выдаче сервисного билета;
  • Security identifiers — известные SID: Authenticated Users, Interactive, This Organization, Account Operators;
  • System Error Codes (8200-8999) — ошибка 8520 ERROR_DS_LOCAL_CANT_HAVE_CROSSDOMAIN_LOCAL_MEMBER.

Выборочная аутентификация:

Ресурсы:

Команды и события:

Доверие, группы, права на ресурсы. Остался инструмент, который в этой части упоминался дважды и ни разу не разбирался, хотя без него не обходится ни один домен: централизованная настройка машин.

Дальше — часть 24: групповые политики. Из чего состоит объект политики и где он лежит, привязка, порядок применения и наследование, фильтрация по группам и WMI, gpupdate и gpresult, Central Store и административные шаблоны, Group Policy Preferences, резервное копирование политик, и модуль GroupPolicy для всего этого.

Оставить комментарий могут только зарегистрированные пользователи.

Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.

© 2006-2026 Виталий Лещенко