If you are like me, you probably aren’t a huge fan of Kerberos, but it does have some advantages. When using an Active Domain (AD) account as a service account, it is handy to reduce the attack vector by minimising the chosen Domain Account’s permissions and privileges.
If you are using a Domain Account as a service account for Microsoft SQL Server, for example, it’s highly likely that you will want the chosen service account to be able to automatically register and unregister Service Principal Names (SPNs) automatically when the service is started and stopped. To avoid giving the account far reaching permissions (such as domain administration rights) you’ll be required to do some editing of the Domain Account’s ADSI properties.
This isn’t as daunting as it sounds (trust me). Below are some articles worth reading – don’t be afraid to allow the account the ability to read and write service names. In case you are in a hurry, here’s exactly what you must do to allow a Domain Account the ability to automatically register SPNs for services (from link #2, below) :
- Click Start, click Run, type Adsiedit.msc, and then click OK.
Note The ADSIEdit tool is included in the Windows Support Tools. To obtain the Windows Support Tools, visit the following Microsoft Web site:
- In the ADSI Edit snap-in, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN= AccountName , and then click Properties.
Notes- DomainName is a placeholder for the name of the domain.
- RootDomainName is a placeholder for the name of the root domain.
- AccountName is a placeholder for the account that you specify to start the SQL Server service.
- If you specify the Local System account to start the SQL Server service, AccountName is a placeholder for the account that you use to log on to Microsoft Windows.
- If you specify a domain user account to start the SQL Server service, AccountName is a placeholder for the domain user account.
- In the CN= AccountName Properties dialog box, click the Security tab.
- On the Security tab, click Advanced.
- In the Advanced Security Settings dialog box, make sure that SELF is listed under Permission entries.
If SELF is not listed, click Add, and then add SELF. - Under Permission entries, click SELF, and then click Edit.
- In the Permission Entry dialog box, click the Properties tab.
- On the Properties tab, click This object only in the Apply onto list, and then click to select the check boxes for the following permissions under Permissions:
- Read servicePrincipalName
- Write servicePrincipalName
- Click OK two times.
Note For help with this process, contact Active Directory product support, and mention this Microsoft Knowledge Base article.
Note To use the dsacls tool to determine if the self account has the Write ServicePrincipalName permission, use the dsacls command. The following is the syntax:dsacls <distinguished_Name_of_service_account>
If the self account has the Write ServicePrincipalName permission, you see the following output:
Allow NT Authority\SELF SPECIAL ACCESS for Validated Write to Service principal name
WRITE PROPERTYThe dsacls tool is part of the Support Tools.
- In the CN= AccountName Properties dialog box, click Attribute Editor.
- Under Attributes, click servicePrincipalName in the Attribute column, and then click Edit.
- In the Multi-valued String Editor dialog box, remove the service principle names (SPNs) for the instances of SQL Server that use this SQL Server service account.
Warning You should only delete the SPNs for the instances of SQL Server that you are currently working on. The other instances of SQL Server that use this service account will be able to remove the SPNs that are related to these instances the next time that you start these instances. - Exit the ADSI Edit snap-in.
Leave a comment is this helped or hindered you! Cheers..R
Further Reading is Recommended
[1] http://msdn.microsoft.com/en-us/library/ms191153.aspx
[2] http://support.microsoft.com/kb/319723
