Project: Steward¶

1. Project objective¶

Build a professional, modern web application to administer selected Microsoft Active Directory (AD DS) features through a simple, intuitive and secure interface.

The application will be used by:

MSP technicians, to administer the user accounts of various clients, with access through Teleport.
Client power users, to whom the MSP wants to delegate certain Active Directory operations without giving them access to domain controllers, servers or traditional administration tools.

The project must be designed as reusable software, deployable independently at several clients, with configuration and rights specific to each installation.

Philosophy: a lightweight, modern, specialised alternative to the everyday functions of Active Directory Users and Computers (ADUC), not a full replacement for ADUC nor a complex IAM platform.

Absolute priorities:

Security and the principle of least privilege.
Granular, easily understandable permission management.
Modern, professional, responsive interface.
Simple deployment, configuration and maintenance.
Respect for Microsoft Active Directory tiering.
Clean, modular, testable and maintainable code.
No use of Microsoft Entra ID, Azure AD or Microsoft Graph.

2. Technical stack¶

Backend¶

ASP.NET Core Web API, on a supported .NET LTS version.
C# with nullable reference types and static analysis.
System.DirectoryServices.Protocols to communicate with Active Directory.
Secure LDAP connection, with LDAPS and strict certificate validation.
Modular architecture without excessive complexity.
REST API with strong request validation.
OpenAPI for technical documentation.
Entity Framework Core for application data.
SQLite for a simple instance, with the option of using PostgreSQL later.
Structured logging.
Automated tests.

Frontend¶

React + TypeScript.
Vite.
Tailwind CSS.
shadcn/ui.
TanStack Query for API calls.
React Hook Form + Zod for forms.
Lucide Icons.
Responsive application, optimised above all for a full-screen desktop display.
Light and dark themes.

Deployment¶

Plan for an application that can run on:

Windows Server.
Linux.
Docker with Docker Compose.

The application must be deployable on a member server, with no installation on the domain controller.

Provide configuration through environment variables and/or a YAML file.

Never store secrets directly in the repository or in unprotected configuration files.

3. Multi-client architecture¶

The software must be common to all MSP clients, but each client must have an independent instance.

Example:

Client A: Steward instance A.
Client B: Steward instance B.
Client C: Steward instance C.

Each instance must have:

Its own Active Directory configuration.
Its own application database.
Its own roles and delegations.
Its own technical AD accounts or identities.
Its own audit logs.
Its own authentication settings.

No dependency on a central MSP platform may be required for the application's normal operation.

Do not build centralised multi-tenant management in V1.

4. Authentication¶

The application must support several authentication methods, which can be enabled or disabled independently at deployment time.

4.1. Teleport Application Access¶

Method mainly intended for MSP technicians.

The application will be published through Teleport Application Access.
Teleport handles authentication and MFA.
The application retrieves the authenticated identity through the identity mechanisms provided by Teleport.
Strictly validate the signed JWT: signature, issuer, audience, expiry and session identifier, depending on the available mechanisms.
Verify the public keys and their rotation.
Never trust identity HTTP headers sent directly by a client.
Prevent any direct access that would bypass Teleport.
Map the Teleport identity to an application user and its roles.
Display names must not be used as security identifiers.

Enabling Teleport must not automatically grant administration permissions.

4.2. Local Active Directory authentication¶

Optional method intended for client power users.

Can be enabled or disabled in the configuration.
Authentication with a named AD account.
Use a suitable secure mechanism: Kerberos/Negotiate in compatible environments, or secure LDAP verification when necessary.
Never store AD passwords.
Never expose credentials in the logs.
Provide protection against repeated attempts, without causing mass account lockouts.
Provide an MFA strategy when this method is exposed beyond the internal network.
Using an AD account grants no application rights by default.

4.3. Configuration¶

Conceptual example:

authentication:
  teleport:
    enabled: true

  active_directory:
    enabled: false

authorization:
  default_access: deny

An installation can run with Teleport only, or with Teleport and AD authentication.

Never allow operation without authentication.

5. Authorisation: granular RBAC¶

Build an authorisation engine that is simple to use but rigorous.

Permissions must be defined along four dimensions:

Subject: user or operator group.
Scope: domain and authorised AD organisational units.
Action: read, modify, password reset, unlock, etc.
Attributes: list of AD attributes that can be read or modified.

The engine must enforce a deny-by-default policy.

An operator without an explicit delegation cannot perform any AD operation.

5.1. Planned actions¶

users.read
users.attributes.read
users.attributes.write
users.password.reset
users.unlock
audit.read
delegations.read
delegations.manage
settings.manage

