Dear Tony, Thanks for your comment..I played more with my ldap and here is what I found out.. If a user in in both /etc/passwd and ldap directory with the same password, linux authentication is used. However, if user etc/passwd is different than the ldap passwd, depending on what passwd is used during the login, appropriate authentication is used(i.e both passwords work just fine) However, here is what I still dont understand: if a user is only in etc/passwd, after executing su user, it seems that there are still some activities in the ldap site. fir instance when I do su karan where karan ONLY exists in the etc/passwd, I get the following in the logfile(/vat/log/local4)
Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 fd=20 ACCEPT from IP=127.0.0.1:33277 (IP=0.0.0.0:389) Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 op=0 BIND dn="" method=128 Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 op=0 RESULT tag=97 err=0 text= Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 op=1 SRCH base="ou=People,dc=ibm,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=502))" Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Feb 22 14:54:03 gamaalien slapd[7896]: <= bdb_equality_candidates: (uidNumber) not indexed Feb 22 14:54:03 gamaalien slapd[7896]: conn=42 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 fd=21 ACCEPT from IP=127.0.0.1:33278 (IP=0.0.0.0:389) Feb 22 14:55:04 gamaalien slapd[7896]: conn=42 fd=20 closed (connection lost) Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=0 BIND dn="" method=128 Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=0 RESULT tag=97 err=0 text= Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=1 SRCH base="ou=People,dc=ibm,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=karan))" Feb 22 14:55:04 gamaalien slapd[7896]: <= bdb_equality_candidates: (uid) not indexed Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=2 SRCH base="ou=People,dc=ibm,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=karan))" Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=2 SRCH attr=gidNumber Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Feb 22 14:55:04 gamaalien slapd[7896]: conn=43 fd=21 closed (connection lost)
do you know whats going on here? if linux authentication is used and karan is not in the ldap directory then why ldap is called? thanks for your help
----- Original Message ---- From: Tony Earnshaw tonni@hetnet.nl To: openldap-technical@openldap.org Sent: Friday, February 22, 2008 2:12:36 AM Subject: Re: using LDAP as central authentication unit
Hamidreza Hamedtoolloei skrev, on 22-02-2008 09:49:
http://www.linux.com/articles/113567 describes the "sufficient" modifier
as follows:
If a sufficient module succeeds, it is enough to satisfy the
requirements of sufficient modules in that realm for use of the service,
and modules below it that are also listed as 'sufficient' are not invoked.
given the following /etc/pam.d/system.auth file:
auth
required
/lib/security/$ISA/pam_env.so
auth
sufficient
/lib/security/$ISA/pam_unix.so likeauth nullok
auth
sufficient
/lib/security/$ISA/pam_ldap.so use_first_pass
auth
required
/lib/security/$ISA/pam_deny.so
I think LDAP is used ONLY if the unix authentication fails?? right??? am
I missing something???
I don't suppose that, reading the article you quote, you're missing anything, but I've just played around with my test machine's FC6 /etc/pam.d/system-auth and found the following for the auth service:
1: Where a user is in both LDAP and /etc/{passwd,shadow} only the pam_unix.so password counts, even though the position of the pam_unix.so and pam_ldap.so lines is swapped. Changing the LDAP entry's password doesn't make any difference to pam; 2: Where a user is only in LDAP the pam_unix.so auth entry is ignored, whatever its position; 3: Commenting out the pam_unix.so line results in all login attempts by everyone to be invalid. So not even root can log in any longer.
So I'd say that the stuff is far more complicated than the author states. Perhaps people are thinking about the nsswitch.conf entries. However, a recent thread in the pam_ldap mailing list hinted that things might be different for systems on which Padl's CNS pam_ldap library is installed, rather than Red Hat's version - as on my machines.
To avoid completely "missing something" I suggest you try it out for yourself ;)
Best,
--Tonni