Service Account

The Service Account page in the Tagnet Admin Console sets the Windows account the Tagnet service logs on as. It matters for one reason: with Windows Authentication, SQL Server sees the service's account, not yours. The installer default, LOCAL SERVICE, has no identity on the network, so a SQL Server on another computer refuses it every time.

The page requires administrator rights; click Restart as administrator if prompted. Tagnet upgrades keep whatever account you set here.

Which account to choose

Option	Password	Use it when
LOCAL SERVICE	None	The database is SQLite, or SQL Server uses SQL Server Authentication. The installer default.
Windows account	Applied once, stored by Windows	SQL Server uses Windows Authentication and your domain provides a service account with a password (a local account on the Tagnet server also works for a SQL Server on the same machine).
Group Managed Service Account (gMSA)	Managed by Windows	SQL Server uses Windows Authentication and your Active Directory administrator can create a gMSA. Preferred: no password exists anywhere, and nothing needs re-entering when passwords rotate. Needs a domain controller reachable whenever the Tagnet server restarts; see If a domain controller is not available at startup.

The console never keeps a password. For a Windows account it checks the password once, applies it to the service, and discards it; Windows stores it with the service configuration, the same place services.msc puts it.

Before you start

• Create the SQL Server login first when the database uses Windows Authentication: CREATE LOGIN [CORP\svc-tagnet] FROM WINDOWS for a user, CREATE LOGIN [CORP\svc-tagnet$] FROM WINDOWS for a gMSA, then grant it the permissions listed in SQL Server Setup. Validate tests the connection as the account, so a missing login shows up before anything is changed.
• Install a gMSA on this computer first: Install-ADServiceAccount svc-tagnet, then Test-ADServiceAccount svc-tagnet. Your Active Directory administrator creates the account and allows this computer to retrieve its password.
• Set the account before switching Database Setup to Windows Authentication. Done in the other order, the service fails to start under LOCAL SERVICE and Database Setup reports a start failure. Database Setup shows the current service account next to the Windows Authentication option for this reason.

Changing the account

1. Open the Admin Console and click Service Account. The banner names the account the service runs as now.
2. Choose LOCAL SERVICE, Windows account, or Group Managed Service Account.
3. For a Windows account, enter it as DOMAIN\user or user@domain (a bare name means a local account on this computer) and its password. For a gMSA, enter DOMAIN\name; the trailing $ is optional.
4. Click Validate. The checks are described below. Fix anything marked as failed; warnings are things Save takes care of.
5. Click Save and restart and confirm. The service is stopped, the account is granted what it needs, the service is reconfigured, and it is started again. Readers cannot post while it is down, typically for well under a minute.
6. Read the result. On success the banner shows the new account. On failure, see When the service does not start.

What Validate checks

Check	What it verifies
Tagnet service	The service is installed on this computer.
Account	The account exists. For a Windows account, the password is correct. A wrong password is rejected at this check and stops the rest, so each Validate costs one failed attempt against your lockout policy, and Save repeats the checks before applying anything. For a gMSA, the account is installed on this computer.
Log on as a service	Whether the account already holds the right. If not, Save grants it. See Group Policy and "Log on as a service".
HTTPS private key	When HTTPS is enabled, whether the account can read the certificate's private key. If not, Save grants it, the same change as Manage Private Keys in certlm.msc.
Database access	When Database Setup uses Windows Authentication: for a Windows account, the console opens the configured connection as that account and reports the login SQL Server saw. A gMSA cannot be tested this way; the service starting after Save is its test. LOCAL SERVICE against a SQL Server on another computer is flagged as a warning: Save is allowed, as the way back from a broken account, but Tagnet will not reach its database until one side is changed.

What Save does

In order: stops the service, grants the account Log on as a service, grants it full control of C:\ProgramData\Stratum Global\Tagnet (with explicit grants on the data and logs folders and on appsettings.Production.json, which the installer sets up not to inherit, and on keys and secrets), grants it read access to the HTTPS private key when HTTPS is enabled, reconfigures the service, and starts it. When the service comes up, the previous account's access to the data folder is removed unless it was LOCAL SERVICE, which the installer relies on.

The change is recorded in the Tagnet Security Events log and in logs\admin-console.log under the data folder: who made it, when, and from which account to which. Passwords are never logged.

Updating the password

When a Windows account's password is changed in Active Directory, the running service keeps working until it next restarts, then fails to log on. Update the stored password before that happens:

