Bug 11482 - rename of workstations on domain incomplete
rename of workstations on domain incomplete
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
unspecified
All All
: P5 minor
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 16:46 UTC by Jason
Modified: 2015-09-02 08:09 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason 2015-09-01 16:46:38 UTC
Hello,

If you rename a Windows workstation that has been added to a Samba 4 domain, using the normal Windows "System Properties -> Change... -> Computer Name -> Reboot", the computer isn't entirely renamed in the Samba directory and will still show as the old name in ADUC.

Using ADUC and looking at the Attributes Editor tab it appears that displayName, dNSHostName, name, sAMAccountName, and servicePrincipalName all DO change (might be wrong on 1 of those, going off memory). HOWEVER, what doesn't change is distinguishedName and CN (obviously). This causes the object in ADUC to still show up as the old name.

This is different behavior to a Windows domain. A rename in that case will fully update everything, including distinguishedName and CN.

I found one mention of this in the mailing list back in Feb 2014.
https://lists.samba.org/archive/samba/2014-February/178611.html

There are two workarounds. Unjoin, rename, join the workstation. Or use ADSI Edit to perform a rename on the object, which will change the distinguishedName and CN.

Unfortunately I'm stuck on an older 4.1 build so can't test if this has been addressed in newer builds. However, it seems this is an edge case since most users wouldn't be renaming workstations or would just unjoin/join instead. So my guess is it still exists and while it isn't a major issue, think it would be worth fixing at some point.

Thanks.
Comment 1 Andrew Bartlett 2015-09-01 22:06:05 UTC
To flesh this out a bit: when a windows domain member server changes
it's name over SAMR, that the changes at the LDAP layer do not match
windows.  In particular, that the CN attribute is not updated to match.

Tasks:
 - Add cross-protocol tests to demonstrate the matching behaviour
between SAMR and LDAP using python.
  - Determine if the CN attribute is attached to the 'full name' or
'account name' in SAMR
  - confirming in particular the error cases where there may be a
conflicting object using the new name.
 - Update SAMR server in the AD DC to match Windows behaviour
(presumably changing the SetUserInfo call to rename the LDAP entry when
setting the account name as suggested in for create in MS-SAMR
3.1.5.14.1 distinguishedName Generation)