> ## 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.

# Using a gMSA or sMSA Account for the MS SQL Server Connection

> Set up a Group or Standalone Managed Service Account for the connection between MS SQL Server and the Application Server, instead of a standard SQL login.

<Warning>
  **NOT AVAILABLE IN SAAS.**
</Warning>

If required — for example, for security reasons — a gMSA (Group Managed Service Account) or sMSA (Standalone Managed Service Account) can be used for the connection between the MS SQL Server database and the Application Server, instead of a standard SQL login. This guide uses "gMSA account" to refer to either type.

## 1. Set up a gMSA account

### 1.1 Create a KDS key

<Steps>
  <Step title="Add a KDS root key">
    Run in PowerShell:

    ```powershell theme={"system"}
    Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
    ```

    This key is used to generate and rotate the gMSA password.
  </Step>

  <Step title="Confirm the key was added">
    ```powershell theme={"system"}
    Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
    ```

    Expected result: `True`.
  </Step>
</Steps>

### 1.2 Create the gMSA account

<Steps>
  <Step title="Enable gMSA support">
    ```powershell theme={"system"}
    Install-WindowsFeature RSAT-AD-PowerShell
    Import-Module ActiveDirectory
    ```
  </Step>

  <Step title="Create an Active Directory group for target computers">
    Add the computers that will use this gMSA account to a new AD group (for example `gmsaServers`).
  </Step>

  <Step title="Create the account">
    ```powershell theme={"system"}
    New-ADServiceAccount <gmsa_login> -DNSHostName <FQDN_server> -PrincipalsAllowedToRetrieveManagedPassword <AD_group> -KerberosEncryptionType AES128, AES256
    ```

    For example:

    ```powershell theme={"system"}
    New-ADServiceAccount MyGmsa -DNSHostName "MyGmsa.my.test" -PrincipalsAllowedToRetrieveManagedPassword "gmsaservers" -KerberosEncryptionType AES128, AES256
    ```

    <Note>
      `-KerberosEncryptionType` is optional but recommended, to avoid future Kerberos authentication issues.
    </Note>
  </Step>

  <Step title="Reboot the group's computers">
    Restart every computer added to the AD group above.
  </Step>
</Steps>

### 1.3 Install the gMSA account on target computers

Repeat on every computer that will use this gMSA account:

<Steps>
  <Step title="Install required modules">
    ```powershell theme={"system"}
    Install-WindowsFeature RSAT-AD-PowerShell
    ```
  </Step>

  <Step title="Install the account">
    ```powershell theme={"system"}
    Install-ADServiceAccount <gmsa_login>
    ```
  </Step>

  <Step title="Confirm installation">
    ```powershell theme={"system"}
    Test-ADServiceAccount -Identity <gmsa_login>
    ```

    Expected result: `True`.
  </Step>
</Steps>

### 1.4 Grant "Log on as a service"

<Steps>
  <Step title="Open Local Security Policy">
    Run `secpol.msc`, go to **Local Policies > User Rights Assignment**, and add the gMSA account to the **Log on as a service** policy.
  </Step>

  <Step title="Repeat on every computer">
    Apply this on every computer where the gMSA account will run.
  </Step>
</Steps>

### 1.5 Grant access to system performance counters

<Steps>
  <Step title="Grant Perflib access">
    To prevent a **"Access to the registry key 'Global' is denied"** error on the System Health page, grant **Full Control** for the gMSA account on `Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib`.
  </Step>

  <Step title="Grant EventLog access">
    For the **EkranServer** service to start, grant **Full control** for the gMSA account on `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog`.
  </Step>
</Steps>

### 1.6 Grant access to the Syteca install folder

For log data to be written correctly, grant **Full control** for the gMSA account on `C:\Program Files\Ekran System\Ekran System`.

## 2. Configure the Management Tool

### 2.1 The LDAP target

If using the gMSA account with an automatic LDAP target:

<Steps>
  <Step title="Run the Application Server under the gMSA account">
    In Windows Services, set the **EkranServer** service to run as the gMSA account.
  </Step>

  <Step title="Refresh the LDAP target">
    On **Configuration > LDAP Targets**, click **Refresh Automatic LDAP Target** for the target using this account.
  </Step>
</Steps>

### 2.2 Database and archive parameters

<Note>
  The gMSA account must be added under **Logins** in SQL Server Management Studio, with the `db_owner` permission granted.
</Note>

