ADFS 3.0 Server 2012 R2

[DamienG1121]

Good Afternoon, I have set up ADFS 3.0 on our DC running Windows Server 2012 R2.

I have Dirsynced all our accounts to Office 365 configured Single Sign On. I can Redirect to our ADFS logon page However when you redirect the ADFS Logon Page it is asking still for a password. I have AD synced to Azure also and according to both domains they are federated for Single Sign On. I have assigned a Wildcard Certificate and made sure the domain exists everywhere. I also have The Token Certificates configured as per what ADFS makes when it is set up. As far as I can see it should all work however I still can't get it to just bypass the logon and go straight into office 365. It does login manually absolutely fine using the UPN Suffix. I have made sure all accounts have been updated to the UPN Suffix I wish to use. I have also got TMG 2010 Configured as our Web Application Proxy and when you do a test using the test connectivity page on Microsoft it all passes. I am just not sure what I could be missing to cause it not to logon automatically. Any help would be really appreciated.

Thank you,

Damien

[FN-GM]

Did you add the ADFS URL as an Intranet Zone in IE?

 

If using a browser other an IE you will need to do this - ADFS v3 on Server 2012 R2 – Allow Chrome to automatically sign-in internally | Jack Stromberg

[DamienG1121]

We have Site to Zone Assignment List set up through our Default Domain Policy GPO and I have added the URL in there. I have also made sure in Advanced IE Options. Windows integrated authentication is enabled. Although our ADFS is set up for just using Forms Authentication. I have tested outside the office also still the same symptoms.

 

I am just looking at it thinking what have I missed...

 

So far Steps I have follows are

 

Set up DirSync

Used IDFix to fix any broken UPN Suffixes so all User Accounts are updated.

Set up ADFS Role using Wild Card SSL Certificate.

Configured a WID Set up service account etc.

Add an A Record in DNS to point to the Server ADFS is hosted on.

Made sure in our DNS Panel externally an A Record is pointing to our External IP with the FQDN tag.

Set up the domains to be federated.

Synced all user accounts to Azure AD.

Made sure the page comes up.

Have done remote connectivity test using

https://testconnectivity.microsoft.com/

 

Made primary authentication for both internal and external to be forms authentication. Made sure all UPN Suffixes are passed through.

 

Rebooted the server.

 

Gone to Login.microsoftonline.com typed in the UPN suffix to which it redirected to our ADFS Page. The page shows up fine but just asks for a password.

 

I have also gone to the IDPinitiated Sign on and that asks for a password too.

 

It signs in fine manually and signs out fine.

 

Thanks I appreciate your help with this.

[FN-GM]

You shouldn't edit the Default Domain GPO every by the way

 

What browser are you using?

[DamienG1121]

It was all done before I started working here. It's not something I tend to touch

 

I have tested using IE 11, Google Chrome (I have tested removing the extendedtokenchcheck) Found the PS on TechNet but it didn't make a different. I also tested Opera and have tested on Microsoft Edge.

 

It doesn't seem to like any of them.

[FN-GM]

Does your internal DNS of the URL point to the private IP of the ADFS server? When you do an NSLookup what do you see?

[DamienG1121]

It does yeah It shows the DN then shows the IP as the server. OOB scenario. It couldn't be because ADFS 3.0 role is installed on a DC that surely wouldn't cause the authentication problem would it. I would have thought it would all just link properly. Plus I thought Microsoft fixed it for Version 3.0. If it does I can try adding it as a member server and see how it roles. Just wondering now if it is a known bug...

 

Thanks,

 

Damien

[DamienG1121]

On a member server can you have just the role installed and nothing else or do you have to DNS installed and all of that stuff. This is the first time I am setting all this up so it is really new ground.

[DamienG1121]

Following on from earlier. I have since moved ADFS of the DC and installed it on a member server running 2012 R2. I am still somehow getting the same error.... Not sure what it could be..

[DamienG1121]

So everything is set up on here now I have covered everything I think. I can get logged into this page manually absolutely fine by typing in the password. I just don't know what to look for for it to not require a password to sign on and just go straight through when I log onto my desktop in the morning.

 

Done all IE checks moved ADFS onto a member server set up TMG to pass through and it does.

 

I just am resigning to the dreadful line now of "I don't know".

[mrbios]

[ATTACH=CONFIG]34830[/ATTACH] So everything is set up on here now I have covered everything I think. I can get logged into this page manually absolutely fine by typing in the password. I just don't know what to look for for it to not require a password to sign on and just go straight through when I log onto my desktop in the morning.

 

Done all IE checks moved ADFS onto a member server set up TMG to pass through and it does.

 

I just am resigning to the dreadful line now of "I don't know".

 

The issue is with chrome.

 

