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.