The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.
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
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
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.
Thanks for all the expert comments, my design is getting there, just need to understand what data is being passed between all points then all will be complete.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
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.