It’s ultimately whether a global catalog is needed for users to log on to the domain is dependent on whether you are in a single or multiple domain forest.
Single Domain Environments and the Global Catalog
In a single domain environment, all domain controllers are capable of processing logon requests without contacting a global catalog server.
This has been verified by setting up a domain with 2 domain controllers. DC01 held all FSMO roles and was the only global catalog. I powered off DC01 and kept DC02 running. When a global catalog is not available in a single domain environment, users will still be able to log on to the domain. You will see a few errors while your only GC is down though.
For one, when you create a new account without any global catalog available you will see the following error about a global catalog not being available and Windows not being able to verify the account is unique.
Even though this error says the user cannot log on until the account is verified to be unique, you can ignore this error and log on with the newly created account just fine.
Also, when you view the groups a user is a member of you will see the following
Despite the error, the groups are displayed OK.
Similarly, you’ll see an error when viewing the members of a group warning you that because the global catalog is not available, some icons may not be displayed.
Also, worth noting is when your global catalog is not available, users cannot perform searches of the entire forest using the Search Active Directory feature of Network even if this is a single domain. This is because searching the entire forest sends the request to a global catalog on port 3268. Users will have to manually choose the domain to search for resources.
Global Catalogs ARE Needed for Logon in Multiple Domain Forests
When a user tries to log on to a domain that is at Windows 2000 Native domain functional level or higher, in a forest with more than one domain, a global catalog must be available somewhere in the forest for the user to be able to log on. If no global catalog is available, but another domain controller that is not a global catalog is online, that user still will not be able to log on even with cached credentials.
Why is this? Two reasons:
1) universal group membership evaluation and
2) user principal name resolution.
Universal Group Membership Evaluation
If the domain a user is trying to log on to is in Windows 2000 Native domain functional level or higher, then it is possible that the user is a member of a universal group.
When a user sends an logon request to a domain controller, that domain controller must determine all the groups that user is a member of. A domain controller has no problem doing this with groups that exist in the domain. It can simply look at the members attribute for all the groups in the domain.
But what if the user is a member of a universal group that exists in a different domain in the forest? A domain controller has no other knowledge about objects in other domains than its own unless of course that domain controller is a global catalog.
So, when a domain controller in a domain that exists in a forest with more than one domain receives a logon request, it will have to contact a global catalog to check for the existence of any universal groups and determine if the user logging on is a member of any of those groups.
I would like to make clear that if the user is logging on to a domain that is in Windows 2000 Mixed mode (where universal groups are not supported) then a global catalog would not have to be contacted even if that domain was in a forest with multiple domains.
User Principal Name Resolution
The other reason a global catalog is needed for a user to be able to log on is in the case of the user logging on while using a user principal name (UPN).
UPN’s take the form of email@example.com, where domain.com is the UPN suffix. It is possible to define a UPN suffix that can be used for any domain in your forest.
Consider the following: I have 2 domains called parent.com and child.parent.com. Let’s say I want all my users in both the parent and child domains to be able to logon simply using a standard firstname.lastname@example.org. When creating the user account, I can set the “User logon name” to use the parent.com suffix.
This is all fine and good, but what happens when users in these domains attempt to log on using the UPN? How will the domain controllers in each domain know whether the user is a member of parent.com or child.parent.com if all users are logging on with a UPN suffix of parent.com?
The answer is they won’t know what domain the user requesting to log on belongs to unless they can contact a global catalog server.
When a domain controller receives a logon request from a user using a UPN, it has to make a couple of decisions. First, the domain controller receiving the request will look at the suffix of the UPN. If the suffix is for a domain that the domain controller is authoritative for, then the domain controller will attempt to find the user in its copy of the Active Directory database.
For example, if a DC in my parent.com domain receives a request to logon from a user using the UPN email@example.com, that DC will recognize the parent.com suffix as being the domain it is authoritative for and will attempt to find the jdoe account in the domain parent.com. If it cannot find the jdoe account in the local domain, the domain controller will search for the object in the global catalog server.
I would like to point out that if the domain controller can find the user account, it will not have to contact a global catalog at that moment. However, a global catalog may still be required to continue to process the logon request if the domain is in Windows 2000 Native mode or higher as discussed earlier.
Similarly, if a domain controller receives a log on request for a UPN with a suffix that it is not authoritative for, it will not bother trying to find the account in the local domain and immediately consult the global catalog. For example, if a domain controller in the child.parent.com domain receives a logon request for firstname.lastname@example.org, it will immediately check the global catalog to find the user object.
When a domain controller determines that it must consult a global catalog, it will query the global catalog for the user account whose userPrincipalName attribute is the same as that in the authentication request. If the global catalog can find a matching user object, it returns that information to the requesting DC.
The DC can then examine the distinguished name of the object and extract the domain the object resides in. Once the domain controller knows what domain the object is in, it can send the client the domain name and then the client will have to query DNS for a DC in that domain where the logon process starts again.
So, hopefully that clarifies when a global catalog is needed for your users to be able to log on. In the case of single domain forests, users can log on just fine without a global catalog. That is not to say you may not see some problems. For example, if you are hosting global catalog dependent applications such as Exchange, you are going to need a global catalog available.
In forests with more than one domain, global catalogs will always be contacted when that domain is in Windows 2000 Native domain functional level or higher. A global catalog may also need to be contacted if the user logs on with a UPN and the domain controller receiving the request is not authoritative for the domain specified in the suffix of the UPN.