1. Open Service Account. The current account is pre-selected.
2. Enter the new password and click Update password and restart.

The console checks the password, stores it on the service, and restarts the service. Nothing else changes. A gMSA never needs this.

When the service does not start

Save waits up to 60 seconds for the service to reach Running. If it does not:

• The previous account had no password (LOCAL SERVICE, a gMSA, or a virtual account): the console puts the previous account back and starts the service again, so Tagnet keeps running as before. The grants made for the new account (data folder, Log on as a service, private key) are removed.
• The previous account was a Windows account with a password: the console cannot restore it, because the password is no longer stored anywhere. The service stays configured for the new account. Fix the cause and save again, re-enter the previous account with its password, or, if Database Setup uses Windows Authentication, switch it to SQL Server Authentication and then choose LOCAL SERVICE here.

The Tagnet log in C:\ProgramData\Stratum Global\Tagnet\logs names the cause. A logon failure (event 7000 in the Windows System log, "The service did not start due to a logon failure") points at the password or the Log on as a service right. A SQL error points at the login or its permissions.

If you reverted to LOCAL SERVICE while Database Setup still uses Windows Authentication against a remote SQL Server, the service keeps failing until one of the two is changed.

Group Policy and "Log on as a service"

Save grants the right on this computer. If your domain assigns Log on as a service through Group Policy, that policy replaces the local list at the next refresh, the grant disappears, and the service stops starting, often days later. Add the account to the policy as well. The Validate result reminds you of this whenever the right is involved.

If a domain controller is not available at startup

Tagnet waits for its database however long it is unavailable (see Startup type and recovery), and that includes a domain controller that Windows Authentication cannot reach: the log shows Could not sign in to database server ... or, when the domain controller is also your DNS server, Database server ... cannot be reached, and Tagnet starts on its own once the domain controller answers. What differs by account is whether Windows can start the service at all.

Account	Tagnet server restarted while no domain controller answers
LOCAL SERVICE, or SQL Server Authentication	Not affected: the account does not need the domain.
Windows (domain) account	Windows signs the service in with the credentials it cached at the last successful sign-in. Tagnet starts, waits for the database, and is available within seconds of the domain controller returning.
gMSA	Windows cannot sign a gMSA in without a domain controller: the service does not start (System log events 7038, "The specified domain either does not exist or could not be contacted", and 7000). The automatic restarts try twice more, a minute apart, and then the service stays stopped, even after the domain controller returns, until someone starts it.

With a Windows account, restarting only the Tagnet service while the domain controller is down is fine too. With a gMSA it worked shortly after the domain controller went away, but do not rely on it during a long outage: the difference that matters is the whole server restarting, for example after patching.

With a gMSA, then:

• Make sure a domain controller is reachable whenever the Tagnet server restarts: a second domain controller, or patching the Tagnet server after the domain controllers rather than alongside them.
• If the server can restart while no domain controller is available (a site that restarts everything at once, or an unreliable link to the domain), use a Windows account instead. It keeps Tagnet recovering on its own, at the cost of a password to update here whenever it rotates.
• After an outage, check the service on the Services page, and start it if it is stopped.

Troubleshooting

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'" in the Tagnet log. SQL Server did not receive an identity. The service is running as LOCAL SERVICE (or another account with no network identity) against a remote SQL Server. Set a Windows account or gMSA here.

"Login failed for user 'CORP\svc-tagnet'". The identity arrived but SQL Server has no login for it, or the login has no access to the Tagnet database. Create the login and grant it the permissions in SQL Server Setup.

Validate says the gMSA is not installed on this computer. Run Install-ADServiceAccount on the Tagnet server, and confirm the account's PrincipalsAllowedToRetrieveManagedPassword includes this computer.

After a restart the service is stopped, and the System log shows event 7038 "The specified domain either does not exist or could not be contacted". The service runs as a gMSA and no domain controller answered when the server started. Start the service once the domain controller is back; see If a domain controller is not available at startup to avoid it.

The service started fine and stopped starting days later. See Group Policy and "Log on as a service", or, for a Windows account, a password rotated in Active Directory that was not updated here.

Diagnostics shows a different account than expected. The Service section of the Diagnostics page reads the account from the service configuration. If it shows LOCAL SERVICE marked as assumed, the configured account could not be resolved from this computer, usually because the domain is unreachable. The Service Account page's banner shows the account name as registered, with the reason it could not be resolved.