Миф о дублировании SID компьютера

3 ноября 2009 года Sysinternals закрыла проект NewSID - утилиты, которая предназначалась для изменения идентификатора защиты компьютера (machine SID). Я написал NewSID в 1997 году (первоначально она называлась NTSID), поскольку в то время единственным доступным инструментом для смены SID был Microsoft Sysprep, а он не поддерживал смену SID на компьютерах с уже установленными приложениями. SID компьютера - это уникальный идентификатор, генерируемый программой установки Windows Setup, который операционная система использует в качестве основы для идентификаторов SID, соответствующих локальным учетным записям и группам, определяемых администратором. После того, как пользователь осуществляет вход в систему, он представляется в системе своими идентификаторами SID пользователя и группы в соответствии с авторизацией объекта (проверки прав доступа). Если две машины имеют одинаковый SID, то учетные записи или группы на этих машинах также могут иметь одинаковые SID. Отсюда очевидно, что наличие нескольких компьютеров с одинаковыми SID в пределах одной сети может привести к угрозе безопасности, так? По крайней мере, это предположение не противоречит здравому смыслу.

Причиной, заставившей меня начать рассматривать возможность отказа от дальнейшей поддержки NewSID, стал тот факт, что, несмотря на в целом положительные отчеты пользователей о работе утилиты на Windows Vista, я не проводил полноценное тестирование ее работы лично, и, кроме того, мне пришло несколько отчетов о том, что после использования NewSID некоторые компоненты Windows завершали работу с ошибкой. Когда я принялся за изучение этих отчетов, я решил начать с попытки понять, как дублированные идентификаторы SID могут стать причиной появления проблемы, так как я не мог принять возможность этого на веру, как все остальные. Чем больше я думал об этом, тем больше убеждался в том, что дублирование SID компьютера (т.е. наличие нескольких компьютеров с одинаковыми идентификаторами SID) не влечет за собой каких-либо проблем, связанных с безопасностью или чем-либо еще. Я обсудил свое умозаключение с командами разработчиков Windows, занимающимися вопросами безопасности и развертывания систем, и никто не смог придумать сценарий, при котором две системы с одинаковыми SID, работающие в пределах рабочей группы или же домена, могли бы стать причиной ошибки. В связи с этим решение о закрытии проекта NewSID стало очевидным.

Я понимаю, что новость о том, что в дублировании SID компьютеров нет ничего плохого, станет для многих неожиданностью, особенно в связи с тем, что практика с изменением SID является фундаментальным принципом в развертывании систем из образов, начиная с первых версий Windows NT. Эта статья призвана разоблачить данный миф, для чего, во-первых, приводится объяснение понятия "SID компьютера", описывается то, как Windows использует SID, после чего наглядно показывается, что Windows (за одним исключением) никогда не предоставляет SID машины за пределами данного компьютера, что доказывает возможность существования нескольких систем с одинаковыми SID компьютера.


Идентификаторы защиты (абб. от security identifier, SID)
Windows использует идентификаторы SID для представления не только машин, но и всех остальных объектов системы безопасности. Эти объекты включают в себя машины, учетные записи домена, пользователей и групп безопасности. Имена таких объектов представляют собой лишь более понятные для пользователей формы представления SID, позволяющие вам, например, переименовать вашу учетную запись без необходимости обновлять списки управления доступом (ACL), которые ссылаются на данную учетную запись, чтобы отобразить внесенные изменения. Идентификатор SID представляет собой числовое значение переменной длины, формируемое из номера версии структуры SID, 48-битного кода агента идентификатора и переменного количества 32-битных кодов субагентов и/или относительных идентификаторов (абб. от relative identifiers, RID). Код агента идентификатора определяет агент, выдавший SID, и обычно таким агентом является локальная операционная система или домен под управлением Windows. Коды субагентов идентифицируют попечителей, уполномоченных агентом, который выдал SID, а RID — не более, чем средство создания уникальных SID на основе общего базового SID (от англ. common based SID).

Чтобы увидеть, что собой представляет SID машины, вы можете воспользоваться инструментом Sysinternals PsGetSid, запустив его через командную строку без параметров:

Здесь номер версии равен 1, код агента идентификатора - 5, а далее следуют коды четырех субагентов. В Windows NT SID использовался для идентификации компьютера в сети, вследствие чего для обеспечения уникальности идентификатор SID, генерируемый программой установки Windows Setup, содержит один фиксированный (21) и три генерируемых случайным образом (числа после "S-1-5-21") кода субагентов.

Еще до того, как вы создадите первую учетную запись, Windows определяет несколько встроенных пользователей и групп, включая учетные записи Администратор и Гость. Вместо того, чтобы генерировать новые случайные идентификаторы SID для этих учетных записей, Windows гарантирует их уникальность, добавляя к SID компьютера уникальные для каждой учетной записи числа, называемые относительными идентификаторами (Relative Identifier, RID). Для упомянутых выше встроенных учетных записей RID предопределены, так что, например, у пользователя Администратор RID всегда равен 500:

