Search code examples
nservicebus

Does an NServiceBus endpoint with SQL Server transport and Windows authentication need to be installed as the user running the service?


I'm installing an NServiceBus 4.x endpoint which uses SQL Server transport. While running the installer (via Octopus Deploy, which runs as Local System by default)...

.\NServiceBus.Host.exe /install NServiceBus.Production /serviceName=$name /username:"$username" /password:"$password

... I get an error:

Failed to execute installers: System.Data.SqlClient.SqlException (0x80131904): Login failed for user 'DOMAIN\MACHINENAME$'.

This is the expected behavior if the installer connects to SQL Server when it's run: Local System becomes the computer account when it leaves the box and the computer account does not have access to the transport database.

However, I do not intend to run the endpoint as Local System. Instead, I intend to use a domain service account which does have access to the transport database, so...

Is it possible to install an NServiceBus endpoint using SQL Server transport as a user who does not have access to the transport database?

Bonus question: Has this behavior been changed in versions of NServiceBus later than 4.x?


Solution

  • The problem here is that the NServiceBus.Host.exe is executed with the credentials of as you say Octopus Deploy and /install runs the NServiceBus installers.

    Some alternatives:

    1. Run Octopus Deploy Agent with permissions that also allows doing schema changes on the database during this deployment phase.

    2. Instead of executing the host directly, launch a shell with different credentials so that the host is run with credentials that have appropriate permissions.

    3. Do not use the host, but use self-hosting. Register that service via sc.exe to register the windows service with the right credentials, and use endpointConfiguration.EnableInstallers() to control if installers must be run.

    4. Use self-hosting as in (3), don't use endpointConfiguration.EnableInstallers() but script all tasks and let these run independently of the 'windows service' registration task. Alternatively, you can instead use sc.exe to register the NServiceBus.Host.exe so that the /install will not be run.

    I would advise NOT to just always run endpointConfiguration.EnableInstallers() on an endpoint. You should distinguish between a deployment and runtime. During deployment you would create tables, schemas etc. but at runtime, that account should not have the permissions to create or drop tables and run least privilege.