Do not use a generic users.write right that gives access to all AD properties.

5.2. Roles¶

Application administrators must be able to create custom roles.

Examples:

Power User Attributes - Search the authorised users. - View the authorised attributes. - Modify company, department, title, description. - No password reset.

Helpdesk L1 - Search users. - View the necessary information. - Reset the passwords of standard users. - Unlock accounts. - No modification of unauthorised attributes.

Helpdesk L2 - Modify the authorised attributes. - Reset passwords. - Unlock accounts.

VIP Operator - Hold additional delegations on certain business VIP accounts.

Roles must be cumulative.

Each delegation must be able to limit its actions, attributes and scopes independently.

Do not allow a permission on one OU to unintentionally widen the actions granted on another OU.

5.3. Active Directory scope¶

Allow OUs to be selected in a visual tree.

Features:

Browse the authorised OUs of the domain.
Select one or more OUs.
Include or exclude sub-OUs.
Define different permissions on different OUs.
Clearly display the scope of a delegation.
Refuse operations on objects that were moved outside the authorised scope.

Use the stable identifiers of AD objects where relevant.

Verify the object's DN and actual scope server-side on every sensitive operation.

Never accept a DN sent by the frontend as proof of authorisation.

6. Protection of VIP and privileged accounts¶

Distinguish two categories.

6.1. Business VIPs¶

These may be executives, HR staff or other sensitive people.

Allow one or more AD groups to be configured as VIP groups.

By default:

Viewing is limited according to roles.
Modifications are forbidden.
Password reset is forbidden.
Unlocking is forbidden.

An additional vip.manage permission can authorise certain operations on business VIP accounts.

This permission grants no rights over privileged administration accounts.

The VIP exception must be explicit, limited to one action and one scope, and logged.

6.2. Privileged accounts¶

The standard application must exclude the accounts of the higher administration tiers:

Domain Admins.
Enterprise Admins.
Domain controller administrators.
Server administration accounts.
Privileged service accounts.
Accounts protected by the relevant AD mechanisms.

Detect membership of sensitive groups, including nested membership, and examine the AD protection indicators.

Do not rely solely on adminCount, a VIP group or the location in an OU.

The classification of privileged accounts must be configurable and conservative.

If there is any doubt about an account's classification, refuse the operation.

A vip.manage permission can never bypass the protection of a Tier 0 or Tier 1 account.

Any administration of another tier must be designed as an independent technical scope.

7. Native Active Directory permissions¶

The application's RBAC must never be considered sufficient protection on its own.

Operations require two authorisations:

Application authorisation.
Effective authorisation in Active Directory.

7.1. Technical identities¶

Never use a Domain Admin account.

Provide separate technical identities depending on the operations and their sensitivity level.

Examples:

AD read identity.
Attribute modification identity.
Password reset identity.
A specific identity for business VIPs, if necessary.

Use gMSAs in compatible Windows environments where their use is relevant.

On Linux, provide a secure technical identification method compatible with AD.

Simply selecting a different identity in the code is not considered sufficient security isolation. Identities with different privilege levels must be separated by appropriate services or environments when necessary.

7.2. Native delegation¶

Create PowerShell scripts to delegate the required AD permissions.

These scripts must:

Target the configured OUs.
Grant only the necessary permissions.
Delegate write rights on the explicitly authorised attributes.
Delegate the password reset right separately.
Never modify the ACLs of protected objects without a specific procedure.
Be idempotent as far as possible.
Offer a simulation mode.
Produce a report of the changes.
Not delete or overwrite existing ACEs in an uncontrolled way.

The application must not have the permissions needed to modify domain ACLs itself during normal operation.

7.3. Verification¶

Create a deployment diagnostic that compares the configured application rights with the expected AD delegations.

In particular, display:

Domain reachable.
Valid LDAPS certificate.
Technical account authentication working.
Accessible OUs.
Expected write rights present or missing.
Reset rights available or missing.
Configuration problems detected.

Do not claim to compute all effective AD permissions if the diagnostic mechanism cannot determine them with certainty.

8. V1 features¶

8.1. User search¶

Create a page that allows:

Searching for a user by last name, first name, login, email address or AD identifier.
Filtering by authorised OU.
Distinguishing active and disabled accounts.
Displaying results clearly.
Loading results progressively.
Limiting searches and the volume of data exposed according to permissions.

Search must be protected against LDAP injection.

8.2. User profile¶

Display a structured profile with:

