AD FS - Windows Integrierte Authentifizierung

[Attack44 2]

Die Testumgebung ist für neue Dinge da die wir schnell/grob ausprobieren möchten bzw. für Dinge mit denen wir noch nicht so viele Berührungspunkte hatten. Die meisten GPOs sind von der produktiven Domain übernommen worden, so dass wir ungefähr die gleiche Ausgangslage haben.

 

Ich bin jetzt einen Schritt weitergekommen, im AuthnContext war ein "Fehler" drin was ich erst jetzt gesehen habe, dort war als Authentifizierungsmethode eingestellt, dass man sich nur mit Passwort anmelden darf. Zum AuthnContext habe ich nun WIA hinzugefügt, worauf im SRVZENTADFS im Log keine Fehler mehr auftauchen.

<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="__authnContextComparison__">
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:federation:authentication:windows
  </saml:AuthnContextClassRef>
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Nur ist das Problem damit nicht ganz gelöst, wenn er jetzt versucht sich über die WIA zu authentifizieren, erhalte ich in jedem Browser ein Login Promt und fordert einem zum Anmelden auf.

Ich habe mir die Internetzonen nochmal angeschaut und keine Fehler gefunden bzw. ich habe auch zum Test in den anderen Zonen (Internet, Lokales Intranet und Vertrauenswürdige Sites) eingestellt, dass er sich automatisch mit aktuellem Benutzernamen und Passwort anmelden soll.

AuthnRequest Template

Hier mal ein Auszug vom AuthnRequest, ob Du da vielleicht etwas siehst was angepasst werden könnte? Ich weiß aktuell nicht genau wo der Fehler herkommt, ob es am ADFS/GPO liegt oder an der Webanwendung, die den Request schickt. Weil hier hat jemand das Problem gelöst bekommen, nur leider funktioniert das bei mir nicht, ist ja auch schon ein paar Tage alt.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="__newId__" Version="2.0" IssueInstant="__instant__" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="__callbackUrl__" Destination="__entryPoint__">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">__issuer__</saml:Issuer>
  __identifierFormatTag__
  __authnContextTag__
</samlp:AuthnRequest>

__newId__: Randomly generated id string

__instant__: Current timestamp

__callbackUrl__: The Rocket.Chat callback URL.

__entryPoint__: The value of the Custom Entry Point setting.

__issuer__: The value of the Custom Issuer setting.

__identifierFormatTag__: The contents of the NameID Policy Template if a valid Identifier Format is configured.

__identifierFormat__: The value of the Identifier Format setting.

__authnContextTag__: The contents of the AuthnContext Template if a valid Custom Authn Context is configured.

__authnContextComparison__: The value of the Authn Context Comparison setting.

__authnContext__: The value of the Custom Authn Context setting.

[Attack44 2]

Ich konnte das Problem jetzt lösen, ich haben den AD FS Server nochmal neu aufgesetzt, dieses mal ein Managed Service Account verwendet und der Farm einen eigenen Namen gegeben und dafür ein Zertifikat gebaut im Anschluss habe ich die User-Agents angepasst und siehe da es funktioniert. Als Vorlage zur Installation/Konfiguration habe diese Anleitung genutzt.

 

Andreas

bearbeitet 12. November 2020 von Attack44

[NorbertFe 2.045]

Aha, also macht man es „richtig“ funktioniert’s auch. ;) quasi: 

 

danke für die Rückmeldung.

 

bye

norbert