LAMP-Server-Kerberos-Konfiguration zur Authentifizierung gegenüber einem schreibgeschützten Windows-KDC in einer DMZ

Question

Hintergrund:

Wir haben eine Reihe von AD-Netzwerken (Domänen), die über VPNs verbunden sind und AD-Vertrauensbeziehungen aufgebaut haben. Wir haben einen extern gehosteten Webserver und haben konfiguriertnahtlose Authentifizierungfür jeden Benutzer innerhalb des vertrauenswürdigen Netzwerks. Dies funktioniert, aber das Vorhandensein des VPN zu einem externen Webserver, der nicht von unserer IT-Abteilung verwaltet wird, wurde vom Netzwerkteam als zu großes Sicherheitsrisiko eingestuft.

Ich habe keinen Administratorzugriff auf die internen Netzwerke, aber vollen Administratorzugriff auf die Webserver.

Möchte:

Richten Sie die gleiche nahtlose Authentifizierung ohne VPN ein, indem Sie zum Verarbeiten aller Authentifizierungsanforderungen einen schreibgeschützten DC in einer DMZ verwenden.

Einzelheiten:

1. Wir haben mehrere AD-Domänen, die sich gegenseitig vertrauen und über VPN-Tunnel verbunden sind.
2. Wir haben einen schreibgeschützten DC in einer DMZ, die mit dem Haupt-AD-Netzwerk verbunden ist
3. Externe LAMP-Webserver – wir verwenden eine einzelne Instanz, um die neue Konfiguration zu testen

Abgeschlossene Aufgaben:

1. Der DMZ DC wurde der Hosts-Datei hinzugefügt.
2. Die Datei krb5.conf wurde aktualisiert und ein einzelner Realm und eine einzelne Domäne (Domäne1) mit DMZ DC verknüpft.
3. Authentifizierung auf der Kommandozeile mit kinit getestet (funktionierte)
4. Die Datei krb5.conf wurde mit zusätzlichen Realms und Domänen-Realm-Mappings aktualisiert, wobei alle Domänen auf den DMZ-DC verweisen.
5. Die Authentifizierung auf der Befehlszeile mit einem Benutzer aus einem der zusätzlichen Bereiche wurde getestet und ist fehlgeschlagen.

Beispiel für aktuelle Konfigurationen

/etc/hosts/: (Aus Vertraulichkeitsgründen habe ich die tatsächliche IP durch x und die echten Domänennamen ersetzt)

xxx.xxx.xxx.xxx  dc01.domain1.com, dc01.domain2.com, dc01.domain3.com, dc01.domain4.com

/etc/krb5.conf:

[libdefaults]
 default_realm = REALM1.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 clockskew = 12000
 kdc_timesync = 1

[realms]
 REALM1.COM = {
  kdc = dc01.domain1.com
  admin_server= dc01.domain1.com
 }
 REALM2.COM = {
  kdc = dc01.domain2.com
  admin_server= dc01.domain2.com
 }
 REALM3.COM = {
  kdc = dc01.domain3.com
  admin_server= dc01.domain3.com
 }
 REALM4.COM = {
  kdc = dc01.domain4.com
  admin_server= dc01.domain4.com
 }

Probleme:

Die DMZ verarbeitet keine Authentifizierungsanforderungen für die vertrauenswürdigen Domänen. Ich weiß nicht, ob dies an der Konfiguration des DC oder der Kerberos-Konfiguration liegt, daher die Bitte um Hilfe.

Habe einige Stunden damit verbracht, andere Fragen zu Serverfault durchzugehen, zu googeln und Tutorials zu lesen, aber nichts scheint zu unserem Szenario zu passen.

Können wir tun, was wir versuchen, und wenn ja, was müssen wir tun, damit es funktioniert? Ist es einfach, die DMZ als Proxy für die KDCs der anderen Bereiche einzurichten?

---

Als Antwort auf Nathan C zeigt das Sicherheitsprotokoll Anfragen für Kerberos-Servicetickets wie diese:

Audit erfolgreich 14.05.2014 11:05 Microsoft-Windows-Security-Auditing 4769 Kerberos-Serviceticket-Operationen „Ein Kerberos-Serviceticket wurde angefordert.

Kontoinformationen: Kontoname: [email geschützt] Kontodomäne: DOMAIN1.COM Anmelde-GUID: {C93D9AAC-6968-6C00-83EF-2C2D54E2363B}

Dienstinformationen: Dienstname: RODC01$ Dienst-ID: DOMAIN1\RODC01$

Netzwerkinformationen: Client-Adresse: ::1 Client-Port: 0

Zusätzliche Informationen: Ticket-Optionen: 0x40810000 Ticket-Verschlüsselungstyp: 0x17 Fehlercode: 0x0 Durchgelaufene Dienste: -

Dieses Ereignis wird jedes Mal generiert, wenn Zugriff auf eine Ressource wie einen Computer oder einen Windows-Dienst angefordert wird. Der Dienstname gibt die Ressource an, auf die der Zugriff angefordert wurde.

Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert werden, indem die Felder „Anmelde-GUID“ in jedem Ereignis verglichen werden. Das Anmeldeereignis tritt auf dem Computer auf, auf den zugegriffen wurde. Dabei handelt es sich häufig um einen anderen Computer als den Domänencontroller, der das Serviceticket ausgestellt hat.

Ticketoptionen, Verschlüsselungstypen und Fehlercodes sind in RFC 4120 definiert."

Leider stimmt der mir zugesandte Protokollauszug nicht mit den Zeitpunkten überein, zu denen ich die Authentifizierung versucht habe. Daher weiß ich nicht, worauf sich dieser Protokolleintrag tatsächlich bezieht. Ich habe einen weiteren Auszug angefordert.

---

Kontoinformationen:

Kontoname: jameel.rahmaa

Angegebener Realm-Name: DOMAIN1.COM

Benutzer-ID: NULL SID

Service Information:

Dienstname: krbtgt/DOMAIN1.COM

Dienst-ID: NULL SID

Netzwerkinformationen:

Client-Adresse: [WEB IP HIDDEN]

Client-Port: 34567

Weitere Informationen:

Ticketoptionen: 0x40800000

Ergebniscode: 0x6

Ticket-Verschlüsselungstyp: 0xffffffff

Vorauthentifizierungstyp: -

Zertifikatsinformationen:

Name des Zertifikatausstellers:

Seriennummer des Zertifikats:

Fingerabdruck des Zertifikats:

Zertifikatsinformationen werden nur bereitgestellt, wenn für die Vorauthentifizierung ein Zertifikat verwendet wurde.

Vorauthentifizierungstypen, Ticketoptionen, Verschlüsselungstypen und Ergebniscodes sind in RFC 4120 definiert.

Ich weiß nicht warum, aber der letzte Buchstabe meines Namens wurde abgeschnitten.

Answer 1

0x6. KDC_ERR_C_PRINCIPAL_UNKNOWNda ist es ... untersuchen Sie das. Es klingt, als wären Ihre SPNs nicht richtig eingerichtet oder es wird versucht, ein Konto zu verwenden, das nicht einmal existiert. Wireshark ist ein weiteres gutes Tool, das Sie auf dem Webserver ausführen können, um zu sehen, was es vom DC erhält, wenn es Anfragen stellt.