Bug 40938 - uid != sAMAccountName after renaming Windows client via Windows
uid != sAMAccountName after renaming Windows client via Windows
Status: RESOLVED DUPLICATE of bug 37388
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.1
Other Linux
: P3 normal (vote)
: ---
Assigned To: Connector maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-23 18:49 CET by Arvid Requate
Modified: 2016-03-23 18:51 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2016-03-23 18:49:27 CET
After renaming a Windows client via Windows the new sAMAccountName is not synchronized to the corresponding uid attribute in OpenLDAP.

As mentioned in Bug 39802 Comment 8 this causes a smbd coredump whenever the client logs on to samba, e.g. to update its machine GPOs.

Basically the renamed account is non-existent as a Posix account. So in the concept of a UCS domain the machine is not properly joined any longer.

Workaround (at the time of writing):

## If "$newname" is the new client name without trailing $-sign:

udm computers/windows modify --dn "$windowsclient" --set name="$newname"
Comment 1 Arvid Requate univentionstaff 2016-03-23 18:51:36 CET

*** This bug has been marked as a duplicate of bug 37388 ***