How To: Determine the Minimum Permissions Required for a SecureAuth Service Account

Version Affected: All

Overview

SecureAuth service accounts fall into two categories depending on what they connect to, and each needs its own limited set of permissions rather than broad administrative rights:

An Active Directory (AD) service account — used by realms that authenticate users and read or write their AD profile attributes.
A SQL Server Integrated Security service account — used when a realm's Datastore, or SQL Logging/Reporting, connects to SQL Server as a Windows account instead of a local SQL account.

This article covers determining, granting, and migrating to the minimum permissions for each.

Any authenticated AD account has Read access to other AD user objects by default. This is all a service account needs if its realms only authenticate users and never update AD -- for example, a SAML or RADIUS realm with no Device Fingerprinting, no QR/URL enrollment, and no password reset in use. If you want to restrict even this default Read access, that requires explicitly denying Read permissions, which is outside the scope of this article.

Write access is different: it must be granted individually, per AD attribute, based on which Profile Properties are mapped to AD attributes and marked writable in each realm's configuration. See SecureAuth's Service Account Setup and Configuration Guide for the official, version-specific list of Profile Properties and their recommended attribute mappings.

Common Feature-to-Attribute Write Requirements

As a starting point, the following SecureAuth features typically require Write access to whichever AD attribute is mapped to the listed Profile Property. Only add Write access for the features you actually use:

Device Fingerprinting (DFP) -- the attribute mapped to the DFP Profile Property (commonly audio, though this varies by environment).
QR Code or URL enrollment -- the attributes storing the OATH Token, OATH Seed, Push Notification Token, and/or Hardware Token, depending on which methods are enrolled.
One-Time Passcode (OTP) via a One Time OATH List -- the attribute mapped to that Profile Property.
OpenID Connect (OIDC) realms -- the attribute used for Consent Storage.
Login for Windows and RADIUS realms -- these commonly map an AuxID Profile Property to OTP Validation, which is in turn mapped to an AD attribute on the Data tab; Write access is needed on that attribute.
Self-Service or Account Management realms -- attributes such as name, phone number, or email address, if the realm allows users to update them.
Password Reset or Account Unlock -- only relevant if these features are actually enabled for the realm; skip them entirely if they are not in use.

Avoid using a broad built-in group such as Account Operators as a shortcut -- it grants far more than a SecureAuth service account needs.

If any accounts that will log in are members of a protected admin group, AD's AdminSDHolder protection can block the service account from updating them even if the Write permissions above are in place -- see Troubleshooting: Unable to Update AD Attributes for Privileged Accounts (AdminSDHolder) if this applies to your environment.

Audit Your Current Attribute Mappings

Rather than guess which attributes are already in use, audit every realm's current configuration. SecureAuth has a PowerShell script that decrypts each realm's web.config, reads every Profile Property using the LDAP Profile Provider, and exports a CSV listing each realm alongside every Profile Property currently mapped to an AD attribute and whether it is set to writable, meant to be run on an IdP server that has access to all of the realm folders you want to audit. Contact SecureAuth Support to obtain a copy of this script.

In the resulting CSV, each row is a realm, and each column is a Profile Property. A non-empty Field value means that property is mapped to an AD attribute; a Write value of True means the realm can write to it. Together with the feature list above, this tells you exactly which AD attributes your environment actually needs Write access to -- and which mappings are leftover from a feature that is no longer in use.

Clean Up and Standardize Attribute Mappings

Once you know which attributes are actually needed, use the audit output to standardize the mappings across all of your realms and remove any that are no longer required. SecureAuth has a PowerShell script that applies a set of Profile Property values to the LDAPProfileProvider section of one or more realms' web.config files, backing up each original first, and lets you choose which Profile Properties to change and set each to the AD attribute (or blank, to remove the mapping) and Write value you want. Contact SecureAuth Support to obtain a copy of this script.

See the Service Account Setup and Configuration Guide for SecureAuth's recommended attribute for each Profile Property, and re-run the audit script afterward to confirm the changes took effect as expected.

Grant AD Permissions to the New Service Account

Create the new service account in AD, then grant it Write access to exactly the attributes identified in the previous steps. SecureAuth has a PowerShell script that adds, removes, or reads WriteProperty permissions for a specified account against a list of AD attributes, scoped to an organizational unit (OU) and optionally its sub-OUs; Add and Remove require typing a randomly generated confirmation string before making any change, Read only reports the existing permissions, and every run is logged to a text file alongside the script. Contact SecureAuth Support to obtain a copy of this script.