You need to disable extendedprotection via powershell (Not recommended though) and also run a command that'll enable chrome as a valid NTLM user agent.

 

To disableExtended protection:

 Set-ADFSProperties –ExtendedProtectionTokenCheck None 

 

To enable Chome as a valid user agent (bare in mind you can't do this without doing the above, or you'll get errors rather than a login screen):

Set-ADFSProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")

 

I'm not entirely sure how much of a risk it is disabling extended protection though.

 

EDIT: Saying that, have you set forms authentication as your intranet auth? It'd need to be set to windows to SSO internal users, but the combination of the above powershell commands to neable chrome SSO will cause external users to get a windows credentials box rather than the forms auth screen.....i haven't worked out why that is yet, but presumably by enabling chrome to be detected as a valid browser, it's forcing it for external and internal users rather than jsut internal users. I'm sure someone on this wide web must have solved this though..

Edited February 3, 2016 by mrbios

[mrbios]

I've been playing around with this some more this morning, does anyone know if Azure Application proxy is essentially a replacement for ADFS Proxy?

[Manny-Tech]

Can you send us a screenshot of your ADFS auth setup? Like @mrbios says, it sounds like you have the internal network to use Forms Authentication? Externally you're only ever going to get Forms.

[DamienG1121]

I have followed what you said but now all I get is an authenticated box. Even added to trusted sites etc.

 

I have attached screenshots of my TMG config as well as ADFS. I hope this helps..

Edited February 3, 2016 by DamienG1121

[Manny-Tech]

The first two images look as though you don't have your internal DNS name for your ADFS servers in the Intranet zone.

[DamienG1121]

I have added that in their and still generates the same symptoms we use site to zone assignment list in Default Domain Policy.

[DamienG1121]

Eureka that worked somehow forgot to GP Update Brilliant Internally that is spot on Is it able to work externally?

[Manny-Tech]

If you're using site to zone assignment, I assume it's set to '1' and in the format https://FQDN.

 

Also, could you run the below command from Powershell and display the output?

 

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

[Manny-Tech]

Eureka that worked somehow forgot to GP Update Brilliant Internally that is spot on Is it able to work externally?

 

By design you can only do Forms Auth externally. Internally you're already authenticated to the domain, externally you are not which is why you have to provide credentials. Standard format.

 

Glad you have it working internally though.

[DamienG1121]

You guys are legends! Thank you so much I am hoping externally if Students and staff authenticate through TMG it should work correctly

[Manny-Tech]

I'm unsure on TMG, I've never used it but I'm fairly sure it acts in the same way as the ADFS WAP which will still mean Forms Authentication.

[DamienG1121]

Have tested it on a remote client not joined to our net work and it behaved how I wanted it to so I am a really happy bunny Thank you so much for your help

[mrbios]

Just FYI @DamianG1121 you might find this useful: Implementing ADFS V3.0 Forms Authentication in Mixed Environments | Kloud Blog as you may find that if you have added in the settings for chrome to SSO, that external users get a windows security box rather than the forms auth.

[Manny-Tech]

Just FYI @DamianG1121 you might find this useful: Implementing ADFS V3.0 Forms Authentication in Mixed Environments | Kloud Blog as you may find that if you have added in the settings for chrome to SSO, that external users get a windows security box rather than the forms auth.

 

I've attempted this before but I had other web applications expecting IE user agents which caused those applications to stop working. I also had the problem with your BYOD devices not supporting WIA therefore getting the Windows Security dialog box, it doesn't look good. In the end we chose Forms Authentication which suits all devices. It's a shame that Microsoft can't enable it to priortise; if SSO/WIA is unavailable then switch to Forms.

 

One of my friends works in another local school and he went down the route of having his BYOD devices on a seperate VLAN therefore making use of a different DHCP scope which then redirected them to a DNS server pointing to the ADFS WAPs which then prompted for Forms Auth. Not ideal, but it's a work around. I think I'd rather do that than mess with custom user agent strings.

[mrbios]

I've attempted this before but I had other web applications expecting IE user agents which caused those applications to stop working. I also had the problem with your BYOD devices not supporting WIA therefore getting the Windows Security dialog box, it doesn't look good. In the end we chose Forms Authentication which suits all devices. It's a shame that Microsoft can't enable it to priortise; if SSO/WIA is unavailable then switch to Forms.

 

One of my friends works in another local school and he went down the route of having his BYOD devices on a seperate VLAN therefore making use of a different DHCP scope which then redirected them to a DNS server pointing to the ADFS WAPs which then prompted for Forms Auth. Not ideal, but it's a work around. I think I'd rather do that than mess with custom user agent strings.

 

Whats the point in adfs at all though if you're not using SSO? Not sure if I'm missing something but without proper SSO isn't adfs just a waste of space?