Red Hat Bugzilla – Bug 160025
Telnet will not authenticate via winbind. krb5-telnet will.
Last modified: 2007-11-30 17:11:07 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: After configuring winbind, telnet will not authenticate to the active directory via pam.d/login. However, krb5-telnet does with the same configuration. /etc/pam.d/login is configured to use /etc/pam.d/system-auth-winbind. Winbind is working and system is joined to the win2003 domain. wbinfo -g, -t, -u all produce results. kinit@REALM verifies the account will authenticate. krb5-telnet does authenticate thew user, but seems to lack /etc/issue.net support. This has been tested on two different domains and two different versions of in.telnetd. Version-Release number of selected component (if applicable): telnet-server-0.17-30 and telnet-server-0.17-32.FC3.2 How reproducible: Always Steps to Reproduce: 1. Configure system as described above. 2. Enable telnet server 3. Telnet to the host and access is denied. 4. Use chkconfig to change from telnet to krb5-telnet 5. Restart xinetd 6. Telnet to the host and the user is authenticated. Actual Results: At step 3, Access is denied and the error message below is logged in /var/log/messages. Jun 10 13:51:54 aucutdpms002 remote(pam_unix)[7095]: authentication failure; logname= uid=0 euid=0 tty=pts/1 ruser= rhost=192.168.0.1 user=pctest Jun 10 13:51:57 aucutdpms002 login[7095]: FAILED LOGIN 1 FROM 192.168.0.1 FOR pctest, Authentication failure At step 6, the auth is successful and no such message generated. Expected Results: Successful login. Additional info: Will attach relevant config files.
/etc/pam.d/system-auth-winbind #%PAM-1.0 auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_unix.so likeauth nullok use_first_pass auth required /lib/security/pam_deny.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/pam_deny.so session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so /etc/pam.d/login #%PAM-1.0 auth required pam_securetty.so auth required pam_stack.so service=system-auth-winbind auth required pam_nologin.so account required pam_stack.so service=system-auth-winbind password required pam_stack.so service=system-auth-winbind session required pam_stack.so service=system-auth-winbind session required pam_mkhomedir.so umask=0022 session optional pam_console.so /etc/samba/smb.conf (real domain and IP info replaced) [global] workgroup = AU server string = Pulse Server log file = /var/log/samba/%m.log max log size = 50 security = ads winbind enum users = yes winbind gid = 10000-20000 winbind enum groups = yes winbind uid = 10000-20000 winbind cache time = 300 winbind use default domain = yes winbind separator = + realm = AU.COMPANY.INT template shell = /bin/bash password server = * encrypt passwords = yes socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 wins server = 10.60.100.2 dns proxy = no
It seems now that krb5-telnet will authenticate without winbind support at all. I presume this is the krb5 services working in the background. Forgive my ignorance here. The problem still exists though. I installed the dovecot pop3 service and changed it's pam.d config to the following: /etc/pam.d/dovecot #%PAM-1.0 auth required pam_nologin.so auth required pam_stack.so service=system-auth-winbind account required pam_stack.so service=system-auth-winbind session required pam_stack.so service=system-auth-winbind This will grant a domain user access via winbind. +OK dovecot ready. user test +OK pass password +OK Logged in. Then the following message appears in /var/log/messages Jun 10 16:01:46 pmsproxy pam_winbind[1935]: user 'test' granted access
It might be worth noting that a server we maintain that is running "Red Hat Enterprise Linux AS release 3" does not have this problem and is configured in the same way. This server uses: samba-3.0.9-1.3E.2 telnet-server-0.17-26
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160025 The telnet server does no authentication at all. It just calls /bin/login. All you see from a telnet login is from the client and /bin/login. So I reassign this bug to util-linux.
I have no attempted a local login at the terminal and this works! This suggests to me that login is working, but the way telnetd calls it or something is not right. I have updated to the latest util-linux package (util-linux-2.12a-24.2), but this has not changed anything. I am now applying all updates on a test system here and will comment again if anything changes. Is this still the right spot if login works at the terminal? Thanks, Stuart
The telnetd calls "/bin/login -h" and it means "remote" login. The login with "-h" option uses /etc/pam.d/remote instead /etc/pam.d/login.