Active.Directory.Utility
A .NET web API that runs PowerShell Active Directory commands for you and returns the results as JSON.
Users
Create, delete, enable, disable, unlock, authenticate, change or reset passwords, read and update attributes.
Groups and OUs
Create and delete groups and OUs, manage membership, list and search.
Password policies
Create, update, apply and remove fine-grained password policies.
Account status
Find locked, disabled, inactive, expiring or expired accounts, and set account expiration.
Security
HTTPS, required API key, AES-256 encrypted secrets, request and error logging with passwords masked.
Operations
Health check endpoint, load-balancer settings for F5, NGINX Plus, AWS, NetScaler and others.
Main use case: role-based security for your applications
Most organizations already control who is who in Active Directory. Active Directory Utility lets every application reuse that, so access is decided by AD groups instead of by separate user lists inside each application.
One source of truth
Treat an AD group as a role, for example App-Invoices-Approvers. Whoever is in the group has the role, in every application that checks it.
Any kind of application
Web, desktop and mobile back ends, internal tools, ERP and HR systems, ticketing, scripts and services. If it can call an HTTPS JSON API, it can use AD roles, whatever language it is written in.
Joiners, movers, leavers
Add or remove a user in a group and the change applies everywhere at once. Disable the account and the person loses access in every application that checks AD.
Audited
Each request is logged with the time, caller IP, method and parameters, with passwords masked, so you can show who asked what and when.
- The application signs the user in with
AuthenticateUser. - It asks AD for the user's groups with
GetUserGroups, or checks one role withIsUserInGroup. - It maps those groups to what the user may do in the application.
- Administrators grant and revoke roles with
AddUserToGroupandRemoveUserFromGroup, or in AD itself.
Example: does jsmith hold the approver role?
GET /api/IsUserInGroup?LDAP_Path=LDAP://OU=Groups,DC=corp,DC=example,DC=com&UserName=jsmith&GroupName=App-Invoices-Approvers
X-Api-Key: your-api-key
{ "Success": true, "Data": { "IsMember": true } }
Group checks use direct membership. Use GetUserGroups and GetGroupsInGroup to work with groups placed inside other groups.
How it runs
ASP.NET Core on .NET 11 and IIS
The API is an ASP.NET Core application on .NET 11, hosted on Windows IIS in an application pool set to No Managed Code. It keeps no session state, so you can run several IIS servers behind one load balancer without sticky sessions.
PowerShell, local or remote
Every method runs the PowerShell Active Directory commands. They can run locally on the IIS server, or remotely on an AD server over WinRM with SSL on TCP 5986.
Load-balanced domain controllers
Your domain controllers can sit behind F5 BIG-IP, Foundry/Brocade, NGINX Plus, AWS Elastic Load Balancing, Cloudflare, Citrix NetScaler (ADC) or HAProxy Enterprise. Pick the one you use in the settings and give it the virtual server name and ports.
Built-in health check
/api/HealthCheck tests PowerShell on the web server, the WinRM connection, the LDAPS (636) TLS handshake and certificate, and a live Active Directory session. Point your load balancer monitors at it.
Encrypted at every step
- Client to load balancer: HTTPS (TLS) on port 443, with a required API key.
- Load balancer to IIS: HTTPS on port 443, re-encrypted rather than passed on as plain HTTP.
- IIS to the AD server: WinRM over SSL on TCP 5986. Certificate trust, name and revocation checks are on by default.
- Health check to the domain controllers: a TLS handshake on LDAPS (TCP 636).
- AD server to the domain controllers: Active Directory Web Services, protected by Windows authentication and encryption.
- Secrets at rest: the remote password and API keys are stored AES-256 encrypted in the configuration file.