IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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”.
Installing the ADFS Proxy Role
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.
Configuring the SSL and DNS
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