Imagine being an admin in an organization with 500 computers, the manager tells you to reset the password of every computer so you log into the first one, go to the settings, reset the password, log off, log into the second one...
Wake up from this nightmare (and start a new one), Active Directory exists!
I'm not a sysadmin but I've learned its basics and it was enough to make me realize it isn't a simple concept to grasp, too much terminology has been thrown onto my screen and I want to try to explain it in a way that wouldn't have got me staring at it for an hour.
What is Active Directory?
At its basics Active Directory is just a structure more than something physical, but to make it easier you can imagine it as your diary.
In there you may write your to-do list, meetings you have, things you had to do but didn't because you forgot...and in this sense AD (don't make me write "Active Directory" every single time) is the same.
Users are here, so is any other type of object (like computers or groups). Oh and you might also find some unused accounts because the admin in question forgot to remove them.
How are domain-joined computers managed?
Some people would say through "AD" and this is a common misconception: AD is just a structure.
They are managed through AD DS (Active Directory Domain Services), from there objects (an object could be anything: a user, a computer, etc.) can be checked and modified. A computer (server) with it becomes a "Domain Controller", there can be multiple of them in a domain.
So, is every server on an AD a "Domain Controller"?
If they have AD DS installed, yes. At its core yes but they can have other roles.
A simple analogy that comes into my mind is about school. A teacher may have other roles such as coordinator of a specific class or safety representative but they're still a teacher and they're the only ones with that title in the school.
In this sense DCs are the same. To be called a "DC" they only need the AD DS but they can also have roles (FSMO roles) and just one DC can have that FSMO role in the domain (or forest). I usually don't like making lists but they are only 5 so I guess I'll introduce them:
Schema Master: dictates what every object should look like (attributes) and other things to create a "blueprint". While every DC can read this blueprint, they cannot modify it. Now imagine if every DC would be able to modify it, maybe at the same time (I guess the domain would explode or have a similar fate)
Domain Naming Master: ensures that every domain has a unique name inside of a forest (I'll tell you what is that in a minute)
Relative ID Master: basically ensures that two objects are uniquely identified so they don't get confused. Takes an RID for each and combines it with the SID, so these will be unique
PDC Emulator: does quite a few things, one of them is synchronization. Seems kind of broad and got me confused at first but I guess we can imagine a scenario in which you just updated your password; your local DC doesn't yet know (updates usually happen at a fixed time) and asks the PDC Emulator about the existence of the credentials you just entered instead of kicking you out
Infrastructure Master: translates GUIDs and SIDs between domains so ACLs can display understandable names instead of "random" codes
AD Structure - From domain to Forest
Now I'm not sure who named digital stuff while going for a trip into the wild, but we apparently have forests and trees and other things (that actually seem more technical)
Instead of randomly dropping definitions I think that referring to an example schema would make the job easier, so let's pretend I have some sort of organization (I wish)
Domain: just a default container for objects that need to be managed together. Think of it as a way to organize objects
Tree: put a few domains together (or just one, but you might want to scale that in the future) that share the same namespace (e.g. Escenes) and you have a tree. Just a way to group domains.
Forest: top-level container, contains the whole organization. From a security point gain access to this and you could potentially gain access to everything.
I think another good analogy, would be a university: a domain may be the computer engineering department that has its own students, classes and labs. A tree may be the whole group of engineering departments, contained inside of the university (which is the forest). In case that uni acquires another uni we can talk about having multiple forests.
"Can and should I divide more?" - OUs and GPOs
Let's say that a domain (like blog.Escenes) has multiple departments, like IT, security and marketing.
You can't literally divide the domain but you can organize it with something called "Organizational Units (OUs)". I don't like overcomplicating stuff, so I'll say that it's just a container in which an admin puts all things somewhat related, that need to be managed together, to make their job easier, like applying GPOs.
A GPO is simply a collection of settings, usually applied to an OU but can also be applied to individual users or groups. With it you can, for example, establish that the marketing department can't use cmd.exe or change the password policy for 500 computers.
Trust
People may trust each other or not, and the same goes for domains. A trust relationship determines the access of resources: what I mean is that the trusted domain can access the resources of the one that trusts them.
There are five types of relationships (nothing to do with marriages and stuff though):
Parent-Child: like in a good family, parent and children trust each other; also it's transitive (grandchildren / grandparents are also trusted automatically).
Cross-link: trust relationship between child domains. While making this post I've learned that, it's just a shortcut to speed up authentication, not something automatic between two "siblings". So an example could've been a trust relationship between Domain1 and Domain3 (not Domain1 and Domain2, it isn't optimal, I even added the white line between them, it's the third time I modify that imagine).
External: 2 domains in 2 separate forests that trust each other (or not actually since it can be one-way).
Tree-root: trust relationship between two root trees, default in the same forest (and I'll make a clarification about this "root" thing in a minute).
Forest: trust relationship between 2 forest root domains.
Clarifications & Others
The post could end here but I have a few things to clarify, either because I feel like they were pretty superficial or because they could result confusing.
Objects
Saying that pretty much anything is an object is pretty superficial but also the truth.
Objects can be "individual" (leaf objects), and there we have users, contacts (external users) printers and computers or containers such as groups, OUs and domains.
I haven't lied after all.
Structure - a better representation
While writing about tree root nodes I started questioning myself - "is a tree a boundary or a domain itself?", and while the answer "both" might be obvious at this point (I think), it's hard to visualize and I did what I could above.
The tree root domain is a domain that also defines a boundary and, so, a namespace; it's both, I feel like I'm explaining quantum mechanics here.
Stuff I found interesting
NTDS.DIT: domain credentials are located on DCs at C:\Windows\NTDS. Nothing much but as I'm studying all this for pentesting, for me it's quite important.
FSMO Roles: when I read about this for the first time I thought "why don't they just assign all of these to every DC and let the last to write win?" but even if there's theoretically always a last one to make a change, if two or more devices make one a millisecond apart a DC won't take it well and make the entire system crash. Good thing that this whole system was thought up by somebody who's not me.
So, as a conclusion, I'll say that this post made things clearer for who wrote it and I hope the same for who read it. Active Directory is... quite a topic, I kind of like it but from what I understood, as a cybersecurity student, I don't have a choice either way.
Top comments (0)