ADFS, Server 2012 R2

ADFS and Office 365 with Windows 2012 R2

This is a very basic setup, where your internal domain and external (public) domains are the same. Because, really, me personally, no need for that. Microsoft came up with that idea in Windows 2000, and now it became gospel, but it is worthless. Just like having a parent root domain and sub domains per site. But that is a discussion for some other time.

Now, before I continue, yes, I did try for weeks using the new Azure Active Directory Connector Tool. It never worked. I kid you not, every single time I ran it, I got a different error at some point. In a later post I will share with you all of them, once I can make sense of my notes. But it was bad, very bad. It is a great idea, but just does not work, trust me. Well at least at this time of the post, it didn’t work, and even somebody at Microsoft said don’t use it, configure it manually. And it was much much much easier to do it manually than it has ever been.

What to expect

I am assume you are reading this because you want to setup ADFS, and not just password sync. That also means you have some basic skills, especially around PowerShell, because most of this will be done through it. I have tried to explain as much as possible what each command does, but you should be able to run get-help command –detailed.

What you will need

At least 2 servers.

domain joined (the ADFS server). This must NOT be the same name used for the service redirect that is in the certificate. Running Windows 2012 R2

one non domain joined with two NICs, one internal and one in your DMZ. The external DMZ network interface should not be routable to the inside network.

A certificate with the domain name that will be used for the ADFS services. This is the URL that will be used for internal and external resolution when you get the re-direct from Office 365. Usually this is adfs.domain.com, but it can be anything, and it can be part of a SAN cert. It can be anything, but it has to match internal and external. So, if you use domain.local internally, and domain.com externally, you will make it adfs.domain.com. Creating a certificate from the command line

A service account that is an Enterprise Admin (yes, that is a requirement from Microsoft)

A Domain in Azure Active Directory that is NOT configured for federation services, that is configured at the end.

An account in Azure Active Directory that you can do to get configurations. It is a one time account. And must be a global administrator

An enterprise and builtin\Administrator member, this is just for a one time usage during configuration

An Account on the Web Application Proxy server that is a local administrator, this is also a one time account used for setup process, it can be the administrator account. This should not be an account within your production domain as a safeguard, though it is only used once.

What this will not cover.

If the internal domain is different than your public domain, I.E. domain.local v.s. domain.com

If your user principal name is different than the public domain, again domain.local v.s. domain.com

If your SIP domain is different than your public domain.

So here is a table to help figure it out

Item Description Value
Domain Name The name of your internal active directory domain. domain.com
Public service name This is where you will be re-directed to from office 365 adfs.domain.com
Service Account This is the account that will do the work, the enterprise admin account domain\adfsservice
Domain Name in Azure This is the vanity name in azure, and should match your domain name domain.com
On-Premise Admin account This is the account used to setup on premise setting administrator@domain.com
Azure Admin Account This adfsuser@domain.onmicrosoft.com
ADFS Server Name and IP Address the FQDN of the server hosting the ADFS Services fedserv.domain.com/10.11.12.13
Web Proxy Server Name The FQDN of the WAP Server wapserv.domain.com
Web Proxy Server Internal IP The Internal ip of the WAP Server 10.11.12.14
Web proxy External facing The internal IP address of the WAP edge interface 10.11.13.14
Web Proxy External IP The external Ip address of the WAP interface 207.201.220.101 (I made that up)

 

Preparing your ADFS Server

In order to get all this working, you need a server with all the right tools. You can set these up on your local desktop and do it, but I just do it from the server I am configuring, and then once in production do it remote. I have just found that there are too many unknowns, remote PowerShell, firewalls, etc. This just simplifies everything.

Once installed you will need to connect to your tenant. Remember, the tenant is your account. For example domain.onmicrosoft.com. To simplify it greatly.

Open the Windows Azure Active Directory Module and run the below command. It will ask you for a username and password. This would be the user on Azure AD, forexample adfsuser@domain.onmicrosoft.com

Connect-msolService

Setting up the vanity Domain name

Nobody wants to login with as user@domain.onmicrosoft.com, it doesn’t look to professional. It works just fine, but not very pretty. And if you are reading this, you already know that.

Run the command Get-MsolDomain. This will make sure that your vanity name does not already exist, if it does, some cleanup work needs to be done, and I will discuss that later.

Now, hopefull when that returns you will see the domain name, and the status is verified and authentication is managed. In order to setup federation it needs to be managed, if it shows federated it means you tried it and something happened.

How to fix common domain issues

There are really only three issues that can happen with a domain, it’s not listed (easy), it’s not verified (easy), it shows as federated (ughh, a little more tricky to figure out)

Oh Dear, my domain does not Exist

That is the best solution to fix. You just need to add the domain and the DNS record. To add a domain follow these steps

New-msoldomain –Name domain.com However, this does not show the TXT record needed. To get that run the following command

