Bug 2126 - winbind stops working via PAM
winbind stops working via PAM
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.6
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-06 12:26 UTC by Michael Leo
Modified: 2005-08-24 10:15 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Leo 2004-12-06 12:26:08 UTC
(my first bug report!)
Samba 3.0.6 on HP x86 server.
/etc/samba/smb.conf:
[global]
netbios name = 
server string = 
# domain info:
workgroup = actualdomainname
security = domain
password server = 192.168.0.1, 192.168.0.2
# disabling master browser functions:
local master = no
domain master = no
preferred master = no
# encrypt our passwords:
encrypt passwords = yes
# insert printer stuff here if needed:
# printcap name = /etc/printcap
# load printers = yes
# printing = lprng
# loggin information:
log file = /var/log/samba/%m.log
max log size = 0
# Network performance options:
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# Since we have WINS:
wins server = 192.168.0.1,192.168.0.2
dns proxy = no
# The next session sets up smb with winbind to allow authentication against 
domain
winbind separator = +
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
template shell = /bin/bash
template homedir = /home/%D/%U


#######################
# Share definitions:
[tmp]
path = /tmp
browsable = yes
writeable = yes
guest ok = no

# Printer shares:



/etc/pam.d/login:

#%PAM-1.0
auth       required     pam_securetty.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
auth       sufficient   pam_winbind.so use_first_pass
auth       required     pam_unix.so use_first_pass
account    required     pam_stack.so service=system-auth
account    sufficient   pam_winbind.so
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    optional     pam_console.so


/etc/pam.d/sshd:
#%PAM-1.0
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    required     pam_limits.so
session    optional     pam_console.so


/etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_winbind.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     sufficient    /lib/security/$ISA/pam_winbind.so
account     required      /lib/security/$ISA/pam_unix.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel 
umask=0022
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so



I have also joined the domain successfully and wbinfo and getent passwd all work 
fine.  I can use ssh to connect and use my AD domain accounts to gain access.

However, after an unknown interval of time, this no longer works--I cannot gain 
access via ssh to this server.

I can ssh via the root account, then use su to authenticate with domain 
accounts. 

If i then restart winbindd, my remote access is fixed, but only for a short 
time.  My AD domain accounts can ssh in, but given time, it will fail.

this is what my /var/log/messages log shows:
Dec  5 04:02:02 lnapp004 winbindd[31618]:   
=============================================================== 
Dec  5 04:02:02 lnapp004 winbindd[31618]: [2004/12/05 04:02:02, 0] lib/fault.c:
fault_report(37) 
Dec  5 04:02:02 lnapp004 winbindd[31618]:   INTERNAL ERROR: Signal 11 in pid 
31618 (3.0.6-2.3E) 
Dec  5 04:02:02 lnapp004 winbindd[31618]:   Please read the appendix Bugs of the 
Samba HOWTO collection 
Dec  5 04:02:02 lnapp004 winbindd[31618]: [2004/12/05 04:02:02, 0] lib/fault.c:
fault_report(39) 



This is very consistant, but I am unsure the time interval for failure, as I 
can't just sit here and log in all the time.

Let me know if i have reported this correctly.

Thanks
Mike
Comment 1 Michael Leo 2004-12-06 12:32:22 UTC
New log info:
I turned on higher debuging and found this error:


[2004/12/05 04:02:02, 0] lib/fault.c:fault_report(36)
  ===============================================================
[2004/12/05 04:02:02, 0] lib/fault.c:fault_report(37)
  INTERNAL ERROR: Signal 11 in pid 31618 (3.0.6-2.3E)
  Please read the appendix Bugs of the Samba HOWTO collection
[2004/12/05 04:02:02, 0] lib/fault.c:fault_report(39)
  ===============================================================
[2004/12/05 04:02:02, 0] lib/util.c:smb_panic2(1407)
  PANIC: internal error
[2004/12/05 04:02:02, 0] lib/util.c:smb_panic2(1415)
  BACKTRACE: 11 stack frames:
   #0 winbindd(smb_panic2+0x14f) [0x80d6daf]
   #1 winbindd(smb_panic+0x27) [0x80d6c57]
   #2 winbindd [0x80c2018]
   #3 /lib/tls/libc.so.6 [0x34feb8]
   #4 winbindd(wcache_invalidate_cache+0xa8) [0x807c0c8]
   #5 winbindd(strftime+0x1305) [0x806e929]
   #6 winbindd(strftime+0x1467) [0x806ea8b]
   #7 winbindd(strftime+0x228f) [0x806f8b3]
   #8 winbindd(main+0x47f) [0x806feef]
   #9 /lib/tls/libc.so.6(__libc_start_main+0xed) [0x33d79d]
   #10 winbindd(ldap_msgfree+0x7d) [0x806e2d1]
Comment 2 Gerald (Jerry) Carter 2005-02-11 08:37:51 UTC
michael, please retest against 3.0.11 when you can.  We've done 
a lot of development in winbindd.  Thanks.
Comment 3 Gerald (Jerry) Carter 2005-08-24 10:15:59 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.