[cifs-protocol] Questions about Validated-SPN validated write

[Dominic Salemno]

Nadezhda Ivanova,

Someone from our team will follow-up with you shortly in regards to your questions.

Dominic Salemno
Escalation Engineer
Open Specifications

From: didrash at gmail.com [mailto:didrash at gmail.com] On Behalf Of Nadezhda Ivanova
Sent: Friday, December 17, 2010 6:08 AM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: Questions about Validated-SPN validated write

Hello,
Does Validated-SPN validated write allow an account to set an object's SPN to the following values:
HOST/samAccountName (without the "$")
HOST/dnsDomainName
if the object is a regular computer object and NOT a DC?

The algorithm described in MS-DRSR 5.5 AccessCheckWriteToSpnAttribute seems to indicate that yes, this should be allowed. Ot the other hand, MS-ADTS 3.1.1.5.3.1.1.4 servicePrincipalName leads me to believe that the object being a DC is mandatory constraint: "The SPN is a syntactically correct two-part SPN, or it is a syntactically correct three-part SPN (see
Mutual Authentication (section 5.1.1.4)) and the object is a DC's domain controller object (see
sections7.1.1.3.1 and 7.1.1.3.2). "

In addition, I did the following test:
Gave Validated-SPN right to a user on a regular computer object, and got CONSTRAINT_VIOLATION when setting its servicePrincipalName with the above described values.
Gave Validated-SPN right to a user on a DC object, and these values were set successfully.

So my questions are:
Is the behaviour of setting servicePrincipalName supposed to be different between LDAP and DRS?
Does servicePrincipalName modification depend on things other then the syntax restrictions described in MS-DRSR and MS-ADTS?
If an object does not have Validated-SPN on Principal-Self, should the account still be allowed to set the above values via DRS?

Best Regards,
Nadezhda Ivanova
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101217/78a2a903/attachment.html>