Для системного администратора

Тема SID-а разжёвана в сети уже многократно, но почему-то к ней приходится возвращаться с удручающей постоянностью, когда выясняется, что многие инженеры и администраторы ОС Microsoft Windows не понимают некоторых весьма важных вещей в отношении использования SID-ов и то как он применяется в системе Windows.

SID (Security IDentifier) состоит из нескольких частей (он может быть переменной длины). В начале идет “версия” SID-а, потом Генеральная область Authority – т.е. ссылка на ту систему-источник, которая отвечает за его выпуск. Версия сейчас в системах Windows всегда одна: 1, чаще всего Генеральная Authority 5 (Windows System) или 1 или 3. Однако с выходом Microsoft Exchange 2007 появилась новая Генеральная Authority – 9 (Exchange 2007). Потом в SID-е следуют один или несколько идентификаторов Sub Authority. И, в завершении, в конце может идти так называемый RID – Relative IDentificator – т.е. локальный для данного Sub Authority номер субъекта безопасности (например, учетной записи пользователя).

Таким образом, SID учетной записи обычно выглядит так: S-1-5-21-1721254763-462695806-1538882281-2605462.

Это примерно как структура ИНН – сначала код региона, потом код налогового органа выдавшего ИНН, а уже потом относительный номер налогоплательщика в данном налоговом органе.

Дополнительную информацию о SID-ах можно почерпнуть тут http://msdn2.microsoft.com/en-us/library/aa379597.aspx и соседние по содержанию темы. Следует так же отметить, что существует целая серия так называемых Well Known SID-ов (хорошо известных SID-ов). К таким SID-ам относятся SID-ы групп: Everyone, Authenticated Users, SELF, BUILTIN\Administrators, BUILTIN\Guests и другие. Достаточно полный список можно посмотреть тут: http://support.microsoft.com/kb/243330.

Так вот, в отношении SID-компьютера стоит помнить два основных факта:

• Компьютерный SID – это внутренний SID системы Windows, который представляет собой идентификатор Sub Autority для ВСЕХ локальных на данном компьютере субъектов безопасности. Он создается при инсталляции операционной системы Windows. На его основе путем добавления RID генерируются ВСЕ SID-ы локальных пользователей и групп для данного компьютера с ОС Windows. Если он поменяется – ВСЕ локальные субъекты безопасности (пользователи и группы) потеряют пава доступа, поскольку в ACL права даются именно по SID-ам. И этот SID никакого отношения к членству в домене не имеет.
• Домен тоже имеет свой Domain SID, который представляет собой область Sub Autority ВСЕГО домена. Когда вы включаете станцию/сервер или даже контроллер домена в базе данных домена (AD NTDS) создается объект типа компьютер. Этот объект выведен из класса Security Principal (субъект безопасности), так же как и класс User или Group. Это значит, что такой объект может быть участником системы безопасности Windows и получать права доступа на другие объекты и ресурсы. Именно поэтому у класса Computer (впрочем, как и у класса User) есть атрибут objectSID. Собственно этот атрибут обязательный для всех Security Principals в домене и без него они не могут существовать. Для генерации SID-ов компьютеров, пользователей и групп берется доменный SID (Domain SID) и к нему пристыковывается первый свободный RID в домене. За выделение всем Security Principals в домене уникальных SID-ов отвечает контроллер, несущий роль FSMO RID Master.

Итак, когда рабочая станция логинется в домен в ее собственном системном Access Token-е будут храниться ДВА SIDа – один SID ее доменной учетной записи компьютера, а другой локальный ее собственный SID. Билет Kerberos TGT, который при логоне получает рабочая станция, будет при этом содержать ТОЛЬКО ее Доменный SID.

Когда вы переносите станцию из домена в домен вы в принципе не можете скопировать SID из старого домена в атрибут objectSID в новом домене – это будет противоречить всей идеологии безопасности. Поэтому для объекта учетной записи компьютера в новом домене будет сгенерирован новый SID, который будет состоять из Domain SID нового домена и какого-то доступного в настоящий момент в новом домене RID-а.

Соответственно если где-то на какие-то ресурсы были даны права с использованием доменной учетной записи компьютера (а не пользователя, но такое бывает довольно часто), то при переносе из домена в домен она (станция) потеряет доступ к таким ресурсам.

В AD есть специальный атрибут sIDHistory – в который администратор домена при миграции может поместить старые SID-ы субъектов безопасности для того, что бы сохранить их доступ к тем ресурсам, где такой доступ им был назначен по их старому SID-у. При входе в систему пользователя у которого заполнен атрибут sIDHistory все SID-ы из этого атрибута так же попадают в Access Token этого пользователя. С применением технологии SID History работают утилиты: movetree и ADMT всех версий.

Утилиты NewSID и Sysprep меняют не только SID компьютера, но и соответственно SID-ы всех локальных компьютерных учетных записей и групп, а также проходят по всем ACL на всех доступных им объектах безопасности для того, что бы обновить информацию о выданных правах с учетом смены SIDов всех локальных учетных записей и групп. Именно поэтому версия sysprep обновляется с выходом каждого Service Pack и на самом деле не подходит от одной версии ОС Windows к другой.

Теперь, когда вы понимаете логику процесса, нужно сказать, что весьма важно, чтобы изменение SID-а компьютера утилитами SysPrep или NewSID происходило как можно ближе к моменту инсталляции системы (пока не сделано много особенных прав доступа, не заведено много пользователей и т.п.). Это связано с тем, что при установке на компьютер какого-то дополнительного ПО могут появиться ресурсы илли другие объекты безопасности, о существовании которых не подозревает ваша версия NewSID или SysPrep. И при смене SIDа ACL на этих объектах безопасности не будут обновлены, как следствие будут нарушены права доступа и работоспособность дополнительного ПО может быть потеряна.

На самом деле при работе в домене ничего страшного в том, что локальные SID-ы компьютеров совпадают, вроде бы нет, однако есть ряд особенностей работы системы аутентификации Windows, при которых даже в доменной среде можно будет получить доступ от одной такой клонированной машины к другой в обход настроенных прав доступа.

Именно поэтому надо при клонировании дисков SID компьютеров МЕНЯТЬ ВСЕГДА.

Что же касается доступа по SID-у компьютера – предоставить доступ по учетной записи компьютера (ее SID-у) можно только в доменной среде на основании аккаунта компьютера в AD и соответственно SID-а из AD, где как я говорил он гарантированно уникальный (при условии что у вас не падал и не восстанавливался из BackUp-а некорректным способом RID Master вместе с AD).

Дырочка в безопасности при совпадении SID-ов компьютеров может быть в доступе предоставленном локальным пользователям на разных компьютерах.

Автор: Константин Леонтьев