CT-Ops
Service Accounts
How CT-Ops tracks manual domain and local service accounts, expiry posture, and CMDB impact links.
The Monitoring -> Service Accounts menu item opens /service-accounts. Use
this page to review manually maintained non-human accounts that run workloads,
integrations, scheduled jobs, and automation across the current CT-Ops instance.
CT-Ops tracks two manual account scopes in one list:
| Account scope | Use it for |
|---|---|
| Domain | Centralised directory accounts such as Active Directory, LDAP, or identity-platform service principals that are reused by applications or enterprise integrations. |
| Local | Non-domain service accounts that operators manually create and maintain in CT-Ops. These are not accounts discovered from the CT-Ops server or from host inventory. |
The Service Accounts table includes a Scope column so operators can see whether each manually maintained account is Domain or Local without switching tabs.
Summary cards
The cards at the top summarise the manual register:
| Card | Meaning |
|---|---|
| Total | Combined count of manually tracked domain and local service accounts. |
| Domain | Centralised service accounts tracked in CT-Ops. |
| Local | Non-domain service accounts manually tracked in CT-Ops. |
| Active | Accounts currently marked active. |
| Disabled | Accounts marked disabled. |
| Locked | Accounts marked locked. |
| Expiring | Accounts with a password expiry date inside the configured warning window. |
Dashboard risk posture uses the same manual account counts for locked, expired, and expiring service accounts.
Account list
The account list shows username, scope, display name, email, status, password expiry, and CMDB link state in one table.
Use Add Service Account when an operator needs to model a shared account. Choose Domain for centralised directory accounts and Local for non-domain accounts that still need manual tracking.
If LDAP or Active Directory integrations are configured, the create dialog can search an enabled directory connection before a domain account is added. Choose the directory connection, enter a username or service-account prefix, run the search, then select the matching LDAP account. CT-Ops copies the available username, display name, email, password expiry, and lock or expiry status into the create form for review before saving.
LDAP search is optional. Leave No LDAP connection selected to enter a domain service account manually when the account is not present in LDAP, the integration is unavailable, or the operator is modelling a planned account.
The create and edit forms record:
| Field | Meaning |
|---|---|
| Username | Account username such as CORP\svc-payments, [email protected], or svc-backup. |
| Scope | Whether the account is Domain or Local. |
| Display name | Human-friendly label for the account. |
| Optional mailbox or owner contact for reviews. | |
| Password expiry | Optional expiry date used by risk and work-queue posture. |
| Status | Current account state. LDAP-selected locked or expired accounts pre-fill this value when the directory exposes that state. |
Opening an account shows whether it is Domain or Local and lets operators edit the account details or link it to a CMDB configuration item. Link accounts to the application, integration, or infrastructure component that would fail if the account were locked, disabled, or expired.
Host user inventory
Host-local Unix or Windows accounts discovered by agents are not managed from the Service Accounts page. They remain in host user inventory. Enable the collection on the host’s Management page or through agent defaults, then run the service-account discovery check from Host Monitoring.
CMDB impact modelling
Domain and local manual accounts can both be linked to CMDB configuration items. Those links make service-account failures visible from CMDB detail pages and from service impact views.
Model the link at the dependency level that best matches the blast radius:
| Dependency | Recommended CMDB link |
|---|---|
| A shared directory account used by one application | Link the domain account to that application service CI. |
| A backup or automation account used by many systems | Link the domain account to the platform or automation CI that owns the dependency. |
| A non-domain account used by one application | Link the local manual account to that application service CI. |
This gives incident, change, and resilience testing a direct path from account health to affected services.
Access control
All users with instance access can view account posture. Users with the Engineer, Instance Admin, or Super Admin role can create and edit service accounts and change CMDB links. Read-only users can still inspect the account inventory and impact context without seeing mutation controls.