pam ldap authentication

Discussion related to network/web services such as Apache, BIND Sendmail, etc.

pam ldap authentication

Postby bluethundr » 09 Oct 2010, 20:26

Well I managed to get my sudo working through ldap. Thanks to all who have helped! But for any of the services that need to authenticate through pam (i.e. ssh and su) it is still a no-go. I am getting pam authentication errors in my log files.

But LDAP is certainly doing it's job!

Using the account I have setup in LDAP as the pam user I can search my base DN:

Code: Select all

[bluethundr@bluethundr-desktop:~ ] $:ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# staff, summitnjhome.com
dn: ou=staff,dc=summitnjhome,dc=com
ou: staff
objectClass: organizationalUnit

# summitnjops, staff, summitnjhome.com
dn: ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
objectClass: organizationalUnit

# people, summitnjhome.com
dn: ou=people,dc=summitnjhome,dc=com
objectClass: organizationalUnit
ou: people

# Services, summitnjhome.com
dn: ou=Services,dc=summitnjhome,dc=com
ou: services
objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com
dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword:: e1NTSEF9K2NsWktBUXVDWEhkbjVBcVRDbFVMb0ROZVcvelltelIg

# sudoers, Services, summitnjhome.com
dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com
ou: sudoers
objectClass: organizationalUnit

# defaults, sudoers, Services, summitnjhome.com
dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here

# root, sudoers, Services, summitnjhome.com
dn: cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoUser: root
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL

# %wheel, sudoers, Services, summitnjhome.com
dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoUser: %wheel
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate

# %summitnjops, sudoers, Services, summitnjhome.com
dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: %summitnjops
sudoUser: %summitnjops
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate

# search result
search: 2
result: 0 Success

# numResponses: 12
# numEntries: 11



And this is the entry I have in my LDAP database for the pam_ldap user:

Code: Select all

5 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: secret


So far so good, everything works.

However, this is how I have my ldap.conf file setup:

Code: Select all
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com


( I have also tried setting the host to 127.0.0.1 as well, with no joy)

And observe what happens if I try to su using pam/ldap

Code: Select all
Oct  9 20:25:11 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct  9 20:25:11 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct  9 20:25:11 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11
Oct  9 20:25:11 LBSD2 su: bluethundr to root on /dev/pts/0



ssh has roughly the same effect on the logs but in order for me to demonstrate that I would likely have to gain physical access to the box to fix it. So hopefully the above example will suffice.

This is how my pam su file is configured:

Code: Select all
LBSD2# cat /etc/pam.d/su
#
# System-wide defaults
#

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            sufficient      pam_ldap.so
auth            required        pam_unix.so        no_warn try_first_pass nullok

# account
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         sufficient      pam_ldap.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so
session         required        pam_ldap.so
session         required        pam_lastlog.so          no_fail

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass



