Bug 114509

Summary: sshd fails authentication with pam_ldap
Product: [Fedora] Fedora Reporter: Glen Eustace <g.eustace>
Component: opensshAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-29 20:26:39 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
system-auth none

Description Glen Eustace 2004-01-28 16:46:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1)

Description of problem:
nss_ldap successfully retrieves data from MS ADS using getpwnam() which would indicate that nsswitch.conf and ldap.conf are ok.
When authconfig has setup system-auth file, sshd fails to find user.  The query being passed to LDAP is looking for NOUSER.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run authconfig and select LDAP
2. Attempt ssh to localhost


Actual Results:  Login declined, invalid user.

Additional info:
Comment 1 Glen Eustace 2004-01-28 16:49:32 EST
Created attachment 97313 [details]
Comment 2 Glen Eustace 2004-01-28 16:54:27 EST
Created attachment 97314 [details]
Comment 3 Glen Eustace 2004-01-28 16:55:38 EST
Created attachment 97315 [details]
Comment 4 Glen Eustace 2004-01-28 16:57:06 EST
Query send to ADS 
Lightweight Directory Access Protocol 
    Message Id: 2 
    Message Type: Search Request (0x03) 
    Message Length: 104 
    Base DN: ou=Staff,ou=Clients,dc=massey,dc=ac,dc=nz 
    Scope: Subtree (0x02) 
    Dereference: Never (0x00) 
    Size Limit: 1 
    Time Limit: 0 
    Attributes Only: False 
    Filter: (&(objectclass=User)(msSFUName=NOUSER)) 
Comment 5 Glen Eustace 2004-01-29 20:26:39 EST
This not a bug, running sshd in debug showed that the shell for the 
user in ldap was invalid on the system running sshd. Using a user 
that has a valid shell for the system concerned works fine.