A digital transformation requires faster time to market, shorter software development lifecycles, and the ability to adapt rapidly to changing customer demands. DevOps provides the solution.
Solved
ADFS internal and external users
Posted on 2016-09-29
Hi,
I've been trawling the 'net' for an answer and diagrams (including network ports) to show how to configure a scenario for both internal and external SSO/ADFS 3.0 design.
I understand I need an internal ADFS server farm (which can be used for internal SSO access.
I also understand I need a WAP server farm in a perimeter network/DMZ for external users.
A public SSL cert wil be used: e.g. adfs.company.com
We'll use DNS internally, internal domain is company.local so i'll add a zone from company.com with an a record of adfs.company.com
We'll use a host file for the WAP servers in the DMZ
The WAP farm servers will obviously communicate with both external clients and the SaaS provider.
How will the internal ADFS communication work for internal users? Does this traffic go out via the WAP server route or will it require it's own access to the SaaS provider?
Also, (sorry I know this is another question)
Is is viable to setup two separate ADFS farms in two locations and use something like route53 to route to site two if site one goes down?
I'm also assuming that port 443 is used for all server and client comms.
Appreciate any help on these questions.
Thanks,
Andy
I've been trawling the 'net' for an answer and diagrams (including network ports) to show how to configure a scenario for both internal and external SSO/ADFS 3.0 design.
I understand I need an internal ADFS server farm (which can be used for internal SSO access.
I also understand I need a WAP server farm in a perimeter network/DMZ for external users.
A public SSL cert wil be used: e.g. adfs.company.com
We'll use DNS internally, internal domain is company.local so i'll add a zone from company.com with an a record of adfs.company.com
We'll use a host file for the WAP servers in the DMZ
The WAP farm servers will obviously communicate with both external clients and the SaaS provider.
How will the internal ADFS communication work for internal users? Does this traffic go out via the WAP server route or will it require it's own access to the SaaS provider?
Also, (sorry I know this is another question)
Is is viable to setup two separate ADFS farms in two locations and use something like route53 to route to site two if site one goes down?
I'm also assuming that port 443 is used for all server and client comms.
Appreciate any help on these questions.
Thanks,
Andy
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
3
6 Comments
Active today
If you have other public DNS records for the domain company.com, on your internal DNS don't create a zone for company.com, but instead for adfs.company.com. Then inside it create an A record with a blank name pointing to the IP of your internal ADFS (or loadbalancer in front).
Basically what happens is when you try to authenticate to the service set up for federation, the client is directed to provide their credentials to adfs.company.com. For an external user, adfs.company.com would resolve to the public IP of the WAP (ADFS Proxy), but for internal users it would resolve to the internal ADFS. If you just had internal users, the WAP wouldn't be needed, and no, communication to the internal ADFS from the internet is not needed.
As to hosting separate farms, I haven't done it (exactly), but what I've seen recommended is to use the full MS SQL server to do replication across the different locations (single farm). From my own experience, I have done a migration to a different ADFS farm and had both live at the same time and it worked perfectly fine. However, long term I think you would need to configure your own certificates for token signing and decrypting which both ADFS farms would use. By default ADFS will do an auto-certificate rollover, generating new certificates every year, and each farm would have a different certificate - this is not workable since the service tie-in to ADFS is based on knowing the specific certificate used for the tokens.
Finally, yes, TCP 443 is all that's required to be open to the WAF from the internet, and from the WAF to the internal ADFS.
Basically what happens is when you try to authenticate to the service set up for federation, the client is directed to provide their credentials to adfs.company.com. For an external user, adfs.company.com would resolve to the public IP of the WAP (ADFS Proxy), but for internal users it would resolve to the internal ADFS. If you just had internal users, the WAP wouldn't be needed, and no, communication to the internal ADFS from the internet is not needed.
As to hosting separate farms, I haven't done it (exactly), but what I've seen recommended is to use the full MS SQL server to do replication across the different locations (single farm). From my own experience, I have done a migration to a different ADFS farm and had both live at the same time and it worked perfectly fine. However, long term I think you would need to configure your own certificates for token signing and decrypting which both ADFS farms would use. By default ADFS will do an auto-certificate rollover, generating new certificates every year, and each farm would have a different certificate - this is not workable since the service tie-in to ADFS is based on knowing the specific certificate used for the tokens.
Finally, yes, TCP 443 is all that's required to be open to the WAF from the internet, and from the WAF to the internal ADFS.
Thanks footech, appreciate the help and that all makes sense ans is as I expected from reading design blogs/technet articles.
Regarding:
For an external user, adfs.company.com would resolve to the public IP of the WAP (ADFS Proxy), but for internal users it would resolve to the internal ADFS. If you just had internal users, the WAP wouldn't be needed, and no, communication to the internal ADFS from the internet is not needed.
My question is:
With the internal users in this scenario, what happens to the traffic once they've hit the internal ADFS farm. Does it still then go out via the WAF?
I assume it's only the WAF that can access the RP in this case and we don't need to also allow comms between the internal ADFS farm and the RP as well as comms between the WAF and the RP?
Again, thanks for the support.
Andy
Regarding:
For an external user, adfs.company.com would resolve to the public IP of the WAP (ADFS Proxy), but for internal users it would resolve to the internal ADFS. If you just had internal users, the WAP wouldn't be needed, and no, communication to the internal ADFS from the internet is not needed.
My question is:
With the internal users in this scenario, what happens to the traffic once they've hit the internal ADFS farm. Does it still then go out via the WAF?
I assume it's only the WAF that can access the RP in this case and we don't need to also allow comms between the internal ADFS farm and the RP as well as comms between the WAF and the RP?
Again, thanks for the support.
Andy
Active today
I couldn't say for certain, but traffic should only pass through the WAP if it was initiated to the WAP.
There was only a brief period a few years ago when I was first setting up ADFS that I only had just the internal server (ADFS 2.0), but I seem to recall a number of things working just fine for my client on the internal network, and I certainly hadn't allowed communication initiated from the internet to reach the server.
There are different traffic flows that can happen depending on authentication method (at least with Office 365/Exchange Online, I'm not aware how things might differ for other services). You might read
http://www.techsupportpk.com/2016/02/exchange-online-identity-models-and-authentication-demystified.html
and scroll down to part 3. I'm really only concerned about inbound traffic. The whole point of the WAP is to proxy the ADFS traffic so the RP would never communicate directly to the internal ADFS.
There was only a brief period a few years ago when I was first setting up ADFS that I only had just the internal server (ADFS 2.0), but I seem to recall a number of things working just fine for my client on the internal network, and I certainly hadn't allowed communication initiated from the internet to reach the server.
There are different traffic flows that can happen depending on authentication method (at least with Office 365/Exchange Online, I'm not aware how things might differ for other services). You might read
http://www.techsupportpk.com/2016/02/exchange-online-identity-models-and-authentication-demystified.html
and scroll down to part 3. I'm really only concerned about inbound traffic. The whole point of the WAP is to proxy the ADFS traffic so the RP would never communicate directly to the internal ADFS.
Thanks footech,
Just one final question:
We have our main domain, and 2 sub domains, do we have to setup anything extra for users, either in ADFS or DNS?
e.g.
uk.comany.com (root domain containing accounts)
us.company.com (sub domain containing accounts)
china.company.com (sub domain containing accounts)
My design steps (as an overview) are as follows:
Create the service account (or gMSA)
Build the 4 2012 R2 servers required for ADFS 3.0 (2 x Internal, 2 x DMZ)
Decide on the public ADFS (federation) service name:
Adfs.company.com/sts.compa
Buy certificate
Import the cert on each server
Consideration: Multiple domains
Setup DNS entries as required (internal, DMZ, external)
Allow port 443 between all devices and externally from WAP farm VIP
Consideration: NLB used in DMZ? If so, setup NLB on both servers with VIP
Add the ADFS role for the first internal ADFS server creating a farm
Configure ADFS with SSL Cert, Federation service name, Federation service display name
Specify Service account, WID. Complete configuration
Test: https://adfs.company.com/federationmetadata/2007-06/federationmetadata.xml
Add the ADFS role for the second internal ADFS server joining the farm and configure
Add to Load Balancer creating the Load balanced VIP
Add the WAP role for the first internal ADFS server creating a farm
Add the WAP role for the second internal ADFS server joining the farm
Test SSO internally
Test SSO externally?
Send metadata to SaaS provider, configure and test.
Hopefully I've got everything there.
Thanks again,
Andy
Just one final question:
We have our main domain, and 2 sub domains, do we have to setup anything extra for users, either in ADFS or DNS?
e.g.
uk.comany.com (root domain containing accounts)
us.company.com (sub domain containing accounts)
china.company.com (sub domain containing accounts)
My design steps (as an overview) are as follows:
Create the service account (or gMSA)
Build the 4 2012 R2 servers required for ADFS 3.0 (2 x Internal, 2 x DMZ)
Decide on the public ADFS (federation) service name:
Adfs.company.com/sts.compa
Buy certificate
Import the cert on each server
Consideration: Multiple domains
Setup DNS entries as required (internal, DMZ, external)
Allow port 443 between all devices and externally from WAP farm VIP
Consideration: NLB used in DMZ? If so, setup NLB on both servers with VIP
Add the ADFS role for the first internal ADFS server creating a farm
Configure ADFS with SSL Cert, Federation service name, Federation service display name
Specify Service account, WID. Complete configuration
Test: https://adfs.company.com/federationmetadata/2007-06/federationmetadata.xml
Add the ADFS role for the second internal ADFS server joining the farm and configure
Add to Load Balancer creating the Load balanced VIP
Add the WAP role for the first internal ADFS server creating a farm
Add the WAP role for the second internal ADFS server joining the farm
Test SSO internally
Test SSO externally?
Send metadata to SaaS provider, configure and test.
Hopefully I've got everything there.
Thanks again,
Andy
Active today
Sorry, but I don't have the answer to that. I've only worked with single domains.
Supposedly a single ADFS farm can support an entire forest. Or you could set up a separate ADFS for each domain.
https://jorgequestforknowledge.wordpress.com/2013/09/24/ad-user-accounts-for-which-the-adfs-sts-can-generate-security-tokens/
I don't notice anything obvious missing from your list.
Supposedly a single ADFS farm can support an entire forest. Or you could set up a separate ADFS for each domain.
https://jorgequestforknowledge.wordpress.com/2013/09/24/ad-user-accounts-for-which-the-adfs-sts-can-generate-security-tokens/
I don't notice anything obvious missing from your list.
Featured Post
The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Compliance and data security require steps be taken to prevent unauthorized users from copying data. Here's one method to prevent data theft via USB drives (and writable optical media).
Wouldn't it be nice if objects in Active Directory automatically moved into the correct Organizational Units?
This is what AutoAD aims to do and as a plus, it automatically creates Sites, Subnets, and Organizational Units.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Internet Business Fax to Email Made Easy -
With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number.
You'll receive secure faxes in your email, fr…
Suggested Courses
Course of the Month9 days, 23 hours left to enroll
722 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.