Active Directory Quotes

“There are a number of restrictions that you have to be aware of when beginning your Active Directory design. We will introduce you to them in context as we go along, but here are some important ones: The forest, not the domain, is the security boundary for Active Directory. Anyone with high-level access rights on any writable domain controller in any domain can negatively impact or take control of any other DC or domain in the forest. You can never remove the forest root domain without destroying the whole forest in the process. The forest root domain is the cornerstone of your forest. Multiple domains cannot be hosted on a single DC. Imagine three child domains under a root domain located in the United States, each of which corresponds to one of three business units. Now imagine that you have a small office of 15 people in Eastern Europe or Latin America with a slow link to the US offices. These 15 users are made up of three sets of 5; each set of 5 users belongs to one of the three business units/domains. If you decide that the intersite link is too slow and you would like to install a local domain controller for these three domains at the remote site, you will need to install and support three separate domain controllers, one for each domain. While this could be virtualized, that is still three additional domain controllers to manage, update, and monitor. Too many group policy objects (GPOs) often leads to long logon times, as the group policies are applied to sites, domains, and organizational units. This obviously has a bearing on your organizational unit structure, as a 10-deep organizational unit tree with GPOs applying at each branch will incur more GPO processing than a 5-deep organizational unit tree with GPOs at each branch. However, if the 10-deep and 5-deep OU structures both contained only two levels with GPOs, they would both incur the same GPO processing.”
― Alistair G. Lowe-Norris, Active Directory: Designing, Deploying, and Running Active Directory

“Logon and Service Access Summary Figure 10-5 summarizes the process we’ve discussed so far. To review, the following steps happen when a user logs onto his workstation and attempts to access a service: An AS_REQ message is sent to begin the authentication process. This message proves the user’s identity by encrypting a message with a hash of the user’s password. Using a hash ensures that the actual password is never transmitted over the network. The domain controller validates the request and produces a ticket granting ticket. The TGT is sent back in an AS_REP message. The client caches the TGT in memory and uses it for subsequent requests for service tickets. The client sends a TGS_REQ message to the DC to request a service ticket for a specific service. Rather than providing credentials again, the client sends the TGT that it cached in memory after step 2. The DC validates the TGS_REQ and constructs a service ticket for the service. The service ticket, encrypted with a hash of the services’s secret, is sent back to the client in a TGS_REP message. The client caches this ticket in memory for subsequent use when authenticating directly to the service. The client presents the service ticket to the service in an AP_REQ message. The service uses this to authenticate the user. The service might also use the user’s access token (contained in the ticket) to perform authorization before allowing access. Optionally, the service can respond with an AP_REQ message for mutual authentication of the service. This is not especially common and entirely optional.”
― Alistair G. Lowe-Norris, Active Directory: Designing, Deploying, and Running Active Directory