Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
ADFS internal and external users
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
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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
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
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial