Schlagwort-Archive: active directory

Mythos: LDAP-Traffic auf Port 389 ist unsicher

Es besteht noch immer die weit verbreitete Meinung, dass LDAP-Traffic über Port 389 zu Active Directory Domain Controllern generell sensible Informationen wie Userid und Passwort im Klartext übertragen werden. Dies ist allerdings nur der Fall, wenn der LDAP Simple Bind verwendet wird.

Aber schauen wir uns das Verhalten mal genauer an. Mit der .NET-Implementierung lassen sich netterweise die einzelnen Authentifizierungsarten als Parameter beim Aufruf mitgeben, so dass sich das Testsetup einfach abbilden lässt. https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.authenticationtypes?view=netframework-4.8

Test1 – Simple Bind

DE = new DirectoryEntry(ldappath, user, password, System.DirectoryServices.AuthenticationTypes.None);

Im Netzwerktraffic sieht man tatsächlich: Die Credentials werden im Klartext übertragen

Ldap: Bind Request, MessageID: 1, Version: 3
- LDAPMessage: Bind Request, MessageID: 1
  + ParserHeader:
  + MessageID: 1
  + OperationHeader: Bind Request, 0(0)
  - BindRequest: Version:3, Name:ldaptest@su-pen.local, UserName: P@ssw0rd, Authentication type = simple
   + Version: 3
   + Name: ldaptest@su-pen.local
   - Authentication: UserName: P@ssw0rd, Authentication type = simple
    + AuthenticationTypeHeader: Authentication type = simple
      SimpleAuthentication: P@ssw0rd

Der Simple-Bind funktioniert nicht mehr, wenn auf den Domain Controllern folgende Einstellung gesetzt ist:

Domain controller: LDAP server signing requirements -> Require signature

Test2 – AuthenticationType Secure – Nicht-Domänenmitglied

DE = new DirectoryEntry(ldappath, user, password, System.DirectoryServices.AuthenticationTypes.Secure);

(Die Defaulteinstellung seit .NET 2.0) Mythos: LDAP-Traffic auf Port 389 ist unsicher weiterlesen

Werbung

Auswerten des Userenv-Logs

Das Ask the Directory Services Team hat 2 schöne Beiträge verfasst, die eine Anleitung geben, wie man das Userenv.log interpretieren kann.

Das Log wird, wenn das Logging auch eingeschaltet ist, vom Userlogon geschrieben und man kann dort den Anmeldevorgang mit dem Laden des Profils (vom Netz) und dem Anwenden der Gruppenrichtlinien nachvollziehen.

Understanding How to Read a Userenv Log – Part 1

Understanding How to Read a Userenv Log – Part 2

Ergänzend gibt es von SysProSoft das Freeware-Tool PolicyReporter, welches das Log deutlich lesbarer darstellt.

SID-History zu Konten hinzufügen

Automatisiert (über VBScript) die SID History von Konten zwischen 2 vertrauenden Domänen ist gar nicht so einfach, wie es auf den ersten Blick wirkt, andererseits ist es auch gar nicht so kompliziert.

Der erste Ansatz einfach die objectSID des einen Kontos zur sIDHistory des anderen Kontos hinzuzufügen schlägt mit einem schönen „Access denied“ fehl.

Beim weiteren Forschen stösst man in den Supporttools auf eine sidhist.vbs, die wohl genau das macht. Allerdings kann man der aufgerufenen Funktion aus den DSUtils.ClonePrincipal keine Usercredentials mitgeben. Das ist also auch untauglich.

Bleibt somit nur übrig ein kleines Progrämmchen zu schreiben, welches die API-Funktion DsAddSIDHistory verwendet.

Hier ist auch ganz gut beschrieben, was dazu alles erforderlich ist. Für 2 native W2K3-Domänen kann man es kurz zusammenfassen:

  • Auditing der Kontenverwaltung muss angeschaltet sein
  • Es muss ein leeres Gruppenkonto mit dem Namen <NetBIOS-Domänenname>$$$ geben. (Hierüber testet die Funktion, ob das Auditing auch tatsächlich angeschaltet ist)

Ansonsten geht es ziemlich einfach. Folgende Funktionen müssen einfach nacheinander aufgerufen werden:

  1. DsMakePasswordCredentials
  2. DsBindWithCred
  3. DsAddSIDHistory
  4. DsUnBind
  5. DsFreePasswordCredentials

Jetzt muss man im Script also nur noch die benötigte Gruppe anlegen (Das Auditing sollte natürlich auch angeschaltet sein). Das neu erstellte Programm aufrufen und diese Gruppe wieder löschen.

ADMT wird das ganze wohl auf dem gleichen Weg machen. Es legt diese Gruppe auch an 😉