После установки системы Windows назначает новым локальным учетным записям пользователей и групп RID, начиная со значения 1000. Вы можете воспользоваться PsGetSid для того, чтобы увидеть имя учетной записи, которой принадлежит указанный SID; на скриншоте внизу вы можете видеть, что локальный SID с RID равным 1000 принадлежит учетной записи Abby - учетной записи администратора, имя которой Windows попросила меня ввести во время установки:

Помимо этих динамически создаваемых SID, Windows определяет несколько учетных записей, которые также имеют предопределенные SID. Примером может служить группа Everyone, которая в любой системе Windows имеет SID S-1-1-0:

Другой пример - учетная запись Local System, под которой выполняются некоторые системные процессы, такие как Session Manager (Smss.exe), Service Control Manager (Services.exe) и Winlogon (Winlogon.exe):

Компьютеры, объединенные в домен, также имеют доменный SID компьютера, основанный на SID домена. Вот скриншот PsGetSid, отображающей SID для домена NTDEV:

Вы можете просмотреть SID домена для учетной записи компьютера, указав имя компьютера вместе с символом "$":

Доменный идентификатор SID для моего компьютера представляет собой SID домена плюс RID 3858199. Довольно проблематично назначить двум компьютерам одинаковые доменные SID, тогда как смена только имени компьютера не окажет никакого эффекта ни на доменный, ни на обычный (локальный) SID компьютера. Если вы клонируете компьютер, подключенный к домену, то единственный способ получения уникальной доменной учетной записи - это исключение компьютера из состава домена, изменение его имени и обратное включение его в домен.


Идентификаторы SID и списки управления доступом (от англ. Access Control Lists, ACL)
После того, как пользователь вошел в систему Windows под своей учетной записью, подсистема локальной авторизации (Local Security Authority Subsystem, LSASS) создает входную сессию и маркер для нее. Маркер - это структура данных, определяемая ядром Windows для представления в системе учетной записи, содержащая в себе SID учетной записи, SID групп, к которым принадлежит данная учетная запись на момент входа в систему, а также привилегии безопасности, назначенные данной учетной записи и группам. Когда последний маркер, ссылающийся на входную сессию, удален, LSASS удаляет эту входную сессию, что означает, что пользователь вышел из системы. Ниже вы можете увидеть информацию о моей интерактивной входной сессии, отображаемой с помощью утилиты Sysinternals LogonSessions:

А на этот скриншоте вы можете видеть информацию о маркере, созданном Lsass для данной сессии, в окне Handle Process Explorer. Заметьте, что число после имени учетной записи - 7fdee - соответствует идентификатору входной сессии из LogonSessions:

По умолчанию процессы наследуют копию маркера их родительского процесса. Например, каждый процесс, запущенный в моей интерактивной сессии, имеет копию маркера, изначально унаследованного им от процесса Userinit.exe, который первым создается Winlogon при каждом интерактивном входе в систему. Вы можете посмотреть содержимое маркера процесса, сделав двойной щелчок на строке процесса в Process Explorer и переключившись на вкладку Security диалогового окна свойств процесса:

Когда один из моих процессов открывает объект операционной системы, например, файл или ключ системного реестра, подсистема защиты выполняет проверку прав доступа, которая просматривает записи списка управления доступом (ACL) объекта, ссылающиеся на SID, находящийся в маркере процесса.

Подобная проверка проходит и для сессии удаленного входа в систему, создаваемой при использовании общих ресурсов с удаленных компьютеров. Для успешного подключения к общему ресурсу вы должны пройти аутентификацию на удаленной системе с помощью учетной записи, известной этой системе. Если компьютер является частью Рабочей группы, то вам нужно вводить входные данные для локальной учетной записи удаленной системы; для системы, соединенной с доменом, входные параметры могу быть как для локальной учетной записи удаленной системы, так и для учетной записи домена. Когда вы обращаетесь к файлу на общем ресурсе, драйвер файлового сервера этой системы использует маркер из входной сессии для проверки прав доступа, усиливая тем самым механизм олицетворения.


Дублирование SID
Поддерживаемый Microsoft способ создания установки Windows, пригодный для развертывания системы для группы компьютеров, состоит в установке Windows на базовый компьютер и подготовке системы к клонированию с помощью утилиты Sysprep. Этот метод называется "обобщением образа", поскольку когда вы загружаете образ, созданный описанным способом, Sysprep запускает установку, генерируя новый SID компьютера, запуская определение установленных аппаратных средств, сбрасывая счетчик времени до активации продукта и устанавливая другие настройки системы, такие как имя компьютера.

