Trusted Domain mit Personalisierungsmodul (Kerberos)

[re-lounge]

Hallo Community,

wir haben einen Kunden bei welchem wir eine Single-Sign-On-Autheitifizierung im Frontend des Intranets mit dem Personalisierungsmodul realiert haben. Die Authentifizierung erfolgt dabei über Kerberos gegen die Domäne des Kunden (im folgenden genannt: "Kundendomäne").

=> Alles OK.

Jetzt ist es aber so, dass es in der Gruppe des Unternehmens weitere Sub-Unternehmen gibt, welche sich auf Ihren PCs an einer eigenen Windows-Domäne (im folgenden genannt: "Subdomäne") authentifizieren.

Auf Windows/Kerberos-Ebene sind diese beiden Domänen als "trusted Domains" eingetragen.

Gibt es eine Möglichkeit, das FirstSpirit Personalisierungsmodul so zu konfigurieren, dass auch alle Rechner, die an der Domäne "Subdomäne" angemeldet sind, automatisch im Frontend des Intranets authentifiziert sind?

Hinweis:

Die Kunden-IT teilt mir hierzu mit, dass dies auf "Kerberos-Ebene" grundsätzlich möglich ist, das Personalisierungsmodul diese Möglichkeit jedoch schlicht nicht anbietet. Ist das richtig so?

Wenn das so ist: Wie wäre hier der nächste Schritt? Soll/kann ich dazu einfach einen FeatureRequest unter Ideas einstellen?

PS.: Zum Einsatz kommt aktuell noch FS 5.1

Beste Grüße,

Stefan Häfele // re-lounge

[isenberg]

Hallo Stefan,

allgemein kann man das FirstSpirit-Loginmodul auch für trusted Domains einfacher Hierarchie einsetzen. Man muss dann nur beachten, welcher Kerberos-SPN in der Keytab-Datei und der zugehörigen Modulkonfiguration in jaas.conf eingetragen wird. Ich muss einmal nachsehen, ob ich noch Informationen zu einer ähnlichen Umgebung habe, wo das Modul eingesetzt wurde. Falls im Unternehmen bereits andere Webserver mit Kerberos-Anmeldung betrieben werden, bitte dort einmal nachsehen, welche SPNs verwendet werden. Die SPNs kann man z.B. auf Client-Seite mittels "klist.exe" auflisten, jeweils die Einträge der Form HTTP/hostname.dnsdomain@WINDOWS-DOMAIN. Bei trusted Domains, die nicht hierarchisch verknüpft sind, wird es tatsächlich schwieriger. In dem Fall ist es einfacher, die Authentifizierung mittels Kerberos im IIS durchzuführen, was dort eine Standardfunktion ist, und dann den HTTP-Header mit dem authentifizierten Benutzernamen durch das FirstSpirit RequestHeader-LoginModul auszulesen.

[re-lounge]

Hallo Holger,

vielen Dank für Deine schnelle Rückmeldung!

Ich habe Rücksprache mit der IT gehalten und folgendes zu berichten:

Voraussetzung: 

Mit dem Begriff „hierarchisches AD“ ist ein AD mit Subdomains gemeint, oder?

Beim Kunden gibt es kein hierarchisches AD. Es gibt eben „nur“ die Vertrauensstellung (=trusted) der beiden autonomen ADs. Kommen wir auch in diesem Szenario weiter?

[isenberg]

Hallo Stefan,

ja, mit nur 2 Domains könnte es auch noch funktionieren, weil die direkt miteinander verbunden sind ohne weitere Domains dazwischen.

Wo bleibt denn aktuell die Authentifizierung hängen? Von Domain A funktioniert es ja, soweit ich es richtig verstanden habe. Dort ist auf Client-Seite dann bei Aufruf von klist.exe ein Ticket zum SPN HTTP/hostname.dnsdomain-a@DOMAIN-A zu sehen. Was zeigt das klist beim Zugriff von Domain B aus an? Ist im Browser bei Domain B Kerberos für die URL http://hostname.dnsdmain-a aktiviert? Zur Konfiguration der Browser für Kerberos siehe FirstSpirit Admin-Handbuch Kapitel "Konfiguration der Clients" Seite 105.

[MichaelaReydt]

Hallo Stefan,

ist dieses Posting noch offen? Benötigst du noch weitere Hilfe oder konnten dir Holgers Antworten bereits weiterhelfen? In diesem Fall wäre es super, wenn du seine "richtige Antwort" entsprechend markierst.

Solltest du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es toll, wenn du sie hier bereitstellst.

Viele Grüße

Michaela

[re-lounge]

Hallo Michaela,

mein Urlaub hat hier leider dazwischengegrätscht, so dass ich aktuell noch mit der Kunden-IT in der Abstimmung bin. Sobald ich Rückmeldungen zu den Tests oder gar eine Lösung habe, melde ich mich selbstverständlich hier direkt wieder...

Beste Grüße,

Stefan Häfele

[sebastianc]

Hallo Stefan,

gibt es mittlerweile Neuigkeiten bezüglich deiner Fragestellung?

Viele Grüße,

Sebastian

[re-lounge]

Hallo Sebastian,

leider noch immer nicht .

Ich hab den IT-Man nun gebeten direkt hier selbst aktiv zu werden, damit diese doch hochtechnische Thematik nicht ständig über mich (als "unwissenden Dritten") geschleift werden muss.

Beste Grüße,

Stefan // re-lounge

[herrmann]

Hallo Herr Isenberg,

zur Verständlichkeit möchte ich kurz das gesamte Szenario darstellen 🙂

Erste  DNS-Domain: a.intern

Zweite DNS-Domain: b.intern

Domain a.intern vertraut Domain b.intern

Domain b.intern vertraut nicht Domain a.intern

Von allen Clients in Domain a.intern ist das Intranet direkt erreichbar unter http://intranet.a.intern (keine Firewall oder Proxy dazwischen).

Clients in a.intern haben ein Kerberos-Ticket HTTP/intranet.a.intern@A.INTERN

Clients in b.intern können über einen Proxy auf Webserver von a.intern zugreifen.

Clients in b.intern müsen sich beim Proxy mit einem AD-Konto von b.intern authentifizieren.

Clients in b.intern haben im Browser in der Liste der Intranet-Trusted-Sites etliche Server der Domain a.intern und b.intern eingetragen.

Clients in b.intern haben keinen Zugriff auf das Active-Directory der Domain a.intern

Daher können Clients aus b.intern sich kein Kerberos-Service-Ticket für http://intranet.a.intern@A.INTERN ausstellen lassen

Clients in b.intern habe in der Ticketliste (klist.exe) folgendene zustätzliche zwei Tickets nach dem Aufruf des Intranet:

  krbtgt/A.INTERN@B.INTERN

  HTTP/proxy.b.intern@B.INTERN

Meiner Ansicht nach könnte das SSO mit Kerberos für Clients aus b.intern funktionieren, wenn diese Clients direkt auf das ActiveDirectory von a.intern zugreifen dürfen.

Dies ist jedoch durch eine Unternehmensrichtline und Security untersagt.

Gibt es trotzdem eine Lösung?

Viele Grüße,

Hans Herrmann