0-60 – Active Directory Objects and Best Naming Practices

One of the most difficult concepts behind IT is constantly learning new technologies. As we learn, our brains adjust conception to comprehend objects easier. Examples of this are mentally renaming terms to something that makes sense more sense or creating a process flow to automate our movements and actions to get a task done. This was the case for the role I had in my university days at Central Michigan.

On average, I was taking 15 credits a semester while working around 20 hours a week at my on-campus job. On top of this, I was involved in four student organizations at my university. Time was constrained, and I did my best to find ways to learn concepts quickly. My job, which was a student role as a Technical Services Technician, saw a hybrid between being a system administrator and a help desk professional. The role sought customer support with a ticket system, as well as deploying workstations utilizing System Center Configuration Manager (SCCM). Often, I found myself accessing Active Directory (AD) and troubleshooting issues related to users file shares and computers.

Learning Active Directory was difficult for me at first. For a college student to even have access to a forest of objects was a huge learning curve. Often, students don’t experience Active Directory until they get into the workforce. My access in my role was limited, as I could only edit workstation objects. While read access to the whole forest was given, the University administrators did not want students to mess around with user accounts and their settings. If this access was given, it was simply asking for a plethora of issues in the future.

To learn faster, I labeled objects differently so my mind could comprehend them better. In a conversation I had recently with a system administrator, they had issues understanding my knowledge in AD. This was because I was calling objects differently from what they were normally called. Computer objects were often called workstation objects. A shared folder saw the term file share. The only one I called correctly was a user object.

To correct this mindset, I went and did some research further on AD, in efforts to solidify my knowledge. Using correct terminology is huge in the field of information technology. If you do not call something correctly it could be mistaken for something else, causing potential issues on your network. The last thing a System Administrator wants is for a mispronunciation to come back and haunt them.

Right off the bat, I went to Windows Active Directory, a website dedicated to topics on AD. One article found saw the following list of objects, with the correct terms:

1. User – This contains contact information about the user, and their login credentials. These objects also allow for hierarchies, as it allows for properties like the direct reports to the user, or who they themselves report to.
2. Contact – This is one I was not too familiar with. The contact object allows for creating contact information to people that might be associated to the business. This is not like a user object, which allows users to sign in and communicate if enabled.
3. Printer – an object dedicated to a printer on the network. This includes the IP addresses, and other information that is there.
4. Computer – What I often called a “Workstation” object, these consist of any type of computer. Cell phones, Portable devices, or even Macbooks if you had the right software to configure it.
5. Shared Folder - This was the object that caused me to go back and look into my knowledge. I often called the Shared Folder object “File share”, going back to my help desk days of answering calls and setting up file shares for users. There is a big difference between a shared folder, and an actual file share. Shared folder objects point to a specific shared folder. Not a hierarchy like a file share might have. You could point the shared folder object to a specific file share if you wanted.
6. Group - This allows for organization within active directory. Group objects allow for administrators to organize different objects into pools. Each group could contain a bunch of users, contacts, or machines. This allows system administrators to assign a certain group to have access to another object like a printer. Groups objects allow a lot of control with role-based access control. 
7. Organizational Unit - Also called OUs, are very similar to files in a computer system. You can organize different objects inside each OU and provide access to manage the OU by giving a user or group object access to control it. 
8. Domain - The top level of active directory. Domains allow for standardization across all objects inside it. Keeping this access limited and in control is a best practice seen from System Administrators.

These eight are the primary objects that system administrators will be utilizing on a day-to-day basis. Examples of this include a user getting removed or added depending on company changes. Groups are going to be needed in case of department changes. Shared folders will be created as central deposits are determined by teams. Printer objects will be sought after when a team decides it needs a new LaserJet. 

The article also goes into other objects that are seen in most active directory environments. However, these are extremely high level, and often do not see edits to them unless something huge needs to be changed. Items like Domain Controllers and Foreign security principals should only be made or edited for very specific changes.

However, what about setting up an Active Directory environment? What are best practices for creating a domain? Luckily for me, people from Microsoft such as Peter Geelen submit to a wiki on different guides and best practices to approach such questions. A couple of best practices for planning a new Active Directory are as follows:

1. Utilize internal sub domains for your general domain. For example, a network engineer’s website might be called activedirectory.com. Adding on an internal subdomain will be internal.activedirectory.com. This internal DNS name will be the redirect for your active directory space.
2. Do not get AD Domain and DNS name confused. They are not the same thing, but they are linked. In the above example, the Internal part of the DNS name will be the active directory name.
3. Do not utilize a dummy DNS name for your top level. This is the use of .lan, .local or .internal on your active directory name.

After setting up, you can continue to make organizational units, and start organizing your active directory. Even further, you can tie your on-premise active directory to Azure, which allow for a bunch more options such as single sign on, multi-factor authentication, or conditional access to certain applications. 

Active directory is everywhere and understanding it can be extremely beneficial to the future of a professional’s IT career.