Active Directory – die UnicodePwd Mystery von AD LDS

Active Directory Lightweight Directory Services verwendet anspruchsvolle Prozedur konvertieren und Kennwörter zu authentifizieren.

Von Robert C. Rettig

Einer meiner Kunden benötigt vor kurzem, bestimmte Informationen über das Internet von Active Directory verfügbar zu machen. Die Absicht war die Authentifizierung (für die Anmeldung) auf eine externe Anwendung bereitzustellen, ohne mit diesen Attributen auswählen. Sie fragen sich vielleicht Neuigkeiten von dem Punkt außerhalb der Anwendung zu authentifizieren. Er versetzt die Onus, auf die Benutzer der Anwendung im Gegensatz zu den Anbieter, wodurch die Haftung des Besitzers.

Verfügbarmachen eines Domänencontrollers mit dem Internet ist normalerweise kein empfehlenswertes Verfahren, ob die Belichtung direkt von der Produktionsumgebung oder über ein Perimeternetzwerk stammt. Die natürliche Alternative besteht darin, einen Server mit Windows Server 2008 mit Active Directory Lightweight Directory Services (AD LDS) Rolle ausführen im Perimeternetzwerk platzieren.

AD LDS wurde ursprünglich als Active Directory Application Mode (ADAM) bezeichnet. Es war erstmals ein Add-on für für Windows 2003, Windows 2003 R2 enthalten und steht jetzt als Serverfunktion für Windows 2008 oder Windows 7. In vielerlei Hinsicht ist es fast wie Active Directory. Wie einige gesagt handelt es sich um eine vollständige Enterprise-Fähigkeiten verfügt nicht über die Farbtönen ab-Version. Implementieren von AD LDS entspricht praktisch auf allen Versionen von Windows, zwar Windows Server 2008 R2 am besten geeignet, ist da Sie Windows PowerShell v2 enthält. Die neue Version von Windows PowerShell bietet verbesserte Verwaltbarkeit von Active Directory/AD LDS-Attribute, die nicht einfach in die OS-Versionen verfügbar sind.

Leicht wechseln

Ob sich Active Directory oder AD LDS, können beide das UnicodePwd-Attribut aufweisen. Dieses Attribut wird in dem Verzeichnis-Anwendung-Partition gespeichert. Dies wird vorausgesetzt, dass der Server heraufgestuft wurde, um einen Active Directory-Domänencontroller oder die richtigen LDIF-Vorlage mit das Attribut für ein AD LDS-Server angewendet wurde.

Mit Active Directory oder AD LDS verwenden Anwendungen Lightweight Directory Access Protocol (LDAP) Version 3.0, das Verzeichnis Abfragen. Zu diesem Zweck muss die Anwendung (Ldp.exe, CSVDE.EXE, LDIFDE.EXE, ADSIEdit.exe oder einer eigenen Anwendung handeln) das Konto und das Kennwort angeben.  Scheint einfach genug, also warum dann ist es jedoch alles? Das Kennwort ist der einfache Teil. Das gespeicherte Kennwort in den UnicodePwd-Attribut ist die Herausforderung. Dies ist deshalb: Die meisten interaktiven Verzeichnisse oder Anwendungen werden wir in der Regel zum Eingeben des Kennworts in der systemeigenen Form aufgefordert. Wenn das Kennwort “ Auto ” war, also, was wir eingeben würden. Beispielsweise ist der Fall, wenn Sie für die Active Directory Gesamtstruktur oder Domäne zugreifen oder beim Zugriff auf eine AD LDS-Instanz mithilfe von ADSIedit oder LDP zuweisen oder Zurücksetzen eines Kennworts für ein bestimmtes Konto.

Wenn Sie gleichzeitige Hinzufügungen oder Änderungen auf einmal vornehmen müssen, ist das Programm LDIFDE.EXE Wahl des Tools. Um das Hinzufügen oder aktualisieren Sie das Attribut UnicodePwd, erfordert Microsoft, dass der Wert des Attributs UnicodePwd in Unicode base64-Format.

