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