samba - Feb 2006 - logins fine, then not: NT_STATUS_WRONG_PASSWORD

I've had samba in production for a few weeks, as follows:

samba 3.0.20b
openldap 2.2.13-4, idealx tools 0.9.1
red hat AS 4
clients: all XP sp2

Samba's the PDC, nothing fancy about the setup other than trying to use LDAP
for
authentication.

So far everything's been mostly fine, then yesterday for some reason a
number of my
users couldn't authenticate after logging out or rebooting, they'd see
an XP error
suggesting they "check username and password".  At the time, LDAP was
up and
responding to queries.

Looking through the samba logs, when the logins fail I see:

[2006/02/01 10:03:29, 5] lib/smbldap.c:smbldap_search_ext(980)
  smbldap_search_ext: base => [dc=lart,dc=com], filter =>
[(&(uid=someuser)(objectclass=sambaSamAccount))], scope => [2]
[2006/02/01 10:03:29, 2] passdb/pdb_ldap.c:init_sam_from_ldap(499)
  init_sam_from_ldap: Entry found for user: someuser
[2006/02/01 10:03:29, 3] smbd/sec_ctx.c:pop_sec_ctx(386)
  pop_sec_ctx (99, 99) - sec_ctx_stack_ndx = 0
[2006/02/01 10:03:29, 3] libsmb/ntlm_check.c:ntlm_password_check(207)
  ntlm_password_check: Interactive logon: NT password check failed for user
someuser

then later on:

check_ntlm_password: sam authentication for user [someuser] FAILED with error
NT_STATUS_WRONG_PASSWORD

I can go run, as root, "/usr/sbin/smbldap-passwd someuser", have them
enter in the
password they normally use, then they can go login fine.

Because it happened to nearly all my users at the same day I suspected the
sambaPwdMustChange attribute, but it's set pretty far out: 1454167813, nor
did
anyone see a warning about needing to change their password.  Also, running
pdbedit
shows:

Password must change: Sat, 30 Jan 2016 07:30:13 GMT

I did add all these folks on the same day weeks ago, and also had most of their
XP
boxes joined to our domain on the same day, so I suspect some default setting
somewhere triggered this.

We don't manage policies on the XP workstations (nor do roaming profiles or
any of
that), pretty much a generic XP pro workstation install.

Thanks for any suggestions on the origin of this problem, I don't want it to
happen
again in two weeks :-)

Global config info from smb.conf, if useful:

[global]
        workgroup = LART
        passdb backend = ldapsam:ldap://ldap.lart.com
        enable privileges = Yes
        username map = /etc/samba/smbusers
        log level = 5 passdb:5 auth:5 winbind:2
        log file = /var/log/samba/%m.log
        unix extensions = No
        socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=8192
SO_SNDBUF=8192
        printcap cache time = 600
        printcap name = /etc/printcap
        add user script = /usr/sbin/smbldap-useradd -m "%u"
        delete user script = /usr/sbin/smbldap-userdel "%u"
        add group script = /usr/sbin/smbldap-groupadd -p "%g"
        delete group script = /usr/sbin/smbldap-groupdel "%g"
        add user to group script = /usr/sbin/smbldap-groupmod -m "%u"
"%g"
        delete user from group script = /usr/sbin/smbldap-groupmod -x
"%u" "%g"
        set primary group script = /usr/sbin/smbldap-usermod -g "%g"
"%u"
        add machine script = /usr/sbin/smbldap-useradd -w "%u"
        logon script = logon.bat
        logon path         logon drive = H:
        logon home = \\%L\%U
        domain logons = Yes
        os level = 64
        preferred master = Yes
        domain master = Yes
        dns proxy = No
        wins support = Yes
        ldap admin dn = cn=Manager,dc=lart,dc=com
        ldap group suffix = ou=Groups
        ldap idmap suffix = ou=Idmap
        ldap machine suffix = ou=People
        ldap suffix = dc=lart,dc=com
        ldap user suffix = ou=People
        idmap backend = ldap:ldap://ldap.lart.com
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        map acl inherit = Yes
        cups options = raw,media=letter






-- 
Joe Mailander
jmailand@lane.k12.or.us

Did you or someone else install any patches/upgrades/service packs on
the client machines? We had an issue with users not being able to
login at one of our clients, until we figured out that the machine
used NTLM-V2 authentication, wich wasn't supported by our domain.
There's a registry key that changes the clients behaviour, you might
want to google for this issue, I remember that there's a nice PDF
somewhere.