Bug 160025 - Telnet will not authenticate via winbind. krb5-telnet will.
Telnet will not authenticate via winbind. krb5-telnet will.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-09 23:56 EDT by Stuart
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-08 06:46:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stuart 2005-06-09 23:56:10 EDT
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.
Comment 1 Stuart 2005-06-10 00:03:31 EDT
/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
Comment 2 Stuart 2005-06-10 02:06:02 EDT
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

Comment 3 Stuart 2005-06-10 02:25:40 EDT
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



Comment 4 Harald Hoyer 2005-06-10 06:14:34 EDT
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.
Comment 5 Stuart 2005-06-15 22:10:06 EDT
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
Comment 6 Karel Zak 2005-06-21 08:58:31 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.