Re: using LDAP as central authentication unit

Hey Buchan,
Sorry for not answering your question.. I must have overlooked your response. My ultimate goal is to use LDAP for user authentication and resource authorization in a grid computing environment. As a starting point, I tried to use ldap as a centralized linux user account management mechanism. So I configured my LDAP to act as linux user authentication using this link:
http://www.ibm.com/developerworks/library/l-openldap/index.html

during analyzing the behavior of ldap I came up with the below observation:
/etc/pam.d/system.auth file has the following content which suggests that linux authentication is used first and it it fails ldap is used.
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass

so if a user is in both /etc/passwd and ldap, linux authentication is used. However, if a user is ONLY in ldap directory, linux authentication fails and ldap is called.
Analysing the case that a user is only in the etc/passwd:
In this case, there are some activities in the ldap site which I dont understand. If a user is only in etc/passwd and pam.d/system.auth file says call ldap only if linux fails, then why ldap is called when linux authentication is successful?

You say this is expected... but if I understood the pam.d/system.auth file correctly, ldap should not be called if a user is only in etc/passwd

Thanks,
~Hamid

----- Original Message ----
From: Buchan Milne <bgmilne@staff.telkomsa.net>
To: openldap-technical@openldap.org
Cc: Hamidreza Hamedtoolloei <hamedtoolloei@yahoo.com>
Sent: Sunday, February 24, 2008 11:02:04 PM
Subject: Re: using LDAP as central authentication unit

On Saturday 23 February 2008 03:09:33 Hamidreza Hamedtoolloei wrote:
> 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.

This is to be expected. But, since you did not answer my previous question
(asking about what you are trying to achieve, not every single question you
have on how user information and authentication technologies work), I am not
sure how to answer some of your questions.

> 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

This is a typical search from nss_ldap, *not* pam_ldap. As such, it has
nothing to do with your PAM configuration, but your nss configuration, which
I don't believe you have provided.

> Feb 22 14:54:03 gamaalien slapd[7896]: <=
> bdb_equality_candidates: (uidNumber) not indexed

You should tell slapd to index uidNUmber (in slapd.conf), and run slapindex to
ensure that the existing entries are 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

Samething with uid.

> 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

Let's see your /etc/nsswitch.conf first ...