# AD objects & OUs Everything that is stored in Active Directory is an Object. It could be a user, a group, a computer, an application, a printer or even a shared folder. Each object represent real-world entity and has attributes (their own properties) that describe themselves. ### Object Types *** * User Object : Represent a person who can log in. * Computer Object : Represents a computer that is connected to a domain. * Group Object : Represent a group of users, computers, or other objects. * Contact Object : Represent an external person (not a login account) * Printer Object : Represent a shared printer on the network. * Shared Folder Object : Represent a shared folder that can be access by authorized users. ### Attributes *** Every object has attributes that represent their identity for example: * User attributes : sAMAaccountName, Display name, mail, phone number, department, manager, etc. * Computer attributes : dNSHostName, Operating System, last logon, etc. * Group attributes : group type, members, managed by. ### Distinguished Name (DN) & RDN *** It defines the full unique path of an object in active directory. As we know every entry inside active directory is an object and the path of those objects are called Distinguished Name (DN). A DN is a series of Relative Distinguished Names (RDN) connected by commas. Technically, DN is made up of key(attribute)=value pairs of RDNs. 
#For example:
CN=Mark,OU=Staff,DC=example,DC=local
CN=Jeff Smith,OU=Sales,DC=Fabrikam,DC=COM
#This is the syntax of DN or you can say DN's analogy.
Here each attribute=pair is a RDN. * CN = CommonName -> represent the object * OU = OrganizationalUnitName -> represent a container, think of it as a department in the office. * DC = domainComponent -> represent the domain name (fox.com) * O = organizationName -> represent company name. * STREET = streetAddress -> represent the physical address of the company. * L = localityName -> represent the city of the branch or headquater. * ST = stateOrProvinceName -> represent the state or region of the branch. * C = countryName -> represent the country of the branch or company. * UID = userid -> represent the unique identify of the user. ### UserPrincipalName (UPN) *** UPN attribute is the user's logon name in the format of email address. Users typically use their UPN to log on to a domain. UPN consist of prefix (the user account name) and suffix (DNS domain name) which are separated by '@' symbol. For example: , basically in the format of username\@domain. UPN is unique among all the security principal objects within a forest. Yes, the UPN can be reused with different suffix. When a user uses a UPN to log on to a domain, the UPN is validated by searching the local domain and then the global cataglog(GC). If not found in the GC, the logon attempts fails, means the UPN do not exists. {% hint style="info" %} If attacker has WriteProperty rights over a user object they can change the user's UPN to impersonate someone else. {% endhint %} ### sAMAccountName *** The sAMAccountName or a Sam(Security Account Manager) Account attribute was used in legacy Windows like Windows NT or you can say pre-Windows 2000. It was used to support clients and servers of Pre2k Windows. Basically the windows that were released before 2000 were used by sAMAccounts like Windows 95 or 98. It is a logon name and was required to be unique among all the security prinicipal objects within your domain. The format of sAMAccounts was Domain\Username, so if your domain is Fox and your username is wolf then it would be FOX\wolf. It was used for authentication purposes when logging into Windows NT. {% hint style="info" %} UPN is the modern login format while sAMAccount is the old format and both works for login. * UPN is used by kerberos, microsoft 365, ADFS and more modern apps and servies. * sAMAccountName is used by NTLM auth, smb and legacy protocols. Many system still depends on NTLM auth, Scripts / services and smb shares. That's exactly why sAMAccountName still exists. {% endhint %} ### Globally Unique Identifier (GUID) *** GUID is a 128-bit value which is a identifier of every object in AD. When an object is created in Active Directory, Domain controller (DC) assigns a GUID to that object. Yes, every object within the Acitve directory has the GUID of itself. It is stored in objectGUID attribute and it never changes until that object is deleted from the AD. Even if the user object rename it's DN or moved from one domain to another, the GUID remains unchanged. The objectGUID attribute value is published in Global Catalog (GC) servers, so if an application in a domain needs to search for an object, the best method will be query to GC that will use objectGUID to fetch the accurate result. ``` #For example: 53081e7d-304c-4235-9c87-8d348a045934 ``` {% hint style="info" %} GUID is designed to be unique and It is quite unlikely to have duplicated GUID as the method to generate it is complex. However, it is technically not guaranteed to be globally unique. {% endhint %} ### Security Identifier (SID) *** To simply explain SID in one line would be , it proves who the entity is and what authority they carry within security boundaries. Technically each & every user's permission is tied to SID. It is a unique value for an object within its domain. The SID is used by the system to identify a user and what group the user belongs to during interactions with windows security. Each user has a unique SID issued by Windows Domain and is stored in ObjectSid attribute. The SID is set by the system when the user is created. Each time user logs on, the system retrives the user's SID from the database and places it in the user's access token. This token is then compared against ACLs (Access Control Lists) on files, folders or printers to see if the user have permission to access them. This SID is also used to retrieve the SID for the group that user belongs to. The SID has big role when its come to ACL abuse because permissions are SID based. If an attacker adds thier own SID or compromised computer's SID in ACL or modify group permission, they can gain access without changing their name. I abused ACL in the last AD box on Hack The Box by adding myself (a domain user) in RODC group that could fetch the Admin password's hash which i later gain the access to administrator. ``` # Example SID: S-1-5-21-3623811015-3361044348-30300820-500 # The structure is followed by: S-1-5-21-- ``` **SID anatomy**: * S - SID identifier. * 1 - Represents Revision level (always 1 as it is required to be initialized as 0x01) * 5 - Represents the Authority (NT authority) (5 is common) * 21 - Represents Domain or local system * DomainID - It is unique per domain * RID - Represents Relative ID for the user or group (unique per object) (500 RID means Administrator's ID) Few important SIDs to recognize what they are: | SID | Meaning | | --------------------- | ------------------- | | S-1-1-0 | Everyone | | S-1-5-18 | Local System | | S-1-5-\-500 | Administrator | | S-1-5-\-512 | Domain Admins | | S-1-5-\-519 | Enterprise Admins | | S-1-5-\-544 | Local Administrator | RID 512 and 519 especially are the Golden Ticket Targets. When a SID has been used as the unique identifier for a user or a group, it cannot be used again to identify another user or group. The SID values assigned to the user will change if the user object is migrated to another domain. SID value assigned by one domain will not be accepted by another domain. When this user migrates to another domain, that domain will grant a new SID to the user. The old SID value will be saved in the sIDHistory attributes. #### sIDHistory The sIDHistory attribute contins the previous SIDs for the user object and is a multi-valued attributes, means it can have multiple values for a single user object. When a user object is moved to another domain, a new SID is created and assigned to the objectSid attributes and the previous SID is added to the sIDHistory attributes. But why save previous SIDs? As mentioned earlier the permissions for a user or group is assigned on their SIDs. SID contains the authority of a user or a group for what they can access. So if an user object moves to another domain without sIDHistory, it will lose its access to resources until the ACL is modified. But if the system consider sIDHistory when granting an access token and if the old SID value is moved over to another domain, the user will still have access to the resources they were assigned with previous SID. sIDHistory is used to preserve permission, so this is why restoring deleted users from the backup is important. SID and sIDHIstory are crucial when its come to abuse, they are used in privilege escalation. * sIDHistory allows an account to carry old SIDs that has access to domain admins so by injecting old SID, a user can escalate to their privileges. * Golden Ticket Attack that forges TGT (Ticket Granting Ticket) using kerberos and inserts user or group's SID which can lead to full domain access without real account. * Silver Ticket Attack that forges TGS (Ticket Granting Service) that includes the SIDs to bypass local authorization on the specific server. * RID Hijacking attack in which RID of the user is modified from 1013(any) to 500 or 512 which is for administrator and domain admins respectively. * ACL & group membership abuse as i mentioned earlier how I become an admin in the lab. * Trust Abuse by SID filtering bypass {% hint style="info" %} Access or Permission, basically authority within the Active Directory is only assigned to a SID. Not you idiot, your a loser. You are not that important. {% endhint %} ### Organizational Unit (OU) *** OUs are container object inside AD that is used to organize and manage directory objects in structured way. It is designed for managing network resources. It is basically a group of resources of specific location or specific purpose so when an admin need to apply a policy then it could be applied on specific collection of resources. Think of a department in the office that handles specific work for the company. The company may have applied special privileges or restricted based on the work or function. AD users may be granted permissions on these containers but its not necessary on the objects included within. This can happen if domain admin want to allow a user to perform basic admin task over a specific OU by applying policies. These policies are also called Group Policies Objects (GPOs). In other words, OUs are container objects that allow an administrator to group domain objects (users or computer or printers) together, providing a easy way to manage them. They are like folder inside the domain, and can be nested, means you can have OUs inside another OU, just like folder inside folders. Always think of OU as a department in a company to understand the term better. ``` # Common OU structures: By Department: OU=HR, OU=Finance, OU=IT By Location: OU=NewYork, OU=London, OU=Tokyo By Function: OU=Workstations, OU=Servers, OU=ServiceAccounts ``` #### What are the functions of OUs? * Simplified management: Organizing network resources as mentioned earlier by applying group policies on them. * Delegation of administration: You can delegate admin control of specific OUs to other user or groups. For example - there is OU for a particular department in your company and domain admin delegate control of that OU to the department admin. This allows you to share management responsibilities. Delegate means giving the control to another person or specific group so they can handle certain task without giving them full administrative rights. * Customized security: You can apply customized security setting to specific resource within the OU. For example - Giving specific password policy to users in that OU and different policy to users in another OU. {% hint style="info" %} Misconfigured OU can leads to privilege escalation or lateral movement. You can abuse delegation here to get the access over a specific OU such as administrator OU. Using tools like SharpHound and bloodhound you can check permissions over specific OU such as GenericAll , GenericWrite, WriteOwner, etc and then you can abuse them by modifying user inside the OU or putting yourself inside that specific OU by ACL abuse. Enumerating OU can reveal sensitive info that you can abuse. * GenericAll : Basically It grants you all the other write permission including the ability to change specific targer's password or modify its group membership. If the target is user they can reset the password and take over the control, if its a group they can add themselves by creating a new user object and adding in that group. * GenericWrite : It grants you to update attribute of the object. \ For example - Resource-Based Constrained Delegation (RBCD) attack in which you can modifies the `msDS-AllowedToDelegationToAccount` attribute to point to a specific computer they control, eventually allowing them to impersonate any user (can be admin). * WriteOwner : It gives you the right to take ownership of the object so you can modify the object's Discretionary Access Control List (DACL) to grant themselves `GenericAll` privileges. There are more permission abuse that will be covered in another pages. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kaizoku.gitbook.io/notes/active-directory/ad-objects-and-ous.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.