The Lighthouse service account

Lighthouse runs as one Windows account: the Windows service Lighthouse, or the IIS app pool when it runs as a website. Everything the server does on its own happens as that account: it signs in to SQL Server, reads and issues at ADCS, reads Active Directory for Windows sign-in, opens the private keys of its certificates, and connects to Windows servers over WinRM for Windows Installations that have no account of their own (see Windows Installations: a separate install account). This guide is for the administrator who sets that account up: which kind to choose, how to create it, every right it needs, how to give it to the installer, how to check it works, and what the usual errors mean.

Each organization is different, so Lighthouse supports four kinds of account:

Not supported: LocalSystem, NT AUTHORITY\NetworkService and NT AUTHORITY\LocalService (far more power than Lighthouse needs, or shared with every other service), a person's own account, any member of Domain Admins or Administrators, and cloud-only Entra ID accounts (Windows cannot run a service as one). A standalone managed service account (sMSA, also ending in $) works like a gMSA on a single server.

Every right, in one place

Required rows apply to every server. When used rows apply only when you turn the feature on or use it. The last column says who gives it: "Setup" means the installer does it for you, as the person installing, with no extra step.

Required

When used

Windows Installations: a separate install account

Keyfactor and Venafi let their IIS and Windows automation sign in as any account that is an administrator on the target, kept apart from the product's own service account, with its password stored encrypted. Lighthouse does the same, and we recommend it over giving the service account administrator rights on your servers.

Why a separate account. Lighthouse's service account already reads and writes the database, issues at the CA and opens its own keys. If it were also an administrator on every IIS, SQL and Exchange server, anyone who got hold of it (or of the Lighthouse server) would hold all of that at once. With a separate install account per group of servers, the service account keeps only what Lighthouse itself needs, and one leaked install password reaches one group of servers and nothing else. Each account can also be turned off, audited and rotated on its own.

