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