Unicode-Base64-Logik

Wie wird der Unicode-base64-Wert berechnet? Dies ist optimal, wo beginnt. Es bleibt zu hoffen, erhalten wir durchschauen Geheimnisse der UnicodePwd (und andere Attribute, die auf die gleiche Codierung) für alle.

Beachten Sie zunächst, dass die folgenden Sätze versehen sind. Verweisen Sie auf die Schritte 1-12 in Abbildung 1 . Das Kennwort in doppelte Anführungszeichen eingeschlossen werden müssen, und jedes Zeichen (einschließlich der Anführungszeichen) muss dann in seine entsprechende Unicode konvertiert werden. Das heißt, es muss zuerst finden ASCII-Äquivalente für jedes Zeichen, und leiten Sie den hexadezimalen Wert von jedem ASCII-Wert, dann jedes Hexadezimalwert mit zwei Nullen (weil UTF16 Windows entspricht) aufzufüllen, so dass 16 Bits dargestellt werden.

Nach der Konvertierung, werden diese Innenabstand hex-Sätze alle in eine lange Zeichenfolge kombiniert. Da base64 6 Bits basiert, wird diese Zeichenfolge jeweils sechs Zeichen von links analysiert. Wenn eine unvollständige hex Sextet bleibt, wird es rechts mit Nullen aufgefüllt bis sechs Zeichen dargestellt werden. Anschließend wird jede hex Sextet in das Binärformat konvertiert. Wie bei binären der Fall ist, tritt beim Analysieren von der rechten Seite und alle sechs Zeichen.

Obwohl es unnötig für eine unvollständige binäre Sextet aufzufüllen Links mit Nullen aufgefüllt, bis sechs Zeichen dargestellt werden (Beachten Sie, dass führende noch gleich Null Nullen, aber dadurch einfacher zu lesen, da die andere Mengen auch sechs Zeichen). Jetzt konvertieren Sie jedes analysierten binären Wert in seine numerische 11 entspricht. Verwenden Sie diese Zahl als Index zu suchen, die gegen eine base64-Tabelle (Abbildung 2 ), und rufen Sie das Zeichen. Wenn eine vollständige Sextet nur Nullen Innenabstand vorgenommen wird, werden diese durch das Gleichheitszeichen dargestellt.

Abbildung 1 in Schritte 1-12, zeigt, wie das Wort Auto konvertiert **IgBjAGEAcgAiAA ==.**Rechter Abstand ist erforderlich, bei der Vorbereitung der Unicode für base64, die von den Text in blau hervorgehoben angezeigt werden können. Der linke Abstand vom Text in rot hervorgehoben dargestellt, ist dies nur, um konsistente und einfacher zu lesen, im Vergleich zu anderen binären Sextets zu machen.

Figure 1 Steps to create a unicode-base64 password

Abbildung 1Schritte zum Erstellen eines Unicode-base64-Kennworts.

Figure 2 Base64 Mapping

Abbildung 2Base64-Zuordnung.

Wenn Sie wissen möchten, wenn diese Fantasievoll Logik korrekt ist, können Sie eine Kopie des Programms stringconverter.exe von gbordier.com/gbtools/stringconverter.htm-erhalten, und führen Sie die folgende Zeichenfolge der DOS-Prompt (Befehl):

stringconverter \"car\" /encode /unicode
IgBjAGEAcgAiAA==

Wie Sie sehen können, sind die Ergebnisse identisch.

Unicode-Base64-Kennwort erstellen