Last name.
First name.
Display name.
Login.
Email.
Phone.
Job title.
Department.
Organisation.
Description.
Authorised custom attributes.
Account status.

Display only the authorised information.

Organise the profile into clear sections.

8.3. Attribute modification¶

Allow modification of only the explicitly authorised attributes.

The available attributes must come from a controlled configuration, not from arbitrary input sent by the frontend.

Provide:

Configurable fields.
Customisable business labels.
Validation by attribute type.
A preview of the changes before saving.
A confirmation for sensitive changes.
Understandable error messages.
Handling of conflicts when the object was modified between being read and being saved.

Example: display company under the label "Organisation".

Provide handling of extensionAttribute1 to extensionAttribute15, only when these attributes exist in the schema and are authorised.

8.4. Audit¶

Log:

Operator identity.
Authentication provider.
Stable identifier of the AD object.
Requested action.
Attributes concerned.
Old and new values for non-sensitive attributes, according to the privacy policy.
UTC date and time.
Result of the operation.
Reason for any refusal.
Correlation identifier.

Never record passwords, secrets, tokens or other sensitive data.

Provide configurable retention and protection of the logs against unauthorised modification.

9. V2 features¶

Prepare the architecture needed for future Helpdesk operations as early as V1, without necessarily implementing them immediately.

Password reset¶

users.password.reset permission independent of attribute editing.
Verification of the target OU.
Verification of VIP and privileged account exclusions.
Use of a dedicated technical AD identity.
Secure LDAP connection.
Enforcement of AD password policies.
Ability to force a change at next sign-in, when compatible.
No password in the logs.
No retention of the password after the operation.
Explicit confirmation of the operation.
Recent re-validation of identity or strengthened authentication for sensitive actions.

Account unlock¶

Independent users.unlock permission.
Same scope and exclusion logic.
Systematic logging.

Do not make these features accessible by default.

10. User interface and experience¶

The application must look far more modern than classic LDAP managers.

Draw inspiration from the interface quality of contemporary professional SaaS products.

Art direction¶

Minimalist, premium design.
Compact side navigation.
Full-screen mode.
Careful typography.
Consistent spacing.
Fast, fluid interface.
Readable tables.
Simple forms.
Discreet notifications.
Polished loading states.
Light and dark themes.
No visual clutter.
Responsive without horizontal overflow.

Main pages¶

Dashboard - Information useful to the operator. - Recent actions. - Shortcuts to the authorised features.

Users - Search. - List. - User profile. - Attribute editing.

Helpdesk - Password reset (V2). - Unlock (V2).

Delegations - Role list. - Permission editing. - OU selector. - Attribute selector. - VIP exclusion management. - Assignment of roles to operators.

Audit - Filterable history. - Access according to permissions.

Configuration - Active Directory domain. - Authentication methods. - Technical identities. - Delegation diagnostics. - Application settings.

All administration pages must be hidden from unauthorised operators, with permissions also enforced on the backend.

Permission simulator¶

Important feature.

Allow an administrator to select:

An operator.
A target AD user.
An action.
An optional attribute.

Display the result:

Allowed or denied.
Role that granted the permission.
OU scope concerned.
Any VIP restriction.
Any tier restriction.
Validation status of the AD delegations.

The simulator must not make any real modification.

11. Application security¶

Apply a secure-by-default approach.

Requirements:

No anonymous access.
Deny by default.
Systematic permission validation in the backend.
Validation of every modified attribute.
Protection against LDAP injection.
Protection against SQL injection.
XSS and CSRF protection depending on the authentication strategy.
Correct session management and secure cookies.
HTTPS mandatory.
Strict validation of LDAPS certificates.
No secrets in the logs.
Secure error handling.
Request rate limiting.
Limits on AD searches.
Protection against mass operations.
Logging of denied actions.
Appropriate HTTP security headers.
Maintained dependencies and pinned versions.
Automated security tests.
Secure update management.
Protection against direct access bypassing Teleport.
Complete permission verification before every sensitive operation.

The frontend is never a security boundary.

Do not use secrets or privileged credentials in the browser.

Provide a clear strategy for protecting the technical accounts and their configuration.

12. Configuration and installation¶

The goal is for an MSP technician to be able to install a new client instance with a minimum of manual operations.

Provide:

A standardised deployment package.
A documented configuration file.
An installation or preparation script.
Domain and LDAPS configuration.
Teleport activation.
Optional activation of AD login.
Selection of the authorised OUs.
Configuration of the VIP groups.
Configuration of the technical identities.
Generation of the PowerShell delegation scripts.
Verification of the connection and permissions.
Creation of the first application administrator through a secure bootstrap procedure.

