Users are part of any network and while sometimes troublesome, it’s the responsibility of the IT admin team to ensure that users can access only the resources necessary to perform their roles. The receptionist has no need to access software project data and software developers have no interest in HR resources. Therefore, user permissions are necessary.

In smaller organizations, setting user permissions in Windows for network objects is achieved using Windows Explorer, simply right click on a file,  folder, volume or device and permissions can be changed if the user has admin control. In this rudimentary example, the ability to read, write and modify file or folder permissions  is assigned and a valid user can easily be added with the correct permissions.  No big deal, right?

Now, imagine that there are 100 servers, thousands of users and several different domains to handle. A trivial exercise in permission assignment is now almost insurmountable. How can you assign desired permissions to an individual user account, prevent access to specified domains while still allowing access to MySQL databases, for example?

This is where Active Directory Domain Services comes in (those in the know just say “AD”) and allows a trained administrator to manage everything from one dashboard. Before delving into Active Directory user permissions in a little more detail, it is worth explaining AD.

What is Active Directory?

Active Directory first made an appearance a beta release in Windows 2000. After nearly two decades, it has evolved (with Windows Server 2016 incorporating the latest version) along with the demand for scalability in today’s network architecture, whether that involves physical equipment or virtual solutions.

But, what is Active Directory? It’s a network operating system (NOS) and from a class of products known as Directory Services. In a Windows environment, AD is used, even if other products are also selected. It may not seem like it, but at its core it performs like a database, allowing admins to manage all information, about users, groups, printers and any other devices or objects connected to the network. In addition, of course, it also includes a hierarchy for distinguishing users and admins.

Like any other advance software, AD has its terminology, and these must be understood before creating or importing users in Active Directory. These terms include but are not limited to:

  • Authentication–Not exactly unique but commonsense dictates that before permission is received, users must prove they are who they claim to be before access to a specific network resource is granted.
  • Authorization–Once credentials (can vary according to the organization-a biometric RFID implant in the skull is one example but tokens are more commonly used) are verified, the user is granted permission. This and (1) are part of the identity management service in AD.
  • Forest–In this context, not a collection of green leafy things but instead a term used to refer to your entire Active Directory and named after the root domain or first domain created. Each domain is referred to a tree, for obvious reasons. Levels of trust are used to distinguish between requests from inside and outside the forest although it is possible to create trust with another forest.
  • Domain–We are all familiar with this term, but AD can apply a variety of domain-specific boundaries.
    1. Admin–Domains are assigned specific admins and can be blocked from accessing other domains.
    2. Security–Security policies are only active in the domain.
    3. Policy–Group policies are determined by each domain and rarely applied across multiple domains.
  • Organizational Unit–A container within an AD domain to store users, user groups, computers and other defined organizational units (OUs). Some companies may have OUs named after their departments, for example. A new hire in Engineering is easily added to the Engineering OU as permissions and policies are already defined for the department.
  • Domain Controller–Domain controllers are servers on a Windows network that manage access to domain resources and are obviously key to ensuring the uptime of your network.

Permissions for all network objects (on all controlled domains) are also managed from AD and adequate admin training in this area can reduce security risks, help ensure compliance with relevant regulations and improve efficiency.

What are User Permissions?

User permissions are not new and we’re all used to the traditional login and username combo to access services. Whether it’s a permission set (Salesforce), actions menu (Oracle), execute permission (Linux) or the ability to assign permissions (Microsoft Dynamics NAV), the terminology used is irrelevant; these companies are enforcing identity management policies.

When it comes to workstations, many companies rely on a local login and password to grant user access. However, with Active Directory, thanks to its domain controllers, a user can log into any machine and connect remotely to a resource if permissions are verified for the object and domain. In short, access is granted by the domain and not a local machine policy.

All users require a domain-controlled account to access the network. As it should be, considering that companies must protect their infrastructure and data from cyber-attacks.