<Steps>
  <Step title="Run both services under the gMSA account">
    Set both the **EkranServer** service and the SQL Server service to run as the gMSA account, in Windows Services.
  </Step>

  <Step title="Configure the database connection">
    Open [Database Parameters](/docs/administration/database/database-parameters) (right-click the Syteca Server tray icon), and on the **Metadata Storage** sub-tab, select **Windows Authentication** and the **Use process credentials** checkbox.

    <Note>
      The **User Name** and **Password** fields are disabled — the gMSA account's credentials are used automatically.
    </Note>
  </Step>

  <Step title="Enter placeholder archive credentials">
    When configuring [archive database parameters](/docs/administration/deployment/database-management) or [adding an archived database](/docs/session-monitoring/archived-sessions), enter any values in the **User** and **Password** fields — they're not actually used when the gMSA account is active, but the fields still require input.

    <Tip>
      Use **Test Database Connection** to confirm the Application Server can reach the archived database.
    </Tip>
  </Step>
</Steps>

## 3. Troubleshooting

<AccordionGroup>
  <Accordion title="EkranServer doesn't run under the gMSA account">
    <Steps>
      <Step title="Verify the account">
        ```powershell theme={"system"}
        Test-ADServiceAccount <your_gMSA_login>
        ```

        If this returns `False`, run:

        ```powershell theme={"system"}
        Install-ADServiceAccount -Identity <your_gMSA_login>
        ```
      </Step>

      <Step title="Reboot the domain controller">
        Restart the computer hosting the domain controller after creating the gMSA account.
      </Step>

      <Step title="Confirm Log on as a Service permissions">
        Open `secpol.msc` > **Local Policies** > **User Rights Assignment** > **Log on as a service**.
      </Step>

      <Step title="Export the master certificate">
        Export `EkranMasterCertificate`.
      </Step>

      <Step title="Open mmc as the gMSA account">
        ```bat theme={"system"}
        .\PsExec64.exe -i -u <your_gMSA_login> mmc
        ```

        For example:

        ```bat theme={"system"}
        .\PsExec64.exe -i -u "my.test\MyGmsa" mmc
        ```

        <Note>
          PsExec is part of the [PsTools suite](https://learn.microsoft.com/en-us/sysinternals/downloads/psexec).
        </Note>
      </Step>

      <Step title="Import the master certificate">
        Import `EkranMasterCertificate` into both **Personal** and **Trusted Root Certification Authorities**.
      </Step>
    </Steps>
  </Accordion>

  <Accordion title="Selecting &#x22;Use process credentials&#x22; loses the database connection and EkranServer will not start">
    <Steps>
      <Step title="Check registered SPNs">
        Confirm `MSSQLSvc/<SQLServerFQDN>` is registered for the gMSA account. Use [Microsoft Kerberos Configuration Manager for SQL Server](https://techcommunity.microsoft.com/blog/sqlserver/released-microsoft-kerberos-configuration-manager-for-sql-server-v3-1/385138) to check and fix SPNs, or run manually:

        ```bat theme={"system"}
        setspn -S MSSQLSvc/<SQLServerFQDN> <your_gMSA_login>
        ```

        For example:

        ```bat theme={"system"}
        setspn -S MSSQLSvc/my-server.my.test:MSSERVER my\MyGmsa
        setspn -S MSSQLSvc/my-server.my.test:1433 my\MyGmsa
        ```
      </Step>

      <Step title="Verify the SPNs">
        ```bat theme={"system"}
        setspn -L <your_gMSA_login>
        ```
      </Step>

      <Step title="Grant SPN write permissions">
        In **Active Directory Users and Computers**, enable **Advanced Features**, open the properties of the computer running **EkranServer**, and on the **Security** tab grant the gMSA account (or its AD group) **Validated write to service principal name**, plus **Read servicePrincipalName** and **Write servicePrincipalName**.
      </Step>

      <Step title="Grant the same permissions to SELF">
        For the group specified as `PrincipalsAllowedToRetrieveManagedPassword`, add **Read** and **Write** permissions for the **SELF** account the same way.
      </Step>

      <Step title="Fix error 18456, Severity 14, State 38">
        If this error appears in SQL Server logs, log in to SSMS as `sa`, open the SQL Server properties, and on the **Permissions** page grant **Control server** to the gMSA account.
      </Step>
    </Steps>
  </Accordion>
</AccordionGroup>

<Warning>
  `EkranServer`, `EkranMasterCertificate`, and the default install path are literal system identifiers, preserved verbatim from source.
</Warning>

## Related

<CardGroup cols={2}>
  <Card title="Database parameters" icon="database" href="/docs/administration/database/database-parameters">
    Configure the database connection and binary storage location.
  </Card>

  <Card title="Windows Authentication and NTLM" icon="shield" href="/docs/administration/database/windows-authentication-ntlm">
    An alternative fix for NTLM-related authentication errors.
  </Card>

  <Card title="Master certificate" icon="key" href="/docs/administration/security/master-certificate">
    Export and import the certificate referenced in troubleshooting above.
  </Card>
</CardGroup>