Назад | Перейти на главную страницу

Рекомендации или опыт использования корпоративных политик в отношении имен пользователей и устранения дубликатов

Я программист и работаю с приложением, которое необходимо интегрировать в новую схему входа в Active Directory для всей компании. Это означает изменение всех имен пользователей в нашей системе для использования новой схемы. Новая схема - «имя, инициалы», поэтому имя пользователя Джо Смита будет jsmith. Если теперь возьмут на работу Джона Смита, он получит jsmith2. НО, как только Джо покидает компанию, его учетная запись AD удаляется, и jsmith снова становится доступным. Так что, если Джилл Смит сейчас возьмут на работу, она получит кузнеца. С точки зрения приложений, на мой взгляд, это вызывает проблемы, потому что теперь у меня могут быть записи, относящиеся к Джо, и записи, относящиеся к Джилл, которые невозможно различить, потому что они оба были созданы «jsmith».

Поэтому мне остается задаться вопросом, существует ли стандартный или передовой метод решения этой проблемы повторного использования имен пользователей в каталоге всей организации, особенно в крупных компаниях. Когда я выразил свои опасения на встрече, мне сказали, что «[название крупной компании] не может до сих пор вести учет каждого пользователя, покинувшего компанию», и это показалось мне сумасшедшим. Итак, есть ли общепринятое решение для обработки имен пользователей? Или каждая компания делает все самостоятельно?

Windows справляется с этим, используя GUID для идентификации каждой учетной записи. Имя пользователя просто украшение. Вы обнаружите, что старый jsmith и новый jsmith имеют разные идентификаторы GUID, хотя имена пользователей совпадают.

Можете ли вы связать GUID с каждой учетной записью в вашем приложении? Если я подумаю об этом, я, вероятно, могу рассказать вам, как получить GUID для пользователя. Это будет атрибут пользователя в активном каталоге.

JR

Да, мы сохраняем в штате каждого пользователя Я обычно рекомендую первое начальное, среднее начальное имя, фамилию, чтобы минимизировать количество учетных записей JQPublic1, но это случается, однако с точки зрения AD пользователи - это просто числа. Вы можете увидеть номер любой учетной записи с помощью этого скрипта:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objAccount = objWMIService.Get ("Win32_UserAccount.Name='myusername',Domain='mydomain'")
Wscript.Echo objAccount.SID

в качестве бесплатного бонуса вот как превратить sid в имя пользователя:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objAccount = objWMIService.Get ("Win32_SID.SID='S-1-5-21-1454471165-1004336348-1606980848-5555'")
Wscript.Echo objAccount.AccountName
Wscript.Echo objAccount.ReferencedDomainName

Как уже упоминалось, использование атрибута GUID учетной записи пользователя Active Directory - отличная идея. Однако если вам нужна удобочитаемость, вам следует взглянуть на документацию для iADsNameTranslate интерфейс. Вы можете получить много пользы от перевода различных возможных имен учетной записи AD (GUID, SID, samAccountName, displayName, DN и т. Д.).

Пример:

Option Explicit

' Constants for the iADsNameTranslate object. (from http://msdn.microsoft.com/en-us/library/aa772267(VS.85).aspx)
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_GUID = 7

Const ADS_NAME_INITTYPE_GC = 3

Dim objNameTranslate 
Dim strUserGUID

' Create a nametranslate object and init to talk to a global catalog server
Set objNameTranslate = CreateObject("NameTranslate")
objNameTranslate.Init ADS_NAME_INITTYPE_GC, ""

' We're looking for an "NT 4" account name type-- aka a samAccountName
objNameTranslate.Set ADS_NAME_TYPE_NT4, "DOMAIN\username"

' Translate into the user's GUID
strUserGUID = objNameTranslate.Get(ADS_NAME_TYPE_GUID)

WScript.Echo strUserGUID

Это не только для учетных записей пользователей. Каждый объект в AD имеет GUID, поэтому, если вам нужно «запомнить» DN, скажем, для базы поиска LDAP (или группы, или чего-то еще), вы можете использовать GUID, чтобы, если он перемещается в AD (подумайте о том, что какой-то администратор уходит и реорганизует подразделения или переименовывает группы) ваш «указатель» на него не сломается (потому что GUID никогда не меняется).

В Active Directory есть несколько атрибутов именования:

  • sAMAccountName: это имя длиной до 20 символов, которое должно быть уникальным в пределах домена, но не в пределах леса.
  • userPrinicipalName: обычно имеет форму sAMAccountName@domain.name, и я считаю, что она должна быть уникальной в пределах леса, но поскольку первая часть уникальна в пределах домена, тогда @ domain.name должно произойти.
  • displayName: что вы видите в ADUC MMC, когда смотрите на пользователей.
  • DN: фактическое DN LDAP пользователя в дереве AD. Обычно так вы идентифицируете пользователя с точки зрения LDAP.

От DN не стоит отказываться, поскольку он изменится, если пользователя переместить или переименовать. Вменяемое возможно для userPrincipalName / sAMAccountName (если они будут переименованы).

Как предположил другой плакат, действительно действительно уникальным атрибутом пользователей, вероятно, является GUID, и, увы, он не приятен и не читается человеком.

GUID, безусловно, лучший вариант. Если вам действительно нужно представить имя человека в удобном для человека формате, просто выполните поиск в AD в коде.

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

ИМО, хорошая практика - никогда не удалять учетные записи, просто отключите их. таким образом их нельзя будет использовать повторно.

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

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