[Fedora-directory-users] moron at the helm - can't coordinate users-groups & padl stuff

[Craig White]

This is basic stuff and I could do it easily with openldap and I can see
I am close. I can get what I need from command line ldapsearch and it
works fine.

RHEL 4 - have run authconfig and my pam.d/system-auth looks like wiki
page for FDS with PAM

I can tell that the padl stuff (nsswitch.conf and /etc/ldap.conf) is
working because the logs show me that 'cn=Directory Manager' is
attempting to bind but it always returns error=32 (obviously no such
object...which by the way is a lousy error report because obviously this
is about invalid credentials and should return error=49)

Anyway, I do have the password for cn=Directory Manager
in /etc/ldap.secret (have tried both with and without a line feed) and
even tried to put rootbinddn & rootpw in /root/.ldaprc to no avail.

Regardless, 'getent passwd' doesn't return anything but contents
of /etc/passwd (likewise for group)

Is there a clue stick for being able to derive accounts from FDS?

I could post the contents of /etc/ldap.conf and /etc/nsswitch if
necessary...perhaps it's one of the commented values in ldap.conf that I
routinely pass over with openldap.

Craig

[Kevin M. Myer]

Quoting Craig White <craigwhite(a)azapple.com&gt;:

>  This is basic stuff and I could do it easily with openldap and I can
> see
>  I am close. I can get what I need from command line ldapsearch and it
>  works fine.
>
>  RHEL 4 - have run authconfig and my pam.d/system-auth looks like wiki
>  page for FDS with PAM
>
>  I can tell that the padl stuff (nsswitch.conf and /etc/ldap.conf) is
>  working because the logs show me that 'cn=Directory Manager' is
>  attempting to bind but it always returns error=32 (obviously no such
>  object...which by the way is a lousy error report because obviously this
>  is about invalid credentials and should return error=49) 
Is "cn=Directory Manager" really your directory manager account?  With 
OpenLDAP, I've always seen rootdn's like "cn=directory manager, 
dc=azapple,dc=com", for instance, so depending on how you converted 
your data, and setup your rootdn in FDS, error=32 is likely correct.

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

[Craig White]

On Tue, 2005-12-06 at 23:11 -0500, Kevin M. Myer wrote:
>  Quoting Craig White <craigwhite(a)azapple.com&gt;:
>  
>  > This is basic stuff and I could do it easily with openldap and I can see
>  > I am close. I can get what I need from command line ldapsearch and it
>  > works fine.
>  >
>  > RHEL 4 - have run authconfig and my pam.d/system-auth looks like wiki
>  > page for FDS with PAM
>  >
>  > I can tell that the padl stuff (nsswitch.conf and /etc/ldap.conf) is
>  > working because the logs show me that 'cn=Directory Manager' is
>  > attempting to bind but it always returns error=32 (obviously no such
>  > object...which by the way is a lousy error report because obviously this
>  > is about invalid credentials and should return error=49)
>  
>  Is "cn=Directory Manager" really your directory manager account?  With 
>  OpenLDAP, I've always seen rootdn's like "cn=directory manager, 
>  dc=azapple,dc=com", for instance, so depending on how you converted 
>  your data, and setup your rootdn in FDS, error=32 is likely correct. 
----
You could be right on this but this is a 2nd install and not my home
setup and not converted from openldap but an entirely new setup.

# ldapsearch -x -h localhost -b "dc=clsurvey,dc=com" \
-D "cn=Directory Manager" -W '(uid=jim)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=clsurvey,dc=com> with scope sub
# filter: (uid=jim)
# requesting: ALL
#

# jim, People, Accounts, clsurvey.com
dn: uid=jim,ou=People,ou=Accounts,dc=clsurvey,dc=com

<<snip>>

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

but /etc/ldap.conf that has...

# cat /etc/ldap.conf
#
host 127.0.0.1
base dc=clsurvey,dc=com
rootbinddn "cn=Directory Manager"
nss_base_passwd         ou=People,ou=Accounts,dc=clsurvey,dc=com?one
nss_base_passwd         ou=Computers,ou=Accounts,dc=clsurvey,dc=com?one
nss_base_shadow         ou=People,ou=Accounts,dc=clsurvey,dc=com?one
nss_base_group          ou=Groups,dc=clsurvey,dc=com?one

and /etc/ldap.secret with the same password that I type in response to
the credential request in my ldapsearch command above should work.

Instead the logs show...

### ldapsearch ###
[07/Dec/2005:07:42:05 -0700] conn=185 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[07/Dec/2005:07:42:05 -0700] conn=185 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[07/Dec/2005:07:42:05 -0700] conn=185 op=1 SRCH
base="dc=clsurvey,dc=com" scope=2 filter="(uid=jim)" attrs=ALL
[07/Dec/2005:07:42:05 -0700] conn=185 op=1 RESULT err=0 tag=101
nentries=1 etime=0
[07/Dec/2005:07:42:05 -0700] conn=185 op=2 UNBIND

### getent passwd ###
[07/Dec/2005:07:46:53 -0700] conn=186 op=0 BIND dn="\22cn=Directory
Manager\22" method=128 version=3
[07/Dec/2005:07:46:53 -0700] conn=186 op=0 RESULT err=32 tag=97
nentries=0 etime=0
[07/Dec/2005:07:46:53 -0700] conn=186 op=1 UNBIND

Which turned out that it was the quotation marks around the rootbinddn
value in /etc/ldap.conf - the log viewer in the console didn't reveal
that issue but the plain text version of the logs made it clear to me.
(The console simply showed 2 sets of double quotes).

Thanks

Craig