I assume that whatever is breaking su is breaking ssh. Does anyone have any ideas as to why slapd cannot access the pam_ldap account user automatically through [FILE]/usr/local/etc/ldap.conf[/FILE]? x(
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

Postby bluethundr » 09 Oct 2010, 21:50

by the way, pam_ldap was certainly installed with the following command:

Code: Select all
portinstall pam_ldap
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

Postby aragon » 09 Oct 2010, 23:25

If you set your loglevel in slapd to 256 you'll get some useful logging information about clients connecting and the searches they run. If 256 isn't enough, check OpenLDAP docs for adding more detail.

Currently your setup won't work because you have no Posix user accounts in LDAP. Remember that the binddn option in ldap.conf is purely for letting pam_ldap search your database for the user that its trying to authenticate. Once it finds the account it attempts to rebind to the LDAP server using the searched out DN and the password from PAM.

In other words, you need the [FILE]cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com binddn[/FILE] entry in LDAP and a Posix entry in LDAP corresponding to the login you want to use on your workstation.

(actually you don't really need the binddn entry - the norm is to search anonymously)
aragon
Giant Locked
 
Posts: 2031
Joined: 16 Nov 2008, 17:04
Location: Cape Town, South Africa

posixAccount added

Postby bluethundr » 11 Oct 2010, 02:28

Greatly clarified! thanks

I have added the corresponding posix accounts in LDAP I wish to use:

Code: Select all
12 uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
userPassword: secret
gecos: Tim


13 cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
userPassword: secret
gecos: Enoch Root


So tho anon search can work this more specific one used in ldap.conf can in fact find the entries:

Code: Select all
ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b "dc=summitnjhome,dc=com"

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
gecos: Tim

# root, staff, summitnjhome.com
dn: cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
gecos:: RW5vY2ggUm9vdCA=


Yet su to these accounts is still broken:


Code: Select all
[bluethundr@LBSD2:~]$:su - root
Password:
Last login: Sun Oct 10 14:57:29 on pts/9


Logging in slapd.conf has been set to 256

Code: Select all
loglevel        256
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args


syslog.conf has been told to log openldap errors to [FILE]/var/log/openldap.log[/FILE]

Code: Select all
local4.*                                        /var/log/openldap.log


Code: Select all
[root@LBSD2:/usr/local/etc/openldap]#tail -f /var/log/openldap.log
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 op=1 RESULT tag=97 err=49 text=
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 op=2 UNBIND
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 fd=11 closed
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 fd=11 ACCEPT from IP=127.0.0.1:60289 (IP=0.0.0.0:389)
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=0 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=0 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=1 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=2 UNBIND
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 fd=11 closed




This is what is going on in the message logs:

Code: Select all
Oct 11 02:12:44 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 11 02:12:44 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 11 02:12:44 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11


Any idea why su _still_ isn't authenticating even tho the user accounts have been added to LDAP??? :::sigh:::
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

Postby aragon » 11 Oct 2010, 02:50

I don't know, but err=49 means invalid credentials. Somewhere there is a password mismatch with the cn=pam_ldap entry.
aragon
Giant Locked
 
Posts: 2031
Joined: 16 Nov 2008, 17:04
Location: Cape Town, South Africa

pam ldap battle rages on

Postby bluethundr » 15 Oct 2010, 22:59

PAM appears to still be broken after I have added posix account entries for my users into LDAP.

I have verified that the same password is being used in my LDAP database for the pam_ldap user and in ldap.conf

LDAP:
Code: Select all
5 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: secret


/usr/local/etc/openldap/ldap.conf
Code: Select all
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com


The only thing I am a little unclear of is the role of the pam_password. AFAIK I am binding on the password 'secret'.

When I test pam authentication with su:


Code: Select all
BSD2# su - bluethundr
Password:
Last login: Fri Oct 15 14:46:26 from 38.121.138.51
[bluethundr@LBSD2:~]$:



It produces these results in messages:

/var/log/messages:

Code: Select all
Oct 15 15:02:52 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 15 15:02:52 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 15 15:02:52 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11


And this is what happens in the LDAP log:

/var/log/openldap.log
Code: Select all
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=1 RESULT tag=97 err=49 text=
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 15:02:52 LBSD2 slapd[3610]:  14r
Oct 15 15:02:52 LBSD2 slapd[3610]:
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_read(14): input error=-2 id=1198, closing.
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_closing: readying conn=1198 sd=14 for close
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: waked
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_close: deferring conn=1198 sd=14
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=2 UNBIND
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_resched: attempting closing conn=1198 sd=14
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: removing 14
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 fd=14 closed



I don't really see the pam_ldap user doing a search for the bluethundr user.



The pam_ldap account can log into LDAP:

Code: Select all
[bluethundr@LBSD2:~]$:ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -W -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# staff, summitnjhome.com
dn: ou=staff,dc=summitnjhome,dc=com
ou: staff
objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com
dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM


So can the user I am trying to su into:

Code: Select all
[bluethundr@LBSD2:~]$:ldapsearch -x -h ldap -D "uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com" -W -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Tim Dunphy
gidNumber: 1001
homeDirectory: /home/bluethundr
sn: Dunphy
uid: bluethundr
uidNumber: 1001
gecos: Tim Dunphy
givenName: Tim
loginShell: /bin/bash
mail: bluethundr@gmail.com
userPassword:: secret


Also (and I know this may be a separate issue) I am attempting to get my CentOS clients to authenticate with this LDAP server. I have set everything up on the CentOS boxes using authconfig.

I _do_ see evidence in the logs of a search being conducted for the user when I attempt to log in via LDAP...

When I try to ssh to the client (sum2) this is what I see in my LDAP logs on the LDAP server (bsd2)

Code: Select all
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_read(14): input error=-2 id=1275, closing.
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_closing: readying conn=1275 sd=14 for close
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_close: deferring conn=1275 sd=14
Oct 15 16:42:55 LBSD2 slapd[3610]: conn=1275 op=2 UNBIND
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_resched: attempting closing conn=1275 sd=14
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: removing 14
Oct 15 16:42:55 LBSD2 slapd[3610]: conn=1275 fd=14 closed
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 busy
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: listen=7, new connection on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: added 14r (active) listener=0x0
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 16:43:11 LBSD2 slapd[3610]:  14r
Oct 15 16:43:11 LBSD2 slapd[3610]:
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 fd=14 ACCEPT from IP=192.168.1.45:50867 (IP=0.0.0.0:389)
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=0 BIND dn="" method=128
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=0 RESULT tag=97 err=0 text=
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 16:43:11 LBSD2 slapd[3610]:  14r
Oct 15 16:43:11 LBSD2 slapd[3610]:
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: AND
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter_list
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: EQUALITY
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: EQUALITY
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter_list
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=1 SRCH base="dc=summitnjhome,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bluethundr))"
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor


I've enclosed more complete logs as an attachement (slapd-logs.txt). I've also included a portion of a tcpdump in the hopes that may shed some light on the situation (tcpdump.txt).



thanks for all the help I've gotten so far...
Attachments

[The extension txt has been deactivated and can no longer be displayed.]

[The extension txt has been deactivated and can no longer be displayed.]

bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

Postby aragon » 15 Oct 2010, 23:12

Perhaps there is a problem with pam_ldap's binddn feature. Can you try without it? (ie. anonymous search)

Looks like the Centos system is binding anonymously, searches for your uid, but doesn't find anything. Try run the search manually:

Code: Select all
ldapsearch -x -h ldap -b "dc=summitnjhome,dc=com" "(&(objectClass=posixAccount)(uid=bluethundr))"


That should return your posixAccount entry...

The pam_password directive tells pam_ldap what password scheme to use when it sets an LDAP password via [man=1]passwd[/man]. The "exop" setting is one of many schemes. Others include md5, ssha, crypt, etc.
aragon
Giant Locked
 
Posts: 2031
Joined: 16 Nov 2008, 17:04
Location: Cape Town, South Africa

Postby aragon » 15 Oct 2010, 23:14

aragon wrote:Looks like the Centos system is binding anonymously, searches for your uid, but doesn't find anything.

I just noticed the err=50 flag in the log. That means insufficient access. You need to permit anonymous searches in your [file]slapd.conf[/file].
aragon
Giant Locked
 
Posts: 2031
Joined: 16 Nov 2008, 17:04
Location: Cape Town, South Africa

ldap anonymous searches

Postby bluethundr » 16 Oct 2010, 20:33

Hello,

At first I wasn't able to do anonymous searches of ldap as should be clear by this point.

So what I did was move anonymous reads from the bottom of the ACL list to the very top of the list, like so:

Code: Select all
access to *
            by read

access to attrs=userPassword by self write
                             by anonymous auth
access to * by self write
            by dn.children="ou=summitnjops,ou=staff,dc=summitnjhome,dc=com" write
            by users read
            by anonymous auth

access to   attrs=shadowLastChange,userPassword
            by self write
            by * auth

access to * by self write
            by users read
            by anonymous auth



I tried to su both with and without the following lines commented out after making the above changes to slapd.conf. I commented out these lines thinking this would force the pam_ldap user to search anonymously:

/usr/local/etc/openldap/ldap.conf
Code: Select all
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
#binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
#bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com


Anonymous searches are working now:

Code: Select all
[bluethundr@bt-laptop:~]$:ldapsearch -x -h ldap -b "dc=summitnjhome,dc=com" "(&(objectClass=posixAccount)(uid=bluethundr))"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=bluethundr))
# requesting: ALL
#

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Tim Dunphy
gidNumber: 1001
homeDirectory: /home/bluethundr
sn: Dunphy
uid: bluethundr
uidNumber: 1001
gecos: Tim Dunphy
givenName: Tim
loginShell: /bin/bash
mail: bluethundr@gmail.com
userPassword:: e0NSWVBUfWNySmg3NGtXbHRXeVE=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



