attribute modification: problem comming soon

[Matthieu Patou]

On 08/18/2009 12:42 PM, Andrew Bartlett wrote:
> On Tue, 2009-08-18 at 12:38 +0400, Matthieu Patou wrote:
>    
>> Hi andrew and nadezhda,
>>
>> A couple of weeks ago I tweaked my S4 in tests to get rid of the
>> verification in kludge_acl.
>>
>> I found that windows 2008 is willing to modify some of his attributes
>> and for at least one of them: servicePrincipalName it keeps modifying it
>> willing to put again and again the same values ie.
>>
>> servicePrincipalName: TERMSRV/smbtstvz01.smb4.tst
>> servicePrincipalName: TERMSRV/SMBTSTVZ01
>>
>> Currently samba4 do not appreciate this and return an error maybe the
>> behavior should be modified to manage this behavior ?
>>      
> What does windows do?  What controls are present on the request
> (permissive modify in particular).
>    
Well today I've been able to trace this problem a bit more, so in order 
to trigger the bug you have to make a w2k8 server (maybe earlier version 
too would trigger it) join a s4 domain (so that TERMSVR entries are 
created as SPN) then make it leave the domain (I tend to make servers 
leave a domain even when the leaved domain has no active DC so that if 
there is any unregistration thing like removing those SPN then it isn't 
done ...) then make it rejoin the domain.

It appears that windows modify this values through DRSUAPI calls 
(dswriteaccountspn) I can't tell much as it's using kerberos for 
encrypting and for the moment wireshark is unable to decrypt it, but 
windows writes an error in the event log indicating that it can't 
register the SPN. As for WWWD it seems that w2k3 copes with this problem 
quite well as there is no error in the client event log when the same 
experience is done with w2k3.

The error in the samba4 log is Failed to modify SPNs on 
CN=SMBTSTVZ01,CN=Computers,DC=smb4,DC=tst: servicePrincipalName: value 
#0 already exists.

Matthieu.