AD FS 2.0 Error 371 bei manuell konfiguriertem Claims Provider Trust

[jostrn 13]

Hallo,

 

bei der manuellen Einrichtung eines nicht von außen erreichbaren Claims Providers mit selbst signiertem Zertifikat kommt bei Anmeldeversuchen im AD FS der Relying Party

 

Source:        AD FS 2.0

Event ID:      371

Level:         Error

 

Cannot find certificate to validate message/token signature obtained from claims provider. 

Claims provider: http://adfs.claimsprovider.local/adfs/services/trust 

 

Source:        AD FS 2.0

Event ID:      111

Level:         Error

 

Description:

The Federation Service encountered an error while processing the WS-Trust request. 

Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue 

 

Additional Data 

Exception details: 

Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier

    (

    IsReadOnly = False,

    Count = 1,

    Clause[0] = Microsoft.IdentityServer.Tokens.MSISSecurityKeyIdentifierClause

    )

'. Ensure that the SecurityTokenResolver is populated with the required key.

 

Das Zertifikat und die CA sind bei der Relying Party im Computerkonto installiert.

 

Edt: Die selbsterstellte CA des Claims Providers wird auch in der Zertifikateverwaltung des AD FS 2.0 Windows Service der Relying Party angezeigt, der dortige Personal-Folder enthält gar keine Zertifikate, auch nicht die der funktionierenden Claims Provider.

 

Liegt hier überhaupt ein Problem mit dem Schlüssel vor oder liegt es vielleicht an etwas anderem? Bei den anderen über die https-Adresse erreichbar und konfigurierten Claims Provider Trusts sind AcceptanceTransformRules und ClaimsOffered befüllt, bei diesem nicht. Muss da was drin stehen?

 

Get-ADFSClaimsProviderTrust "ClaimsProvider"

 

AllowCreate                              : True

AutoUpdateEnabled                        : False

WSFedEndpoint                            : https://adfs.claimsprovider.local/adfs/ls/

AcceptanceTransformRules                 :

ClaimsOffered                            : {}

ConflictWithPublishedPolicy              : False

Enabled                                  : True

EncryptionCertificate                    : [subject]

                                             CN=adfs.claimsprovider.local

 

                                           [issuer]

                                             CN=ITCERT, DC=claimsprovider, DC=local

 

EncryptionCertificateRevocationCheck     : CheckChainExcludeRoot

SigningCertificateRevocationCheck        : CheckChainExcludeRoot

Identifier                               : http://adfs.claimsprovider.local/adfs/services/trust

LastMonitoredTime                        : 1/1/1900 1:00:00 AM

LastPublishedPolicyCheckSuccessful       :

LastUpdateTime                           : 1/1/1900 1:00:00 AM

MetadataUrl                              :

MonitoringEnabled                        : False

Name                                     : Claims Provider

Notes                                    :

OrganizationInfo                         :

ProtocolProfile                          : WsFed-SAML

RequiredNameIdFormat                     :

EncryptedNameIdRequired                  : False

SignedSamlRequestsRequired               : False

SamlAuthenticationRequestIndex           : 0

SamlAuthenticationRequestParameters      : None

SamlAuthenticationRequestProtocolBinding :

SamlEndpoints                            : {Microsoft.IdentityServer.PowerShell.Resources.SamlEndpoint, Microsoft.Ident

                                           ityServer.PowerShell.Resources.SamlEndpoint, Microsoft.IdentityServer.PowerS

                                           hell.Resources.SamlEndpoint, Microsoft.IdentityServer.PowerShell.Resources.S

                                           amlEndpoint}

SignatureAlgorithm                       : http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

TokenSigningCertificates                 : {[subject]

                                             CN=adfs.claimsprovider.local

 

                                           [issuer]

                                             CN=TECCERT, DC=claimsprovider, DC=local

 

Get-ADFSClaimsProviderTrust "WorkingClaimProvider" | Select AcceptanceTransformRules, ClaimsOffered | fl

 

AcceptanceTransformRules : @RuleTemplate = "PassThroughClaims"

                           @RuleName = "E-Mail"

                           c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]

                            => issue(claim = c);

 

                           @RuleTemplate = "PassThroughClaims"

                           @RuleName = "Role"

                           c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"]

                            => issue(claim = c);

 

                           @RuleTemplate = "PassThroughClaims"

                           @RuleName = "Group (MGR)"

                           c:[Type == "http://schemas.xmlsoap.org/claims/Group"]

                            => issue(claim = c);

 

ClaimsOffered            : {, , , ...}

 

 

Vielen Dank für eure Hilfe.

bearbeitet 13. November 2014 von jostrn

[NilsK 2.789]

Moin,

 

die Fehlermeldung besagt schon, dass das passende Zertifikat nicht gefunden wurde. Hast du sowohl das Zertifikat selbst als auch das Root-Zertifikat bei der Relying Party installiert?

 

Hier wird die Konfiguration noch mal ganz hübsch beschrieben:

 

[How to Build Your ADFS Lab on Server 2012 Part 1 - Ask Premier Field Engineering (PFE) Platforms- TechNet Blogs]
http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx
 

Die anderen Dinge müssen sicher auch noch geprüft werden, aber das Zertifikat musst du zuerst lösen, sonst geht es nicht weiter.

 

Gruß, Nils

[jostrn 13]

Moin Nils,

 

 

die Fehlermeldung besagt schon, dass das passende Zertifikat nicht gefunden wurde. Hast du sowohl das Zertifikat selbst als auch das Root-Zertifikat bei der Relying Party installiert?

Ich glaube schon, aber nach Deinem hervorragenden Verweis zu TechNet und dort wiederum hierher bin ich verwirrt:

 

Which type of certificates does AD FS require?

Basically you need three types of certificates.

• Service communication certificate
  • AD FS uses this certificate to enable HTTPS which is a requirement for traffic to and from the federation server and federation server proxies ( to secure communication) So it is basically a SSL certificate which needs to be installed on the IIS for each federation server and federation server proxy
• Token signing certificate
  • AD FS uses this certificate to digitally sign outgoing AD FS tokens. This is not used to secure data but in fact it is used to ensure the integrity of the security tokens as they pass between the federation servers and application server via the client computer.
• Token decrypting certificate
  • AD FS 2.0 and above has the ability to encrypt the contents of the AD FS tokens. This is in addition to having these tokens signed by the server's token signing certificate.

 

Das erste ist klar, da ist seitens der Relying Party ein öffentlich signiertes externes Zertifikat hinterlegt. Als Token signing certificate ist das selbsterstellte Zertifikat des Claims Provider eingetragen, auch richtig nehme ich an.

Bei Token decrypting certificate war nichts drin und ich habe manuell ebenfalls das selbsterstellte Zertifikat des Claims Provider eingetragen - das war falsch? Für das selbsterstellte Zertifikat des Claims Provider hat die Relying Party keinen Schlüssel was zu der Fehlermeldung passen würde!

 

Ergo: Token decrypting certificate leer lassen oder mit einem Zertifikat ersetzen, für das beide Seiten einen Schlüssel haben?

[NilsK 2.789]

Moin,

 

bei einer asymmetrischen Verschlüsselung hat die Relying Party natürlich nicht den Schlüssel des Claims Providers. Der muss immer geheim bleiben.

 

Der empfohlene Weg ist, für die beiden Token-Zertifikate bei "Self-signed" zu bleiben. Damit die Relying Party (in SAML-Sprech ist das der Service Provider) die verschlüsselten Zertifikate entschlüsseln kann, braucht er das "öffentliche" Zertifikat des Claims Providers (in SAML: Identity Provider). Normalerweise werden diese Zertifikate beim Einrichten des Trusts zwischen den Parteien ausgetauscht. Um was für eine SAML-Implementierung handelt es sich denn bei der Relying Party?

 

Gruß, Nils

[jostrn 13]

Ich meine, dass es so konfiguriert ist, wie Du sagst:
Relying Party: bei beiden Token-Zertifikaten ist das selbsterstellte Zertifikat des Claims Provider eingestellt; manuell erstellter Trust, siehe auch die Screenshots.
Claims Provider: bei allen drei Zertifikaten ist das StartSSL Class 2-Zertifikat der Relying Party eingestellt; Trust via Verbundmetadaten-Adresse.
 
Andere Claims-Provider funktionieren mit der Relying Party, auch da sind für beide Tokens die StartSSL Class 2-Zertifikate eingestellt. (Und auch nicht änderbar, wegen Konfiguration über die Verbundmetadaten-Adresse.)

 

Wie finde ich raus, um welche SAML-Implementierung es sich handelt?

XML-Datei Relying Party: <EntityDescriptor [...] xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

XML-Datei Claims Provider: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ...

Claims Provider Trust, Reiter Endpoints:

WS-Federation Passive
SAML Single Sign-On Redirect & Push
SAML Logout Endpoint Redirect & Push

 

Dieses Beitrags nach soll das Problem in der nicht konfigurierten Signatur des Claims Provider liegen, aber da steht das StartSSL-Zertifikat drin und kann auch nicht geändert werden :confused:

[NilsK 2.789]

Moin,

 

ich meine, um was für einen Typ Relying Party es sich handelt. Ist das auch ADFS? Dann wäre es ggf. einfacher, mit dem Metadaten-Austausch zu arbeiten, als den Trust manuell einzurichten. Oder ist das so geschehen?

 

Das SSL-Zertifikat setzt man normalerweise nur als Service-Zertifikat ein, eben für SSL. Für die Verarbeitung der Tokens nutzt man eigene Zertifikate (eben meist die selbstsignierten), nicht das SSL-Zertifikat. In den Eigenschaften der Relying Party muss das Token-Signing-Zertifikat der anderen Seite stehen.

 

Gruß, Nils

bearbeitet 13. November 2014 von NilsK

[jostrn 13]

Ach so, sorry! Beidseitig Windows Server 2008 R2 mit AD FS 2.0.

 

Was meinst Du mit Metadaten-Austausch? Der Claims Provider kann die Relying Party erreichen, aber nicht umgekehrt. Daher musste ich den Trust manuell mit den Daten aus der /FederationMetadata/2007-06/FederationMetadata.XML des Claims Provider erstellen - oder geht das einfacher?