The initial administrative operations on AD must remain explicit and be carried out by an authorised person.

Also provide:

Update procedure.
Database migration.
Backup and restore.
Health checks.
Logs usable by monitoring.
Troubleshooting documentation.

13. Development quality¶

Use a pragmatic architecture.

Avoid:

Unnecessary microservices.
Mandatory Kubernetes.
A complex IAM infrastructure.
Dependencies on cloud services.
Premature abstractions.
Features that were not requested.
Duplication of the permission engine.
Full administration of Active Directory.

Favour a modular application that is easy to test and deploy.

Organise the backend by responsibility:

Authentication
Authorization
Directory
Delegation
User Management
Auditing
Configuration
Diagnostics

Create interfaces that allow the authorisation logic to be tested without a connection to a real Active Directory.

Provide a development environment with fictitious users and OUs to test the frontend without access to the production domain.

14. Mandatory tests¶

Add automated tests covering the following cases:

Authorisations - No role: no access. - Read-only: modification denied. - Modification of an authorised attribute: accepted. - Modification of an unauthorised attribute: denied. - User outside the OU: denied. - Sub-OU not included: denied. - Several roles with different scopes: no accidental elevation. - Attempt to modify an attribute through a direct API call: denied.

VIP and tiering - VIP user without exception: modification denied. - VIP with a valid exception: operation allowed only within its scope. - Privileged account with a VIP exception: denied. - Nested privileged group: exclusion applied. - Classification impossible: deny by default.

Authentication - Invalid Teleport token: denied. - Expired token: denied. - Wrong audience: denied. - Direct access bypassing Teleport: denied. - AD authentication disabled: method unavailable. - Authenticated user without a role: no AD operation.

Active Directory - LDAP connection unavailable. - Invalid LDAPS certificate. - Technical account with insufficient rights. - Object moved outside the authorised OU. - Object deleted during a modification. - Concurrent modification conflict. - Special characters in searches. - LDAP injection attempt.

Include integration tests with an Active Directory lab where necessary.

15. Delivery method¶

Do not start by generating a huge monolithic application containing all the features.

Proceed in stages.

Stage 1 — Architecture¶

Present:

The technical architecture.
The project structure.
The data model.
The authorisation model.
The model of technical AD identities.
The main security risks.
The development plan.

Identify the important decisions and any technical limits.

Stage 2 — Application foundation¶

Create:

ASP.NET Core solution.
React frontend.
Design system.
Configuration.
SQLite database.
Authentication system.
Authorisation engine.
Logging.

Stage 3 — Active Directory integration¶

Create:

LDAPS connection.
Search.
User reading.
OU reading.
Controlled attribute modification.

Stage 4 — Delegation administration¶

Create:

Roles.
Permissions.
OU scopes.
Attribute allowlist.
VIP groups.
Permission simulator.

Stage 5 — Security and deployment¶

Add:

Tests.
AD diagnostics.
PowerShell delegation scripts.
Docker / Windows installation.
Documentation.
Security checks.

Stage 6 — Helpdesk features¶

Add in a later phase:

Password reset.
Unlock.
Dedicated technical identities.
Strengthened controls.

16. Success criteria¶

The first version is considered functional when:

An MSP technician can access the application through Teleport.
A client power user can sign in through AD if this feature is enabled.
An administrator can create a role and associate certain OUs with it.
An administrator can precisely select the modifiable attributes.
An operator can search for and modify only the authorised users and attributes.
VIP accounts are protected by default.
Privileged accounts remain inaccessible.
Every modification is traced.
Native AD permissions prevent operations that exceed the technical delegations.
The application works without Microsoft Entra ID or any cloud dependency.
A new client instance can be deployed with an independent configuration.
The interface is modern, clear, responsive and suited to daily use.

17. Final instructions¶

Act as a senior software architect specialising in cybersecurity, Microsoft Active Directory, ASP.NET Core and React.

Security must guide the architecture choices, but without turning this application into an oversized IAM platform.

Never replace a real permission check with mere hiding in the interface.

Never introduce a Domain Admin account to simplify operations.

Avoid developing features that are not necessary for V1.

Do not assume that tiering is guaranteed solely by a user's location in an OU.

Favour simple, maintained, proven and easily auditable components.

Start by producing the detailed architecture and the development plan. Identify the risks or decisions to validate, then progressively build a functional, testable V1.

Do not consider a feature complete without real implementation, permission checks and appropriate tests.