none
ADFS SSO und Claim Erstellung RRS feed

  • Frage

  • Hallo zusammen,

    ich habe folgende Situation.

    Ich habe ein kleine AD Infrastruktur bestehend aus zwei Domänencontrollern, einem Exchange-Server, einem Sharepoint-Server, eine Hand voll Clients und seit neustem einem ADFS-Server.

    Die Infrastruktur wird für eine Teamchat-Lösung benutzt. Nun soll für diese Teamchat-Lösung SSO via ADFS realisiert werden. Den ADFS-Server (dediziert) habe ich aufgesetzt, eine RPT eingerichtet. 

    Mit den Claims/Ansprüchen habe ich aber meine Schwierigkeiten. 

    Also Rule Template habe ich "Send LDAP Attributes as Claims" genommen und LDAP Attribute "E-Mail-Addresses" sowie Outgoing Claim Type "E-Mail Address" gewählt.

    Danach habe ich ein Rule Template "Transform an Incoming Claim" genommen, Incoming Claim Type als "E-Mail Adress", Outgoing claim Type als "Name ID" und also Outgoing name ID format habe ich "Email" genommen.

    Jetzt erhalte ich, sobald ich mich am Teamchat anmelden möchte folgende Fehlermeldung:

    Fehler:

    invalid_response
    Grund: The status code of the Response was not Success, was Requester -> urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy

    Im ADFS erhalte ich die beiden Events 321 und 364.

    Event 321

    Event 364

    Die Anwendung als solches erwartet eine im SAML 2.0 mitgeschickte Email. 

    Habe ich die falschen Claims erstellt? Wenn ja, wie erkenne ich das? Und wenn ja, welche müssten es sein?

    Wie schicke ich die Email im SAML 2.0 Style mit? Und wie erkenne ich, dass das Mailattribute gesendet wird.

    P.S.: Die Mailadressen sind im Useraccount gepflegt.

    Mittwoch, 23. August 2017 09:47

Antworten

  • Hi,

    hat etwas gedauert, aber das Problem ist gelöst. Die Claims waren richtig und alles andere sogar beim ersten Versuch richtig konfiguriert. Jedoch hat die Anwendung (eine Teamchat-Software) etwas anderes erwartet bzw. als Ergebnis angenommen.

    Das stand letztendlich auch in den Events ;-)

    • Als Antwort markiert Thorsten Jung Freitag, 5. Januar 2018 14:36
    Freitag, 5. Januar 2018 14:36

Alle Antworten

  • Hallo Thorsten Jung,

    die Ursache könnte sein, dass die benutzerdefinierte Anspruchsregel nicht richtig konfiguriert ist und daher die SAML-Abfragerückmeldung fehlschlägt.

    Empfehlenswert wäre, sicherzustellen, dass die Attribute-Zuordnung für "user_principal" und "UID" unter AD FS- benutzerdefinierte Anspruchsregeln (Claim Rules) wie in der Konfigurations-GUID definiert werden.

    1. RDP zum AD FS-System.

    2. Bearbeiten Sie die Anspruchsregel für benutzerdefinierte Anspruchsregeln.

    3. Stellen Sie sicher, dass der AD FS-IDs FQDN (Vollständig qualifizierter Domänenname) angegeben ist.

    Weitere Informationen zur Problembehandlung spezieller Probleme mit den Anforderungsfehler, können Sie unter dem Abschintt "Troubleshooting SAML request failures" (Ereignis ID: 321 und Ereignis ID: 364) im folgenden Dokument finden.

    Troubleshooting Fedpassive request failures with AD FS 2.0

    Gruß

    Michaela


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.



    Donnerstag, 24. August 2017 09:51
    Moderator
  • Hi Michaela,

    ich glaube, dass ich das noch nicht richtig verstanden habe. Es muss zwingend die Email verwendet werden, da in der Teamchat Applikation nichts weiter verwendet wird. Weder Name, noch User_Principal.

    Wie definiere die Anspruchsregel korrekt?

    Donnerstag, 24. August 2017 09:56
  • Hi,

    hat etwas gedauert, aber das Problem ist gelöst. Die Claims waren richtig und alles andere sogar beim ersten Versuch richtig konfiguriert. Jedoch hat die Anwendung (eine Teamchat-Software) etwas anderes erwartet bzw. als Ergebnis angenommen.

    Das stand letztendlich auch in den Events ;-)

    • Als Antwort markiert Thorsten Jung Freitag, 5. Januar 2018 14:36
    Freitag, 5. Januar 2018 14:36