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.