Run it with -Action Read first to confirm the current state before making any changes, then -Action Add to grant the permissions.

Additional Steps for Windows SSO (Kerberos)

If none of your realms use Windows SSO (Kerberos), skip this section entirely and go to Migrate Realms to the New Service Account.

If Windows SSO is in use, the new service account also needs:

Read permission on any certificates used by the Windows SSO realms.
A new Application Pool in IIS, with its Identity set to the new service account.
A Service Principal Name (SPN) assigned in AD that matches the realm's hostname -- see Configure WinSSO Realm to Use a Custom SPN for the full SPN assignment and Realm Configuration steps.

Testing has confirmed the service account does not need to be a member of the Local Administrators group on the IdP server(s) for Windows SSO to work. It does need the following local user rights, which can be applied via Group Policy or the Local Security Policy on each IdP server:

Log on as a batch job
Log on as a service
Replace a process level token
Adjust memory quotas for a process

IIS negotiates Kerberos first and falls back to NTLM automatically if Kerberos fails, so a working login does not necessarily mean Kerberos is being used -- NTLM will quietly cover for it. Check that Negotiate is listed above NTLM in the realm's IIS Authentication Providers, and if you need to confirm which mechanism is actually being used, see How To: Enable Additional Kerberos Logging to Diagnose SPN Issues.

You can also confirm which mechanism was used for a specific login directly from the browser, without needing access to the appliance's logs. Open the browser's developer tools to the Network tab and reload the login page. A 401 response on the first request to the realm is a fairly reliable sign that Kerberos is failing -- a successful Kerberos negotiation authenticates silently, with no visible 401.

If that first response includes a WWW-Authenticate response header that says Negotiate followed by a Base64-encoded token, run the following in the browser's console (replacing %TOKEN% with that value) to see whether the token is actually Kerberos, or NTLM riding inside the same Negotiate/SPNEGO header:

const raw = atob('%TOKEN%');

if (raw.includes('NTLMSSP')) {
  console.log('NTLM under SPNEGO');
} else {
  console.log('Kerberos AP-REQ');
}

An NTLM under SPNEGO result means the browser fell back to NTLM even though the header said Negotiate -- Kerberos itself is failing somewhere upstream (SPN, clock skew, delegation) and NTLM is quietly covering for it. A Kerberos AP-REQ result confirms Kerberos succeeded for that request.

Migrate Realms to the New Service Account

Migrate realms onto the new service account one at a time, rather than changing the Identity on an existing Application Pool that multiple realms already share -- that would move every realm in that pool over at once, with no ability to roll back a single realm if something is not configured correctly.

Create a new Application Pool in IIS (or reuse the one created for Windows SSO above), with its Identity set to the new service account.
In IIS Manager, move one realm's Web App into the new Application Pool.
On that realm's Data tab, update the credentials to the new service account.
Test that the realm authenticates users as expected.
Test that the realm's AD writes still work as expected -- for example, enroll a device if the realm uses Device Fingerprinting or supports enrollment.
Repeat for each remaining realm, confirming each one before moving to the next.

An Account Management or Enrollment realm is a good realm to migrate and test first, since those realm types typically exercise the widest range of AD attribute writes.

SQL

Configure the Windows Account for a SQL Integrated Security Connection

An Integrated Security connection to SQL Server — for either the Datastore connection or SQL Logging/Reporting — authenticates as the Windows account assigned to the realm's (or SecureAuth0's) Application Pool, which needs different, and more limited, permissions than a local SQL account. Before granting the SQL permissions below, configure that Windows domain account:

Join the SecureAuth IdP server to the domain the account belongs to, if it is not already joined.
In IIS, set the Application Pool Identity for both the .NET v4.5 and SecureAuth0 Application Pools to the domain account, and set Load User Profile to True.
Add the domain account to the local Administrators group on the SecureAuth IdP server(s), and confirm it has the Log on as a batch job user right.

Grant the Minimum SQL Permissions

At minimum, the account used for the Integrated Security connection needs:

CONNECT
EXECUTE

If SQL Reporting will also be used, also assign SELECT.

Assign these permissions to the database either directly, on the database's Properties - Permissions page, or by creating a new Role, assigning the permissions to the Role, and adding the account to that Role.

Whenever the account's permissions change in SQL, restart IIS (or just the affected Application Pool) on the IdP server(s) before testing the change.

Special Considerations

Always test these scripts, and any AD permission or web.config change, in a non-production environment first. The exact list of attributes your environment needs is unique to your realm configuration -- the audit script is how you determine it, rather than any fixed list in this article.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.