External Activator security

This short post deals with security and permission-related aspects of External Activator.

Selecting External Activator service account

When you install External Activator, you are asked to choose the service account (the Windows account that External Activator service will run as). The choice is from well-known Windows service accounts and a custom user with a password. For more information on the well-known accounts, please refer Sql Server Books Online or MSDN pages. The recommended service account for External Activator is a local or domain user.

Local security groups created by External Activator

The External Activator setup application will also create one or two (depending on the Operating System) local security groups for administrative purposes.

The first group, SSB EA Admin, is created regardless of the OS used. Members of this group have permission to start/stop the service, view the trace (log) file and modify the configuration file. The purpose of this group is to provide sufficient privilege separation so that the user(s) configuring and running External Activator doesn’t have to be a box admin.

The second group, SSB EA Service, is only created on down-level OSes and its purpose is to make changing External Activator’s service account easier (more on that below).

Changing External Activator’s service account

On newer OSes (starting from Vista/Server 2008) changing External Activator’s service account is as simple as setting the new account in Services MMC snap-in (Win-R –> services.msc). The reason it works is that ACLs on External Activator’s files are created based on Service SID, which is independent of service’s “real” service account (more about Per Service SID can be found here). On down-level OSes using the Services MMC snap-in is not enough, because changing the External Activator’s service account there won’t automatically change the file ACLs to the new account. This is something you need to do yourself, but in order to make it easier, the SSB EA Service local group has been introduced. The files are ACLed to be accessible by members of SSB EA Service group rather than by the External Activator’s service account directly. Therefore, when changing service account, it’s enough to add the new account to that group (and possibly remove the old one), without the need to actually touch any file ACLs. You can do that from a command line window:

net localgroup “SSB EA Service” /add “<new account name>”
net localgroup “SSB EA Service” /delete “<old account name>”

Local security groups created by External Activator

One of the previous posts provided a detailed description of all the Sql Server permissions that External Activator needs in order to work properly. It all starts with creating a Sql Server login for External Activator to use. There are several options how this login may be created, depending on the topology of the services:

1. External Activator runs on a machine in different domain from the machine hosting Sql Server. Even though External Activator doesn’t support Sql authentication when connecting to the notification service, you can still make connections across domain boundaries. The trick is to use “mirrored accounts”, which boils down to creating a local/domain windows user on the database server with the same username and password as the External Activator’s service account. The service account must be a local or domain user (you can’t use e.g. NT AUTHORITY\NETWORK SERVICE). Once you create a Sql Server login from that user and grant necessary Sql Server permissions to that login, External Activator will be able to connect, even from outside of the database server’s domain.
2. External Activator runs on different machine from Sql Server, but both machines are in the same domain or in trusted domains.
1. If External Activator runs as NT AUTHORITY\NETWORK SERVICE or NT AUTHORITY\SYSTEM, the login may be created from machine account (e.g. MyDomain\EaMachine$ - note the dollar sign necessary for machine accounts).
2. If External Activator runs as domain user, the login may be created from that user directly (e.g. MyDomain\EaUser).
3. If External Activator runs as local user, you have to resort to using mirrored accounts as described above.
4. NT AUTHORITY\LOCAL SERVICE is not supported as External Activator service account in a multi-machine deployment.
3. External Activator runs on the same machine as the Sql Server it’s connecting to. In this case, in addition to the above possibilities, you can also use the following:
1. If External Activator runs as local user, the login may be created from the local user (e.g. MachineName\EaUser).
2. If the OS is Vista or higher, the login may be created using the service SID (i.e. NT SERVICE\SSBExternalActivator).
3. If the OS is older than Vista, the login may be created using the SSB EA Service local group (i.e. MyMachine\SSB EA Service). Note however that it won’t work if External Activator runs as NT AUTHORITY\SYSTEM. Local system is a special account and even if it belongs to SSB EA Service security group, that group’s token won’t be passed to Sql Server when External Activator tries to log in, hence the login will fail.
   
   The advantage of using Service SID/SSB EA Service group as a base for Sql login is that nothing needs to be done on Sql Server side when External Activator’s service account is changed.