Für einfache Anfangstests können ( Abbildung 1-in Excel erstellt wurde) die folgenden Excel-Funktionen verwenden Sie schnell die richtige Unicode base64 eingegebenen Text erstellen:

  • CODE() – gibt den numerischen Wert eines Zeichens zurück.
  • DEC2HEX() – konvertiert eine dezimale Zahl in eine Hexadezimalzahl
  • Concatenate() – Verknüpfungen mehrere Zeichenfolgen zu einer einzigen Zeichenfolge
  • BIN2DEC() – konvertiert eine binäre Zahl in Dezimal
  • MID() – gibt das Zeichen aus der Mitte einer Zeichenfolge zurück.

Die beste Möglichkeit, befassen sich mit der eine Vielzahl von UnicodePwd Werte besteht darin, ein Skript zu schreiben. Auf diese Weise in Excel mithilfe von VBA ermöglicht es Ihnen, die generierten Werte, und bewahren Sie diese Informationen in der Kalkulationstabelle zur zukünftigen Referenz. Verwenden ein anderes VBA-Skript, konnte ich sofort eine LDIF-Datei für den Import in AD LDS-Instanz generieren.

Der Unicode-Base64 UnicodePwd Value hochladen

Da die UnicodePwd mithilfe des Programms LDIFDE.exe bearbeitet wird, muss die UnicodePwd hochladen das LDIF-Dateiformat entsprechen. Da das Engagement die Windows Server 2008 R2 AD LDS-Rolle beteiligt, ist diese LDIF-Dateiformat, was ich folgen, so dass Basisinformationen geuploadet wurde. Beachten Sie, dass das Benutzerkonto von John Doe zuerst mit den UnicodePwd Wert Auto als IgBjAGEAcgAiAA ==.

 

dn: CN=JohnDoe,OU=Accounts,DC=CONTOSO,DC=COM
Changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: John Doe
givenName: John
sn: Doe
userPrincipalName: johnd@Contoso.COM
mail: johnd@Contoso.COM
unicodePwd::IgBjAGEAcgAiAA==\
msDS-UserAccountDisabled: FALSE

dn: CN=Jess  Wanders,OU=Accounts,DC=CONTOSO,DC=COM
Changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Jess Wanders
givenName: Jess
sn: Wanders
userPrincipalName: JessW@Contoso.COM
mail: JessW@Contoso.COM
unicodePwd::IgA3ACQANQBNAHMAIwA0AEQAaQBHACIA
msDS-UserAccountDisabled: FALSE

Um diese Datei zu importieren, vorausgesetzt, dass der Dateiname ist also Accounts.ldf, geben Sie an der Konsole für Windows Server 2008 R2 Eingabeaufforderung die folgende Syntax:

C:\Windows\system32\LDIFDE –i –f Accounts.ldf.

Binden und das Kennwort für das Konto testen

Nach dem Uploaden von mindestens einem neu erstellter Konten auf die Anwendungspartition, und das Herstellen einer Verbindung oder Bindung an den LDAP-Dienst mit des Kontos UserPrincipalName und UnicodePwd, es ‘ s wichtig, um sicherzustellen, dass das Unicode-base64-Format der UnicodePwd korrekt ist. Das Tool eignet sich am besten und ist leicht zu verwenden ist LDP.exe. Sie können sich vorstellen, dass IgBjAGEAcgAiAA == ist das richtige Kennwort eingeben, wenn diese verwenden, aber nicht. Es ist, was wir ursprünglich mit gestartet: Auto.

Sobald Sie mit der LDP mit AD LDS-Instanz verbunden haben, binden Sie den UPN des Upload-Kontos, und geben Sie das Kennwort. Wenn Sie die Logik zum Erstellen des UnicodePwd base64-Unicode Wert richtig befolgt haben, sehen Sie eine positive Bestätigung angezeigt, die auf das LDP-Fenster, die tatsächlich auf diese AD LDS-Instanz mit diesem Benutzerkonto gebunden sind.

Mithilfe von Windows PowerShell UnicodePwd-Attribut aktualisieren

