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.
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.
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.
- 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
22.214.171.124.1 distinguishedName Generation)
Hi, I can confirm that this is still present in Samba 4.7.6 version.
I'm currently working around this with a bash script that compares the computers attributes cn and sAMAccountName (excluding $ signal), if they don't match, change the rdn with an ldapmodify query. The ldif statement is as follows:
As far I can see, this has the same effect that ADSI Edit rename operation, but with the automation advantage.
Still applies/affected on Samba 4.9.4.
Client Group Policy logs show:
* "Starting manual processing of policy for computer SAMDOM\NEWNAME$"
* "The system call to get account information completed. CN=OLDNAME,CN=Computers,DC=SAMDOM"
"samba-tool computer list show NEWNAME" has the following output (approximate):
* dn: CN=OLDNAME,CN=Computers,DC=SAMDOM
* CN: OLDNAME
* displayName: NEWNAME$
* sAMAccountName: NEWNAME$
* dNSHostName: newname.samdom
* servicePrincipalName: HOST/newname.samdom
* servicePrincipalName: RestrictedKrbHost/newname.samdom
* servicePrincipalName: HOST/NEWNAME
* servicePrincipalName: RestrictedKrbHost/NEWNAME
* servicePrincipalName: WSMAN/newname.samdom
* servicePrincipalName: WSMAN/NEWNAME
* distinguishedName: CN=NEWNAME,CN=Computers,DC=SAMDOM
* memberOf: <unchanged from previously assigned groups>
* objectSID: <unchanged from previous>
Now this might look like a small problem, but this is getting more problematic.
I noticed that some of my pc's where not getting there updated, which i push with ninite.
Ninite used the computer name in AD.
Now since this is an old name, its not found.
samba-tool computer show old-name
ERROR: Unable to find computer "old-name$"
samba-tool computer show new-name
the list kris Lou showed is "almost" complete.
Incorrect are :
the others are ok.
Tested on Samba 4.9.7 AD-DC
samba-tool dbcheck shows 0 errors.
(In reply to Louis from comment #4)
I forgot to mention, re-join from within windows:
Windows "System Properties -> Change... -> Computer Name -> Reboot"
Works without any problems but that did not fix things for me.
Using ADSI Edit, and changing the dn: CN=OLDNAME.OU=... to the new name, did change all other value also to the correct values.
(In reply to Louis from comment #5)
After a bit more checking, when the PC name is corrected, DNS A and PTR should be checked also.
in notice my "oldname" and new name still existed in the DNS as A and PTR record and should be removed also.
which in my case, was a computer that moved from site1 to site2, which are different ip ranges.
This might needs some extra thoughts whats the best way todo this.