My answer is probably based on new code which wasn't available when the original question was asked, but here it is:
When you do a net ads join, add the option "--no-dns-updates"
From "man net":
--no-dns-updates
Do not perform DNS updates as part of "net ads join".
I found it.
I manually registered the SPN to the service account, then inspected the AD with ADSIEdit, only to find that the manually-registered SPNs were not stored in the servicePrincipalName
field of the Computer account, but the servicePrincipalName
field of the specific User account.
So, instead of granting my SQL Servers
group rights to register their own SPNs, I had (inadvertantly) granted them the rights to alter the SPNs registered by services running as the Local System / Network Service accounts on that computer.
I have now removed the new ACE from the Computers
container and, instead, created a new SQL Servers
Organisational Unit. I have added an ACE for SELF
to this OU, and constrained it to apply to descendant users:
SQL Servers
OU ACL
SELF
- Apply to: Descendant User objects
- Read servicePrincipalName: Allow
- Write servicePrincipalName: Allow
Now, when I start my SQL Server instance, I see the expected The SQL Server Network Interface library successfully registered the Service Principal Name
, and Kerberos is now being used for my remote connections.
(Now to update our internal process documentation, so it requires new SQL Server service accounts be created under the new OU, rather than added to the group)
Edit: Note that a domain administrator can also manually register SPNs to a domain account, using setspn.exe
.
setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 DOMAIN\User
setspn -S MSSQLSvc/myhost.redmond.microsoft.com DOMAIN\User
Register a Service Principal Name for Kerberos Connections (TechNet).
Edit 2: If the Read servicePrincipalName
and Write servicePrincipalName
properties are not visible in the ACE list, go to the Attribute Editor tab of the object's Properties dialog, click the Filter button and ensure the following:
- Show only attributes that have values is unchecked
- Show only writable attributes is unchecked
- Show attributes: Mandatory is checked
- Show attributes: Optional is checked
- Show read-only attributes: Constructed is checked
- Show read-only attributes: Backlink is checked
- Show read-only attributes: System-only is checked
(Other combinations may work, but this is what does it for me)
Best Answer
I would start with Read ServicePrincipleName and Write ServicePrincipleName property permissions.