Isolated Names und identische Usernamen im gleichen Forest

Hallo, hier wieder einmal Rol mit einem Thema aus aktuellem Anlass. Diesmal geht es um “Isolated Names”.
Wem es nicht geläufig ist – unter “Isolated Names” versteht man die Angabe eines Usernamens ohne dem entsprechenden Domänennamen, also ohne Prefix "Domain\Username" oder mittels UPN "Username@DomainFQDN".
Im aktuellen Kundenszenario wurde eine eigenentwickelte Applikation verwendet, welche als Eingabe nur einen Usernamen und ein Passwort anfordert, aber keinen Domänennamen und so einen “Isolated Name” Logon generiert. Die Applikation lief problemlos über Jahre hinweg. Nachdem die Konten jedoch vom ursprünglichen Tree, nennen wir ihn Tree1.Contoso.com, in einen neuen Tree Tree2.Contoso.com migriert wurden, war die Anmeldung nicht mehr möglich, wenn der Client in Tree3.Contoso.com des gleichen Forest mit Root Root.Contoso.com stand. Es erschien dann immer eine Meldung, daß das Passwort falsch oder der User nicht bekannt ist.

Problem Setup:

Um die Umstände näher zu klären, haben wir zunächst mit NLTEST /SC_QUERY geprüft, zu welchem DC der Domäne Tree3 der Client1 seinen Secure Channel hat:

C:\>nltest /sc_query:Tree3 /server:Client1
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\DC1.Tree3.Contoso.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

Im Anschluss haben wir dann auf dem DC aus obiger Ausgabe DC1.Tree3.Contoso.com das Netlogon Logging aktiviert:

NLTEST /DBFLAG:0x20FFFFFF
Anmerkung: späteres Abschalten mit NLTEST /DBFLAG:0x0 nicht vergessen

Im entsprechenden Netlogon Log findet man dann folgende Einträge zum Zeitraum der fehlschlagenden Applikations-Anmeldung:

08/04 12:51:58 [LOGON] SamLogon: Transitive Network logon of (null)\User1 from Client1 (via Client1) Entered
08/04 12:51:58 [LOGON] NlPickDomainWithAccount: User1: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
08/04 12:51:58 [CRITICAL] NlPickDomainWithAccount: Username User1 can't be cracked (On GC). 0xc0000001 1332513024   -> 0xc0000001=STATUS_UNSUCCESSFUL
08/04 12:51:58 [CRITICAL] NetpDcHandlePingResponse: Dom1.ExternalTrusted.com: User1: response says specified account not found.
08/04 12:51:58 [CRITICAL] NlPickDomainWithAccount: Dom1 responded negatively for account User1
08/04 12:51:59 [CRITICAL] NetpDcHandlePingResponse: Dom2.ExternalTrusted.com: User1: response says specified account not found.
08/04 12:51:59 [CRITICAL] NlPickDomainWithAccount: Dom2 responded negatively for account User1
...
08/04 12:52:03 [LOGON] SamLogon: Transitive Network logon of (null)\User1 from Client1 (via Client1) Returns 0xC0000064  ->0xC0000064=STATUS_NO_SUCH_USER

Der entscheidende Fehler passiert beim Eintrag:
"NlPickDomainWithAccount: Username User1 can't be cracked (On GC). 0xc0000001 1332513024"

Aber wie kommt es jetzt dazu? Der GC sollte doch eigentlich beide samAccountName für User1 in Tree1 und Tree2 finden!?

Der Ablauf ist wie folgt. Ohne Angabe des Domänennamens wird “(null)\User1” zunächst in der lokalen Domäne gesucht, hier Tree3.Contoso.com. Dort ist er nicht definiert. Das ist aber zugleich der Grund, warum es funktioniert, wenn Client1 in Tree1 oder Tree2 steht.
Im nächsten Schritt wird nun der “Isolated Name” (null)\User1 am Global Catalog GC gesucht. Die Domänen Tree1.Contoso.com und Tree2.Contoso.com, in denen User1 jeweils definiert ist, sind Tree Domänen im gleichen Forest mit Root Root.Contoso.com.
Demnach müßte ja eigentlich die GC Suche erfolgreich sein, schlägt aber fehl mit
“NlPickDomainWithAccount: Username User1 can't be cracked (On GC). 0xc0000001" (STATUS_UNSUCCESSFUL)
Mit dieser Meldung haben wir eine Source Code Analyse durchgeführt und festgestellt, daß der Netlogon Dienst die Funktion DsCrackNames verwendet, jedoch mit einem Flag daß nur den Erfolg erlaubt, wenn nur ein Konto gefunden wird. Ansonsten gäbe es keine Eindeutigkeit beim Logon. Netlogon setzt dann den Fehler STATUS_UNSUCCESSFUL, um eine falsche Zuweisung zu vermeiden.
Der Fehler tritt also sicher nicht auf, wenn der Domänenname mit angegeben wird, also z.B. Tree1\User1, dann wäre die Suche wieder eindeutig.
Die Suche über weitere Trusts ist gemäß Netlogon Log, wie erwartet, dann auch nicht erfolgreich und Netlogon gibt zum Schluß den Fehler STATUS_NO_SUCH_USER zurück.

Das Verhalten ist damit By Design, wenn auch zugegebenermaßen bis dato wenig dokumentiert.

Anmerkung:
Wenn man anders herum noch mit Applikationen, welche “Isolaten Names” verwenden, geschlagen ist und Benutzer hat, die potentiell betroffen sind, kann man über folgende LDIFDE Ausgabe prüfen, ob es samAccountName Duplikate im Forest gibt:

ldifde.exe /f LookUp_User1.ldf /t 3268 /d "" /l samAccountName /r "(samAccountName=User1)" /p subtree

Fazit:
Applikationen, welche “Isolaten Names” verwenden, sind nicht mehr zeitgemäß. Abgesehen von obigen Verhalten, welches zu Irritationen führen kann, hatten wir in der Vergangenheit auch schon schwerwiegende Performanceeinbrüche auf DCs, wenn viele “Isolated Names” über alle Trustverbindungen gesucht werden. Aus diesem Grund haben wir bereits im Jahr 2003 und mit Microsoft Windows 2000 Service Pack 3 (SP3) die Einstellung LsaLookupRestrictIsolatedNameLevel eingeführt, um diese Suchen zu unterbinden, siehe auch
818024 How to restrict the lookup of isolated names in external trusted domains by using the LsaLookupRestrictIsolatedNameLevel registry entry
https://support.microsoft.com/default.aspx?scid=kb;EN-US;818024

Ich hoffe das hilft weiter, zumindest um “Isolaten Names” loszuwerden.
Damit einen hoffentlich bald sonnigeren August,
Euer Rol