Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160025 - Telnet will not authenticate via winbind. krb5-telnet will.
Summary: Telnet will not authenticate via winbind. krb5-telnet will.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-10 03:56 UTC by Stuart
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-08 10:46:46 UTC


Attachments (Terms of Use)

Description Stuart 2005-06-10 03:56:10 UTC
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 04:03:31 UTC
/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 06:06:02 UTC
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 06:25:40 UTC
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 10:14:34 UTC
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-16 02:10:06 UTC
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 12:58:31 UTC
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.