> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Service Account Dependency Discovery and Onboarding
> Discover Windows services, scheduled tasks, and IIS application pools running under Active Directory or local Windows accounts, and keep them running through password rotation.
**Service Account Discovery and Onboarding** extends [Account Discovery](/docs/pam/discovery/overview) by detecting **Windows services**, **scheduled tasks**, and **IIS application pools** (collectively, **dependencies**) that run under Active Directory or Windows local accounts. Once dependencies are discovered, Syteca can manage them automatically during **account onboarding** and **remote password rotation** - so services keep running after credentials change.
**Use this when you need to:**
* Rotate a service account's password without breaking every Windows service, scheduled task, or IIS pool that authenticates with it.
* Get visibility into which systems and services depend on a given privileged account before you touch its credentials.
* Discover and track **Group Managed Service Accounts (gMSA)** dependencies, even though gMSA accounts themselves are managed by Active Directory and can't be onboarded.
Applies only to **Active Directory Discovery** and **Computer Discovery** rule types. Linux Discovery rules don't support dependency scanning.
The Account Discovery page requires the administrative **Privileged Accounts Management** permission and a **PAM seat license**.
## 1. Prerequisites
Dependency scanning needs specific permissions and components on each target computer, depending on what's being scanned.
### 1.1 Windows Services - grant "Log on as a service"
For Syteca to discover Windows services running under an account, that account needs the **Log on as a service** right on the target computer.
Press **Win+R**, type `secpol.msc`, press **Enter**.
Go to **Security Settings > Local Policies > User Rights Assignment**.
Double-click **Log on as a service**.
Click **Add User or Group…**, enter the account name (for example `LocalUser` or `DOMAIN\ServiceAccount`), and click **Check Names**.
Click **OK**, then **Apply**.
Open **Group Policy Management** (`gpmc.msc`) on a Domain Controller.
Right-click the GPO applying to your target servers (for example "Default Domain Policy" or a custom OU-scoped GPO) and select **Edit**.
Go to **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment**.
Double-click **Log on as a service**.
Select **Define these policy settings**, click **Add User or Group…**.
Add your service account, or a dedicated security group (recommended).
Run `gpupdate /force` on the target machines to apply immediately.
### 1.2 Scheduled Tasks - grant "Log on as a batch job"
For Syteca to discover scheduled tasks running under an account, that account needs the **Log on as a batch job** right.
Press **Win+R**, type `secpol.msc`, press **Enter**.
Go to **Security Settings > Local Policies > User Rights Assignment**.
Double-click **Log on as a batch job**.
Click **Add User or Group…**, enter the name (for example `BackupUser` or `NT SERVICE\ALL SERVICES`), and click **OK**.
Click **Apply**, then **OK**.
Open **Group Policy Management** (`gpmc.msc`).
Right-click your target GPO and select **Edit**.
Go to **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment**.
Double-click **Log on as a batch job**.
Select **Define these policy settings**, click **Add User or Group…**, and add your account.
Run `gpupdate /force` on the destination machines.
### 1.3 IIS Application Pools - prerequisites for WMI/PowerShell scanning
On the target computer, open **Control Panel > Programs > Programs and Features**, click **Turn Windows features on or off**, navigate to **Internet Information Services > Web Management Tools**, and enable **IIS Management Scripts and Tools**.
Restart the computer.
IIS version 7 or later is required.
To let the discovery account query IIS configuration via WMI:
Press **Win+R**, type `wmimgmt.msc`, press **Enter**.
Right-click **WMI Control (Local)**, select **Properties**, and go to the **Security** tab.
Expand the namespace tree to `root\WebAdministration`, select it, and click **Security**.
Click **Add…**, enter the username or group, and click **OK**.
Select the user or group, and check **Allow** for **Remote Enable** and **Execute Methods** (optionally also **Read Security** and **Provider Write**).
Members of the local **Administrators** group already have the required WMI permissions - these steps are only needed for non-administrator accounts.
## 2. Configure discovery rules to scan for dependencies
When adding or editing an **Active Directory Discovery** or **Computer Discovery** rule, a **Dependencies** section controls whether the scan looks for services, scheduled tasks, and IIS application pools running under the discovered accounts.
Log in as a user with the administrative **Privileged Accounts Management** permission, click **Account Discovery**, and select the **Rules** tab.
Click **Add** to create a new rule, or click an existing rule to edit it.
Set **Type** to **Active Directory Discovery** or **Computer Discovery**.
In the **Dependencies** section (below **General**), enable the **Dependencies** toggle.
Select one or more:
| Option | Discovers |
| ------------------------- | ------------------------------------------------------------- |
| **Windows Services** | Services running under the specified account. |
| **Scheduled Tasks** | Scheduled tasks configured under the specified account. |
| **IIS Application Pools** | IIS application pools configured under the specified account. |
Click **Save**.
If **Dependencies** is enabled but no checkboxes are selected when you click **Save**, the rule saves with **Dependencies** disabled. The section only appears for Active Directory Discovery and Computer Discovery - not for Linux Discovery rules.
## 3. View discovered accounts and their dependencies
After a discovery rule with dependency scanning runs, discovered accounts appear on the **Privileged Accounts** tab. The **Active Directory** and **Windows Local** sub-tabs each gain a **Dependencies** column showing how many dependencies were found per account.
### 3.1 Dependencies column
Shows the dependency count for each account. Clicking the count opens the **Dependencies** tab, filtered to that account.
### 3.2 Dependencies filter
Filter Active Directory and Windows Local accounts by:
* **Has dependencies** - accounts with at least one discovered dependency.
* **No dependencies** - accounts with none.
### 3.3 Account Type filter (Active Directory tab only)
Multi-select filter:
* **gMSA/sMSA account** - Group and Service Managed Service Accounts only.
* **AD user account** - standard Active Directory user accounts only.
### 3.4 Group Managed Service Accounts (gMSA)
Discovered gMSA accounts are marked with a dedicated icon in the Active Directory sub-tab. Hovering shows: *"Group Managed Service Accounts (gMSA) are managed by Active Directory group policies and cannot be onboarded into Syteca."*
gMSA accounts can't be onboarded - the **Onboard** icon is unavailable for them, and **Bulk Action > Onboard** is disabled if any gMSA account is selected. See [Group Managed Service Accounts](#9-group-managed-service-accounts-gmsa) below.
## 4. Understand the Dependencies tab
The **Dependencies** tab on the Account Discovery page consolidates every dependency discovered across all rules, sorted by **Discovered** date (most recent first).
| Column | Contents |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------ |
| **Computer** | The endpoint (hostname) where the dependency is located. |
| **Type** | Windows service, IIS Application Pool, or Scheduled Task. |
| **Status** | The dependency's current operational status - see below. |
| **Login** | The login name of the account the dependency runs under. |
| **Discovered** | When the dependency was first discovered. |
| **Last Onboarding Time** | When the associated account was last onboarded. |
| **Description** | The name of the service, pool, or task. |
| **Discovery Rule** | The rule that discovered it. If found by multiple rules, shows only the most recently run one. |
| **Secret** | The secret created during onboarding for the associated account. Click the name to open it on Password Management. |
### 4.1 Dependency statuses
| Status | Meaning |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Running** | Enabled and running. |
| **Stopped** | Stopped. |
| **Failed** | Status couldn't be checked (availability, permissions, or other errors), or the dependency failed to restart/stop. |
| **Exposed** | A new, previously unknown dependency was detected for an already-managed account. |
| **Unknown** | The most recent check couldn't confirm current status (endpoint unavailable, insufficient permissions, network issues). Previously discovered, but unconfirmed now. |
Hovering over a **Status** value shows "Last dependency check: ``", updated automatically. Dependency checks run after discovery, after onboarding, after each remote password rotation, and automatically every 3 hours.
### 4.2 Search, filter, and export
**Search** matches the **Computer**, **Login**, and **Description** columns (full or partial text).
| Filter | Filters by |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Status** | Running, Stopped, Failed, Exposed, or Unknown. |
| **Type** | Windows service, IIS Application Pool, or Scheduled Task. |
| **When** | Date range, based on **Discovered**. |
| **Who** | Login name. |
| **Discovery Rule** | The rule (only AD Discovery and Computer Discovery rules are listed). |
| **Secret** | Secret name. |
| **Warnings** | "Dependencies with warnings" / "Dependencies without warnings" - a warning marks a newly discovered dependency on an already-managed account. |
**Export** offers two options:
* **CSV (All Fields)** - every field, all pages, respecting applied filters.
* **CSV (Current Fields)** - only currently visible columns, all pages, respecting filters and column visibility.
Exported files are named `DiscoveredDependencies_{localDate}.csv`.
Deleting a discovery rule doesn't delete the dependencies it already discovered.
## 5. Onboard accounts with dependencies
Onboarding an AD or Windows local account that has dependencies shows a **Dependencies** section on the **Properties** tab of the **Onboard Account** popup.
Log in as a user with the administrative **Privileged Accounts Management** permission, click **Account Discovery**, select **Privileged Accounts**, then the **Active Directory** or **Windows Local** sub-tab.
Click the **Unmanaged** icon in the **Status** column for a single account, or select multiple and use **Bulk Action > Onboard**.
On the **Properties** tab of **Onboard Account**, fill in **General** and **Password Settings** as usual.
In the **Dependencies** section, enable the toggle.
| Option | Behavior after the password rotates |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Restart dependencies after onboarding** *(default)* | Updates credentials in each dependency, then restarts each service, task, or pool. |
| **Stop dependencies after onboarding** | Updates credentials in each dependency, then stops each service, task, or pool. |
Complete **Account(s) for Rotation** by selecting the secret to use for remote password rotation.
Click **Onboard**.
**Dependencies** is disabled by default; **Restart dependencies after onboarding** is pre-selected once enabled. The section is unavailable if **Use current password** is selected under Password Settings, and doesn't appear when onboarding Linux accounts. When onboarding a mix of accounts with and without dependencies via Bulk Action, the section still displays.
## 6. View dependencies on the Edit Secret page
After onboarding an account with dependencies, its **Dependencies** tab appears on the **Edit Secret** page.
On **Password Management**, open the secret for the onboarded account.
Select the **Dependencies** tab.
| Column | Contents |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Computer** | The endpoint hostname. |
| **Type** | Dependency type, with a color-coded status label next to it (Running / Stopped / Failed / Exposed / Unknown - same meanings as [above](#41-dependency-statuses)). |
| **Description** | The service, pool, or task name. |
Hovering the status label shows "Last dependency check: ``." The grid paginates at 50 records per page (not configurable), newest entries first. **Last dependency status check** (below the grid) shows the most recent check time for this account's dependencies.
### 6.1 Configure dependencies from the Automation tab
The **Automation** tab on **Add/Edit Secret** has its own **Dependencies** section - the same toggle and **Restart**/**Stop after onboarding** options - letting you change dependency handling for an already-onboarded account without repeating onboarding.
Only available for Active Directory and Windows local account secrets, since dependency management requires remote password rotation support. If Account Discovery hasn't run for this account yet, the tab shows: "Account Discovery must be performed to detect dependencies for this account."
## 7. Onboarding workflow and retry logic
When an account with dependencies is onboarded - or remote password rotation runs for an already-managed account with dependencies - Syteca follows a structured workflow.
### 7.1 Step 1: Password rotation and dependency management
Syteca rotates the service account's password, then either:
* **Restart dependencies after onboarding** - rotates dependency passwords, restarts each dependency.
* **Stop dependencies after onboarding** - rotates dependency passwords, stops each dependency.
Up to **2 attempts** are made for the initial rotation and restart/stop.
### 7.2 Step 2: Reconciliation with a dedicated account
If Step 1 fails, Syteca automatically retries using the **reconciliation account** configured on [Configuration → Account Discovery](/docs/administration/configuration/account-discovery-settings#1--configure-the-reconciliation-account) - typically a domain admin account.
* Uses the first available reconciliation secret matching the account's domain.
* Success stops the process there; failure tries the next secret from the same domain.
* Secrets from other domains aren't used.
* Only one reconciliation attempt per rotation cycle, with a 10-second timeout between retries.
### 7.3 Step 3: When dependencies fail to restart
If dependencies still fail after reconciliation:
* The **Tasks List** task is marked **Finished with errors**, naming the failed dependencies (for example, *"'Windows Service1', 'Windows Service2' dependencies failed to restart. Manual intervention required."*).
* A System Health notification appears.
* The affected dependency's status changes to **Failed**.
Common causes: insufficient permissions, application failure on the endpoint, or insufficient CPU/RAM/memory. Errors are logged in the Tasks List, the Server log file, and the Onboarding log file.
If the account's password rotates successfully but a dependency fails to restart/stop, the task shows **Finished with errors** (not **Failed**) - onboarding itself is considered complete; only the dependency update failed.
## 8. Manage the Exposed account status
If Syteca detects a **new dependency** for an account already in **Managed** status, the account automatically becomes **Exposed** - meaning its credentials may now be used by an additional, unsecured service or process.
When this happens:
* The account gets a dedicated **Exposed** icon on the Privileged Accounts tab (tooltip: *"New unmanaged dependency detected using this account."*).
* The new dependency appears on the Dependencies tab with a warning icon.
* An email notification goes to the user defined in the discovery rule that triggered detection.
### 8.1 Resolve the Exposed status
On **Password Management**, open the secret for the affected account.
Select the **Automation** tab.
Enable the **Dependencies** toggle and select **Restart dependencies after onboarding** or **Stop dependencies after onboarding**.
Click **Rotate Now** for an immediate rotation, then **Save** - or just click **Save** and wait for the next scheduled rotation.
During rotation, Syteca rotates the Exposed account's password, all known dependency passwords, and all newly discovered dependency passwords. On success, the status returns to **Managed** and the warning icon clears.
## 9. Group Managed Service Accounts (gMSA)
**gMSA** accounts are Active Directory accounts whose passwords Active Directory group policies manage automatically. Syteca can discover gMSA accounts (in the **Domain Admins** or **Enterprise Admins** groups) and their dependencies during Active Directory Discovery scans.
Discovered gMSA accounts appear on the Active Directory sub-tab with a dedicated icon. Restrictions:
1. **Can't be onboarded** through standard onboarding - the **Onboard** icon is unavailable, with tooltip *"Group Managed Service Accounts (gMSA) cannot be onboarded. These accounts are stored as read-only."*
2. **Bulk Action > Onboard** is disabled if any gMSA account is selected (alone or with regular AD accounts).
3. gMSA accounts can be **skipped** via **Bulk Action > Skip**.
Their dependencies still appear on the Dependencies tab.
## 10. Upgrade from a previous version
Upgrading to a version with Service Account Discovery doesn't automatically populate dependency information for accounts discovered before the upgrade.
Configure discovery rules as described in [Prerequisites](#1-prerequisites) and [Configure discovery rules](#2-configure-discovery-rules-to-scan-for-dependencies), then run them again from the beginning to detect dependencies for existing accounts.
After the upgrade, when rules run:
1. If discovery finds dependencies for an account already **Managed**, that account automatically becomes **Exposed**.
2. New dependencies appear on the Dependencies tab with a warning icon.
3. To return the account to **Managed**, perform a remote password rotation for its secret with **Dependencies** enabled - see [Resolve the Exposed status](#81-resolve-the-exposed-status).
## Related
Discovery rule types, running scans, and basic onboarding.
Configure the reconciliation account and WMI/PowerShell/Linux SSH scanners.
The rotation mechanism dependency management builds on.
Prerequisites for the scanners used during Computer Discovery.