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

--
Tony Earnshaw
Email: tonni at hetnet dot nl



Looking for last minute shopping deals? Find them fast with Yahoo! Search.