O365 Multi forest ADFS <> Domain Controller Communication

%3CLINGO-SUB%20id%3D%22lingo-sub-172139%22%20slang%3D%22en-US%22%3EO365%20Multi%20forest%20ADFS%20%26lt%3B%26gt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-172139%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20currently%20have%20the%20following%20setup%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3E2%20AD%20forests%20(with%20a%202way%20trust)%3CUL%3E%0A%3CLI%3EContoso.com%3C%2FLI%3E%0A%3CLI%3EFabrikam.com%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3CLI%3EADFS%20%26amp%3B%20AADC%20deployed%20in%20the%20Contoso.com%20forest%20connected%20to%20the%20O365%20tenant%3C%2FLI%3E%0A%3CLI%3EAADC%20is%20syncing%20users%20from%20both%20forests%20to%20AAD%3CUL%3E%0A%3CLI%3EADFS%20successfully%20authenticates%20users%20in%20the%20Contoso.com%20forest%20but%20doesn't%20authenticate%20users%20in%20the%20Fabrikam.com%20forest%20(the%20sign%20in%20page%20just%20loads%201-2%20minutes%20and%20just%20refreshes%20then%20without%20an%20error%20or%20anything)%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENow%20my%20question%3A%3C%2FP%3E%0A%3CP%3EWhich%20ports%20do%20I%20need%20to%20open%20between%20the%20ADFS%20servers%20in%20the%20Contoso.com%20forest%20and%20the%20Domain%20Controllers%20in%20the%20Fabrikam.com%20forest%20in%20order%20to%20successfully%20authenticate%20those%20Fabrikam%20users%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EUnfortunately%2C%20the%20docs%20under%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fidentity%2Fad-fs%2Foverview%2Fad-fs-requirements%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fidentity%2Fad-fs%2Foverview%2Fad-fs-requirements%3C%2FA%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Edo%20not%20specify%20the%20ports.%20We%20currently%20only%20opened%20443%20between%20the%20ADFS%20and%20the%20DCs%20in%20the%20Fabrikam%20forest%20but%20what%20do%20we%20need%20to%20open%20to%20make%20it%20work%20exactly%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-172139%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-233597%22%20slang%3D%22en-US%22%3ERe%3A%20O365%20Multi%20forest%20ADFS%20%26lt%3B%26gt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-233597%22%20slang%3D%22en-US%22%3E%3CP%3EYes%20I%20got%20this%20working!%20I%20used%20all%20of%20the%20ports%20listed%20in%20the%20AD%20section%20here%20(%3CA%20href%3D%22https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F832017%2Fservice-overview-and-network-port-requirements-for-windows%234%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F832017%2Fservice-overview-and-network-port-requirements-for-windows%234%3C%2FA%3E)%20and%20also%20added%20Kerberos%20tcp%2F88.%20I%20also%20implemented%20the%20other%20communications%20I%20suggested%20and%20SSO%20to%20office.com%20from%20the%20trusted%20forest%20works%20beautifully.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-231286%22%20slang%3D%22en-US%22%3ERe%3A%20O365%20Multi%20forest%20ADFS%20%26lt%3B%26gt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-231286%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20thinking%20client%20to%20ADFS%20server%20communications%20from%20the%20fabrikam.com%20clients%20in%20the%20other%20forest%20to%20the%20ADFS%20server(s)%20in%20contoso.com%20are%20also%20required%20by%3A%3C%2FP%3E%3CP%3E-%20Opening%20port%20443%20on%20the%20firewall%20so%20the%20fabrikam.com%20clients%20can%20talk%20to%20adfs.contoso.com%20over%20HTTPS.%3C%2FP%3E%3CP%3E-%20Use%20split%20DNS%20and%20a%20conditional%20forwarder%20to%20adfs.contoso.com%20in%20the%20fabrikam.com%20DNS%20servers%20so%20they%20can%20resolve%20the%20address%20across%20the%20VPN%2Fdirect%20tunnel%2C%20if%20it%20exists.%26nbsp%3B%3C%2FP%3E%3CP%3E-%20Adding%20adfs.contoso.com%20to%20the%20Intranet%20zone%20for%20fabrikam.com%20clients%20via%20GPO.%3C%2FP%3E%3CP%3E-%20fabrikam.com%20clients%20should%20bypass%20proxies%20when%20accessing%20adfs.contoso.com.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWill%20test%20this%20in%20my%20lab%20and%20get%20back%20with%20the%20results.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-229286%22%20slang%3D%22en-US%22%3ERe%3A%20O365%20Multi%20forest%20ADFS%20%26lt%3B%26gt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-229286%22%20slang%3D%22en-US%22%3E%3CP%3E443%20is%20not%20enough%2C%20unless%20Fabricam%20has%20their%20own%20ADFS.%3C%2FP%3E%3CP%3EI%20think%20that%20you%20need%20at%20least%20389%20and%20636%20(SSL)%20for%20LDAP%2C%20but%20here%20is%20the%20full%20list%20of%20possible%20ports%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F832017%2Fservice-overview-and-network-port-requirements-for-windows%234%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F832017%2Fservice-overview-and-network-port-requirements-for-windows%234%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-229158%22%20slang%3D%22en-US%22%3ERE%3A%20O365%20Multi%20forest%20ADFS%20%26amp%3Blt%3B%26amp%3Bgt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-229158%22%20slang%3D%22en-US%22%3EYuz60377%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-229149%22%20slang%3D%22en-US%22%3ERe%3A%20O365%20Multi%20forest%20ADFS%20%26lt%3B%26gt%3B%20Domain%20Controller%20Communication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-229149%22%20slang%3D%22en-US%22%3E%3CP%3ESame%20scenario%20for%20me%20right%20now%20and%20I%20am%20wondering%20if%20you%20ever%20resolved%20this%20one%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Contributor

