asked on

ADFS Configuration Issue

We have an ADFS server set up that we use authenticate our domain users for Skype for Business online. This works successfully so I know that the basic configuration is correct. I have created a relay trust with one of our application partners, who have written their own STS system. When clicking on the link to the application, we are redirected to our AD FS front end but we're unable to login. Speaking to our partner, they're saying that the claim we're producing does not include the name id which they need to allow us to login. The relay trust has been set up without encryption or signing requirements and I have set up a rule that based on the Mapping of LDAP Attributes to outgoing claim types with the LDAP attribute being E-Mail-Addresses and the outgoing claim type Name ID.

When trying to connect, 2 events are generated in the AD FS Admin log of the ADFS server. These events are;
1) Event 303. The Federation Service encountered an error while processing the SAML authentication request (MSIS0037: No signature verification found for issuer https://xxxxxx
2) Event 364 . Encountered error during federation passive request (MSIS0037: No signature verification certificate found for issuer https://xxxxxx

The site https://xxxxxx (which is set up as the identifier in the relay party trust) has a mismatched certificate name but as signing and encryption are switched off on the trust, I don't understand why I'm seeing the message and why the token is not being generated.

Can anyone help?

Thanks.

Adam Brown

You'll need to first verify that the attribute you're transforming the email to exactly matches the value they use for that field on their end. That info *should* be included in their metadata file, but you may need to communicate with them to get the info from them. You'll also need to make sure the value is *formatted* correctly to match what their system needs. It's entirely possible that their system doesn't accept UPN formatted Name IDs and is filtering out what you're passing them. Again, you'll need to communicate with them on this to verify.

Regarding the error messages you're getting, you will need to verify whether the other side will accept unsigned, unencrypted trusts. If they don't accept those kinds of trusts, they'll never trust your environment (And really, I wouldn't want to disable those features on a relying party trust).

And in that vein, the Verification Certificate used is *not* the certificate used by your ADFS server's HTTPS interface. It's the Token Signing Certificate generated, used, and exchanged by the relying party you created the trust with at the time the trust was created. You can turn Signature Verification and Encryption on even if the HTTPS certificate doesn't match the namespace used by the trust. ADFS uses self-signed certificates for Verification and Token Signing, and the other side's configuration determines whether to ignore the certificate errors when connecting through HTTPS. Read this for more info: https://technet.microsoft.com/en-us/library/cc730660(v=ws.11).aspx

Paul Gray

ASKER

Hi Adam, Thanks for the comment. The resource party in this case is a self-written STS server, with no metadata, so the RPT was set up manually. They assure me that it works with other fed services but we're the first to try with ADFS. It's quite possible that my lack of experience with this is causing the issue. They are expecting a non-encrypted and non-signed token and their only stipulation is that we send them a name id with our users email address.

To this end, I have set up the following;

On our Claims Provider Trust for AD, pass through UPN claims (authentication through our fed server is done through UPN)
On the Relying Party Trust, what they called their entity ID is set as the identifier and their ACS URL's are set as the Endpoints, with nothing in encryption or signatures
The Issuance Authorisation rule is permit all
The Issuance Transform rule is a Send LDAP Attribute as claim (LDAP attribute E-Mail-Addresses, out going claim type = Name ID)

Paul Gray

ASKER

We're no nearer resolving this issue. The token coming in is unencrypted and unsigned and we're not encrypting the out going token. I have read somewhere that ADFS will always sign an outgoing token. If this is true, then our partner will have to accommodate that but I'm still confused as to why we're getting the error messages in the event log. Why is ADFS attempting to validate the identifier certificate. Isn't the identifier in effect the realm?

Kaibuk

When you were setting up the Relying partners where you provided with a XML file to pull all the required certificates and configuration or did you setup everything manually?

You could try to use following cmdlet:
Get-ADFSRelyingPartyTrust -TargetName relyingpartyname and check whats set on SignedSamlRequestsRequired

You could try to set it to $false
Set-ADFSRelyingPartyTrust -TargetName relyingpartyname -SignedSamlRequestsRequired $false

But most important is that you make sure you get a xml file from the Application Partner so you cna import all the configuration rather then setting it up manually. My experience showed me that a lot of vendors don't have any idea how SSO works and, they always try to blame your system bt at the end they don't have a clue what they are doing so ask for the xml file review it or better create a new relying partner with the imported XML.

This question needs an answer!

Become an EE member today

7 DAY FREE TRIAL

Members can start a 7-Day Free trial then enjoy unlimited access to the platform.

View membership options

Learn why we charge membership fees

We get it - no one likes a content blocker. Take one extra minute and find out why we block content.