So while sudo is as mentioned working su is still not authenticating:

/var/log/messages
Code: Select all
Oct 16 20:20:50 LBSD2 sudo: bluethundr : TTY=pts/5 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/usr/local/bin/bash
Oct 16 20:21:09 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 16 20:21:09 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 16 20:21:09 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11


And I'm still getting error 49's (credential errors) in the ldap logs:

Code: Select all
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 RESULT tag=97 err=49 text=
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on 1 descriptor
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on:
Oct 16 20:21:09 LBSD2 slapd[60645]:  11r
Oct 16 20:21:09 LBSD2 slapd[60645]:
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: read activity on 11
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_read(11): input error=-2 id=1000, closing.
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_closing: readying conn=1000 sd=11 for close
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on 1 descriptor
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: waked
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_close: deferring conn=1000 sd=11
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=2 UNBIND
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_resched: attempting closing conn=1000 sd=11
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: removing 11
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 fd=11 closed


:::guh:::
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

moderate progress

Postby bluethundr » 16 Oct 2010, 20:39

In moderately good news, ldap authentication on foreign hosts seems to be creaking to life!

Code: Select all
[bluethundr@LCENT02:~]$:ssh mon
bluethundr@mon's password:
Last login: Sat Oct 16 16:34:18 2010 from 192.168.1.45
#########################################################
#               SUMMITNJHOME.COM                        #
#               TITLE:       VIRTCENT11 BOX             #
#               LOCATION:    SUMMIT BASEMENT            #
#                                                       #
#########################################################


id: cannot find name for group ID 1001


Not perfect yet but it's coming along..... ;)
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46

Postby aragon » 16 Oct 2010, 22:57

bluethundr wrote:And I'm still getting error 49's (credential errors) in the ldap logs:

Code: Select all
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 RESULT tag=97 err=49 text=


The BIND log entry above says that pam_ldap is still trying to authenticate for searches (and failing). The dn= parameter should be blank with an anonymous bind.
aragon
Giant Locked
 
Posts: 2031
Joined: 16 Nov 2008, 17:04
Location: Cape Town, South Africa

pam / LDAP success!!!

Postby bluethundr » 26 Oct 2010, 15:17

I have a NEW development!! PAM now appears to be authenticating through LDAP!!! whew!! Apparently I was using the encrypted password for the pam services in ldap.conf when the setup wasn't working. Don't know why I didn't think of this sooner, but when I tried putting the pam user's password in plain text in the ldap.conf file everything came to life!!! :stud

Sorry for being such a needy pain in this thread but in the end I'm glad it all came together and THANKS to everyone who helped!!!
bluethundr
Junior Member
 
Posts: 62
Joined: 21 Jul 2010, 02:46


Return to Web & Network Services

Who is online

Users browsing this forum: No registered users and 0 guests