Best Practices oder Erfahrungen mit unternehmensweiten Benutzernamenrichtlinien und dem Auflösen von Duplikaten

Ich bin ein Programmierer mit einer Anwendung, die in das neue unternehmensweite Active Directory-Anmeldeschema integriert werden muss. Dies bedeutet, dass alle Benutzernamen in unserem System geändert werden, um das neue Schema zu verwenden. Das neue Schema ist "Vorname, Nachname", also hätte Joe Smith einen Benutzernamen von jsmith. Wenn John Smith jetzt eingestellt wird, bekommt er jsmith2. ABER sobald Joe das Unternehmen verlässt, wird sein AD-Konto gelöscht und jsmith ist wieder verfügbar. Wenn Jill Smith jetzt eingestellt wird, würde sie einen Schmied bekommen. Vom Standpunkt der Anwendung aus verursacht dies meiner Ansicht nach Probleme, da ich jetzt Aufzeichnungen über Joe und Aufzeichnungen über Jill haben könnte, die nicht zu unterscheiden sind, da beide von "jsmith" erstellt wurden.

Ich muss mich daher fragen, ob es einen Standard oder eine bewährte Methode gibt, die dieses Problem der Wiederverwendung von Benutzernamen in einem organisationsweiten Verzeichnis behandelt, insbesondere in größeren Unternehmen. Als ich bei einem Meeting meine Bedenken äußerte, wurde mir gesagt, dass "es keine Möglichkeit gibt, dass [großer Firmenname] immer noch Aufzeichnungen über jeden Benutzer hat, der das Unternehmen verlassen hat", und das kam mir verrückt vor. Gibt es also eine allgemein akzeptierte Lösung für den Umgang mit Benutzernamen? Oder macht es jedes Unternehmen nach, wenn es geht?

Windows bewältigt dies, indem es eine GUID verwendet, um jedes Konto zu identifizieren. Der Benutzername ist nur Dekoration. Sie werden feststellen, dass der alte und der neue Schmied unterschiedliche GUIDs haben, obwohl die Benutzernamen identisch sind.

Können Sie jedem Konto in Ihrer App eine GUID zuordnen? Wenn ich darüber nachdenke, kann ich Ihnen wahrscheinlich sagen, wie Sie an die GUID für einen Benutzer gelangen. Es ist ein Attribut des Benutzers im Active Directory.

JR

Ja, wir behalten jeden Benutzer, der jemals eingestellt wurde. Normalerweise empfehle ich einen ersten Anfangsbuchstaben, einen mittleren Anfangsbuchstaben und einen Nachnamen, um die Anzahl der JQPublic1-Konten zu minimieren, aber aus AD-Sicht sind Benutzer nur Zahlen. Sie können die Nummer für jedes Konto mit diesem Skript sehen:

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

Als kostenlosen Bonus können Sie aus einem Sid einen Benutzernamen machen :

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

Wie bereits erwähnt, ist die Verwendung des GUID-Attributs des Active Directory-Kontos des Benutzers eine gute Idee. Wenn Sie jedoch eine gute Lesbarkeit wünschen, sollten Sie sich die Dokumente für die iADsNameTranslate- Schnittstelle ansehen . Für die Übersetzung der verschiedenen möglichen Namen eines AD-Kontos (GUID, SID, samAccountName, displayName, DN usw.) können Sie eine Menge Kilometer sammeln.

Beispiel:

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

Dies gilt nicht nur für Benutzerkonten. Jedes Objekt in AD verfügt über eine GUID. Wenn Sie sich also beispielsweise einen DN für eine LDAP-Suchbasis (oder eine Gruppe oder etwas anderes) "merken" müssen, können Sie die GUID so verwenden, dass sie in AD verschoben wird (denken Sie nach) Wenn ein Administrator losgeht und Organisationseinheiten neu organisiert oder Gruppen umbenennt, wird Ihr "Zeiger" darauf nicht kaputt gehen (weil sich die GUID nie ändert).

In Active Directory gibt es mehrere Namensattribute:

• sAMAccountName: Dies ist der Name mit bis zu 20 Zeichen, der innerhalb der Domäne, jedoch nicht innerhalb der Gesamtstruktur eindeutig sein muss.
• userPrinicipalName: Dies ist normalerweise in Form von sAMAccountName@domain.name und ich glaube, dass es innerhalb der Gesamtstruktur eindeutig sein muss, aber da der erste Teil innerhalb der Domäne eindeutig ist, sollte @ domain.name einfach passieren.
• displayName: Was Sie in ADUC MMC sehen, wenn Sie sich Benutzer ansehen.
• DN: Der tatsächliche LDAP-DN des Benutzers in der AD-Struktur. Auf diese Weise würden Sie den Benutzer normalerweise aus LDAP-Sicht identifizieren.

DN ist ein schlechter Schlüssel, da er sich ändert, wenn der Benutzer verschoben oder umbenannt wird. Für userPrincipalName / sAMAccountName ist Sane möglich (wenn sie umbenannt werden).

Wie ein anderes Poster andeutete, ist das wirklich wirklich einzigartige Attribut der Benutzer wahrscheinlich GUID und leider nicht nett und menschlich lesbar.

GUID ist definitiv der richtige Weg. Wenn Sie den Namen der Person wirklich in einem benutzerfreundlichen Format präsentieren müssen, führen Sie einfach eine AD-Suche im Code durch.

Andere haben bereits Skript-Snippets veröffentlicht, und an den üblichen Codierungsseiten finden Sie zahlreiche Code-Snippets für eine Vielzahl von Sprachen. Versuchen Sie, diese nach Dingen wie "Benutzer zu führen", "Benutzer zu ID" usw. zu durchsuchen.

IMO, es wird empfohlen, niemals Konten zu löschen, sondern sie nur zu deaktivieren. Auf diese Weise können sie nicht wiederverwendet werden.

Peter, meine eigene Erfahrung damit ist - erwarte nicht, dass der Benutzername eindeutig ist, es sei denn, du hast eine Möglichkeit, die Eindeutigkeit des Benutzernamens zu garantieren. Wie Sie sagen, es klappt nie wirklich.

Die App muss, was auch immer es ist, andere relevante Daten verwenden, um zu bestimmen, was den Benutzer im Kontext dessen, was die App tut, einzigartig macht. Wenn Sie beispielsweise eine App zum Generieren von E-Mail-Flyern erstellen, möchten Sie wahrscheinlich nicht mehr als einen Flyer pro eindeutiger Postanschrift senden.