I did a Duo run through a few weeks ago, and to be honest their documentation is usually pretty good. I was spinning this up as a PoC for a client so I thought I’d put my take on the procedure here.
ADFS Duo Pre-Requisites
I already have a Duo Authentication Proxy server setup and my users are enrolled, you will need to set this up first. See the following article;
Log into the the Duo Admin Portal > Applications > Protect an Application > Search for and select Microsoft ADFS > Protect This Application.
Copy the Integration Key, Secret Key and the API hostname to notepad.
Download the Duo AD FA MFA Adapter on your ‘first‘ ADFS server. Enter the information you copied to Notepad, (above). Tick ‘Bypass Duo Authentication when offline’, and because my users are logging on with their Office 365 UPNs, I’m also ticking ‘Use UPN username format’ (SEE USERNAME NORMALISATION NOTE BELOW.)
Note: I only have one ADFS server, if you have an ADFS Server farm you will need to install each one with the SAME shared session key, you can generate one of these yourself in PowerShell with the following commands;
I only have one, so I’ll simply ‘Generate new session key‘ > Finish the install wizard.
Note: If one has already been deployed, and you don’t know the key, go to the ADFS server on which it’s working, and look in the following registry key.
USERNAME NORMALISATION: Because I’m logging users on with UPNs (first-name.last-name.domain-name.com) Back in the Duo Portal under protected applications Microsoft ADFS > Set username normalisation to ‘None” > Scroll down and save the change.
Server 2019 Only: I’m deploying on Server 2019 so I also need to execute the following Powershell command, you will need to enter YOUR API Hostname (you copied above).
Tick ‘Duo Authentication for AD FS {version}’ > Apply > OK.
Relying Party Trust > Here I have my Office 365 trust, yours may be for something else! Edit Access Control Policy.
Click ‘Use Access Control Policy’ > The one I want is ‘Permit Everyone and Require MFA for Specific Group‘. This way I can select who gets 2FA challenged, and I can migrate users slowly into this group once I know they are enrolled, (also I use the same group to Sync the users to Duo to make things simple). Change the <parameter> and locate you domain security group.
Now when the users connect to ADFS, after they logon, they are challenged to provide 2FA authentication.
like so;
Related Articles, References, Credits, or External Links
While trying to connect Outlook (2016) to an Office 365 email account;
We can’t connect you
It looks like we can’t connect you to one of our services the moment. Please try again later, or contact your helpdesk if the issue persists.
0xCAA70010
{ADFS-URL}
Solution
This was happening because my ADFS server was using a ‘self-signed’ certificate (i.e. not a purchased one). This should NEVER be done in a production environment, but this is my test network, (so I refuse to spend money on certificates for testing etc!)
I cured the problem by simply importing/trusting the CA Certificate from my internal Certificate Services CA server, (that issued the ADFS servers certificate).
If you see this on a production server, with a publicly signed certificate, check that the ‘problem’ client does not need a Windows Update, to update its trusted CA Certificates, or that your certificate simply hasn’t expired, and you ‘forgot’ to renew it. If so;
Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.
I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?“
So I built it on the test bench, and did it myself.
Solution
To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.
First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.
Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.
WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.
Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.
OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;
I needed to change the certificate used by an ADFS server today. I’d used a temporary self signed wildcard cert to get me up and running now I needed to replace it with a new publicly signed one.
I found a number of ways of doing this INCORRECTLY, so hopefully I will save you making the same mistakes!
Solution
Firstly you need to import your certificate, here from a PFX file, (if you want a PFX file import by double clicking the certificate, then export the certificate, include the private key, and set a password on it). I’ve done this in lots of different articles just use the search bar above it you get stuck.
Make sure your certificate has a small key over the icon, or says ‘you have a private key that corresponds to this certificate‘. If yours does not, then import it on the server/PC you created the CSR (Certificate Signing Request) on, then export it to PFX, them import it using the command above on your ADFS server.
On your certificate > All Tasks > Manage Private Keys.
Add > Object Types > Select Service Accounts > Locate and select your ADFS service account. Grant full control.
Launch the AD FS management console > Service > Certificates > Set Service Communication Certificate.
Select the correct (new) certificate > OK.
On the properties of your new certificate locate the thumbprint (not the serial number!) Copy it to the clipboard, then execute the following command;
[box]
Set-AdfsSslCertificate -Thumbprint {Paste in the thumbprint - minus the spaces!}
[/box]
Note: BEWARE: If you press tab to complete the above command make sure you DON’T use Set-AdfsCertificate it’s Set-AdfsSslCertificate(it will accept the wrong command, without error, and then wont work at the end).
Changing ADFS Certificates: Things That Might Go Wrong
Error;
The ServiceCommunications primary certificate cannot be used because the KeySpec must have a value of AT_KEYEXCHANGE (1).
This value can be changed by reimporting the certificate from a pfx file. From an elevated command prompt, use the command “certutil -importpfx filename.pfx AT_KEYEXCHANGE”. For more information, see http://go.microsoft.com/fwlink/?LinkId=798501
You will also see an Event ID 550
Solution: Import the certificate using the ‘certutil -importpfx certificate-name.pfx AT_KEYEXCHANGE‘ syntax.
Error
Solution: Disable certificate rollover with ‘Set-ADFSProperties -AutoCertificateRollover $false‘ syntax. (Note: Dont forget to enable it again afterwards!)
Related Articles, References, Credits, or External Links
There are a lot of things that can be customised on the ADFS logon page, but most people just want to change the image, and the ‘Company Logo’. Note: By default the company logo is just the Federation Service Display Name but you can replace that with a logo of you own.
Replace ADFS Logon Page Main Image
As per Microsoft recommendations;
“We recommend the dimensions for the illustration to be 1420×1080 pixels @ 96 DPI with a file size of no greater than 200 KB.”
If you are going to use ‘self signed’ certificates then before you deploy ADFS, (Active Directory Federation Services,) you will want to Deploy Certificate Services. Here I’m going to use a self signed wildcard certificate. In production however, I would suggest you use a wildcard certificate signed by a public CA authority. (Click the Certificate link above).
To deploy ADFS simply follow the steps in this article;
There are a few ‘Web’ Services that Exchange provides, Outlook Web App, and Exchange Control Panel (Exchange Administration Centre), are ‘tied’ together and need to be presented in the same way, so we will cover them first.
IMPORTANT: You need to change OWA and ECP together, BE AWARE that means your Exchange Administration panel will be secured by ADFS, (and ADFS ONLY!) So you may need to change the way you do Exchange administration, (or leave one Exchange server without ADFS secured ECP for internal management).
So you create the ‘trusts’ for OWA and ECP in ADFS, then the WAP server will use those ‘trusts’. CARRY OUT THE FOLLOWING PROCEDURE TWICE, once for OWA, and once for ECP.
Open the ADFS management console > Relying Party Trusts > Add Relying Part Trust > (With ‘claims aware’ selected) > Next.
Enter data about the relying party manually > Next.
Give the trust a name e.g. ‘Outlook Web App’ > Next.
Next
Enter the ORL for OWA (with a trailing slash) e.g. https://mail.domainname.com/owa/
Permit everyone > Next.
Next
Close.
NOW REPEAT THE ABOVE PROCEDURE FOR ECP (https://mail.domain.com/ecp/)
ADFS Create “Claims Issuance Policies”
Why are you doing this? This allows you to connect to the WAP server and enter your username and password ONCE. To enable you to only supply usernames and passwords once, you need two things, 1) Claims Issuance Policies, that can query AD and collect your UPN and check your password, and 2) Exchange set to allow ADFS authentication, (instead of the usual basic, and ‘forms based’ authentication is uses for OWA and ECP out of the box).
AGAIN CARRY THIS PROCEDURE OUT TWICE, ONCE FOR OWA AND ONCE FOR ECP
From ADFS Management > Relying Party Trusts > Select your OWA Trust > Edit Claim Issuance Policy > Add Rule.
The WAP server either needs a Static public IP address that is registered in public DNS to the URLS you will be pointing to it, or HTTPS port forwarding form the firewalls outside IP address to the internal IP of the WAP server, (if you don’t have spare public IP addresses).
WAP Server requires TCP Port 443 (HTTPS) open TO it from the outside world.
WAP Server requires TCP Port 443 (HTTPS) open FROM it to BOTH the exchange server and the ADFS Server.
Installing Web Application Proxy
To be honest, this is pretty simple, the server itself does not have to be a domain member (which is good for a DMZ server!) For productions I’d disable the local administrator account and harden the server somewhat also. Make sure you have a copy of your wildcard certificate on this server also.
Server Manger > Manage > Add Roles and Features > Next > Next > Next > ‘Remote Access’ > Next > Next > Next > “Web Application Proxy” > Next > Install
Launch the post deployment configuration wizard > Next.
Enter the FQDN of your ADFS Server, and administrative credentials > Next > Select Your Wildcard Certificate > Next.
Configure > Close.
All being well the Remote Access management console should open and should show ‘All Green’ on the Operational Status.
Configure Web Application Proxy for OWA and ECP
Navigate to > Configuration > Web Application Proxy > Publish > Next.
Select Active Directory Federation Services > Next > Select ‘Web and MSOFBA > Next.
Select the ‘Relying Trust’ object that WAP can see for Outlook Web app > Next > Give the Published Rule a Name > Set the Public URL > Select the wildcard certificate > Set the Backend URL > Next.
Publish > Close.
REPEAT TO PUBLISH ECP
When you have finished it should look something like this;
x
Solution – Step 4 Configure Exchange for ADFS Authentication
Your Exchange needs a copy of the ADFS Signing certificate, this certificate is a ‘self signed’ certificate created on the ADFS server itself, you can find it here;
By Default this certificate only lasts a year, and will need to be manually imported onto Exchange, you can change the certificate duration by suing the following PowerShell and changing the Day value, (in this example to three years).
Exporting the ADFS Signing Certificate
With the certificate selected, navigation to the ‘Details‘ tab > Copy to File > Follow the instructions, (accept the defaults).
Importing the ADFS Signing Certificate Into Exchange
Physically copy the exported certificate to the Exchange server, and double click it > Install Certificate > Local Machine > Next > Place Into the Following Store > Trusted Root Certification Authorities > Next > Finish.
Now the certificate has been imported you need to get its thumbprint, open and Exchange Administration Console, and issue the following command. locate the ADFS certificate and copy its thumbprint to the clipboard.
Finally you need to set the OWA and ECP virtual directories to accept ADFS authentication, then restart the IIS services, to make the changes take effect.
[box]
Set-EcpVirtualDirectory -Identity "EX-SERVER\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Set-OwaVirtualDirectory -Identity "EX-SERVER\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
net stop was /y
net start w3svc
The actual configuration of ADFS depends largely on what you intend to do with it. Here I’m using it to broker connections from my Microsoft Web Application Proxy. This article is just to ‘join the dots’ and covers just the installation of the role itself.
Solution
Before you Start: Make sure you have a certificate ready to use for ADFS. I typically use a wildcard cert for this, it’s better if you have purchased one, or if you use certificate services, here’s how to create a wildcard certificate.
Note: You can add adfs.{your-domain} to your wildcard as a SAN, (Subject Alternative Name), Also add certauth.adfs.{your-domain}. Yes, even on a wildcard certificate!
For example: adfs.petenetlive.com and certauth.adfs.petenetlive.com.
You can either create a service account for ADFS to run under, or use a GROUP MANAGED SERVICE ACCOUNT.
What’s a Group Managed Service Account?
It’s an AD object that acts as a service account, and you don’t need to worry about entering a password for it.
Create a Group Managed Service Account
Before you can have a GSMA account you need a KDS Root Key in active Directory, to set that up, execute the following command;
[box]
If you have only one domain controller;
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
If you have more than one domain controllers;
Add-KdsRootKey –EffectiveImmediately
If you use the second option you must then WAIT 10 HOURS!
[/box]
Then go to a Domain Controller, and issue the following command;
In case you are interested, you will then see it appear in Active Directory.
Then ON the ADFS Server, run the following command;
[box]
setspn -a host/localhost {GSMA-Account-Name}
[/box]
Deploying Active Directory Federation Services
Server Manager > Manage > Add Roles and Features > Next > Next > Select the server > Next > Server Roles > Select Active Directory Federation Services > Accept all the defaults and install the role.
Launch the configuration wizard > Create the first federation server in a federation farm > Next.
I’m setting this up while logged on as the domain administrator, so I’ll use that account to connect to AD > Next.
WARNING: If you use a wildcard cert like me it will choose the name of *.{domain-name}. THIS IS BAD! Change the federation service name to something sensible, like adfs.domain.com. The ‘Federation Service Display Name‘ is what will be shown to the users as they authenticate. > Next.
Make sure the federation server DNS name can be resolved in DNS! Remember if your Web Application Proxy server is in your DMZ, or outside the firewall, it will also need to be able to resolve this name, (I put them in the ‘hosts‘ file on my DMZ servers for this reason).
Enter your Group Managed Service Account, (created above) > Next.
Create a database. (Note; If you are reinstalling it will discover any existing databases, and ask if you want to overwrite them) > Next.
Next
Configure.
Close. (Note: I’ve got some warnings but all is well, trust me!)
To test, open a web browser and go to https://{FQDN-Of FS-Service}/adfs/ls/idpinitiatedsignon and log in.
Note: If using Server 2016 or Server 2019, you have to enable this, or it will error! See the link below.
At this point, how you proceed depends on what you are using Active Directory Federation Services for. You would set up either a relying or a claims provider trust next.
As said above I’m using this for Web Application Proxy. When that article is complete, I’ll put the link at the bottom of this article.
Related Articles, References, Credits, or External Links
I was setting up ADFS in Server 2019 today, and once I have all the basics setup, I like to got to, https://{server-fqdn}/adfs/ls/IdpInitiatedSignon to test, but this happened;
The resource you are trying to access is not available. Contact your administrator for more information.
Error details
.Activity ID: 3c53140c-cff3-4b59-0900-0080010000d4
.Error details: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
.Node name: 8d53ee58-2a75-42c1-ac37-88c7bc00ce97
.Error time: Thu, 02 May 2019 12:35:56 GMT
.Cookie: enabled
.User agent string: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko
Solution
At first I though I’d broken something or forgotten to tick a tick box! But it seems this was turned off in Server 2016. You need to enable it on the ADFS server.
This is part of a larger piece of work Im putting together on publishing Remote Desktop Services with Microsoft Web Application Proxy.
This article is simply to guide you though the process of installing the Web Application Proxy role. In a later article I will run though configuring it to work with Active Directory Federation Services, and Remote Desktop Services, to present secure RemoteApps.
Solution
Before You Start: This is a secure web proxy so that means certificates, I find it a lot easier to use wildcard certs for this sort of thing, The best solution is to buy one from a vendor, or you can create your own wildcard certificate.
You will need a Server deployed to install this on, preferably a non-domain joined computer that resides in a DMZ (this is a secure deployment, if you want to put it on your LAN, then why not just point external clients directly at your Remote Desktop Services Web Access server and forget WAP?)
You will also need to have deployed ‘Active Directory Federation Services‘ in you LAN, and TCP port 443 (Https) needs to be open from the WAP server to the ADFS server.
Server Manager > Manage > Add Roles and Features > Next > Next > Select the server > Next > Server Roles > Select Remote Access > Next > Next >Next.
Select Web Application Proxy only > Accept all the defaults and install the role.
Launch the Post-Deployment configuration wizard.
Next.
Type in the name of your AD federated SERVICE > And supply credentials to be able to access that server > Next.
Note: As you can see below I can resolve the name of the federation service “fs.smoggyninja.com”, from my DMZ server, it’s easier to just put an entry in the WAP servers hosts file rather than open DNS to the LAN, (or you can register it in public DNS of course!) Below you can see I’ve been able to ping the federation server, normally you would not be able to, (from the DMZ), I simply opened ICMP/Ping for testing, as stated (above), you only need https open > Next.
Select the certificate you are going to use.
Configure.
Close.
The ‘Remote Access Management Console’ should open, if not launch it from administrative tools.
Select Operational Status and all the services should be ‘Green’.
That’s the role installed, now you just need to setup a publishing rule to publish the service you want to present. In my case thats Remote Desktop Web Access. Which I will cover in the next article.
Related Articles, References, Credits, or External Links
When installing the Active Directory Federation Services Role, you need to supply a certificate. I was running this up using a self signed wildcard certificate when this happened;
The certificate with the specified thumbprint {thumbprint} has a Cryptographic Next Generation (CNG) private key. The certificates with the CNG private key are not supported. Use a certificate based on a key pair generated by a legacy Cryptographic Service Provider.