In part one of this series, we talked about the too many cooks in the kitchen problem. Any multi-management application has to deal with this; Active Directory is no different. On the mundane side, this can include attribute misspellings, missing group memberships, and misplaced users. On the catastrophic side, it can cause domain wide outages through accidental modifications or deletions!
Many organizations adopt a draconian response to this problem. They simply restrict all changes to a single (or few) administrator(s). Ironically, these AD administrators still use a domain administrator account for everything – greatly increasing the risk of an accidental slip or exposing permissions to malicious actors. The solution shouldn’t be draconian but it isn’t an egalitarian environment either. Instead, a nudge, role, and rule based approach is needed.
Nudging Away Problems
Nudges, or cues, push people toward correct choices. For example, the username field of a website may be populated with someone@YOURDOMAIN.com to instruct users to use a certain format. Introducing these nudges into Active Directory management can go a long way to fixing the problems above. In Adaxes, Property Patterns provide that nudge.
Each major object type has a builtin property pattern. The Computer Pattern is pictured above. These patterns should be modified to fit the naming convention of your environment and to specify the attributes that you need to fill. I like my computer names to be formatted like this: SITE-ROOM-STATIONNUMBER. For example, TEC-06-01 tells me that this computer is located at the TEC complex in room six and it is the first computer. All teacher machines are given the 01 station number so I also know that it is a staff computer. You can see that regex constraint below:
A computer name pattern could be applied to the TEC OU and it can enforce all of those parameters. This eliminates mistakes like naming the computer TCE instead of TEC. It keeps everything in sequential order because the station number needs to be two digits long (09 instead of just 9).
Property patterns can also be used to provide drop down list. These lists work really well for departments, titles, and locations.
How many domain administrators should you have?
No user’s primary account should be a domain administrator. Whether you use Adaxes or not, your primary account should be a standard user. Like Microsoft’s Advanced Group Policy Management (AGPM), Adaxes uses a service account to manage content. During installation, this service account should be delegated permission to manage any applicable OUs or domains. This is the one time that you may use the domain administrator account for a specific task.
After delegation, permission changes are stored within the Adaxes configuration. Access to older AD object management tools should be restricted through AppLocker or native AD permission changes. If you have deployed AGPM, you should find these steps familiar. The service account user is made a service administrator – end users (including IT staff) should not use it to launch the Administration Console or to access the web consoles.
Users needing to manage Active Directory should be assigned to Security Roles. These roles group together common individual permissions into a single group like object. It is important to note that Adaxes is a layer on top of Active Directory. When a user is assigned to a security role, they are delegated permissions within Adaxes – permissions inside Active Directory are not modified.
Existing roles can quickly be copied and modified. For example, the Help Desk role works great for our regular IT staff. It provides too many permissions to our Help Desk interns though. By copying the Help Desk role, I can quickly remove the Disable User Account option from the new Security Role.
The Ghost in the Directory
Automation is the key to efficiency but your implementation may have hidden dangers. In our environment, many simple jobs are automated with Scheduled Tasks and PowerShell scripts. If your environment is like mine, ask yourself these questions:
- Are the scripts ran with least privileged users?
- Are the scripts designed and signed to prevent tampering?
- Do the scripts centrally log changes?
- Are changes and schedules clearly visible to everyone?
By solving all of your individual problems with individual solutions, you have accidentally created a ghost in the directory – a place where changes (good or bad) can happen with little oversight. A bug could cause an essential script to stop functioning without you knowing. A malicious attack could leverage the scheduled task and user account to inflict massive damage.
Business rules solve this problem by putting light onto your automation. These rules can be ran before or after nearly any action that you would take in Active Directory. Think about the three stages of a user object: creation, maintenance, and deletion. Each stage is ripe for a business rule. In fact, Adaxes has a default rule that can run after any user is created. Below, our business rule as a single trigger (after user creation) and five tasks that should run.
Business Rules are designed to bring any every aspect of an action. The After User Creation rule can create a folder on a file server, edit file permissions, configure Exchange settings, and modify Office365. Four difference management consoles are combined into a single action.
To take advantage of business rules, make a list of all actions that you would do during any life cycle stage of any object. For example, user maintenance often occurs when an employee changes positions. A trigger for user maintenance could occur when the user moves OUs. Actions could include attribute updates, emails to managers, and group membership changes.
Adaxes solves a lot of our problems with object life cycle management. It provides a clean way to group AD management, makes automation clearly visible, and nudges actions toward consistency. In our next post, we will look at configuring our web consoles and setting up self service for our staff.