[cifs-protocol] 117013115252666 Validated-Writes of servicePrincipalNames

Sreekanth Nadendla srenaden at microsoft.com
Thu Feb 23 02:31:49 UTC 2017


Hello Stefan, below is the answer to your question. Let me know if you have any concerns.

There are two cases to consider

1.	Clients who are either granted Full Control on an object, or are granted RIGHT_DS_WRITE_PROPERTY on the servicePrincipalName attribute on an object, may write any 2-part or 3-part SPN on the object.     
2.	Clients who are only granted RIGHT_DS_WRITE_PROPERTY_EXTENDED on the servicePrincipalName attribute, are allowed to write 2-part or 3-part SPNs subject to certain constraints 

We do not document all possible permutations or even the default states of the security descriptors for computer and domain controller account objects.   A reasonable generalization would be to say that Domain Admins are granted Full Control over everything and thus fall into the first case above.   By default, computer accounts are granted RIGHT_DS_WRITE_PROPERTY_EXTENDED on servicePrincipalName (via a SELF allow ace).    Also by default, domain controllers are granted RIGHT_DS_WRITE_PROPERTY_EXTENDED on servicePrincipalName (via a SELF allow ace).    So computer and domain controller accounts fall into the second case above.

When a client has only been granted RIGHT_DS_WRITE_PROPERTY_EXTENDED on servicePrincipalName and tries to update that attribute, section 3.1.1.5.3.1.1.4 of MS-ADTS documents the constraints that the domain controller must enforce.    That section of the document is accurate but incomplete.    In particular, it does not describe validation of SPNs where the host name is followed by an optional “:port” or “:instance” component.    SPN modifications that are authorized only by an RIGHT_DS_WRITE_PROPERTY_EXTENDED ACE (the second case above) will be allowed by Active Directory for SPNs that contain a “:port” component (note, this is only assuming all other constraints are also met), but will be rejected for SPNs that contain an “:instance” component.   

We will modify section 3.1.1.5.3.1.1.4 of MS-ADTS to make this more clear.    


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Stefan Metzmacher [mailto:metze at samba.org] 
Sent: Friday, January 13, 2017 9:19 AM
To: Sreekanth Nadendla; cifs-protocol at lists.samba.org
Cc: MSSolve Case Email
Subject: Re: [REG:116052814221908] Validated-Writes of servicePrincipalNames

Hi Sreekanth,

sorry for the long delay.

The difference I see is that you're doing this as administrator.

I'm talking about validated-writes done by an account on it's own computer object. And that's what [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName about, also see the parent section 3.1.1.5.3.1.1 Validated Writes

Can you please continue your reserach on this?

Thanks!
metze

> Hello Stefan, simple tests at my end using a test domain controller shows that all of the following values are allowed by MS Windows domain controller. Before I propose any doc changes, can you confirm which domain controller you have used when you say "Testing against a Windows DC shows that **only** numeric characters are allowed after ':'" Did you mean to say the domain controller itself failed to add such SPN ? Or are you saying that it is the SQL Server that didn't find an SPN that has a nonnumeric character after ":"  ?
> 
> 
> 
> C:\Users\Administrator>setspn -A MSSQLSvc/myhost.379135DOM.LAB:1433   lvisser
> 
> C:\Users\Administrator>setspn -A MSSQLSvc/myhost.379135DOM.LAB:MYINST1   lvisser
> 
> C:\Users\Administrator>setspn -A MSSQLSvc/myhost.379135DOM.LAB/MYINST2   lvisser
> 
> C:\Users\Administrator>setspn -l lvisser
> 
> Registered ServicePrincipalNames for CN=lora visser,CN=Users,DC=379135DOM,DC=LAB:
> 
>         MSSQLSvc/myhost.379135DOM.LAB/MYINST2
>         MSSQLSvc/myhost.379135DOM.LAB:MYINST1
>         MSSQLSvc/myhost.379135DOM.LAB:1433
> 
> 
> You can even have MSSQLSvc/myhost.379135DOM.LAB:8989797/MYINST2
> 
> 
> But ultimately, If the SPN does not match the string as constructed by the Service i.e. SQL Server in this case, authentication will fail.



More information about the cifs-protocol mailing list