In this article, we are going to implement our three remaining features. First, we will look at deployment and software integration. This ensures that the administrative console is easily accessible. It also ensures that all clients are configured and connected. Next, we are going to enable password resets straight from the Windows logon screen! This process will also allow users to unlock their accounts without having to contact the IT department. Finally, we will optimize our change control policies. Change control will give us more flexibility with Active Directory delegation and can prevent career altering mistakes.
Last week, I spent 3 hours setting up an Always On VPN project in Group Policy/PowerShell that would have taken 30 minutes in Intune. This seemed really silly to me. Microsoft has this mountain of technology (Group Policy) but chose to build the Always On VPN client config switch in just Intune.
We see this problem often. Builtin technology stagnates, 3rd party tools then become required. The same is true for Active Directory object management. The last major improvement shipped in Server 2008 R2. It took us that long to get a sensible way to manage fine grain password policies! Some items, like the Active Directory Administrative Center, start out with so much potential but are ignored after release. I would argue that almost every improvement since these have been Azure AD only. Self service, web based management, special reporting, and ready made roles are some notable features missing from on-premise that are needed.
Over the next year, we are going to give Active Directory the attention it deserves. With the help of Softerra’s Adaxes, we will bring AD management about decade forward. This will be a five part series documenting an existing AD environment using a new Adaxes installation. The next three posts will cover the technical integration of Adaxes, problems that we faced, and best practices for configuration. You will see these over the next four months. The final post will provide a year follow up where we will compare our pre-environment to the current setup. To do this experiment, Softerra only provided me an installation license for Adaxes.
Through this experiment, I am hoping to address three large problems (that I am sure you also deal with). First, I am wanting to reduce daily object maintenance by providing self service capabilities. Second, I want to simplify the management interfaces for these objects. Our staff use a variety of tools and scripts for AD object management – my hope is to use a unified and customizable tool. Finally, we face a too many cooks problem at times. Anyone who has made a mistake in AD management can relate to this issue. Let’s look at these problems in depth and our potential solutions.
Problem 1: Reduce daily object maintenance
Managing AD with the native tools has turned into a messy challenge for my environment. Specifically, I am talking about the account maintenance / daily AD tasks that we deal with every day. Just to list a few, here are some of those challenges:
- Staff changing names, locations, and positions on a regular basis
- Staff forgetting passwords
- Staff forgetting how to reset their passwords through the text message method
- Staff needing to be added to / removed from security/distribution groups
I am a firm believer that anything can be automated and that any reduction in the routine tasks listed above is a great thing. Providing self service functionality to users may not prevent all routine account maintenance but it will prevent some!
Likewise, bringing the reset password option directly to the logon screen might not fix every forgotten password ticket but it will stop a many. If you want to stop fighting fires, every little thing helps. Both of the solutions for the problems discussed above are individual features found in Adaxes. Many are simple to enable. The more complicated ones, such as self service password resets, will be detailed in later articles.
Problem 2: Simplify management
If your environment is like mine, you probably have certain AD tasks delegated out to different staff. For example, you might have an HR employee who can update staff details. In the education sector, it is also common to delegate some permissions to media specialists or principals. Unfortunately, the native AD management tools are way too complicated and potentially risky when given to these types of account managers. I have taken two approaches to this in the past.
- Build single use PowerShell tools for users to run.
- This method is not very flexible and can kind of scare users.
- Design a custom ADUC interface for each user role.
- This was my go to for a long time as MMCs provided a lot of flexibility over the single use PowerShell scripts. To the user, it would look like a normal application and it was easy to learn. This method did not scale well and was difficult to update. Now with the push away from traditional MMCs, this is no longer that viable.
Adaxes provides us two solutions to this problem. First, our technical staff are able to use an improved and actively updated management console. Tasks like checking ACLs or making a small series of changes should be much easier!
The second solution are the web based interfaces. The three initial interfaces are: Administrators, Help Desk, and Self-Service. After setup, you can quickly create custom Web UIs that are tailored for specific departments. I am most excited to get these web consoles up and running. Instead of giving staff single use custom tools or creating a custom AD view, they will be able to use a clean web interface that is completely controlled from my end.
Problem 3: Too many cooks
Every organization with more than a single person IT department faces the too many cooks problem. Many take an egalitarian approach where every IT staff is treated identical. This works well until something bad accidentally happens. It might be a critical OU getting deleted, software getting automatically deployed domain wide, or a C-level account getting marked as stale. When an event like this occurs, most react the same way by removing permissions. Instead of 8 people managing AD, the CIO might insist upon just a single person handling that role.
This goes completely against the magician mentality though! No sane person wants to spend all day – every day doing the exact same thing. Role based management combined with approval workflow is the solution to the too many cooks problem! It can allow an organization to be flexible while reducing the risk that a career ending mistake is made. In fact, Microsoft saw this need for Group Policy and bought the Advanced Group Policy Management (AGPM) technology to fix it.
Adaxes is to AD as AGPM is to GP. Once Adaxes is setup, I will rest a little easier knowing that approval based tasks can be safely delegated and that every change is clearly visible!
My Plan for Deployment
Over the next few months, you will get to see how this experiment plays out. So far, the documentation and support has been great. The end result should be a high availability Adaxes installation sitting on top of our existing AD infrastructure. Right now, Softerra has a 30 day trial for Adaxes. I am trying to sweet talk them into providing a 180 day trial. Microsoft believes that it takes 180 days to really explore a product – I don’t see why Adaxes would be any different. If that trial offer changes, I will be sure to update you all.
In our next post, we will setup the administrative console, explore role based management, and configure the user management circle of life. I hope it moves us all.
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.
Welcome back to our year with Adaxes series! In this part, we are going to explore two key features that I personally love. First, we will look at the web consoles available in Adaxes and how you can customize them for your environment. These web based tools have the ability to replace Active Directory Users and Computer (ADUC) as well Active Directory Administrative Center (ADAC). We will then look at the self-service tools available for online and offline use. These tools automate away most of the routine object work that you are probably already doing in AD. Specifically, they can eliminate attribute changes, group membership changes, and password resets.
Using Web Consoles to Manage Active Directory
In the earlier articles of this series, we quickly mentioned the different management methods that Adaxes allows. Along with an expanded local administration console, three web interfaces are available after initial installation. To make access a bit easier, I actually took the shortcut files provided in the install and deployed those with Group Policy.
Of the two management web consoles, the Administrators version is most similar to ADAC/ADUC. The Help Desk version is a good starting point for HR (or in our case, media specialist use). In larger organizations, it would make a great tool for tier 1 helpdesk. Both can include the familiar and navigable AD tree of OUs. These console excels by bringing common tasks to the forefront. Think about easy ADAC made resetting passwords by including that tool on the start page. Now think about how easy other tasks could be if you had a simple button available at the very beginning. In the screenshot below, you can see our administrators console with common tasks brought to the homepage.
The three consoles are really well thought out. If you need to change them, it is very simple to create a copy and to edit the new page. A few years ago, one of my favorite tools was a modified ADUC MMC with a bunch of scripts builtin to the side pane. The Administrators web console, which I spend most of my time in, is a more powerful version of that modified MMC. It is also a lot easier to manage and scale out. You can see some of these customization in the console above. For example, we often prestage computer accounts in AD before imaging them and have added the Create Computer button directly to the homepage.
About a year ago, I started using Adaxes. I have been a fan of this software for quite a while because it fills many of the holes in an Active Directory environment. Out of the box, Adaxes provides mobile management, user self-service, and a mighty AD management console. Softerra has now released their most comprehensive update for Adaxes yet. Now that I have had a bit of time to get used to it, I wanted to write up some of my personal experiences and review where we were, where we are now, and where we hope to be with Active Directory management.
Before Adaxes and Our Current State
One word could summarize our environment in the past. That word is messy. We had many inconsistent naming schemes for every object type. Attributes, like descriptions or Outlook details, varied depending on when the object was created. Most actions were driven through multiple people and many routine AD management tasks were done by hand.
Since that time, we have moved to a very streamlined (but still not perfect) management scheme. In our environment, AD is the source for many of our applications and user data. Almost everything ties back into it. Because of this, our goal is a single console and service for all AD management. In the past, we would do some routine management (like a weekly task list) in ADAC and have various scripts running as scheduled tasks. All of that is now managed by Adaxes because we could use many of the built-in tasks and import scripts that were previously written. Below is a truncated screenshot showing the scheduled tasks agenda view in Adaxes. Even though I receive status notifications from these Adaxes tasks, I love getting to see this 30,000-foot view of future automated actions.
At our current state, most object management and maintenance are automatically handled by the scheduled task features in Adaxes. This makes the behind-the-scenes stuff simple, but what about the front-end? To be honest, our users are probably not even aware that we are using Adaxes to extend Active Directory because it integrates so well. Features like self-service password reset magically show up on the login screen. Our HR and Finance staff go to their custom designed Adaxes web portal for their AD management tasks. This is a considerable improvement over the clunky custom Active Directory Users and Computers MMC as I can design workflows for our staff to use.
Adaxes 2018.1 made AD web administration and management so much better! In previous versions, web consoles were created with a separate utility. While not difficult to use, I spent a lot of time jumping back and forth between the on-server utility and the console while making modifications. Now, web consoles are modified in the same browser. The screenshot, above, shows me modifying the Administrator web console. Everything is on one page – neatly divided with headers – and searchable.
From the end user standpoint, the web consoles are cleaner and easier to navigate in. Below is a screenshot of the AD console that our department can use for mobile access. Four buttons cover the majority of AD actions required in the field. When I am in a classroom or office, I can push out some software or a printer in just a few clicks from my phone.
With the new web consoles in Adaxes 2018.1, most routine work can be pushed into the browser wherever the user is located. From IT’s perspective, management is more accessible due to the unified management tool, unified login, and unified creation. Regarding customization, the browser management platform is superior. Every bit of content can be changed or rearranged for specific roles or tasks.
For more complex work, I spend most of my time working in the new Adaxes Administration console. Below is a screenshot of the console in our environment. It still has the traditional Active Directory view when I expand the Active Directory Node, but I also get to view our maintenance tasks, approval requests, workflows, and reporting within the same window. One thing to note is that Adaxes licenses per active user that you want to manage. We have licenses for all of our users, and it was a little confusing when they didn’t show up under the Active Directory node.
If you have ever worked with System Center Configuration Manager, you probably found it impressive to see software, updates, operating systems, security settings, inventory, etc. in the same console. I get that same happy feeling when I see AD reports, logging, tasks, etc. in the Adaxes console. One new feature that I am enjoying, which I highlighted above, is the inclusion of Best Practices as reports.
Almost every report breaks out into an interactive console. Computers, Users, and Groups each have an Overview Dashboard. When I click on Groups, I get a 30,000′ view of my group structure. If I click on the (5) Created Recently button, I get a custom view that shows these groups and the related attributes.
I do wish that Adaxes would combine AD audit events into their single pane of glass approach. If an environment audits group creation/deletion and the Adaxes service is delegated permission to read those events, the console should merge that data into their reports. Because the reporting platform is so flexible, it would be possible to pull this data in through external scripts that you set up. As of right now, that data is just not native to a report.
Going Forward with Adaxes
Like I said at the beginning, I don’t feel that I am at a perfect environment yet, but Adaxes is helping me get there. Going forward, I would like to look at moving some of the scheduled tasks over to business rules. This would allow our HR/finance staff to drive staff changes in real-time instead of feeding them into a scheduled task. I would also like to get a bit more redundancy built into my setup. Adaxes 2018.1 does streamline this with their new shared hierarchy models.
Adaxes is excellent, but I would like to recommend some future features. First, tie in AD domain controller audit events into the Logging and Report nodes. These events have always been a pain to read, and their integration would allow us to have a clearer insight into our environment. Second, make the Active Directory node an accurate view of AD – this will keep administrators in the console instead of having to fall back to ADUC/ADAC at times. The 30,000′ views are fantastic – keep adding to them! For example, property patterns allow us to create consistent computer accounts once implemented. A report showing naming irregularities would provide insight into our previously misnamed machines. Custom commands can allow us to fix these issues fairly quickly. Finally, add additional right-click management tools (similar to the SCCM Right Click Tools) and allow administrators to modify/add their own. Being able to right click and remote into a computer would be one example. Another would be a right-click – rename feature that works on one computer or a group of computers. Linking these right-click options to reports would provide insight and action with one tool. As of right now, custom commands can be added here. I have been told that the next big update will make these additional options easier to implement!
So, what is my final take with Adaxes and the 2018.1 Update? It is an incredible design for modern AD management. I think it will keep getting better! Adaxes is one of the few companies that I would consider holding a maintenance agreement with and that is because they provide solid feature rich updates on a regular basis. If you have never tried it before, play around with their live demo environment here.