First published on TechNet on Mar 16, 2014
Hey y’all Mark and Tom back after a small hiatus. We (well mostly Mark because this was his responsibility) got distracted by other things like “helping customers”, “the Olympics” and “I’m tired I’ll do it tomorrow, what’s on Netflix streaming?”. Hopefully so far you’ve followed along and have an ADFS server built and have a sample Web SSO so you can start messing around or if your manager asks, “learning” about ADFS. By now the security group has probably gotten wind of this experiment and come to you with “Hey man, these ADFS servers can make claims about anyone, they are just like a DC, no way we’re putting these in the DMZ.” Technically this person is correct. You will want to protect your ADFS servers the same way you protect a DC. If you wouldn’t put a DC in your DMZ (hint you probably shouldn’t) then same goes for ADFS. However you can now sit back and tell your security group “Don’t worry, we got an ADFS Proxy”.
When you see how simple this is you will be ashamed it took me this long to write this post. You’ll have a machine that can be domain joined or doesn’t have to be as long as it can talk to the ADFS server on port 443. Since this is a test lab, I do have my ADFS Proxy joined to the domain. Start by click Add Roles and Features in Server Manager.
Click on Active Directory Federation Services
Accept all the requirements by click Add Features.
Select Federation Services Proxy and hit next.
You’ll then click finish let it install.
The next thing you are going to need to do is put an SSL cert on your ADFSProxy. This SSL name should ALSO match the SSL cert on your ADFS server. This shouldn’t be too much of a shock when you think about what role it’s providing. For external users or applications that are external, they are going to resolve the same ADFS service name, in my case sts.markmorow.com and it will connect to the proxy instead of the internal ADFS server. Which brings us to DNS. It’s up to the administrator to configure the internal DNS servers to point at the internal ADFS server and the external DNS servers to point proxy.
This is the error message you’ll get if you thought you were slick and skipped that last paragraph about SSL and DNS.
Right click the default website, edit bindings, Add port 443 and select a certificate. For this lab you can use an internal cert as well but in the real world you will want to use a public cert.
After the SSL and DNS has been configured we are now ready to run the ADFS Proxy Configuration wizard.
It’s a pretty short wizard as you can see, click Next.
You’ll add the federation server you want to connect to, remember your DNS configuration from before so you should be pointing to the INTERNAL adfs server, for me that will be sts.markmorow.com. You’ll then enter your domain credentials to establish the trust.
Alright you are done. The proxy is configured. A good way to “simulate” the proxy in a lab environment is to change your host file to resolve that name to the proxy instead of your internal adfs server. So after this post you should have a fully functional test lab that includes an ADFS server, ADFS Proxy and sample claims app. Don’t worry folks we are just getting started on this topic, if you have specific ADFS things you’d like to see covered or any comments let us know below.
Mark ‘didn’t even medal’ Morowczynski and Tom ‘coach’ Moser
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.