Сегодня разберём неочевидную, но важную тему: кто может изменять SPN в AD — и почему это может быть проблемой. Был у меня случай, когда обычный сервисный аккаунт внезапно “помог” и снёс SPN у пары серверов. Угадайте, сколько времени ушло на восстановление? 🙃
🔍 По умолчанию владельцем SPN является компьютер или учётка, которой принадлежит объект AD. Но если у пользователя есть права
Write servicePrincipalName — он может спокойно его менять.💡 Как проверить, кто может править SPN на конкретном объекте?
# Показываем ACL для объекта
$comp = Get-ADComputer -Identity "server01"
$acl = Get-ACL "AD:\$($comp.DistinguishedName)"
$acl.Access | Where-Object { $_.ActiveDirectoryRights -like "*WriteProperty*" -and $_.ObjectType -eq "bf9679c0-0de6-11d0-a285-00aa003049e2" }
📌
bf9679c0... — это GUID атрибута servicePrincipalName. Всё, что найдено — потенциальные редакторы SPN.✅ Чтобы ограничить доступ, можно:
* Убрать из ACL лишние делегирования (например, у сервисных аккаунтов).
* Создать отдельную группу SPN-админов, у которой будет право на редактирование, и только у неё.
* Мониторить изменения SPN через
Security Event Log или Auditing в AD.💬 А как ты контролируешь права на SPN? Сталкивался с ситуацией, когда “лишний” доступ ломал Kerberos или WinRM?
👉 @win_sysadmin