Уникальный идентификатор для пользовательских профилей в Windows

Question

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

При первом использовании клиентское приложение запишет файл или запись реестра с GUID в текущий профиль. Этот GUID впоследствии будет использоваться в качестве ключа в базе данных конфигурации на сервере.

Теперь мне интересно, есть ли в профилях пользователей Windows уникальные идентификаторы, которые я мог бы использовать вместо генерации своих собственных GUID.

Имя пользователя не будет работать, поскольку у пользователей может быть несколько профилей. Объединение его с именем компьютера не сработает, поскольку могут быть перемещаемые профили.

Обновление:

Я только что посмотрел на SID в HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList на двух компьютерах в одном домене. Роуминг не включен, поэтому моя учетная запись пользователя имеет отдельный профиль на каждом компьютере. Оба профиля перечислены с одинаковым SID. Это означает, что я должен продолжать генерировать свои собственные GUID.

Answer 1

Пользователи и группы Windows используют идентификаторы безопасности (SID).

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

Существует список предопределенных идентификаторов безопасности , который встроен в Windows. Другие SID генерируются путем объединения текущего (96-разрядного) SID текущего компьютера с увеличенным числом.

SID пользователей, имеющих учетные записи на компьютере, хранятся в реестре под HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

Образцы SID (взяты из Политика Microsoft в отношении дублирования дисков при установке Windows XP ):

В следующем примере отображаются SID для четырех локальных учетных записей пользователей. Обратите внимание, что только последние четыре цифры увеличиваются при добавлении новых учетных записей.

• S-1-5-21-191058668-193157475-1542849698-500 Администратор
• S-1-5-21-191058668-193157475-1542849698-1000 Пользователь 1
• S-1-5-21-191058668-193157475-1542849698-1001 Пользователь 2
• S-1-5-21-191058668-193157475-1542849698-1002 Пользователь 3

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

Answer 2

Вы можете использовать идентификатор безопасности профиля пользователя (SID).

LookupAccountName () Win32 API принимает имя пользователя и имя компьютера в качестве ввода и возвращает вам связанный SID.

Answer 3

Я мог бы использовать более LDAP-ориентированное решение этой проблемы, но это может быть намного больше работы для вашего приложения.

В AD есть несколько уникальных полей для пользователя. Вы можете использовать весь DN записи пользователя (т.е. DC = com, DC = пример, CN = Users, DN = bob smith). Вот что однозначно идентифицирует запись в AD. Тем не менее, MS также имеет поле с именем UPN, которое выглядит как адрес электронной почты (иногда это так) и принимает форму user @ domain.

Конечно, эта информация требует доступа для чтения к AD, и это может быть непрактичным для вашего приложения.

Answer 4

R Bemrose и snowccrash верны, SID учетной записи именно то, что вы запросили. Вы правы в том, что для того, чтобы это решение работало, вам нужно включить перемещаемые профили; именно поэтому они называются перемещаемыми профилями.

Если вы не хотите использовать проверку подлинности домена для идентификации пользователей, тогда другой вариант - WAS (службы проверки подлинности Windows). Это обычно, но не обязательно, реализовано поверх Microsoft SQL Server в вездесущей базе данных ASPNETDB.

WAS - это решение с поддержкой dotnet с тщательно продуманной поддержкой ASP.NET, которое также доступно для настольных программ. Если вам это тоже не нравится, вы можете свернуть свои собственные, но это кажется мне неоптимальным использованием ресурсов. Если вы не создаете программное обеспечение dotnet, вы все равно можете использовать WAS, но это будет не совсем удобно.