Introduction
By default the vSEC:CMS service runs under the local Windows SYSTEM account. It may be required to change this so that a dedicated Windows domain account is used for the vSEC:CMS service to run under. This article will cover how you can configure the vSEC:CMS service to run under a dedicated Windows account.
Configure Dedicated Windows Account
Follow the instructions here to configure the vSEC:CMS Service to run under a dedicated Windows account.
Create Windows Domain Account
The Windows account does not need to be a specific type; therefore, domain user type is sufficient but you will need to configure specific permissions for this account as described below in the section Configure Windows Permissions.
It is recommended to configure the Windows account password to never expire. If the dedicated Windows account password is not configured to never expire then the vSEC:CMS service will fail to start if the Windows password is changed.
If the Windows account used is a Windows group Managed Service Account (gMSA) then it will not be possible to issue an Enrollment Agent (EA) if a Microsoft CA is used if you are using server-side EA signing in the CA connection configuration. The only option in this case is to generate a .pfx for the service account and import the certificate in this case into the local user certificate store on the server where vSEC:CMS is installed.
Configure vSEC:CMS Service
1. Once a dedicated Windows account is created, open up Windows service, services.msc, and stop the service vSEC:CMS Service.
2. Right click the service vSEC:CMS Service and select Properties.
3. Go to the Log On tab and select This account radio button. Manually enter the Windows user account name created in Step 1.
The Windows account name should be entered in the Windows account format pre-2000. For example, if the Windows account name is cms_service and the domain name is my-lab, therefore the account name should be entered as: my-lab\csm_service. If the account name is not entered in this format the CMS service may not start automatically after a server restart.
If you are using other vSEC:CMS services you should leave them all to run under Local SYSTEM.
Configure Windows Permissions
It will be required to give full control (allow all permissions) to the dat folder and all files and folders within it to the Windows user account that the service is running under. The dat folder will typically be located in the location where the vSEC:CMS was installed, typically C:\Program Files (x86)\Versasec\vSEC_CMS S-Series for 32-bit, and C:\Program Files\Versasec\vSEC_CMS S-Series for 64-bit, if the default location was chosen during installation. Typically, these permissions can be granted by following the steps below, but these steps may not be applicable in your environment. Therefore, consult with your Windows IT administrator who should be able to set these if you do encounter issues with this.
1. Right click the dat folder and select Properties.
2. Go to the Security tab and click the Edit button and add the specific Windows user account created. Give the user full control and click Apply.
3. Additionally, it will be necessary to configure specific permissions to a registry folder for this Windows account. Open registry editor using regedit and browse to below location for 32-bit version:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
Or below for 64-bit version:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
Right click on the Service folder and select Permissions. Click the Add button and add the Windows user created and give them full control. Click Apply and close.
4. Start the vSEC:CMS Service from the Windows service. Now the vSEC:CMS service will run under the dedicated Windows account.
If the vSEC:CMS does not startup and shows an error that the database specified does not exist this is typically because the Windows user account cannot access the dat folder and/or cannot write/execute in the dat folder. Make sure that the Windows user account can access and read/write/execute in this folder.
Additionally, check that the registry key below is set to a value of 0 on 32-bit version:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service\autorecover]
Or below for 64-bit version:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service\autorecover]
If the vSEC:CMS is configured to use MS SQL as the database and MS SQL is required to use the Windows dedicated account for the connection then it will be required to add the dedicated Windows account to the MS SQL database table with full read, write permissions.
If the vSEC:CMS is configured to use MS CA it is required that the dedicated Windows account has permissions on the CA to revoke certificates. For example, in the Windows certsrv console right click the CA and select Properties. Then from the Security tab ensure that the dedicated Windows user account is in a Group or user list with minimum permission of Issue and Manage Certificates.
Comments
0 comments
Please sign in to leave a comment.