Univention Bugzilla – Bug 30170
winbind on memberserver fails to access idmap LDAP backend after password rotation.
Last modified: 2013-02-28 20:38:29 CET
Ticket#: 2013010821000661 contains a report about a memberserver denying SMB services probably since the server password was rotated. /var/log/samba/log.winbindd-idmap showed: [2013/01/24 13:04:21.876681, 0] lib/smbldap.c:1225(smbldap_connect_system) failed to bind to server ldap://master.domain.local:7389 with dn="cn=member1,cn=memberserver,cn=computers,dc=domain,dc=local" Error: Invalid credentials (unknown) Maybe this is caused by a missing winbind restart in /usr/lib/univention-server/server_password_change after the new machine credentials were stored via smbpasswd -w for LDAP access. The case at hand was observed in a samba4 environment but I guess it's generic.
Small correction: I did restart winbind manually which didn't help. Actually, the error messages didn't crop up until I restarted it, beforehands it just failed silently. To fix it, I had to apply the command smbpasswd -w $(</etc/machine.secret) and restart winbind manually (actually, I restarted all samba processes). I wonder if this was really necessary since I thought winbind used Kerberos as well. It also looks like the password was rotated on Jan 21 but the Kerberos token refreshed on Jan 24, the day when th connection actually failed (see below). What additional data/files do you need? root@member1:/etc# ls -l machine.secret* -rw------- 1 root root 8 Jan 21 01:08 machine.secret -rw------- 1 root root 168 Jan 21 01:08 machine.secret.old -rw------- 1 root root 16 Sep 19 00:05 machine.secret.SAVE root@member1:/etc# ktutil list --timestamp FILE:/etc/krb5.keytab: Vno Type Principal Date Aliases 33 aes256-cts-hmac-sha1-96 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 aes128-cts-hmac-sha1-96 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 des3-cbc-sha1 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 arcfour-hmac-md5 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 des-cbc-md5 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 des-cbc-md4 host/member1.domain.local@DOMAIN.LOCAL 2013-01-24 33 des-cbc-crc host/member1.domain.local@DOMAIN.LOCAL 2013-01-24
Hmmm... what I wrote might be misleading. The connection actually failed on Jan 23 (almost exactly at 1700 CET). The Kerberos token probably has the newer timestamp since I also rebooted that VM yesterday.
This is getting more urgent: It looks like I have to re-set the password after each reboot of this VM. These incarnations "fix" the problem: smbpasswd -w $(</etc/machine.secret) /etc/init.d/winbind restart /etc/init.d/samba restart
univention-support-info was uploaded as upload_7q3zvU.bz2
Created attachment 5031 [details] server-password-change.log The "last" password change (Mon Jan 21 01:08:45 CET 2013) shows an error when running the "net idmap secret alloc <PW>" after (successfull?) "smbpasswd -w": --- Setting stored password for "cn=member1,cn=memberserver,cn=computers,dc=domain,dc=local" in secrets.tdb setting idmap secret for alloc from /etc/machine.secret The only currently supported backend is LDAP ---
We switched the master's DNS backend to ldap to work around ticket 2013010821000661. I think this problem started to appear when I switched the DNS backend back to samba4.
The server_password_change script still sets the "net idmap alloc secret" which was removed in Samba 3.6 (Bug 24231) by yet another idmap rewrite (v6R2). I guess this should be "net idmap '*' secret", which is set in 26univention-samba.inst.
Fixed in errata3.1-0 and ucs3.1-1: * replace legacy "idmap secret alloc" by "idmap secret '*'" * restart winbind as well after doing this Advisory: 2013-02-18-univention-server.yaml Changelog: changelog-3.1-1.tex
wbinfo and smbclient work fine after password change with /usr/lib/univention-server/server_password_change (errata3.1-0 and ucs3.1-1) OK - errata3.1-0 and ucs3.1-1 OK - Advisory OK - Changelog
http://errata.univention.de/3.1-errata53.html
Please reopen this bug. I updated the server to errata60 and after a reboot I had to use 'smbpasswd -w $(</etc/machine.secret)' again to make idmap work.
(In reply to comment #11) > Please reopen this bug. I updated the server to errata60 and after a reboot I > had to use 'smbpasswd -w $(</etc/machine.secret)' again to make idmap work. → Bug #30621