Archive | ADFS RSS for this section

ADFS in 2012R2 – Replacing the Service Communications certificate

I’m not alone in this. Replacing the Service Communications certificate in ADFS under Server 2012R2 is an inconsistent experience to say the least. After a less than ideal run through of updating the cert on some test ADFS servers, I felt that I at least knew the pitfalls and could update the production ADFS servers without too much hassle.  Wrong.

What seems like it should be the obvious method to specify a different Service Communications certificiate, using the ADFS Management MMC, does not work reliably.  For one, you need to manually add permissions for the new cert’s private key.  NT Service\drs and NT Service\adfssrv need read access. The MMC does warn you of that, but that’s something that seems like an obvious oversight.  The installation adds those permissions, so why would the change then be manual?

adfs-mmc

Onto the problem. I found in both the Test and Prod setups that attempting to change the certificate in the MMC does not work.  The new cert is shown in the MMC, and even if queried with Get-AdfsCertificate, but the clients still see the old certificate. Several restarts of the ADFS service, and reboots of the server did not help.

On the Test server, I was able to use Set-AdfsCertificate, followed by another restart to have it start using the new cert.

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumbprint>

Made the assumption that this would be the same case for Prod.  It wasn’t. After running through those first steps, the new cert wasn’t in use and no amount of setting it to the new, back to the old, back to new was making a difference.

Finally came upon a number of posts where people mentioned having to manually bind the new cert using netsh.

netsh http delete sslcert hostnameport=<your hostname>:443
 
netsh http add sslcert hostnameport=<your hostname>:443 certhash=<your cert thumprint> appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

same thing for localhost:443, and then <your hostname>:49443, but leave off the sslctlstorename for 49443.

Shoutouts to

http://tristanwatkins.com/changing-adfs-url-windows-server-2012-r2/
http://www.reinhard-online.nl/2014/10/strange-behavior-ad-fs-windows-server_88.html

Also to http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx Interesting powershell script to check for issues with the cert bindings

Advertisements

Error when adding second 2012R2 AD FS server when using gMSA

Ran into an set of errors when adding a second 2012R2 ADFS server where the service was being run under a Group Managed Service Account.

They were:

  • There were no SPNs set on the following service account ‘DOMAIN\gMSAname$’. Specify the service account used to configured the other FederationServers in the farm, or set the host SPN for the farm on the service account.
  • The user name of password is incorrect
  • Unable to determine the Service SPN.  There were no SPNs set on the following service account ‘DOMAIN\gMSAname$’. Specify the service account user to configure the other Federation Servers in the farm, or set host SPN for the farm on the service account.
  • Unable to retrieve configuration from the primary server. The username or password is incorrect
  • Prerequisites Check Completed
  • One or more prerequisites failed. Please fix these issues and click “Rerun prerequisites check”

I had previously set up ADFS 3.1 with standard service accounts with no issues in the same layout as the new servers so the only immediate difference to me was the gMSA.  The errors as listed appeared incorrect, as I could verify the SPN for the ADFS farm on the gMSA, and more importantly, the first server was working fine.  The error about the password being incorrect seemed erroneous as one of the features of using the gMSA was specifically that it handled passwords automatically.

Finally got a hint to a solution when I came across this post https://secureidentity.se/mystery-with-adfs-and-gmsa/

The issue appears to be related to the location/availability of the 2012R2 Domain Controller, in relation to the new ADFS servers.  In order to deploy gMSAs, at least 1 2012R2 Domain Controller in the domain is necessary.  I had added only 1, so as to satisfy this requirement.  Since I’m deploying ADFS across sites, the result was that I had one ADFS server in a site with a 2012R2 DC, and the other was in a site with only 2008R2 DCs.

It appears that when your initial ADFS server using gMSA is installed, it matters for future servers whether or not they can communicate with a DC of the same version (or higher?) as the original ADFS server does when installing.  When I had done the first ADFS install, it was in the site with the 2012R2 DC, but the second install was in a site where there was no 2012r2 DC.  After reading the above post, I tried some of the steps related to changing the logonserver, but realized in my situation that since the two servers were in different sites, it might not be possible to cause them to use the same DC, without altering the sites anyway.  Instead, I removed the ADFS install on the first server and did the new first install on the server in the 2008R2 site.  Now, the second install in the 2012R2 site runs smoothly and ADFS works great.

Configuring Cisco WebEx Meeting Server to work with ADFS 2.0+

Fantastically useful set of instructions! If only Cisco’s own docs were this good…

Digital Glue

Like so many other things I’ve written about, this is another example of where I was unable to find a solid set of instructions online about how to do something and had to assemble a working solution from a number of fragments spread across vendor-provided information, blog posts and cries for help posted in online forum threads.  Hopefully this can spare at least a few others from having to go through the same thing.

This procedure has been used to create a system that works on the “first try” so I know that it works.  It’s possible that this could be further refined with some additional testing.

This post is targeted to the on-premise version of the Cisco WebEx meeting server, not the hosted (SaaS) version.  I believe that most of what is here should be applicable to the hosted version but there are apparently some differences in the configuration…

View original post 1,227 more words

ADFS site configured for Integrated Auth continually prompts for password when DNS hostname is a CNAME

I have bad habits by some accounts.  I like CNAMEs. In my mind, they allow for easy changes to the DNS namespace without having to remember IPs, and in that way create simplicity. But they are invariably frowned upon for various reasons, they create additional DNS traffic, aren’t compatible with other record types on the same namespace (MX for instance).

I’ve run into a case where use of a CNAME breaks expected functionality. In an environment using Active Directory Federation Services, if the hostname of the federation service resolves to a CNAME, Windows Integrated Authentication will not work.  As an example:

CNAME federation.example.com  ->  adfs.example.com
A     adfs.example.com        ->  192.168.1.10

The federation service hostname as configured in ADFS is federation.example.com and the actual servername of the federation server is adfs.example.com. You attempt to access a URL of the federation service under the  federation.example.com namespace, and instead of being authenticated transparently you are prompted for a username and password as below.

adfs-logon-prompt

Repeated attempts to enter the password fail, eventually resulting in a 401 page. Replacing the DNS CNAME with an A that points to the same IP resolves this issue. Config as below:

A     federation.example.com  ->  192.168.1.10
A     adfs.example.com        ->  192.168.1.10

This is documented, though not as a bug, and I would not expect it to be fixed.

KB2461628 – Note resolution #4