From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) I try login as local user "root", but login denied. Reproducible: Always Steps to Reproduce: Case 1 1.LDAP client. /etc/nsswitch.conf: passwd: files ldap shadow: files ldap group: files ldap ... /etc/ldap.conf: host x.x.x.x base dc=xxx ssl start_tls 2.LDAP server is configured, but for example isn't support TLS/SSL, and I think don't send answer on SSL request. Case 2 LDAP client. /etc/nsswitch.conf: passwd: files ldap shadow: files ldap group: files ldap ... /etc/ldap.conf: #host x.x.x.x #base dc=xxx ssl start_tls Actual Results: access denied Expected Results: access permited It is a client's error. Client primarily must to check exit conditions of previous searchings in local files (passwd, shadow). Then must don't send any requests to server or other actions except permit access if exit conditions are SUCCESS.
We (Red Hat) should really try to resolve this before next release.
What are the contents of your /etc/pam.d/system-auth file? Are there any messages in /var/log/messages or /var/log/secure related to the user's access being disallowed?
Created attachment 9499 [details] unchanged installed file
Created attachment 9500 [details] unchanged installed file
/var/log/messages and /var/log/secure are empty related the disallowed access.
Okay, this should be resolved by authconfig-4.1.3, which until it pops up in Raw Hide (ftp://ftp.redhat.com/pub/rawhide/) will be in http://people.redhat.com/nalin/test/. Apply the update, run authconfig (you can leave the settings the same, the update changed what gets generated), and that should resolve the problem. If you find that that doesn't fix it, please reopen this bug ID. Thanks!
Nothing changed. Please, pay attention to useless SSL request. The same in wolverine.
Please check if the nss_ldap package in http://people.redhat.com/nalin/test/ properly fails if starting up TLS fails. It does on my test machine.
The same. Client send useless requests (unknown for server). Any login fails.
This is a bug in PAM configuration by authconfig. Original /etc/pam.d/system-auth is: ... account required /lib/security/pam_unix.so account required /lib/security/pam_ldap.so ... Must be: ... account sufficient /lib/security/pam_unix.so account required /lib/security/pam_ldap.so ...
Created attachment 91259 [details] Original system-auth after authconfig setup for LDAP authentication
Created attachment 91260 [details] Updated system-auth after manually editing file per recommendations in #26449
Created attachment 91262 [details] Context diff between system-auth.orig and system-auth
The above notes indicate this problem would be resolved by authconfig 4.1.3. Red Hat 9 with authconfig-4.3.4 still contains this bug.
There is another problem I have discovered in looking at the system-auth file. When using authconfig to enable ldap authentication, the "account" line for ldap is written to the system-auth file in an incorrect format. The correct format should be: account required /lib/security/$ISA/pam_ldap.so default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore What is written is: account required [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so This generates the following error message in /var/log/messages: Apr 24 11:25:57 localhost gdm[2515]: PAM unable to dlopen(/lib/security/default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore) Apr 24 11:25:57 localhost gdm[2515]: PAM [dlerror: /lib/security/default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore: cannot open shared object file: No such file or directory] Apr 24 11:25:57 localhost gdm[2515]: PAM adding faulty module: /lib/security/default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore