BLangley
Tera Contributor

Working for 2 years with ADFS 2.0 and ServiceNow and trying to upgrade to ADFS 2012 R2 (alias ADFS 3.0) and currently running fine internally and externally. We chose this option as we had a third party product with ADFS to allow email as logon ID.

  Now, After upgrading to ADFS 3.0 this option does not work internally and externally. This is now a pure vanilla Microsoft only environment as ADFS 3 allows email as logon ID.


If we try .
setAuthnContextClassRef("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport")

it works externally but not internally, and
- If we try .
setAuthnContextClassRef("urn:federation:authentication:windows")

it works internally but not externally
We need some option set that will work both ways and since ADFS 3.0 is nearly 10 months old this hopefully is not a new problem


Has anyone experienced this issue with ADFS 3.0 and ServiceNow, and does anyone know of a solution or work around? Thanks for any assistance you can provide!

2 Comments
BLangley
Tera Contributor

Solution: In the SAML 2.0 Properties, after changing the AuthContextClassRef method to "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", the Create an AuthnContextClass request in the AuthnRequest statement must be unchecked. Now both internal and external authentication are working.


poyntzj
Kilo Sage

Hi Bobby


what version of Service-now are you running ? and is that the SAML 2.0 Update 1 ?



cheers