
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-07-2017 09:33 PM
G'Day fantastic people.
So I have done a few implementations with customers establishing SSO via the customers ADFS and the ServiceNow SAML connection.
And what happens is:
1. If customer is on internal customer network, browsing to instance takes them straight to the instance, because their network email is the same as in SN;
2. If customer is remote (ie Not on network), then they are presented with the ADFS Sign in Page, where they select what they want to connect to, being name of instance, followed by their network credentials. Hit Ok and they are into their instance.
This is all great.
However, this time, no matter what I try, the customer will ALWAYS ends up at the ADFS login page. They can select instance, pop in some credentials (network), and they are in. But for users on the internal network, I want this to bypass the ADFS screen and assuming their emails match, let them in.
I have used the URL that allows me to hard code the service I want to go to, that's fine.... albeit it still asked me to login at the ADFS page even if I'm already logged into the network.
[Here is the URL for reference ... https://samportal.example.com/adfs/ls/idpinitiatedsignon.aspx?logintoRP=https://company.service-n... (of course, with values changed)]
The only thing I can see different is that the customer is using ADFS 3.0, and the others ADFS 2.0.
Any ideas out there? Thanks in advance.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-09-2017 09:22 PM
Hi Darren,
I assume its a new ADFS server. Did you check the Authentication Policy ? Image is attached :
If thats already set, you can force the Windows Auth by ticking the "Create an AuthnContextClass" property and setting "AuthnContextClassRef method" to "urn:federation:authentication:windows".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-07-2017 11:27 PM
Hi Darren,
Can you go to the following page and check the 2 settings mentioned and set them the same :
(Workaround) Support Kerberos authentication
Cheers

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-07-2017 11:47 PM
Sorry Mohamad
I should have mentioned, that I already have the Kerberos workaround in place as follows:
AuthnContextClassRef method is set to
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Thanks for responding though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2017 08:40 AM
Hello Darren.
You tried with this one?
urn:federation:authentication:windows

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2017 04:42 PM
Hi Corina
Yes, I have also tried that, bit as with both settings in the Kerberos workaround, neither of the make a difference.
Thanks for making the suggestion though.