(2014-10-28) You Have Multiple AD Forests And You Also Need ADFS – What Are The Possibilities?
Posted by Jorge on 2014-10-28
In the following blog posts I explained for which user accounts an ADFS STS was able to issue security tokens: (2013-09-24) AD User Accounts For Which The ADFS STS Can Generate Security Tokens.
–
Unless your AD forests have a forest-wide two-way trust with the AD forest hosting ADFS, you would need to deploy an additional ADFS instance for every other AD forest and setup federation. In this post let’s have a look at some subtle differences in setup, and also something new that recently became possible.
–
[Scenario 1]
- DMZ forest fully trusts the internal forest (forest wide authentication is enabled)
- Internal forest DOES NOT trust the DMZ forest
- ADFS server is member of the DMZ forest
- ADFS service account is part of the internal forest
–
With this setup it is possible for:
- Internal users to authenticate against the ADFS STS server
- DMZ users to authenticate against the ADFS STS server
- The ADFS service account to retrieve attribute info for users part of the internal forest
- The ADFS service account to retrieve attribute info for users part of the DMZ forest
–
The biggest downside here is that in this scenario you have a very powerful system, the ADFS STS server, in the DMZ that is allowed to issue security tokens for connected applications on the internal forest or in the cloud. If that ADFS STS server is compromised, everything connected to ADFS (e.g. applications, other federation systems) goes down the drain. In addition, if the service account from the internal forest, which is used on the ADFS STS server in the DMZ forest, is compromised, it can be used to access anything on the internal forest where it has explicit permissions, or through authenticated users. Rule of thumb: NEVER place an ADFS STS in a DMZ forest!
This scenario would also not work when you have multiple forests compared to the DMZ forest. You would still need to implement an ADFS instance in the forests similar to the DMZ forest.
REMARK: I would never suggest this setup as its security is really bad.
–
[Scenario 2]
- DMZ forest fully trusts the internal forest (forest wide authentication is enabled)
- Internal forest selectively trusts the DMZ forest (selective authentication is enabled)
- ADFS server is member of the internal forest
- ADFS service account is part of the DMZ forest
–
With this setup it is possible for:
- Internal users to authenticate against the ADFS STS server
- DMZ users to authenticate against the ADFS STS server
- The ADFS service account to retrieve attribute info for users part of the internal forest, but only AFTER it has been given the explicit permission "Allowed To Authenticate" on every DC computer account to be able to perform LDAP queries
- The ADFS service account to retrieve attribute info for users part of the DMZ forest
–
The biggest downside here is that in this scenario the ADFS service is able to perform any LDAP query for anything it likes. Besides that you have to configure it in such a way that it does not become a management nightmare when you add new DCs and/or remove existing DCs. The only way to achieve that easily would be to configure the permissions on the "Domain Controllers" OU in every AD domain in the internal forest. This scenario would also not work when you have multiple forests compared to the DMZ forest. You would still need to implement multiple AD service accounts which ADFS does not support.
REMARK: I would never suggest this setup as its security is really bad and I do not like the setup either.
–
[Scenario 3]
- DMZ forest fully trusts the internal forest (forest wide authentication is enabled)
- Internal forest selectively trusts the DMZ forest (selective authentication is enabled)
- ADFS server is member of the internal forest
- ADFS service account is part of the internal forest
–
With this setup it is possible for:
- Internal users to authenticate against the ADFS STS server
- DMZ users to authenticate against the ADFS STS server, but only AFTER those users have been given the explicit permission "Allowed To Authenticate" on the ADFS service account. This can be done through a custom security group, which needs to be managed, or by just using the "Authenticated Users" well-known security principal.
- The ADFS service account to retrieve attribute info for users part of the internal forest
- The ADFS service account to retrieve attribute info for users part of the DMZ forest
–
This way all important and secure resources are in the internal forest, and DMZ users can only authenticate against the ADFS STS server and nothing else.
REMARK: I would suggest this setup as its security and setup is better than the previous 2 scenarios.
–
[Scenario 4]
- DMZ forest DOES NOT trust the internal forest
- Internal forest DOES NOT trust the DMZ forest
- ADFS server is member of the internal forest
- ADFS service account is part of the internal forest
–
With this setup it is possible for:
- Internal users to authenticate against the ADFS STS server
- DMZ users to authenticate against the ADFS STS server, but only AFTER a so called local claims provider has been configured for every untrusted forest as explained in the following blog post: (2014-10-20) Configuring A New Identity Store As A Claims Provider In ADFS
- The ADFS service account to retrieve attribute info for users part of the internal forest
- The ADFS service account to retrieve attribute info for users part of the DMZ forest, through the credentials configured for the local claims provider.
–
The biggest downside here is that this scenario is only possible with ADFS v4.0! For more information see: (2014-10-20) Configuring A New Identity Store As A Claims Provider In ADFS. This scenario would also work when you have multiple forests compared to the DMZ forest. You would to configure a local claims provider for every untrusted AD forest.
REMARK: I would suggest this setup as its security and setup is better than the previous scenarios as it does not require Windows trusts at all!
–
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Konnan said
I’m trying to implement scenario 3. Problem is, I have a hard time when I put the Web Application Proxy, which has to be in the DMZ. Since I need to publish some non-claims aware applications, the Web Application Proxy need to get a Kerberos ticket on behalf of the user. To do that, it seems that it needs to access domain controllers in the internal forest directly instead of using the trust. How would you do it ? Thanks ! Konnan
Jorge said
For KCD to be possible, the following is required:
* Web App Proxy is domain joined
* either using old-style KCD or new-style KCD
PS: read more here: https://jorgequestforknowledge.wordpress.com/2015/11/08/kerberos-constrained-delegation-kcd-visualized-the-easy-way/
to understand your scenario, the OSes being used are important to know
regards,
jorge
Michael said
Jorge,
Your posts are much appreciated and have been a great resource for me as we architect our ADFS solution. I am struggling with wanting to improve upon MS’s best practice for allowing external access. Standard design is to utilize the Web Application Proxy (WAP) in a DMZ to allow for external client access to ADFS as well as pre-auth for publishing internal applications. However, we would like to prevent any publically available system from also having access to our internal network. Under MS’s recommended configuration the WAP is both open from the internet over 443, AND has access to the ADFS server on the internal network over 443. This could be a problem should the WAP be compromised. Do you have any recommendations for handing off or otherwise “proxy-ing” the proxy traffic from the WAP to the ADFS Farm, so we can lock down that communication?
The best solution that I have been able to come up with involves standing up a private DMZ with domain (in addition to the public DMZ) and moving the ADFS Farm infrastructure there. The proxy(s) will stay in the public DMZ and then only have ports open to the ADFS Farm in the private DMZ, which is not on the internal domain. I am not sure precisely how we would handle providing internal attribute info from the internal domain… establishing a forest trust, or configuring our internal AD as a claims provider (without trusts). Your thoughts on the matter would be most appreciated.
Thanks,
Michael
Jorge said
Hi,
Sorry for the very late reply. I have been busy and swamped with work.
The Web Application Proxy (WAP) is a system that is deployed on the perimeter of your network and is an intermediate system, trusted enough without any special powers, to redirect traffic between internet clients (apps and STSes using the fed service metadata URL, and users authenticating and performing HRD as needed) and the ADFS STSes themselves. Remember that the WAP does not have any special permissions within, except for being allowed to be a proxy. If you want to publish non-claims aware apps, while wanting to perform KCD, the WAP must be domain joined.
I would never have ADFS directly connected to the internet. I would have ADFS farm on the internal network and have another system as an intermediate brokering traffic between internet stuff (apps, client, STSs, etc) and the ADFS farm. You have to trust something.
Yet another option is to not use WAP, and only allow your users to VPN into your network. Those users are then on the internal network and could access ADFS. However, that will work perfectly for your users, but most likely not for third-party users
Using WAP or something similar is I think your best bet
regards,
Jorge
see:
https://jorgequestforknowledge.wordpress.com/2014/12/07/web-application-proxy-with-kerberos-constrained-delegation-kcd/
http://blog.kloud.com.au/2013/07/11/kerberos-constrained-delegation/
http://blog.ittoby.com/2014/04/web-application-proxy-server-in-2012-r2.html
Another option is maybe to use WAP in Azure:
http://blogs.technet.com/b/klince/archive/2015/02/27/sso-for-on-premise-integrated-windows-auth-apps-using-kcd-with-azure-web-application-proxy.aspx
regards,
jorge
Michael said
Jorge,
Your posts are much appreciated and have been a great resource for me as we architect our ADFS solution. I am struggling with wanting to improve upon MS’s best practice for allowing external access. Standard design is to utilize the Web Application Proxy (WAP) in a DMZ to allow for external client access to ADFS as well as pre-auth for publishing internal applications. However, we would like to prevent any publically available system from also having access to our internal network. Under MS’s recommended configuration the WAP is both open from the internet over 443, AND has access to the ADFS server on the internal network over 443. This could be a problem should the WAP be compromised. Do you have any recommendations for handing off or otherwise “proxy-ing” the proxy traffic from the WAP to the ADFS Farm, so we can lock down that communication?
The best solution that I have been able to come up with involves standing up a private DMZ with domain (in addition to the public DMZ) and moving the ADFS Farm infrastructure there. The proxy(s) will stay in the public DMZ and then only have ports open to the ADFS Farm in the private DMZ, which is not on the internal domain. I am not sure precisely how we would handle providing internal attribute info from the internal domain… establishing a forest trust, or configuring our internal AD as a claims provider (without trusts). Your thoughts on the matter would be most appreciated.
Neil said
Hi, great post.
We have a situation where we have 3 separate forests, with not trusts configured, all requiring access to a single Office 365 tenant. We also need SSO to a hosted application. In this case do we have 3 UPN’s (1 per forests), 3 instances of ADFS and AAD Connect. Will this allow Synched identities to O365 and also allow all forests to authenticate to both O365 and also the application?
Thanks
Jorge said
Hi,
With Azure AD at a high level you need to take the following into account:
[1] identity synchronization
[2] identity federation
With [1] you can only have 1 active AADSYNC instance working with a single Azure AD tenant. Therefore in your scenario, you need to determine which AD forest with host the AADSYNC instance. After that you can create a connector for every AD forest. All the config decisions during the AADSYNC wizard will apply to all forests. Therefore make sure the AD schema versions are the same OR you need to customize the sync rules of every connector if specific are not used within an AD forest
With [2] you need to create a domain in the Azure AD tenant and then configure the domain as a federated domain. In your case you have 3 domains, so you must configure all 3 domains and also configure all as a federation domain. When configuring a federation domain you must define an on-premises federation system per domain. In your case you have 2 options
[a] use a central forest with ADFS and federate between that ADFS instance and Azure AD for every domain in Azure AD. Then federate the other ADFS instances, with each its own AD forest), with the central ADFS
[b] federate each ADFS instance with Azure AD, where each domain is configured with the ADFS instance hosted in the same AD forest where the corresponding upn/mail suffix (domain) lives
I do not where the hosted application located and what options are available.
If the hosted application supports federation with multiple ADFS instances, then do that. (similar to option [b])
If the hosted application only supports federation with a single ADFS instance, then use the central ADFS or the ADFS in the same AD forest as the hosted application, as the ADFS instance to federate with the hosted application. Then federate the other 2 ADFS instances with the ADFS instance that is connected to the hosted application
With federation it is important to keep federation paths as short as possible.
regards,
Jorge
Alexander K. said
Hello Jorge, excellent posts there and really in depth! Thanks!
I am in the process of implementing scenario 3 as I can’t do scenario 4 yet.
You say:
With this setup it is possible for:
Internal users to authenticate against the ADFS STS server
DMZ users to authenticate against the ADFS STS server, but only AFTER those users have been given the explicit permission “Allowed To Authenticate” on the ADFS service account. This can be done through a custom security group, which needs to be managed, or by just using the “Authenticated Users” well-known security principal.
The ADFS service account to retrieve attribute info for users part of the internal forest
The ADFS service account to retrieve attribute info for users part of the DMZ forest:
My ADFS service account is a gMSA account on the internal domain.
If I enable a selective auth trust from internal to DMZ, I will need to give “allow to authenticate” permission to the users in the DMZ for the :
Machines that comprise the ADFS farm?
ADFS gMSA service account?
AD systems in the internal domain?
This is the point of confusion for me…
Thanks in advance!
Alexander K. said
I opened a thread on this one:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/d4151743-f797-44b1-bc58-16dc339461d3/adfs-on-dmz-selective-authentication-on-gmsa-account-not-possible?forum=ADFS