Kerberos Constrained Delegation UPN anders als AD FQDN

[bouncer86 5]

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 ?

[bouncer86 5]

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 29. Dezember 2016 von bouncer86

[NilsK 2.930]

Moin,

 

ist der UPN Suffix im AD als solcher definiert? Möglicherweise ist dieses Szenario ein Fall, in dem das erforderlich ist.

 

Gruß, Nils

[bouncer86 5]

Moin,

 

ist der UPN Suffix im AD als solcher definiert? Möglicherweise ist dieses Szenario ein Fall, in dem das erforderlich ist.

 

Gruß, Nils

Welche Stelle im AD meinst du? Unter Domain and Trust? Dort ist sowohl Test.local als auch test.de hinterlegt. Im User sehr selbst lässt sich ja nur ein upn definieren.

[NilsK 2.930]

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 30. Dezember 2016 von NilsK

[testperson 1.674]

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

[bouncer86 5]

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.

[NilsK 2.930]

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

[NorbertFe 2.027]

Naja so lange einen die Kunden immer noch groß anschauen, wenn man nach upn fragt bzw. Ihnen erklärt, dass der Local Part nicht gleichlautend zum samaccountname sein muss...

[bouncer86 5]

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?

[NilsK 2.930]

Moin,

 

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

 

Gruß, Nils

[bouncer86 5]

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 ?

[testperson 1.674]

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?

[bouncer86 5]

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...

[testperson 1.674]

Du hast da eine Domäne / einen Forest, mehrere Domänen / einen Forest oder mehrere Domänen / mehrere Forests?