TAMS does not connect to any password store or hold AD credentials. It performs AD operations using the Windows service account identity it runs as, and it trusts the TruU Identity Server as the authoritative source of user identity.
Architecture
Component Overview
A TAMS deployment is made up of the following logical components:- Web server — hosts the REST API (ASP.NET Core) that the Windows Authenticator calls to request an account unlock.
- Token validation layer — validates the OAuth2 Bearer token on every request against the TruU Identity Server.
- Active Directory integration layer — locates the user by UPN and performs the unlock via
System.DirectoryServicesandSystem.DirectoryServices.AccountManagement. - Configuration store — settings are read from the Windows Registry under
HKLM\SOFTWARE\TruU\AccountManagement. - Observability — health checks, structured logging (NLog), and event reporting (Sentry).
Deployment Model
- Installed as a native Windows Service via an MSI installer.
- Runs on a Windows Server joined to, or with access to, your Active Directory domain/forest.
- Configuration is stored in the Windows Registry under
HKLM\SOFTWARE\TruU\AccountManagement. - The service process identity is a Windows service account with the minimum AD permissions required.
- Compiled for x64 only — ARM64 and x86 hosts are not supported.
TAMS is stateless — no session or in-memory state is shared between instances. This makes it straightforward to run multiple instances for high availability. See High Availability & Load Balancing.
-1.png?fit=max&auto=format&n=oUVNMOp0X8IEcmRy&q=85&s=0f7eeddb78befc5d9edcd278a2d66c38)
Technology Stack
| Component | Technology |
|---|---|
| Runtime | .NET 10 (Windows) |
| Web server | ASP.NET Core on Kestrel |
| AD integration | System.DirectoryServices & System.DirectoryServices.AccountManagement |
| Installer | WiX Toolset (MSI) |
| Monitoring | Sentry, NLog |
| Configuration | Windows Registry |