Active Directory admins typically create a new user by selecting one of three methods:

  • ADAC– Active Directory Administrative Center. First seen in Windows Server 2008. Does not require a user password or container to create a new user. PowerShell commands are available to create scripts.
  • ADUC– Active Directory Users and Computers. One of the tools from the first version of AD in Windows 2000
  • PowerShell–A scripting engine based on the .NET framework. The AD module can be loaded into PowerShell using the command:
Import-Module ActiveDirectory

Whether you use ADAC, ADUC, or PowerShell (used a lot for automation) to create a new AD user account, setting permissions is normally the next step.

How Do you Set User Permissions in Active Directory?

Since 2008, Active Directory admins have predominantly used ADAC and PowerShell to modify user permissions. Unlike local policies, domain-controlled permissions are not as simple, but all methods adhere to the same AD features.

For example, the administrator creates a new user to provide a new gender-neutral robot employee with the necessary access permissions to fulfil the role. Aren’t you fed up of political correctness? I know I am.

In any case, it is part of the Quality department in a manufacturing facility and part of the role involves compliance audits that cover all company departments. What permissions should it receive? What are the considerations?

Open your preferred GUI tool, find the relevant user account and right click to find ‘properties’, then modify what is needed. It’s tedious to do the same in PowerShell, as primary benefits of this tool lie in copying from one account to another or importing permissions from a group or OU. If the GUI is tedious, then a PowerShell script might save time.

Bearing in mind that this is just an example pulled from an orifice and that the process is similar, whether ADAC or PowerShell is used, the process is similar.

The following questions and answers should make the process a little clearer.

  • Is it a user? –Sure it is, and is part of the Users Group – lowest level of the hierarchy with no ability to change security, permission settings or any other admin function.
  • Do you need to enforce a password policy?– Some companies enforce a policy where user passwords must be changed at regular intervals. This is good practice.
  • Is it a part of an organizational unit (OU)? –If AD is configured correctly, then there will be a Quality container or at least an employee level designator that allows the required access to all objects for the Quality department. If ‘Compliance’ is available as another OU, then it would also be added to that OU. In addition, as document management is also part of the Quality remit, the department would also have access to all official documents released to production, to engineers, to material specs for purchasing and engineering and all other documentation for processes defined by the company Quality manual. It can all get rather complicated and permission management is not to be taken lightly.
  • Are there any relevant Groups? –This depends on how AD is set up; some companies may prefer to use groups by seniority level rather than departments. For example, categories, could include admins, directors, managers, supervisors and general operatives–each of these would have related permissions.
  • Are there any special permissions necessary? – The AD admin will be informed if additional permissions are required.
  • Are new policies needed? –Group policies are to be avoided if possible as they can be problematic when they conflict with other permissions.

As you’ll notice, setting up permissions requires some planning but once OUs and User group permissions are defined then the task is easier. AD permissions are in some cases hierarchical so once a user is added to a group or OU then permissions are inherited. If higher than basic user permissions, then the higher permissions take precedence.

In conclusion, Active Directory is not a replacement for local permission management using Windows Explorer. Books have and will continue to be written on the subject. Avoid unnecessary complexity when setting AD permissions or changing policies. In addition, it is worth considering the use of GUIs and tools such as PowerShell to automate repetitive tasks.

In fact, I recommend you test AD in an offline or virtual environment before rolling out changes to an active network as users tend to complain when they can no longer access their social media or streaming video. Is your IT team spending too much time managing users? Perhaps you need to consider the benefits of Active Directory, so they can concentrate more on cybersecurity and process improvement?

Michael O'Dwyer

About Michael O'Dwyer

Michael O’Dwyer is a business & technology journalist, independent consultant and writer who specializes in writing for enterprise, small business and IT audiences. With 20+ years of experience in everything from IT and electronic component-level failure analysis to process improvement and supply chains (and an in-depth knowledge of Klingon,) Michael is a sought-after writer whose quality sources, deep research and quirky sense of humor ensures he’s welcome in high-profile publications such as The Street and Fortune 100 IT portals.


Leave a Comment