Хранение SID Windows в базе данных для поиска - PullRequest
5 голосов
/ 27 октября 2009

У меня есть приложение ASP.NET MVC, в котором мне нужно разрешить клиентам настраивать MembershipProviders на основе их среды, но при этом иметь возможность сопоставлять это MembershipUser с конкретной моделью User в нашей базе данных.

Membership.GetUser() даст мне доступ к зарегистрированному пользователю Membership.ProviderUserKey. Я могу использовать это, чтобы относиться к записи пользователя. Наш пользовательский поставщик SQL просто вернет User.Id, но AD - это другая история. В этом случае ProviderUserKey является IdentityReference.

Эти поиски будут происходить очень часто, как вы можете себе представить (хотя кэширование может помочь уменьшить количество поисков на уровне базы данных).

Я не могу решить, какой маршрут лучше выбрать: сохранение SID в виде столбца varbinary или varchar. Этот столбец не будет первичным ключом и не будет иметь кластеризованного индекса. Знание того, что я могу очень хорошо индексировать строки, и чтение SID в строковом формате, конечно, лучше, чем двоичный. Кто-нибудь готов поделиться, как они решили такую ​​ситуацию?


Обновление

Я не знаю, как я пропустил этот ТАК вопрос , когда я искал, прежде чем отправлять сообщения, но кажется довольно ясным, что ActiveDirectoryMembershipProvider и ActiveDirectoryMembershipUser не совсем подходят для задачи рука, как они существуют сегодня.

Ответ на этот вопрос SO связал следующую статью , где было указано следующее:

Относительная часть идентификатора SID уникален по отношению к домену, поэтому, если домен меняется, относительный идентификатор также меняется.

Таким образом, когда объект User перемещается из одного домен в другой, новый SID должен быть генерируется для учетной записи пользователя и хранится в свойстве Object-SID.

Однако у каждой группы и пользователя есть Object-GUID, который никогда не изменится, даже если учетная запись перемещена. Следовательно, мне следует использовать Object-GUID в моем классе User, а не Object-SID. В противном случае, чья-либо запись пользователя будет удалена, если он будет перемещен, и, следовательно, нарушит связь между его принципалом и данными, которые он создал.

К сожалению, ActiveDirectoryMembershipUser не позволяет мне получить Object-GUID. Поэтому мне придется либо преобразовать SID в GUID после того, как ActiveDirectoryMembershipUser выполнит свою работу, либо создать свой собственный MembershipProvider, который будет делать все, что мне нужно на месте. К сожалению, это означает, что мне, возможно, придется дублировать уже предпринятые для меня усилия к ActiveDirectoryMembershipProvider.

Ответы [ 3 ]

6 голосов
/ 27 октября 2009

Microsoft хранит SID как varbinary (85) в sys.server_principals

Это также уникальный столбец, поэтому он должен иметь индекс ...

1 голос
/ 14 декабря 2010

имя пользователя - ПОСЛЕДНЯЯ вещь, которую вы хотите проиндексировать.

SID меняются в AD только при смене пользователя с одного домена на другой. RID разделены на 2 группы - встроенные (<1000) и пользовательские RID. Заранее определенные пользователи, такие как Администратор, Гость и т. Д., Всегда имеют один и тот же RID. </p>

Если вы хотите управлять перемещением пользователей и т. Д., То GUID - это то, что вам нужно.

имя пользователя может быть изменено в любое время в управлении пользователями и группами.

это отличается от имени объекта, которое является инвариантным, но я не верю, что мандат уникален в лесу. У вас может быть любое количество пользователей John Smith.

Я бы посмотрел на объекты ADSI. Это COM-объекты, которые должны быть доступны из ASP. MSDN объясняет довольно хорошо. объект ADSearch может использоваться для возврата пользовательских атрибутов (например, DN) из GUID.

0 голосов
/ 27 октября 2009

Звучит так, будто вы делаете это намного сложнее, чем нужно. Для чего вам нужен SID или GUID? У вас уже есть уникальный, отлично читаемый идентификатор для учетной записи пользователя, поддерживаемой в ActiveDirectory.

Это называется "имя пользователя". Надеемся, что это то же имя пользователя, что и в таблице «user» ваших приложений.

Ваше приложение просто должно знать, успешно ли аутентифицировано это имя пользователя с ActiveDirectory. Поэтому, если они успешно войдут в систему - вы просто сохраните факт аутентификации в ваших переменных Session.

Если они настроены на использование имени пользователя db, в случае успеха установите ту же переменную Session, указывающую, что они успешно вошли в систему.

Никаких причудливых GUID или SID ... просто.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...