Windows – Global Catalog Server on multiple AD Sites

domaindomain-controllerwindows

we've multiple AD Sites (5) for each office which are connected via WAN.
Most offices have 2 DCs which are virtualized.
What would be the perfect setup for the DC? Currently every DC is a Global Catalog server. Is this necessary? Can only one DC per Site be the GC?

The Domain is running in 2012 Mode.

Best Answer

Unless you have an explicitly good reason not to, every DC should be a GC. Any other configuration is either a legacy recommendation or something weird like a DC on a cruise ship with a satellite uplink and SMTP site links.

If you've got a "normal" case, like it sounds, just make everything a GC and be done with it.

Related Solutions

Number of Domain Controllers needed

One DC should be able to handle the authentication load from that just fine. If you have all authentication traffic centralized at a single location, I'd start with just two and make both Global Catalogs (for redundancy) and only add more if you need it.

Domain – Single forest with multiple domains – authentication

Do I need to have domain controller for both domains on each remote site to authenticate users, or can a single global catalog server that is in one domain authenticate users in the other domain?

A DC in another domain, whether a GC or not, cannot authenticate users from another domain, whether trusted or not.

So no, you won't be able to have a single DC for domain "BOB" and be able to authenticate users from domain "MARY" via that GC DC. The DC in "BOB" will have to pass MARY\joe off to a DC in MARY domain for actual authentication. So if you don't want to traverse the WAN link back to a DC in MARY domain, you'll need 1 DC for BOB domain and 1 DC for MARY domain at each location.

But auth traffic for a user across a WAN is actually pretty miniscule overall. If your links aren't saturated or prone to going down you're likely just fine traversing the WAN.

More info: How Domain and Forest Trusts Work

Kerberos V5 Referral Processing

If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a domain controller in its account domain. The Kerberos Key Distribution Center (KDC) acts as a trusted intermediary between the client and server; it provides a session key that enables the two parties to authenticate each other. If the target domain is different from the current domain, the KDC follows a logical process to determine whether an authentication request can be referred:
Is the current domain trusted directly by the domain of the server that is being requested?

    If yes, send the client a referral to the requested domain.

    If no, go to the next step.

Does a transitive trust relationship exist between the current domain and the next domain on the trust path?

    If yes, send the client a referral to the next domain on the trust path.

    If no, send the client a logon-denied message.

Best Answer

Related Solutions

Number of Domain Controllers needed

Domain – Single forest with multiple domains – authentication

Related Topic