Однако, некоторые IT-администраторы сначала устанавливают Windows на одну из своих систем, устанавливают и настраивают приложения, после чего используют инструменты развертывания, которые не сбрасывают SID на копиях установок Windows. До сих пор лучшим средством в таких случаях было использование утилит для смены SID, таких как NewSID. Эти утилиты генерируют новый SID компьютера, пытаются найти все возможные места в системе, где упоминается SID компьютера, включая всю файловую систему и ACL системного реестра, и обновляют его на новый SID. Причиной, по которой Microsoft не поддерживает подобный способ модифицирования системы, является то, что в отличие от Sysprep подобные утилиты необязательно должны знать обо всех местах, где Windows упоминает SID компьютера. Надежность и безопасность системы, использующей одновременно старый и новый SID компьютера, не могут быть гарантированы.

Так является ли проблемой наличие нескольких компьютеров с одинаковыми SID? Это возможно только в том случае, если Windows когда-либо ссылается на SID других компьютеров. Например, если во время подключения к удаленной системе SID локального компьютера был передан на одну из удаленных систем и использовался для проверки прав доступа, дублированный идентификатор SID стал бы причиной проблемы безопасности, поскольку удаленная система не смогла бы отличить SID удаленной учетной записи от такого же SID локальной учетной записи (в этом случае SID обеих учетных записей имеют одинаковые SID компьютера, являющиеся их основой, и одинаковые RID). Однако, Windows не позволяет вам проходить аутентификацию на другом компьютере, используя учетную запись, известную только локальному компьютеру. Вместо этого, вы должны использовать входные параметры или для учетной записи, локальной для удаленной системы, или для учетной записи доверенного для удаленного компьютера домена. Удаленный компьютер находит SID для локальной учетной записи в его собственной базе данных учетных записей (от англ. Security Accounts Database, SAM) и для учетной записи домена - в базе данных Active Directory на контроллере домена. Удаленный компьютер никогда не предоставляет SID компьютера подключенному компьютеру.

Иными словами, не SID предоставляет полный доступ к компьютеру, а имя пользователя и пароль учетной записи: одно только знание SID учетной записи удаленной системы не дает вам доступ к компьютеру или каким-либо его ресурсам. В качестве доказательства этому вы можете вспомнить тот факт, что встроенные учетные записи, такие как учетная запись Local System, имеют одинаковые SID на любом компьютере, что могло бы стать серьезной брешью в защите компьютера, если бы предыдущее утверждение было бы ложно.

Как я уже сказал ранее, есть одно исключение из этого правила – контроллер домена (DC). Каждый домен имеет уникальный SID домена (Domain SID), полученный из SID компьютера первого DC домена, и все SID компьютеров DC, входящих в состав домена, совпадают с SID домена. Так что, в каком-то смысле, это тот случай, когда идентификаторы SID компьютеров используются другими компьютерами. Это означает, что компьютеры, являющиеся частью домена, не могут иметь те же самые SID компьютера, что и DC и, соответственно, домен. Однако, подобно таким компьютерам, каждый DC также имеет учетную запись компьютера в домене, по которой и происходит их идентификация при аутентификации на удаленной системе. Все учетные записи в домене, включая компьютеры, пользователей и группы безопасности, имеют идентификаторы SID, основанные на SID домена, точно так же, как SID локальных учетных записей основываются на SID компьютера, однако эти два вида

Некоторые статьи про дублирование SID, включая эту, предупреждают о том, что наличие у нескольких компьютеров одинаковых SID приводит к тому, что ресурсы на сменных носителях, таких как, например, отформатированный под систему NTFS внешний жесткий диск, не могут быть защищены средствами локальной учетной записи. Авторы таких статей не учитывают тот факт, что права доступа к ресурсам на таких сменных носителях в любом случае не могут быть защищены, поскольку пользователь может подключить их к компьютерам, работающим под операционной системой, не соблюдающей правил доступа файловой системы NTFS. Кроме того, зачастую сменные носители используют заданные по умолчанию права доступа, гарантирующие доступ известным идентификаторам SID, например, SID группы Администраторов, которые одинаковы на всех системах. Это фундаментальное правило физической защиты, и именно поэтому Windows 7 включает в себя функцию Bitlocker-to-Go, позволяющую вам зашифровывать данные на сменных носителях.

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


Наиболее подходящий вариант
Немного удивительно то, что проблема дублирования SID так долго не подвергалась сомнению, при этом каждый предполагал, что кто-то другой точно знает, почему это является проблемой. К моему огорчению, на самом деле NewSID никогда не выполнял какой-либо полезной функции, так что теперь, когда поддержка этой утилиты закрыта, нет никаких причин тосковать по ней. Обратите внимание, что Sysprep сбрасывает состояние компьютера так, что в случае дублирования это может привести к проблемам в работе некоторых приложений, среди которых Windows Server Update Services (WSUS), поэтому официальная политика Microsoft все еще будет требует, чтобы клонированные системы были уникальными путем использования Sysprep.


Источник: http://blogs.technet.com/mark_russinovich
Перевод: Dazila