About Active Directory, et al.

I have some basic questions about Active Directory (AD)-like animals from this quasi-layman dabbling outside my comfort zone. I appreciate the help for the convenience of “one stop shopping” as opposed to mining Google just for some “plain vanilla” answers, as it were. Please answer all/some…whatever q’s below you can speak to:

Is there a generic term to cover all “cats and dogs” like Active Directory (AD) type databases? Also, let’s a say an organization (ala Wiley Coyote’s “Acme, Inc.”) has a network segmented into varioius domains. Could each domain have its own unique AD (or equivalent)? OTOH, is it also possible that all domains share one & the same AD…perhaps needing to cross domains to access it? And, if the very latter case is true, is there a unique port number for “AD traffic”, as it were? Or, is this a part of port 80 (for non-secure) trafficing?

Please be kind, and thanks for your patience in answering what may be trivial matters to the SD’s IT gurus out there. - Jinx

‘Directory service’ seems to be the best general term that’s not too general, as long as you ignore all the Google hits referring to 19th Century technology (the phone system). It also encompasses things like the X.500 standard and DNS. (DNS is the Domain Name System, which maps hostnames like google.com to IP addresses like 74.125.225.19, in addition to some other things.)

What follows is simplified a bunch. I’m hoping Jinx can use this to come back with more coherent questions.

AD is Microsoft’s implementation of LDAP-style directory services.

An AD domain is NOT the same thing as a DNS domain. The two terms are almost completely unrelated. (more later)

Each Windows AD installation IS a Windows domain. The existance of an AD server (called a “domain controller” or DC for short) is precisely the thing which defines a Windows domain. Each domain must have at least one DC. Usually there are more than one for redundancy or traffic load balancing. Within a single domain all the DCs are equal partners, sharing & cross-updating each other as needed. One DC is slightly “more equal” than the rest, but the details there are real advanced stuff.

A domain is THE boundary for security. The DC(s) IS/ARE the security authority for all computers & users in the domain it controls. All authentication requests within a domain are directed to, and answered by, a DC of that domain.

Multiple unrelated domains can participate in “trust relationships” where one domain trusts the credentials issued by another domain. These trusts can be one way or bi-directional. This involves the DC(s) in each domain passing authentication requests to the other domain’s DC(s) & accepting the results.

Related domains can be grouped together into a structure called a “forest”. Bidirectional trust is implicit beteen all DCs in the forest. Forests can be arranged in tree-like hierarchies or as just a big collection of child domains. There are special inter-Domain DCs called GCs (global catalog servers) and “forest controllers” to keep track of the structure.

AD Domains can also be partitioned into separate physical locations, called replication zones. The classic example is a HQ & a branch office. A local DC in the branch office will handle all authentication chores for the local branch & have a special synchronization path & schedule with the DCs at HQ. This keeps all the branch office authentication traffic local & therefore quick.

Within a Windows domain, the DCs typcially also provide DNS services for the machines in the domain. So there is often a 1-to-1 mapping between Windows authentication domains and corporate internal DNS domains. These are unrelated to public DNS for things like public facing websites & public employee portals.

The network traffic between client computers (whether servers or end-user workstations, commonly called “member computers”) and DCs takes place over a myriad of TCP/IP ports. Port 80 is not involved at all.

There is also a new technology called “federation” which is used when multiple unrelated entities want to use each other’s credentials. It’s essentially an AD trust relationship done at arm’s length & meant to be used over the internet in general and the WWW in particular. Windows AD can participate in federations, as can other non-Windows systems.

The classic business case goes like this: Company A sells to company B. A wants to let B’s purchasing agents log on to A’s website & place orders directly. But A doesn’t want to be in the business of issuing credentials to each of B’s purchasing agents & tracking who gets hired & fired over at B. Much better to delegate that overhead to B’s HR folks.

So the end process is something like this: A & B IT depts set up a pre-arranged trusting mechanism between dedicated trust web servers at each company. One of B’s employees is issued a credential by B’s HR.

The B employee goes to A’s website & puts in his creds. A can’t use the creds, but recognizes they come from B. The A website sends the user’s browser over to a dedicated B authetication website to log in. The B website recognizes the creds and issues cookies & such which say “I, the B authentication server, recognize this guy & his rights are X, Y, and Z according to the A-to-B federation agreement”.

The B server then sends the user’s browser back to A’s website which reads & accepts the cookies & then gives the user the appropriate results for somebody with access rights X, Y, and Z.

And everything is encrypted & signed so A can trust that the authentication assertion from B is not forged or tampered with.
I’m guessing from Jinx’s last questions that he’s kinda nosing around in this general direction.