We currently have the following setup:

  • 2 AD forests (with a 2way trust)
    • Contoso.com
    • Fabrikam.com
  • ADFS & AADC deployed in the Contoso.com forest connected to the O365 tenant
  • AADC is syncing users from both forests to AAD
    • ADFS successfully authenticates users in the Contoso.com forest but doesn't authenticate users in the Fabrikam.com forest (the sign in page just loads 1-2 minutes and just refreshes then without an error or anything)

 

Now my question:

Which ports do I need to open between the ADFS servers in the Contoso.com forest and the Domain Controllers in the Fabrikam.com forest in order to successfully authenticate those Fabrikam users?

 

Unfortunately, the docs under https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements do not specify the ports. We currently only opened 443 between the ADFS and the DCs in the Fabrikam forest but what do we need to open to make it work exactly?

5 Replies
Highlighted

Same scenario for me right now and I am wondering if you ever resolved this one?

Highlighted
Highlighted

443 is not enough, unless Fabricam has their own ADFS.

I think that you need at least 389 and 636 (SSL) for LDAP, but here is the full list of possible ports: https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-w...

 

Highlighted

I'm thinking client to ADFS server communications from the fabrikam.com clients in the other forest to the ADFS server(s) in contoso.com are also required by:

- Opening port 443 on the firewall so the fabrikam.com clients can talk to adfs.contoso.com over HTTPS.

- Use split DNS and a conditional forwarder to adfs.contoso.com in the fabrikam.com DNS servers so they can resolve the address across the VPN/direct tunnel, if it exists. 

- Adding adfs.contoso.com to the Intranet zone for fabrikam.com clients via GPO.

- fabrikam.com clients should bypass proxies when accessing adfs.contoso.com.

 

Will test this in my lab and get back with the results.

Highlighted

Yes I got this working! I used all of the ports listed in the AD section here (https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-w...) and also added Kerberos tcp/88. I also implemented the other communications I suggested and SSO to office.com from the trusted forest works beautifully.