Bug 11047 - Duplicate single-valued attributes on some DCs
Duplicate single-valued attributes on some DCs
Status: ASSIGNED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.1.9
All All
: P5 minor
: 4.3
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on: 11778 11443
Blocks:
  Show dependency treegraph
 
Reported: 2015-01-12 10:45 UTC by Sven Schwedas
Modified: 2016-03-08 14:00 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Schwedas 2015-01-12 10:45:43 UTC
We have 4 servers on 2 geographic locations (but in the same Samba site). Location A contains the "PDC" (running all FSMO roles, running .11) and another DC, location B two normal DCs (running .9, upgraded to .11 after the version discrepancy was noticed).

The AD scheme was extended with some custom attributes we need for backwards compatibility with our mail servers, cf. this mailing list thread to how it went: https://lists.samba.org/archive/samba/2014-April/180299.html (Most of the schemes were later modified via Microsoft's AD schema editor, but the mailServer attribute in question wasn't, as far as I recall).

The mentioned mailServer attribute is supposedly single-valued, and used in postfix to determine the destination mail server. Postfix' LDAP expansion (correctly) blows up when this particular field is multi-valued, which shouldn't be and hadn't been possible until sometimes around Christmas, when the servers in location B started to report duplicate values for a single user. 

As the value is more or less fixed (bound to the user's department), I'm fairly confident it hasn't been modified since April, and the particular user's record in general hasn't been changed in a few months. 

Due to the rather obscure way of noticing the bug (Postfix' error only triggers when a user in department B sends a mail to the department A user in question, which didn't occur over the holidays), I cannot really pin-point when or how it happened – a dbcheck doesn't report this issue, and the samba.log is clean (at the default debug level).


ldbsearch output on location A:

    # record 1
    dn: CN=Foo,CN=Users,DC=ad,DC=tao,DC=at
    mailServer: mail.graz.tao.at

    # Referral
    ref: ldap://ad.tao.at/CN=Configuration,DC=ad,DC=tao,DC=at
    # Referral
    ref: ldap://ad.tao.at/DC=DomainDnsZones,DC=ad,DC=tao,DC=at
    # Referral
    ref: ldap://ad.tao.at/DC=ForestDnsZones,DC=ad,DC=tao,DC=at

    # returned 4 records
    # 1 entries
    # 3 referrals


ldbsearch output on location B:

    # record 1
    dn: CN=Foo,CN=Users,DC=ad,DC=tao,DC=at
    mailServer: mail.graz.tao.at
    mailServer: mail.graz.tao.at.

    # Referral
    ref: ldap://ad.tao.at/CN=Configuration,DC=ad,DC=tao,DC=at
    # Referral
    ref: ldap://ad.tao.at/DC=DomainDnsZones,DC=ad,DC=tao,DC=at
    # Referral
    ref: ldap://ad.tao.at/DC=ForestDnsZones,DC=ad,DC=tao,DC=at

    # returned 4 records
    # 1 entries
    # 3 referrals


ldbedit on location B shows both entries, if I delete one, it reports "# 0 adds  0 modifies  0 deletes" and nothing changes.

Deleting one and changing the other, or changing the only reported value on location A, results in "1 modifies", which is then correctly replicated to all 4 DCs (in this example, mail.graz.tao.at. is a stale, old value, and mail.graz.tao.at the current one).

The workaround/"fix" seems to be removing the attribute altogether from an entry with ldbedit (resulting in "2 modifies"), then re-adding it. As this only happened with one record (as far as I can tell), I'm currently unable to reproduce the issue for further debugging.
Comment 1 Andrew Bartlett 2016-01-15 00:25:14 UTC
This is related to the incorrect attribute ID values that are used for custom schema that has an msDS-IntID set in the schema.

I've made this bug depend on that one.  The extra work for this bug will be to write a dbcheck rule to clean this up, or to confirm that dbcheck is already handling it correctly.