Jump to content

Kerberos Constrained Delegation UPN anders als AD FQDN


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

in unserem AD test.local haben wir für unsere Benutzer als UPN test.de konfiguriert. Die Anmeldung an den Workstations funktioniert.

 

Nun möchten wir zwecks Zertifikatsbasierter Authentifizierung Kerberos Constrained Delegation nutzen. Hier bekommen wir kein Ticket für den User otto@test.de. Unser Kerberos Client meldet, REALM not Found.

 

Nun sagt der Supporter von der Lösung (Citrix Netscaler), dass es auch am AD liegen kann.

 

Dies glaube ich nicht, da ja die Workstation Anmeldung funktioniert. Habt ihr dazu irgendwelche Infos, bzw. KCD schon mal mit unterschiedlichen UPN zu AD FQDN konfiguriert ?

Link zu diesem Kommentar

Ich habe mittlerweile herausfinden, dass ich ein Kerberos Ticket erhalte, wenn ich dieses für otto@test.local anfordere. Obwohl im AD Objekt als UPN @test.de konfiguriert ist.

 

Aber warum funktioniert es? Eine interaktive Windows Anmeldung geht nur mit @test.de !?

 

PS: die Frage geht an Microsoft und hat nichts mit Citrix Netscaler zu tun.

bearbeitet von bouncer86
Link zu diesem Kommentar

Moin,

 

hm, okay, war so ein Verdacht. Im ADUC kann man in der Tat nur dann ein anderes UPN-Suffix auswählen, wenn es im AD definiert ist (Forest- oder OU-Ebene). Legt man User per Skript an, dann kann man beliebige Suffizes nutzen, auch wenn sie nicht zentral vorgegeben sind.

 

Dann scheint hier aber kein Zusammenhang zu bestehen. Ich bin momentan überfragt, vielleicht hat noch jemand eine Idee.

Auf meine Netscaler-Kollegen habe ich wg. Urlaubs :) gerade keinen Zugriff, ich weiß, dass die auf der Ebene recht viel unterwegs sind.

 

Gruß, Nils

bearbeitet von NilsK
Link zu diesem Kommentar

Hi,

 

wie sieht denn deine LDAP Policy am Netscaler aus?

Geht es hier um AAA und SSOn zu "irgendetwas" oder "ganz normal" Netscaler GW -> Storefront?

 

Gruß

Jan

Geht um AAA mit einer. Cert authentication policy. Der Netscaler in Version 11 Build 69 macht dann Kerberos constrained delegation gegen Exchange.

 

Aber wie geschrieben, ich glaube nicht, dass es etwas netscaler spezifisches ist. Könnte ja mit dem TMG( ja abgekündigt, ich weiß ;) ) das gleiche Szenario haben.

UPN im Zertifikat ein anderer sein, als der fqdn des active Directory.

 

Die Frage ist halt, ob es das AD generell nicht erlaubt, Tickets für UPNs auszustellen. Oder wie der supportete Weg in solch einem Szenario auszusehen hat.

Link zu diesem Kommentar

Moin,

 

Die Frage ist halt, ob es das AD generell nicht erlaubt, Tickets für UPNs auszustellen.

 

ohne es genau sagen zu können (weil ich es bisher nicht recherchieren musste): Das halte ich für höchst unwahrscheinlich. Der UPN ist gleichwertig zum herkömmlichen Anmeldenamen (sAMAccountName) und sollte diesen ursprünglich in kurzer Zeit* ablösen.

 

Ich würde eher vermuten, dass der NetScaler nicht richtig fragt. Aber das ist Spekulation.

 

Gruß, Nils

* das war zu der Zeit, als man auch noch dachte, WINS hätte sich bald erledigt. :D

Link zu diesem Kommentar

Moin,

 

 

 

ohne es genau sagen zu können (weil ich es bisher nicht recherchieren musste): Das halte ich für höchst unwahrscheinlich. Der UPN ist gleichwertig zum herkömmlichen Anmeldenamen (sAMAccountName) und sollte diesen ursprünglich in kurzer Zeit* ablösen.

 

Ich würde eher vermuten, dass der NetScaler nicht richtig fragt. Aber das ist Spekulation.

 

Gruß, Nils

* das war zu der Zeit, als man auch noch dachte, WINS hätte sich bald erledigt. :D

 

Hallo Nils,

 

Vielen Dank. Hast du spontan eine Idee, wo man die Frage am besten einkippt?

Link zu diesem Kommentar

Moin,

 

ich würde auf den Citrix-Support tippen. Oder auf einen Partner, der NetScaler in der Tiefe supporten kann.

 

Gruß, Nils

 

Hi Nils,

 

der Citrix Support ist selbst etwas ratlos zur Zeit und weiß nicht, ob sich das AD richtig verhält, oder der Netscaler falsch. Daher hier die Frage.

 

Hat jemand so ein Konstrukt denn schon mal mit einem TMG / F5 oder sonstigem Reverse Proxy umgesetzt und kann sagen, wie es dort funktioniert ?

Link zu diesem Kommentar

Was der Netscaler da tut solltest du in der aaad.debug und / oder der nskrb.debug finden. Die sollte der Citrix Support aber kennen ;) Vielleicht lässt du das Ticket da mal eskalieren.

Funktioniert denn alles wie gewünscht, wenn du die Authentifizierung testweise nur per LDAP per UPN machst?

 

LDAP Auth an sich funktioniert. 

 

Habe gerade festgestellt, mein oben beschriebenes Szenario ist doch nicht ganz korrekt. Der Netscaler hatte ein Kerberos Ticket gecached, daher funktionierte die Authentifizierung mit REALM "test.local", obwohl im User Objekt als REALM "TEST.DE" eingetragen ist. 

 

Stelle ich im AD im User Objekt den REALM auf "test.local" funktioniert auch Kerberos Constrained Delegation gegen den Netscaler einwandfrei.

 

Aber das möchte ich ja nicht. Ich glaube daher nicht, dass es ein Netscaler Konfigurationsfehler ist. Sondern entweder ein Bug, oder aber das Active Directory kann keine Kerberos Tickets ausstellen, für UPN's. 

 

Erhalte im nskrb.debug Log übrigens die Meldung: "Error obtaining cross realm s4u2self ticket for"

 

Mich wundert nur, dass ich scheinbar mal wieder der einzige bin, bei dem UPN vom AD FQDN Namen abweicht und Kerberos Constrained Delegation benötigt...

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...