Bug 13040 - Two objects can end up with the same sAMAccountName through replication
Two objects can end up with the same sAMAccountName through replication
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.7.0rc6
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-19 03:16 UTC by Tim Beale
Modified: 2017-10-09 01:00 UTC (History)
0 users

See Also:


Attachments
Test case to reproduce the problem (5.59 KB, text/x-python)
2017-09-25 20:54 UTC, Tim Beale
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Beale 2017-09-19 03:16:46 UTC
Normally Samba rejects a DB modification that will mean 2 user objects have the same sAMAccountName. However, a duplicate sAMAccountName can still occur through replication. E.g. if the same user were added on 2 different DCs, Samba will detect the conflict and force a rename of one of the DNs, however, it allows both objects to be added with the same sAMAccountName.

The sAMAccountName is indexed and gets looked up when a user tries to login. If there are duplicate sAMAccountNames in the DB, then this lookup may return the wrong object, which means the wrong password may be used to verify the user.

Note that this problem also occurs on Windows AD.
Comment 1 Tim Beale 2017-09-25 20:54:19 UTC
Created attachment 13629 [details]
Test case to reproduce the problem

The attached python file adds test cases that highlight the problem. We decided not to commit these tests to samba.git as they currently fail on Windows as well (there should be at least one test environment in which the tests can pass).
Comment 2 Tim Beale 2017-10-09 01:00:44 UTC
Update: We asked Microsoft about this. After investigation, they observed that the SAM implementation does in fact take care of identifying and fixing duplicates - it just doesn't do this detection immediately as part of replicated updates.

Windows SAM implementation has an asynchronous procedure that periodically scans and renames the duplicate samAccountName to unique values. The new name is like $DUPLICATE-<RID> based on the object’s RID in hexadecimal. Administratively, one of the two objects should be deleted. 

This article has more information:
https://social.technet.microsoft.com/wiki/contents/articles/15435.active-directory-duplicate-object-name-resolution.aspx#When_a_Duplicate_sAMAccountName_in_Domain_is_Detected