Nun, es wäre gerecht, wenn erwähnt, dass LDIFDE.exe um das einzige Tool war Blendenöffnung Massenänderungen UnicodePwd-Attribut. Dann würde nicht Sie zum Generieren des Unicode-base64-Werts gelernt haben.

In Windows Server 2008 R2 geschaltet Windows PowerShell v2 etwas mehr Granularität in der Fähigkeit, select-Attribute in Active Directory und AD LDS zu bearbeiten. Arbeiten mit AD LDS, ich Lieferumfang von der Syntax in Abbildung 3 (note that for the sake of readability, I placed each command option on its own line) um die gleichen Ergebnisse zu erzielen, die das VBA-Skript in der Excel-Tabelle.

Es ist offensichtlich, dass mit nur wenigen Codezeilen Windows PowerShell, Sie schnell die notwendigen Änderungen vornehmen können, ohne über Hoops springt, wenn es sich bei den Unicode-base64-Wert für alle Kennwörter erstellen zu müssen. Dies ist eine leistungsfähige Funktionen von Windows PowerShell-Anweisung, aber es geht zu Lasten des Verarbeitungszeit, alle diese im Hintergrund wird in Erwägung ziehen. Dies ist insbesondere dann offensichtlich, wenn Hunderte oder Tausende von Konten zu verarbeiten.

Wenn Sie gelegentlich zu erstellen oder aktualisieren einige Konten und wieder benötigen, verwenden Sie Windows PowerShell. Wenn Sie immer erstellen oder Hunderte oder Tausende in regelmäßigen Abständen zu aktualisieren, ist die Verwendung LDIFDE.exe viel schneller langfristig.

Abbildung 3Windows PowerShell v2-Skript, das Kennwort zu aktualisieren.

Import-Csv c:\scripts\accounts.csv | 
New-ADUser
–Name $_.commonName
–GivenName $_.givenName
–Surname $_.sn

-EmailAddress $_.email
-Type user
-UserPrincipalName $_.userPrincipalName
–Server LDS01:389 |
Set-ADAccountPassword
-Identity $_.distinguishedName
-NewPassword (ConvertTo-SecureString -AsPlainText $_.Password -Force)
-Reset

-Server LDS01:389 |

Enable-ADAccount

-Identity $_.distinguishedName

-Server LDS01:389

Ob mit Active Directory oder AD LDS (oder sogar ADAM, dass) arbeiten, stehen verschiedene Möglichkeiten zur Aktualisierung von UnicodePwd-Attribut. Wenn Sie nur ein Konto geändert haben, verwenden Sie Ldp.exe oder ADSIedit, um erledigt abzurufen. Wenn nur eine Handvoll und wieder, funktioniert mit Windows PowerShell v2 für Windows Server 2008 R2 Active Directory/AD LDS hervorragend.

Wenn Sie weiterhin mit Windows Server 2003 oder höher arbeiten und Hunderte für Tausende von Konten, die müssen konstant aktualisiert haben, führen Sie vorab Prep arbeiten, um den base64-Unicode Wert für das Attribut UnicodePwd zu generieren. Verwenden Sie, um diese Änderungen auf einmal uploaden LDIFDE.exe.

Frank Rettig

Frank Rettig ist ein Berater in den USA Öffentlicher Sektor praktische Übung mit 26 Jahre Erfahrung in der Arbeit domestically und International in der Washington, D.C., Bereich befindet. Er spezialisiert Verzeichnisintegration, Identitätsverwaltung, Lösungen für Mobilität und computing-Standards Regierung. Frank kann unter frank.rettig@microsoft.com erreicht werden.

 

Bestätigungen:

Ich möchte die Teammitglieder Microsoft Informationsdienste Security ACE USPS auf Services ’ Anthony de Lagarde (Senior Consultant) für die Überprüfung von Inhalten, Roger Grimes (Principal Security Architect) und Shawn Rabourn (leitender Sicherheitsberater) zur Überprüfung der in diesem Artikel danken.

 

Verwandter Inhalt: