1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

pam ldap authentication

Discussion in 'Web and Network Services' started by bluethundr, Oct 9, 2010.

  1. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    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:
    
    [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:
    
    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:
    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:
    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:
    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 /usr/local/etc/ldap.conf? x(
     
  2. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    by the way, pam_ldap was certainly installed with the following command:

    Code:
    portinstall pam_ldap
    
     
  3. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    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 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com binddn 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)
     
  4. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    posixAccount added

    Greatly clarified! thanks

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

    Code:
    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:
    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:
    [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:
    loglevel        256
    pidfile         /var/run/openldap/slapd.pid
    argsfile        /var/run/openldap/slapd.args
    
    syslog.conf has been told to log openldap errors to /var/log/openldap.log

    Code:
    local4.*                                        /var/log/openldap.log
    
    Code:
    [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:
    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:::
     
  5. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    I don't know, but err=49 means invalid credentials. Somewhere there is a password mismatch with the cn=pam_ldap entry.
     
  6. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    pam ldap battle rages on

    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:
    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:
    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:
    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:
    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:
    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:
    [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:
    [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:
    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...
     

    Attached Files:

  7. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    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:
    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 passwd(1). The "exop" setting is one of many schemes. Others include md5, ssha, crypt, etc.
     
  8. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    I just noticed the err=50 flag in the log. That means insufficient access. You need to permit anonymous searches in your slapd.conf.
     
  9. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    ldap anonymous searches

    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:
    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:
    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:
    [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:
    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:
    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:::
     
  10. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    moderate progress

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

    Code:
    [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..... ;)
     
  11. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    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.
     
  12. bluethundr

    bluethundr New Member

    Messages:
    62
    Likes Received:
    0
    pam / LDAP success!!!

    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!!!