How it is set. On an IIS site, another Windows use or Files on Windows Installation, under Sign in as, give the Account and the Password secret name. Leave both empty and Lighthouse signs in as its service account (or the Outpost's), as before. Through the API they are signInAs and signInPasswordSecret in the job's parameters. Only administrators make and change Windows Installations; the Keeper's Log records each change with the account's name.

Step by step

1. Make the account, one per group of servers (web servers, SQL servers, Exchange). A domain user is best:

   New-ADUser -Name lh-install-web -SamAccountName lh-install-web -AccountPassword (Read-Host -AsSecureString "Password") `
     -Enabled $true -PasswordNeverExpires $false -AccountNotDelegated $true -Description "Lighthouse installs on web servers"
   

   -AccountNotDelegated is Account is sensitive and cannot be delegated: its sign-in can never be passed on to another server. Deny it interactive sign-in through Group Policy (Deny log on locally, Deny log on through Remote Desktop Services). It may go in Protected Users when it is a domain account, since Lighthouse signs it in with Kerberos only. Or a local account on each server, with the same name and password on each server in the group, written .\name in Lighthouse.
2. Make it an administrator on those servers only, never in Domain Admins. With a group, so new servers are one step: a domain group Lighthouse Install Web holding the account, added to the local Administrators group of each web server by Group Policy (Restricted Groups, or Local Users and Groups), or by hand: Add-LocalGroupMember -Group Administrators -Member "CONTOSO\lh-install-web".
3. Let WinRM in, as for any Windows Installation (Enable-PSRemoting on Windows Server, TCP 5985 or 5986 from the computer that does the work). For a local account that is not the built-in Administrator, also set LocalAccountTokenFilterPolicy: New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1 -PropertyType DWord -Force.
4. Store the password, on the computer that does the work:
   • The Lighthouse server: as an administrator there, lh secret set windows-web-servers (it asks without echo). The secret is encrypted with DPAPI for that computer under %ProgramData%\Lighthouse\secrets, or, on a group of servers, sealed to the group certificate in the database, so every server can use it.
   • An Outpost: in the console, Settings, Outposts, the Outpost, Secrets, where it is sealed in the browser to that Outpost's key, or on the Outpost's computer lh-outpost secret set windows-web-servers. It never comes to Lighthouse.
5. Name it on each Installation under Sign in as: CONTOSO\lh-install-web and windows-web-servers.
6. Try it with a Replace-All Drill dry run: the Windows check signs in as the account, says so, and changes nothing.
7. Take the service account's rights away on those servers once every Installation there has its own account: remove it (or CONTOSO\WEB01$ for the built-in account) from their Administrators group.

How Lighthouse uses it

• Only the account's name and the secret's name are kept with the Installation. The password is read from the secret store for the run and never written to the database, a log, the Keeper's Log or an error.
• It reaches PowerShell in the environment of the one PowerShell process that runs the step, which takes it out at once: never on a command line (which a process list shows) and never in the script's text (which PowerShell's script block logging, event 4104, records).
• It always signs in over WinRM, even to the server Lighthouse runs on. A domain account (DOMAIN\name or name@domain) uses Kerberos only, so its password is never offered to a computer outside the domain: give the server by its full DNS name, not an address. A local account (.\name, or SERVER\name with the server's own name) uses Negotiate: the server must be in WinRM's TrustedHosts on the computer that does the work, or have a WinRM https listener.
• CredSSP is never used, so there is no second hop: the account can do what it may on that server and nothing beyond it.
• A shell that cannot sign in as the account refuses the step. Lighthouse never falls back to its own account for an Installation that names one, and an Outpost older than this version refuses the work rather than run it as its own account.

Changing the password

Change it in Active Directory (or on each server for a local account), then set the secret again with the same name: lh secret set windows-web-servers, or the Outpost's Secrets. Every Installation that names it uses the new password on its next run.

Option 1: a group managed service account (recommended)

A gMSA is a domain account whose password Active Directory makes and changes by itself. Only the computers you name can fetch it, nobody can sign in with it interactively, and there is nothing to expire, lock out or forget.

What you need first: a domain controller on Windows Server 2012 or later, and the Active Directory module for PowerShell on the Lighthouse server (Install-WindowsFeature RSAT-AD-PowerShell).

1. Once per forest, the KDS root key. If your domain has never had a gMSA, a domain admin runs this on a domain controller, then waits 10 hours so every domain controller has it:

   Get-KdsRootKey            # nothing listed: no key yet
   Add-KdsRootKey -EffectiveImmediately
   

2. A group for the servers that may use it (easier to add a second server later):

   New-ADGroup -Name "Lighthouse Servers" -GroupScope Global -GroupCategory Security
   Add-ADGroupMember "Lighthouse Servers" -Members "WEB01$"
   

3. The account:

   New-ADServiceAccount -Name gmsa-lighthouse -DNSHostName gmsa-lighthouse.contoso.com `
     -PrincipalsAllowedToRetrieveManagedPassword "Lighthouse Servers" `
     -KerberosEncryptionType AES128,AES256 -Description "iRonShore Lighthouse"
   

4. On the Lighthouse server, restart it (so its new group membership counts), then:

   Install-ADServiceAccount gmsa-lighthouse
   Test-ADServiceAccount gmsa-lighthouse     # True
   

5. CA rights (only for the ADCS features you use): in certsrv.msc, right-click the CA, Properties, Security, Add. In the picker, choose Object Types and tick Service Accounts (gMSAs are hidden otherwise), enter gmsa-lighthouse, and tick Read, and Request Certificates to issue, and Issue and Manage Certificates to revoke. In certtmpl.msc, each template's Properties, Security: add it the same way with Read and Enroll.
6. Kerberos for Windows sign-in (optional; NTLM works without it):

   setspn -S HTTP/lighthouse.contoso.com CONTOSO\gmsa-lighthouse$
   

   In IIS, also: %windir%\system32\inetsrv\appcmd.exe set config "Lighthouse" -section:system.webServer/security/authentication/windowsAuthentication /useAppPoolCredentials:true /commit:apphost. Check it after each upgrade.
7. Install. On the setup screens, How Lighthouse runs: choose Domain service account with no password to manage (gMSA) and type CONTOSO\gmsa-lighthouse$. Setup checks that this computer may use it. Silently: SERVICEACCOUNT=CONTOSO\gmsa-lighthouse$.

Option 2: a domain user account

A normal Active Directory user, used only by Lighthouse. It works everywhere a gMSA does. The difference is the password: you keep it, you change it, and Windows needs it on every install, upgrade and repair, because the service or app pool is set up again each time. Lighthouse never saves the password: Windows keeps it for the service (as it does for every service), and IIS keeps it encrypted in its own configuration for the app pool.

1. Make the account. A long random password (25 characters or more) from your password vault:

   New-ADUser -Name "svc-lighthouse" -SamAccountName svc-lighthouse `
     -UserPrincipalName [email protected] -Description "iRonShore Lighthouse service" `
     -AccountPassword (Read-Host -AsSecureString "Password") -Enabled $true `
     -PasswordNeverExpires $true -CannotChangePassword $true
   Set-ADAccountControl svc-lighthouse -AccountNotDelegated $true
   

   If your policy does not allow Password never expires, plan the change in Changing the password before the password expires: the service keeps running, but will not start again with an expired password.
2. Keep it a service account. Do not add it to Administrators or Domain Admins (except Administrators on Windows servers it installs on as itself, below; better, give those Installations a separate install account). Deny it interactive sign-in through Group Policy (Deny log on locally, Deny log on through Remote Desktop Services). Do not put it in Protected Users: that group stops the NTLM and the cached sign-ins a service needs.
3. Log on as a service. Setup gives it on the Lighthouse server. If a Group Policy sets Log on as a service on your servers, add the account to that policy, or setup's change is undone at the next policy refresh and the service will not start after a restart.
4. CA rights, as for a gMSA in step 5 above, but the picker finds the user without changing Object Types.
5. Kerberos for Windows sign-in (optional): setspn -S HTTP/lighthouse.contoso.com CONTOSO\svc-lighthouse, and useAppPoolCredentials in IIS as above.
6. Install. On the setup screens, How Lighthouse runs: choose Domain user account with a password, type CONTOSO\svc-lighthouse and its password. Setup signs in as the account to check the password, and stops with the reason if it is wrong, expired, disabled or locked out. Silently:

   msiexec /i Lighthouse-0.37.0-x64.msi /qn /l*v lighthouse-install.log ^
     SERVICEACCOUNT=CONTOSO\svc-lighthouse SERVICEPASSWORD="<password>" ...
   

   SERVICEPASSWORD stays out of the MSI log and out of answer files, and is never written to the settings file. A command line is kept in your shell history, so prefer the screens, or a deployment tool's secret variable.
7. Upgrades and repairs. A double-click upgrade or a repair shows one screen, Service account password, and checks it before anything changes. A silent upgrade needs SERVICEPASSWORD again: without it, setup stops with that reason and rolls back, leaving the old version running.

Changing the password

1. Change it in Active Directory.
2. On every Lighthouse server, straight away (the old password, tried again and again, can lock the account out):
   • Windows service: services.msc, iRonShore Lighthouse, Log On, type the new password twice, OK, then restart the service.
   • IIS: IIS Manager, Application Pools, Lighthouse, Advanced Settings, Identity, the ... button, Set, type the new password, OK, then Recycle.
   • Or run the same MSI again with SERVICEPASSWORD="<new password>", which checks it and sets it either way.
3. Check Settings, Application, Servers: every server shows up again.

Option 3: the built-in account

NT SERVICE\Lighthouse (for the Windows service) and IIS APPPOOL\Lighthouse (for the app pool) are made by Windows for Lighthouse alone and have no password. On this server they are their own account. Towards any other computer they are the server's computer account, CONTOSO\WEB01$, so every right Lighthouse needs elsewhere goes to the computer:

• SQL Server on another computer: the login is CONTOSO\WEB01$. Setup makes it for you when the database is elsewhere. With SQL Server on the same computer, the login is the built-in account itself.
• ADCS: in the CA's and the templates' Security tabs, choose Object Types, tick Computers, and add WEB01.
• WinRM: add CONTOSO\WEB01$ to Administrators on each web server.
• Kerberos: Windows already has HTTP/WEB01.contoso.com on the computer. For another name, setspn -S HTTP/lighthouse.contoso.com WEB01.

Choose it for a trial, or for one server whose computer account nobody else uses for anything sensitive. Anything else on the server that uses the network as the computer (other services running as the built-in, Network Service or a virtual account) gets the same CA and SQL rights. With two or more servers, each computer account needs its own rights. To install: the default on the setup screens, or leave out SERVICEACCOUNT.

Option 4: a server that is not in a domain

Without Active Directory, there is no ADCS, no Windows sign-in for domain users and no WinRM with Kerberos. Use an OpenID Connect provider for sign-in (see Sign-in providers), EJBCA, Vault or a public CA for issuing, and SSH, appliances or cloud vaults for installs. Two ways to run it:

• The built-in account, with SQL Server on the same computer (SQL Server Express is enough for a small inventory). Nothing to set up.
• A local account, when SQL Server is on another computer through a SQL login, or when your policy asks for a named account:

  New-LocalUser -Name lighthouse -Description "iRonShore Lighthouse service" `
    -Password (Read-Host -AsSecureString "Password") -PasswordNeverExpires -AccountNeverExpires
  

  Do not add it to Administrators. On the setup screens choose Domain user account with a password and type .\lighthouse (setup writes it as WEB01\lighthouse). Silently: SERVICEACCOUNT=WEB01\lighthouse SERVICEPASSWORD="<password>". With SQL Server on another computer, give a SQL login in the connection: CONNECTION="Server=sql01;Database=Lighthouse;User ID=lighthouse;Password=<password>;Encrypt=true". Setup then grants nothing in SQL Server (the DBA gives that login db_datareader and db_datawriter), and the connection is kept in the settings file, which only SYSTEM, Administrators and the account can read. Setup refuses a local account with Windows sign-in to SQL Server on another computer, since that computer cannot know the account.

Changing to another account later

1. Give the new account its rights first (CA, WinRM, SPN; setup makes its SQL login).
2. Run the installed version's MSI again with the new account:

   msiexec /i Lighthouse-0.37.0-x64.msi REINSTALL=ALL REINSTALLMODE=vomus SERVICEACCOUNT=CONTOSO\gmsa-lighthouse$
   

   Add SERVICEPASSWORD="<password>" for a domain user or local account. Setup gives the new account the settings file, folders and keys.
3. Check the server, then take the old account's rights away.

Checking that it works

• %ProgramData%\Lighthouse\setup.log lists every step setup took, with the account.
• The service: Get-CimInstance Win32_Service -Filter "Name='Lighthouse'" | Select-Object StartName, State.
• The app pool: %windir%\system32\inetsrv\appcmd.exe list apppool Lighthouse /text:processModel.userName.
• A gMSA: Test-ADServiceAccount gmsa-lighthouse on each server says True.
• SQL Server: the console opens and Settings, Application, Servers lists the server as up.
• ADCS: Settings, CAs, the CA, Test connection; then enroll a test certificate from an ADCS template.
• Windows sign-in with Kerberos: on a PC, sign in to Lighthouse, then klist shows a ticket for HTTP/lighthouse.contoso.com.

Common errors and what to do

For a DBA

When the person installing may not add logins, a DBA runs this once (change the account and database names), then the install can go on. For the built-in account with SQL Server elsewhere, the login is the computer, such as CONTOSO\WEB01$.

CREATE LOGIN [CONTOSO\gmsa-lighthouse$] FROM WINDOWS;
GO
USE [Lighthouse];
CREATE USER [CONTOSO\gmsa-lighthouse$] FOR LOGIN [CONTOSO\gmsa-lighthouse$];
ALTER ROLE db_datareader ADD MEMBER [CONTOSO\gmsa-lighthouse$];
ALTER ROLE db_datawriter ADD MEMBER [CONTOSO\gmsa-lighthouse$];
-- Once the database has its tables (after the first install), as setup does:
DENY UPDATE, DELETE ON OBJECT::dbo.AuditEvents TO [CONTOSO\gmsa-lighthouse$];

The person installing still needs dbcreator (or db_owner on an empty database the DBA made) to create and upgrade the schema, or installs with MIGRATE_DB=0 and the DBA runs lh db migrate.