emeriks
Goto Top

Authentifizierung über AD LDS

Hi,
weiß jemand, wie man ein AD LDS einrichten muss, damit darüber die Authentifizierung mit AD-Konten funktioniert, z.B. von einer vSphere Appliance (VCSA)? Oder anderen Linux-basierten Systemen?

Kurz zum Setup und Problem (siehe auch u.g. Grafik)
  • AD mit Windows Server 2016, alle Funktionsebenen auf 2016
  • ein Forest mit mehreren Domänen
  • wir haben intern mehrere Systeme (z.B. solche o.g. VCSA), welche im internen Netz sind und im SSO das AD als Identitätsquelle eingerichtet haben - keine Probleme damit

Jetzt soll ein externer Dienstleister einen Web-Anwendung für uns hosten und betreiben. Es ist gewollt, dass sich von unseren Anwendern dann ausgwählte über ihre AD-Konten dort anmelden können. Dafür muss eine Anbindung an unser AD eingerichtet werden. Aus Datenschutzgründen können wir aber keine direkte Anbindung an unser AD einrichten, weil sonst der externe Dienstleister die Informationen aller Anwender aus dem gesamten AD auslesen kann, auch solcher, welche mit dieser genannten Web-Anwendung gar nichts zu tun haben. Das technisch einzuschränken (Lese-Zugriff verweigern) wäre extrem aufwändig bzw. ohne komplette Umstrukturierung unserer AD-Strukturen überhaupt nicht machbar. Deshalb die Idee, dass über einen AD LDS zu erledigen.

Wir haben also ein AD mit mehreren Domänen hinter einer Firewall. Vor der Firewall steht ein Windows Server 2016 mit AD LDS (im weiteren "LDAP-Proxy" genannt). Der LDAP-Proxy ist Mitglied einer der internen Domänen. Diese Domänenmitgliedschaft ist voll funktionstüchtig, die entsprechenden Regeln in der FW dafür eingerichtet. Soweit kein Problem.

Der AD-Proxy synchronisiert ausgewählte AD-Konten aus den verschiedenen Domänen und legt dafür in seinem LDAP userProxy-Objekte an. Soweit auch gut, kein Problem.

Was nicht funktioniert, ist die Anbindung als Identitätsquelle z.B. in einer VCSA, welche sich ebenfalls vor der FW im selben Subnetz wie der LDAP-Proxy befindet.

Beim Versuch, die Identitätsquelle auf der VCSA einzurichten wird auf dem LDAP-Proxy im Sicherheits-Ereignislog protokolliert:
Überwachung gescheitert - Ereignis-ID 4776

Es wurde versucht, die Anmeldeinformationen für ein Konto zu überprüfen.

Authentifizierungspaket: ADAM_XyZ
Anmeldekonto: CN=XyZuser1,OU=Benutzer,DC=XyZ,DC=ADproxy,DC=local
Arbeitsstation: 192.168.245.35:34760
Fehlercode: 0xC000006D

Der Fehlercode variiert.
Verwenden wir zur Einrichtung der Identitätsquelle den NT Anmeldnamen wie "domain\samaccountname", dann kommt als Fehlercode
0xC0000064
Bedeutung: Benutzeranmeldung mit falsch geschriebenem oder fehlerhaftem Benutzerkonto
Das scheint logisch, weil im userProxy-Objekt zwar der sAMAccountName steht, aber nicht der NetBIOS-Name der Domäne.

Verwenden wir zur Einrichtung der Identitätsquelle dagegen den UPN wie "name@domain.tld", dann kommt als Fehlercode
0xC000006D
Bedeutung: Dies liegt entweder an einem fehlerhaften Benutzernamen oder an Authentifizierungsinformationen.
Der UPN steht im userProxy-Objekt und in der Ereignislog-Meldung steht dann auch der korrekt erkannte DistinguishedName.

(Quelle für Fehlercodes: https://docs.microsoft.com/de-de/windows/security/threat-protection/audi ..)

Ich habe die Einrichtung der Identitätsquelle sowohl mit einem Konto versucht, welches auf den LDAP-Proxy synchronisiert wird, als auch mit einem AD-Konto, welches nicht synchronisiert wird, als auch mit einem lokalen Konto des LDAP-Proxy. (alle 3 sind jeweils Mitglied der Rolle "Readers" im AD LDS)

Was ich ausschließen kann:
  • falscher Benutzername -- mehrere versucht
  • falsches Passwort -- mehrere versucht
  • fehlende offene TCP/UDP-Ports -- Die lokale Firewall des LDAP-Proxy habe ich zum Test deaktiviert und zwiwschen VCSA und LDAP-Proxy ist keine weitere FW.


Irgendwas mache ich also falsch. Hat jemand ne Idee?

E.

2020-07-17 09_58_42-zeichnung1 - visio standard

Content-Key: 588537

Url: https://administrator.de/contentid/588537

Printed on: April 19, 2024 at 21:04 o'clock

Member: Dani
Dani Jul 18, 2020 at 18:41:15 (UTC)
Goto Top
Moin,
auch auf die Gefahr hin, dass du dir die Möglichkeiten schon vorab durch den Kopf gehen lassen hast:
Was spricht gegen eine Implementierung mit Hilfe von AD FS?


Gruß,
Dani
Member: emeriks
emeriks Jul 20, 2020 at 06:39:52 (UTC)
Goto Top
Zitat von @Dani:
Was spricht gegen eine Implementierung mit Hilfe von AD FS?
Braucht man dafür nicht extra Lizenzen?
Member: Dani
Dani Jul 20, 2020 updated at 08:03:27 (UTC)
Goto Top
Moin,
in der Microsoft Welt ist eine Windows Server Lizenz notwendig. AD FS ist eine Rolle wie z.B. das AD DS.
Keine CALs oder externe Connector Lizenzen.


Gruß,
Dani
Member: emeriks
emeriks Jul 20, 2020 at 09:01:11 (UTC)
Goto Top
OK, danke.
Ich habe inzwischen einen anderen Ansatz über das MSDN Forum bekommen.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/24949e1c ...

Jetzt kann ich die Identitätsquelle einrichten, aber anschließend die Konten nicht auflisten, um sie im VCSA berechtigen zu können.
Member: Dani
Dani Jul 20, 2020 at 12:25:19 (UTC)
Goto Top
Moin,
Ich habe inzwischen einen anderen Ansatz über das MSDN Forum bekommen.
schon gesehen... face-smile

Zu Vollständigkeit noch der Thread aus dem inoffiziellen, deutschsprachigen VMware Forum:
https://vmware-forum.de/viewtopic.php?f=51&t=33831


Gruß,
Dani
Member: emeriks
emeriks Jul 20, 2020 at 12:50:59 (UTC)
Goto Top
Die Kollegen vom Dienstleister haben gemeldet, dass sie nun auch mit Ihrer Anwendung zugreifen können.