ADFS issue with hosted WHD

On the advanced tab for the RP trust in ADFS change the secure hash algorithm to SHA1.

You will also need to make sure that the Web Help Desk and ADFS server FQDN's are added into the intranet zone sites for

IE to do the pass though authentication.

Also on the /adfs/ and adfs/ls/ directories under IIS and authentication / windows authentication go to advanced properties

and turn off extended protection and kernel mode authentication

Thanks or the suggestions.  We're already set to SHA1, and not too concerned about pass through authentication (though this is already tested and working aside from the issue described).  In Server 2012 R2 ADFS is 3.0, which doesn't use IIS anymore, but I was none the less able to turn off extended protection.  Unfortunately that doesn't resolve the issue.  Not sure how to turn off kernel mode auth (or if I can at all).

Any other ideas?

ADFS 3.0 does use IIS the same as 2.0 and is needed for SSO with Web Help Desk.

The login server should be https://FQDN/adfs/ls and making sure that the SSL certificate used is from an external CA (versign, godaddy etc)

and SHA1 signed (also the verification cert too) if on Web Help Desk 12.1.0 of lower.

And you might want to try without verification cert

I appreciate your suggestions!  Actually 3.0 really doesn't use IIS - http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx

But no matter, the issues are the same.  So when you suggest trying without a verification cert, are you referring to the cert that you upload to WHD?  You'd try with no cert uploaded?

We're using ADFS 3.0 with our WHD install.

Here's how we have it configured:

On WHD side:

sign-in page URL: https://adfs.fqdn.here/adfs/ls

log out URL: https://adfs.fqdn.here/adfs/ls/?wa=wsignout1.0

The verification certificate is the the Token-signing cert from ADFS

On the ADFS side:

Relying party identifiers: https://whd.fqdn.here/helpdesk/WebObjects/Helpdesk.woa

Encryption: this tab is blank

Endpoints:

SAML Consumer endpoint:

Trusted URL: https://whd.fqdn.here/helpdesk/WebObjects/Helpdesk.woa

Binding: Post

SAML Logout Endpoint:

Trusted URL: https://adfs.fqdn.here/adfs/ls/?wa=wsignout1.0

Binding: Post

Thanks for the detail.  Of course it looks just like our config.   The only difference, which I suspect is the problem, is that our WHD identifier/endpoint end with /wa?id=123 (required to specify our instance in this hosted environment).  This may be the nature of the environment we're working in, in which case I'll have to continue to hope that our hosting provider comes up with a solution.

Ah.

I remember having grief around the certificate as I didn't use the token signing one.

ADFS is pretty chatty in the logs; it might shed some light.

One thing to check in you LDAP settings is what you are using for the authentication attribute, if you are not

using SamAccountName then the default claim mapping will not work and you will need to change to the

appropriate AD attribute.

If Loop1 can get logging of what is happening at sign on they might be able to shed some light on what is happening

Thanks all for the replies and suggestions. We are using SamAccountName in LDAP, mapped to NameID in ADFS.  We provided some logs to Solar Winds, who indicated that the config looked good but also thought there may be a problem with the instance ID in the relying party and endpoint URLs.  I've also confirmed in the ADFS logs that the return request coming from WHD has the wa?id=123 stripped, causing ADFS to be unable to match the relying party trust identifier.  Removing the variable from the URL just breaks it since the Loop1 server doesn't know how to identify the tenant without it.  I'm 90% certain that this is the issue at this point.  Hopefully Loop1 can provide us a URL to access our instance that doesn't require this variable ("vanity" URL perhaps?).  We'll see once their support guy returns from vacation.

Anyone here using WHD with Loop1 and ADFS?