Get-MsolDomainVerificationDns -DomainName domain.com -Mode DnsTxtRecord This will return the TXT record you need to add to DNS, it is the root level, so it would be @ TXT MS=ms…. If you cannot do txt you can use DnsMXRecord instead.

Now that you have your DNS setup, you just need to verify the record confirm-msoldomain –DomainName domain.com

Now if you run get-msoldomain –domainname domain.com you should now see verified

Dang, it’s not verified

Odds are you have just not gone through the verification steps yet. Just run the following commands to verify it

Get-MsolDomainVerificationDns -DomainName domain.com -Mode DnsTxtRecord This will return the TXT record you need to add to DNS, it is the root level, so it would be @ TXT MS=ms…. If you cannot do txt you can use DnsMXRecord instead.

Now that you have your DNS setup, you just need to verify the record confirm-msoldomain –DomainName domain.com

Now if you run get-msoldomain –domainname domain.com you should now see verified

Ughhh, it shows federated

At this point you are kind of in some deep crap. You can convert it back to standard or you can delete it and start over.

To set the domain back to managed you can run the following command: Convert-MsolDomainToStandard –domainname domain.com Now, be careful doing this, if people are signed in using that domain and you do not have password hash sync on, they will all require new passwords.

Now sometimes it is just easier to remove the domain and start over, but there are a few things to keep in mind. You cannot delete a domain name that has an associated account, login, or email address assigned to it. And when you re-add it, it will be a new DNS setting used, and have to start over. I will discuss later how to deal with this. But in short, you have a few options

  1. Change the login IDs for anybody on that domain
  2. Remove any SMTP addresses assigned to that domain
  3. Remove any users from your tennenat that is part of that domain and then re-add them, and choosing the option to fix any broken SMTP addresses.

So your domain is all set now. At last, we can get to setting things up.

Preparing the ADFS server

Installing ADFS services is pretty straight forward. Add-WindowsFeature ADFS-Federation -IncludeManagementTools

Now you need to install the certificate. If you have not already done so, see my other post on Creating a certificate from the command line

Once you have your certificate you will need to import it into the computer’s certificate store by running certlm.msc. Once you have it imported, you will need to export it with the private key for the WAP server later. Also make sure that the chain is valid and they root, intermediate keys are all in the correct location.

Preparing the WAP server

Just like ADFS, Installing WAP is pretty easy add-windowsfeature Web-Application-Proxy –IncludeManagementTools

You will also need to install the certificate that you exported previously into the computer’s certificate store.

Configuring ADFS

Okay, don’t get scared, this is really hard.

First, you will need the thumbprint of the certificate you imported. You can get the thumbprint by running the command get-childitem cert:\Localmachine\My

Now you need your service account credentials (you know the enterprise admin one). It must be in the form of domain\account. $cred=get-credential

Now configure the farm Install-AdfsFarm –Certificate Thumbprint “CertThumbPrint” -FederationServiceName “adfs.domain.com”–ServiceAccountCredentials $cred -FederationServiceDisplayName “Company name” –OverwriteConfiguration. Let me break this down for you a little bit.

  • Certificate thumbprint is the thumbprint of the certificate from the above PowerShell command
  • The federation service name much match an entry in the certificate. Remember, this is what the re-direct will go to for authentication.
  • The Federation Display Name is the name that appears when the redirect happens. This can be changed easily
  • OverwriteConfiguration. I just run this no matter what, just in case there is an existing configuration setup.

Now that should just finish without any issues. Now you have to convert your Office 365 domain to a federated domain. Convert-MsolDomainToFederated -DomainName “domain.com”

At this point, if you have a dns record of adfs.domain.com pointing to your ADFS Server, you will get re-directed and it should work. However, external people are now screwed because they will not be able to login. So read on.

Configuring WAP

We already assume that you have your firewall setup right to allow 443 to your edge interface of your WAP server

You will also need your enterprise admin trust account here too in the format domain\user: $cred=get-credential

Install-WebApplicationProxy -CertificateThumbprint “Certificate Thumbprint”-FederationServiceName “Adfs.domain.com” –FederationServiceTrustCredential $cred

This commands in this are pretty much familiar.

Now you need to configure the Pre-Authentication Part

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://adfs.domain.com/’ -ExternalCertificateThumbprint ‘thumbprint’ -ExternalUrl ‘https://adfs.domain.com/’ -name ‘descriptive name’ -ExternalPreAuthentication PassThrough

And you are done.

ADFS should now work

4 thoughts on “ADFS and Office 365 with Windows 2012 R2

  1. Propecia Contraindications Ace Inhibitors Diferencia Viagra Y Cialis Cialis Pharmacie Sans Ordonnance [url=http://cialibuy.com]cialis 20mg for sale[/url] Zithromax Interaction

Leave a Reply

Your email address will not be published. Required fields are marked *