Welcome back to our final piece in the Adaxes setup series. Previously, we performed our initial installation, managed our object lifecycles, and setup the web management tools.

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.

Deploying the Adaxes Administrative Console and Self Service Client

Both pieces of software, the Administrative Console and the password self service client, come as MSIs. The Administrative Console requires that .NET Framework 3.5 be installed on the management machine first. You likely already deploy this prerequisite or bake it into your standard image.

The Console and Server components are built into a single MSI. Don’t silently deploy this without specifying that you only want the console part to be installed. To do this, pass ADDLOCAL=AdminConsoleFeature as a parameter to your MSIEXEC command.

You can also edit the MSI with ORCA to enable the AdminConsoleFeature and to disable the other server components. If you are doing an upgrade, ensure that the previous version is uninstalled first. I like to link the Adaxes Administrative Console to my RSAT deployment. This ensures that anyone needing those tools also have this console available as a default option.

Though we talked about the end result of the self service client in the last post, we did not cover the actual steps required to get to that end result. The self service client can be successfully deployed without any additional configuration. Once it is installed and the client is rebooted, the Reset Password link will appear on the logon screen. For a reset to actually work, we have a bit of configuration to do first.

Enabling Self Service Password Resets from the Logon Screen

Once the client is installed on the machine, it will look for configuration settings. These settings can be pushed out through the Adaxes Administrative Console and can be further customized through Group Policy. In the Adaxes Administrative Console, these settings are configured under Configuration\Password Self-Service. Magically, policies can be applied to security groups or OUs. Multiple policies can be created as well.

In the screenshot below, our default password self-service password is only requires that a user answer two out of their three security questions in order to reset their password. Users can choose from a populated set of questions or they can type their own questions. They can also unlock their account if needed.

This default policy that I created may be fine for student accounts or guest accounts. Teachers and school administrative staff should probably have a more stringent reset policy. In this case, we can create a second policy and adjust the precedence order. Our second policy requires that the user answer three out of their four security questions. It also requires a secondary contact method. Adaxes supports SMS and comes configured to work with several popular SMS gateways. Our policy uses a secondary email.

Most people have their primary personal email address configured on their phone already. The self service client can prompt users to enroll contact methods for self service resets. You can also use PowerShell prompts to enroll those attributes.

After setting up the default self-service settings, I configured additional settings through the Adaxes group policy settings. I prefer having all of my settings for any program visible in Group Policy instead of tucked away in various locations.

One setting that you will notice above is the option to Allow offline password resets. This is a pretty cool tool and functions similarity to an offline MFA code. Without having any internet access to your DC, a user can reset their own password! In education, this is an awesome feature for our summers as teachers forget their passwords.

Change Control through Business Rules

Active Directory does not have a native change control feature. You either have permission to do something or you are denied. This makes delegation tricky as you either end up giving support staff too many permissions or too few. In Adaxes, Business Rules are automated tasks that process around an action. They can automatically run before something occurs or after an action is taken.

In our environment, applications are deployed through security group membership. A lot of work behind the scenes makes it easy for applications to be deployed. In fact, it is so easy that you could create a Security Role that gives all Media Specialists permission to add computers to software deployment groups. You can see that security role below.

This works great 95% of the time. Some applications may be licensed per seat or might need to be watched over. After all, you would not want to deploy your IT management tools to every computer accidentally. To fill this remaining 5%, we have a business rule that requires membership changes to be approved for certain groups. This process is very similar to Microsoft’s Advance Group Policy Management tool but more flexible.

Change control can be applied to a lot more than groups. It can allow staff to join distribution groups at their school and have approval requests routed to the principal or it can allow IT interns to work within AD safely. Any object type can be used in change control requests. These rules can be applied to specific groups or OUs as well. This allows you to maintain your AD structure while taking advantage of these rules!

With that, our setup series is wrapped up! Adaxes fills in the missing components of Active Directory management and greatly extends the available features. I am personally surprised that Microsoft hasn’t tried to purchase for an MDOP or Enterprise feature. In a few months, we will circle back once more and see how our Adaxes implementation went over the year.