Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

9 Responses to “(2014-10-28) You Have Multiple AD Forests And You Also Need ADFS – What Are The Possibilities?”

  1. 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

  2. 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

  3. 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.

  4. 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

  5. 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!

  6. 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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: