I've been unsuccessfully trying to get nss_ldap to work. I've chased down hundreds of google searches over the last 3 days, and I can't seem to get a centos system to authenticate against ldap.
Every daemon on the system is running into the same problem:
nss_ldap: could not search LDAP server - Server is unavailable
sshd, nscd, httpd, you name it..
slapd is clearly running, telnet localhost 389 actually connects me to it.
I've run authconfig, /etc/sysconfig/authconfig agrees.
I'm at a complete and utter loss. I've followed every how-to out there, RH, Openldap, Debian, FreeBSD I can verify ldap is working, I can't seem to get any PAM applications to use it.
Peter
On Wed, 2009-12-16 at 11:24 -0800, Peter Serwe wrote:
I've been unsuccessfully trying to get nss_ldap to work. I've chased down hundreds of google searches over the last 3 days, and I can't seem to get a centos system to authenticate against ldap.
Every daemon on the system is running into the same problem:
nss_ldap: could not search LDAP server - Server is unavailable
sshd, nscd, httpd, you name it..
slapd is clearly running, telnet localhost 389 actually connects me to it.
I've run authconfig, /etc/sysconfig/authconfig agrees.
I'm at a complete and utter loss. I've followed every how-to out there, RH, Openldap, Debian, FreeBSD I can verify ldap is working, I can't seem to get any PAM applications to use it.
---- forget 'telnet'
Can you do an ldapsearch?
ldapsearch -x -h localhost -D '$YOUR_ROOT_BIND_DN' -W '(ou=*)'
Craig
On Wed, Dec 16, 2009 at 11:33 AM, Craig White craigwhite@azapple.comwrote:
forget 'telnet'
Can you do an ldapsearch?
ldapsearch -x -h localhost -D '$YOUR_ROOT_BIND_DN' -W '(ou=*)'
Craig
Sure I can, this is the output, slightly sanitized.
# extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (ou=*) # requesting: ALL #
# People, mynet.net dn: ou=People,dc=mynet,dc=net ou: People objectClass: organizationalUnit
# testuser, People, mynet.net dn: cn=testuser,ou=People,dc=mynet,dc=net uid: testuser cn: testuser sn: Test givenName: Test objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount ou: People uidNumber: 10001 gidNumber: 10001 userPassword:: dGVzdA== homeDirectory: /tmp mail: test@mynet.net
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
Peter
I've been unsuccessfully trying to get nss_ldap to work. I've chased down hundreds of google searches over the last 3 days, and I can't seem to get a centos system to authenticate against ldap.
Every daemon on the system is running into the same problem:
nss_ldap: could not search LDAP server - Server is unavailable
sshd, nscd, httpd, you name it..
slapd is clearly running, telnet localhost 389 actually connects me to it.
I've run authconfig, /etc/sysconfig/authconfig agrees.
I'm at a complete and utter loss. I've followed every how-to out there, RH, Openldap, Debian, FreeBSD I can verify ldap is working, I can't seem to get any PAM applications to use it.
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
mark
I was going to say no TLS on either side.
Specifically because I wanted to make sure that I was doing it with basic auth prior to using tls, but I found TLS lines in the /etc/ldap.conf.
I commented those out, and guess what, no more nss_ldap messages in /var/log/messages..
Now, I'm somewhat guessing that my directory doesn't have the right information in it. Maybe I just need an ldif recipe for adding the users.
Peter
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Found an ldif user recipe for CentOS5.2..
Added the user "tactest" with the password "tactest".
Dec 16 12:05:30 ldap sshd[11705]pam_unix(sshd:auth): check pass; user unknown Dec 16 12:05:30 ldap sshd[11705]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ldap Dec 16 12:05:30 ldap sshd[11705]: pam_succeed_if(sshd:auth): error retrieving information about user tactest
auth still fails.
Peter
On Wed, Dec 16, 2009 at 11:49 AM, Peter Serwe peter.serwe@gmail.com wrote:
I was going to say no TLS on either side.
Specifically because I wanted to make sure that I was doing it with basic auth prior to using tls, but I found TLS lines in the /etc/ldap.conf.
I commented those out, and guess what, no more nss_ldap messages in /var/log/messages..
Now, I'm somewhat guessing that my directory doesn't have the right information in it. Maybe I just need an ldif recipe for adding the users.
Peter
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Peter Serwe http://truthlightway.blogspot.com/
and, of course:
Dec 16 12:05:31 ldap sshd[11705]: Failed password for invalid user tactest from 127.0.0.1 port 52949 ssh2
Peter
On Wed, Dec 16, 2009 at 12:07 PM, Peter Serwe peter.serwe@gmail.com wrote:
Found an ldif user recipe for CentOS5.2..
Added the user "tactest" with the password "tactest".
Dec 16 12:05:30 ldap sshd[11705]pam_unix(sshd:auth): check pass; user unknown Dec 16 12:05:30 ldap sshd[11705]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ldap Dec 16 12:05:30 ldap sshd[11705]: pam_succeed_if(sshd:auth): error retrieving information about user tactest
auth still fails.
Peter
On Wed, Dec 16, 2009 at 11:49 AM, Peter Serwe peter.serwe@gmail.comwrote:
I was going to say no TLS on either side.
Specifically because I wanted to make sure that I was doing it with basic auth prior to using tls, but I found TLS lines in the /etc/ldap.conf.
I commented those out, and guess what, no more nss_ldap messages in /var/log/messages..
Now, I'm somewhat guessing that my directory doesn't have the right information in it. Maybe I just need an ldif recipe for adding the users.
Peter
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Peter Serwe http://truthlightway.blogspot.com/
-- Peter Serwe http://truthlightway.blogspot.com/
On Wed, 2009-12-16 at 12:07 -0800, Peter Serwe wrote:
Found an ldif user recipe for CentOS5.2..
Added the user "tactest" with the password "tactest".
Dec 16 12:05:30 ldap sshd[11705]pam_unix(sshd:auth): check pass; user unknown Dec 16 12:05:30 ldap sshd[11705]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ldap Dec 16 12:05:30 ldap sshd[11705]: pam_succeed_if(sshd:auth): error retrieving information about user tactest
auth still fails.
---- before you get into authorizations...
does the user show? I think not...
getent passwd |grep tactest
if that's the case, and you want help from the list...
what is in files... /etc/nsswitch.com /etc/pam.d/system-auth /etc/ldap.conf
Craig
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
[root@ldap home]# getent passwd | grep example [root@ldap home]#
[root@ldap home]# cat /etc/nsswitch.conf | grep -v #
passwd: files ldap shadow: files ldap group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus aliases: files nisplus
[root@ldap home]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
[root@ldap home]# cat /etc/ldap.conf | grep -v #
BASE dc=tncionline, dc=net URI ldap://127.0.0.1 port 389
SIZELIMIT 12 TIMELIMIT 15 DEREF never timelimit 600 bind_timelimit 600 bind_policy soft idle_timelimit 3600
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus base dc=tncionline, dc=net pam_password md5
Peter On Wed, Dec 16, 2009 at 12:24 PM, Craig White craigwhite@azapple.comwrote:
On Wed, 2009-12-16 at 12:07 -0800, Peter Serwe wrote:
Found an ldif user recipe for CentOS5.2..
Added the user "tactest" with the password "tactest".
Dec 16 12:05:30 ldap sshd[11705]pam_unix(sshd:auth): check pass; user unknown Dec 16 12:05:30 ldap sshd[11705]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ldap Dec 16 12:05:30 ldap sshd[11705]: pam_succeed_if(sshd:auth): error retrieving information about user tactest
auth still fails.
before you get into authorizations...
does the user show? I think not...
getent passwd |grep tactest
if that's the case, and you want help from the list...
what is in files... /etc/nsswitch.com /etc/pam.d/system-auth /etc/ldap.conf
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2009-12-16 at 12:39 -0800, Peter Serwe wrote:
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
[root@ldap home]# getent passwd | grep example [root@ldap home]#
[root@ldap home]# cat /etc/nsswitch.conf | grep -v #
passwd: files ldap shadow: files ldap group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus aliases: files nisplus
[root@ldap home]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
[root@ldap home]# cat /etc/ldap.conf | grep -v #
BASE dc=tncionline, dc=net URI ldap://MailScanner warning: numerical links are often malicious: 127.0.0.1 port 389
SIZELIMIT 12 TIMELIMIT 15 DEREF never timelimit 600 bind_timelimit 600 bind_policy soft idle_timelimit 3600
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus base dc=tncionline, dc=net pam_password md5
---- here's a big problem... /etc/ldap.conf
you need to add...(assuming this is where you have People/Groups)
nss_base_passwd ou=People,tncionline,dc=net?one nss_base_shadow ou=People,tncionline,dc=net?one nss_base_group ou=Groups,tncionline,dc=net?one
take the space out of base... base dc=tncionline,dc=net
I'd also add (until you can deal)... ssl no
Craig
On Wed, 2009-12-16 at 13:44 -0700, Craig White wrote:
On Wed, 2009-12-16 at 12:39 -0800, Peter Serwe wrote:
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
[root@ldap home]# getent passwd | grep example [root@ldap home]#
[root@ldap home]# cat /etc/nsswitch.conf | grep -v #
passwd: files ldap shadow: files ldap group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus aliases: files nisplus
[root@ldap home]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
[root@ldap home]# cat /etc/ldap.conf | grep -v #
BASE dc=tncionline, dc=net URI ldap://MailScanner warning: numerical links are often malicious: 127.0.0.1 port 389
SIZELIMIT 12 TIMELIMIT 15 DEREF never timelimit 600 bind_timelimit 600 bind_policy soft idle_timelimit 3600
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus base dc=tncionline, dc=net pam_password md5
here's a big problem... /etc/ldap.conf
you need to add...(assuming this is where you have People/Groups)
nss_base_passwd ou=People,tncionline,dc=net?one nss_base_shadow ou=People,tncionline,dc=net?one nss_base_group ou=Groups,tncionline,dc=net?one
take the space out of base... base dc=tncionline,dc=net
I'd also add (until you can deal)... ssl no
---- oh...
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus
you can remove pserwe,dgates from the list unless you have daemon services running as those users prior to LDAP start (highly unlikely)
and if the above doesn't work, it is because your slapd.conf ACL's are blocking anonymous binds at the indicated dn's
So you might want to either simplify your ACL's, permit anonymous binds to the 'people/groups' or let us see what you've got for ACL's
these are some rules that I've found good to have in /etc/openldap/slapd.conf - YMMV
allow bind_anon_dn
access to attrs=userPassword,sambaNTPassword,sambaLMPassword by self write by anonymous auth by * none
access to dn.regex="^uid=([^,]+)ou=People,dc=azapple,dc=com$$" by self read by anonymous auth by * none
# a bottom catchall rule... access to * by anonymous read by * read
access to dn.base="cn=Subschema" by * read
Craig
I just had those users in there because I didn't want to attempt to hit ldap for known local users.
Peter
On Wed, Dec 16, 2009 at 12:58 PM, Craig White craigwhite@azapple.comwrote:
On Wed, 2009-12-16 at 13:44 -0700, Craig White wrote:
On Wed, 2009-12-16 at 12:39 -0800, Peter Serwe wrote:
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
[root@ldap home]# getent passwd | grep example [root@ldap home]#
[root@ldap home]# cat /etc/nsswitch.conf | grep -v #
passwd: files ldap shadow: files ldap group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus aliases: files nisplus
[root@ldap home]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
[root@ldap home]# cat /etc/ldap.conf | grep -v #
BASE dc=tncionline, dc=net URI ldap://MailScanner warning: numerical links are often malicious: 127.0.0.1 port 389
SIZELIMIT 12 TIMELIMIT 15 DEREF never timelimit 600 bind_timelimit 600 bind_policy soft idle_timelimit 3600
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus base dc=tncionline, dc=net pam_password md5
here's a big problem... /etc/ldap.conf
you need to add...(assuming this is where you have People/Groups)
nss_base_passwd ou=People,tncionline,dc=net?one nss_base_shadow ou=People,tncionline,dc=net?one nss_base_group ou=Groups,tncionline,dc=net?one
take the space out of base... base dc=tncionline,dc=net
I'd also add (until you can deal)... ssl no
oh...
nss_initgroups_ignoreusers pserwe,dgates,root,ldap,named,avahi,haldaemon,dbus
you can remove pserwe,dgates from the list unless you have daemon services running as those users prior to LDAP start (highly unlikely)
and if the above doesn't work, it is because your slapd.conf ACL's are blocking anonymous binds at the indicated dn's
So you might want to either simplify your ACL's, permit anonymous binds to the 'people/groups' or let us see what you've got for ACL's
these are some rules that I've found good to have in /etc/openldap/slapd.conf - YMMV
allow bind_anon_dn
access to attrs=userPassword,sambaNTPassword,sambaLMPassword by self write by anonymous auth by * none
access to dn.regex="^uid=([^,]+)ou=People,dc=azapple,dc=com$$" by self read by anonymous auth by * none
# a bottom catchall rule... access to * by anonymous read by * read
access to dn.base="cn=Subschema" by * read
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, Dec 16, 2009 at 12:58 PM, Craig White craigwhite@azapple.comwrote:
allow bind_anon_dn
access to attrs=userPassword,sambaNTPassword,sambaLMPassword by self write by anonymous auth by * none
access to dn.regex="^uid=([^,]+)ou=People,dc=azapple,dc=com$$" by self read by anonymous auth by * none
# a bottom catchall rule... access to * by anonymous read by * read
access to dn.base="cn=Subschema" by * read
Have all that now..
Had to take out the samba stuff, openldap complained on restart.
[root@ldap home]# getent passwd | grep example [root@ldap home]#
Still nothing good from getent.
Peter
On Wed, 2009-12-16 at 12:39 -0800, Peter Serwe wrote:
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
---- and by the way... don't waste time trying to authenticate users/groups that don't exist.
If they don't show up when you give commands like...
getent passwd getent group
you aren't going to be able to authenticate... the system doesn't see them. You can't authenticate users that don't exist. Likewise, groups that don't exist or memberships to groups that don't exist are a problem.
Craig
getent still fails, now I'm getting can't connect messages again.
Dec 16 12:59:58 ldap nscd: nss_ldap: could not search LDAP server - Server is unavailable
Also, the People container was removed and not re-added when I re-created the tree with webmin, hence, I modified the lines in /etc/ldap.conf to reflect:
nss_base_passwd dc=tncionline,dc=net nss_base_shadow dc=tncionline,dc=net nss_base_group dc=tncionline,dc=net
Peter
On Wed, Dec 16, 2009 at 12:47 PM, Craig White craigwhite@azapple.comwrote:
On Wed, 2009-12-16 at 12:39 -0800, Peter Serwe wrote:
I think not as well. The tactest user has been blown back out. I can re-add it from ldif again.
and by the way... don't waste time trying to authenticate users/groups that don't exist.
If they don't show up when you give commands like...
getent passwd getent group
you aren't going to be able to authenticate... the system doesn't see them. You can't authenticate users that don't exist. Likewise, groups that don't exist or memberships to groups that don't exist are a problem.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2009-12-16 at 13:02 -0800, Peter Serwe wrote:
getent still fails, now I'm getting can't connect messages again.
Dec 16 12:59:58 ldap nscd: nss_ldap: could not search LDAP server - Server is unavailable
Also, the People container was removed and not re-added when I re-created the tree with webmin, hence, I modified the lines in /etc/ldap.conf to reflect:
nss_base_passwd dc=tncionline,dc=net nss_base_shadow dc=tncionline,dc=net nss_base_group dc=tncionline,dc=net
---- I think I give up.
If you are going to ask for help and then discard - there's little reason to try.
Craig
Which part did I discard that was relevant?
I don't have a People container at the moment.
There was something that looked like ?one on the end of the string, I couldn't make sense of it.
Which part are you offended by the discard of?
Peter
On Wed, Dec 16, 2009 at 1:35 PM, Craig White craigwhite@azapple.com wrote:
On Wed, 2009-12-16 at 13:02 -0800, Peter Serwe wrote:
getent still fails, now I'm getting can't connect messages again.
Dec 16 12:59:58 ldap nscd: nss_ldap: could not search LDAP server - Server is unavailable
Also, the People container was removed and not re-added when I re-created the tree with webmin, hence, I modified the lines in /etc/ldap.conf to reflect:
nss_base_passwd dc=tncionline,dc=net nss_base_shadow dc=tncionline,dc=net nss_base_group dc=tncionline,dc=net
I think I give up.
If you are going to ask for help and then discard - there's little reason to try.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
OMG.
My bad.
I thought ?one was an artifact of your copy of MailScanner.
I added it and logged in.
The People container is not present and I didn't put that back in.
I can now log in as "example@$host".
Peter
On Wed, Dec 16, 2009 at 1:38 PM, Peter Serwe peter.serwe@gmail.com wrote:
Which part did I discard that was relevant?
I don't have a People container at the moment.
There was something that looked like ?one on the end of the string, I couldn't make sense of it.
Which part are you offended by the discard of?
Peter
On Wed, Dec 16, 2009 at 1:35 PM, Craig White craigwhite@azapple.comwrote:
On Wed, 2009-12-16 at 13:02 -0800, Peter Serwe wrote:
getent still fails, now I'm getting can't connect messages again.
Dec 16 12:59:58 ldap nscd: nss_ldap: could not search LDAP server - Server is unavailable
Also, the People container was removed and not re-added when I re-created the tree with webmin, hence, I modified the lines in /etc/ldap.conf to reflect:
nss_base_passwd dc=tncionline,dc=net nss_base_shadow dc=tncionline,dc=net nss_base_group dc=tncionline,dc=net
I think I give up.
If you are going to ask for help and then discard - there's little reason to try.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Peter Serwe http://truthlightway.blogspot.com/
And since I forgot. Thanks!
Silly question, is any of this documented anywhere?
Peter
On Wed, Dec 16, 2009 at 1:40 PM, Peter Serwe peter.serwe@gmail.com wrote:
OMG.
My bad.
I thought ?one was an artifact of your copy of MailScanner.
I added it and logged in.
The People container is not present and I didn't put that back in.
I can now log in as "example@$host".
Peter
On Wed, Dec 16, 2009 at 1:38 PM, Peter Serwe peter.serwe@gmail.comwrote:
Which part did I discard that was relevant?
I don't have a People container at the moment.
There was something that looked like ?one on the end of the string, I couldn't make sense of it.
Which part are you offended by the discard of?
Peter
On Wed, Dec 16, 2009 at 1:35 PM, Craig White craigwhite@azapple.comwrote:
On Wed, 2009-12-16 at 13:02 -0800, Peter Serwe wrote:
getent still fails, now I'm getting can't connect messages again.
Dec 16 12:59:58 ldap nscd: nss_ldap: could not search LDAP server - Server is unavailable
Also, the People container was removed and not re-added when I re-created the tree with webmin, hence, I modified the lines in /etc/ldap.conf to reflect:
nss_base_passwd dc=tncionline,dc=net nss_base_shadow dc=tncionline,dc=net nss_base_group dc=tncionline,dc=net
I think I give up.
If you are going to ask for help and then discard - there's little reason to try.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Peter Serwe http://truthlightway.blogspot.com/
-- Peter Serwe http://truthlightway.blogspot.com/
On Wed, 2009-12-16 at 13:38 -0800, Peter Serwe wrote:
Which part did I discard that was relevant?
I don't have a People container at the moment.
There was something that looked like ?one on the end of the string, I couldn't make sense of it.
Which part are you offended by the discard of?
---- After we fix the nss-ldap stuff, you change the DSA. I have to laugh.
You are flailing and changing things and configurations far beyond where you were an hour ago and so there is no way to know where you are at.
Suggestion... LDAP System Administration by Gerald Carter
It will teach you what you need to know. The book is pure spoon feeding and makes it simple. I am sure that you will waste a ton of time if you don't read this book.
Craig
Right, I was actually trying the things suggested by multiple people at the same time.
nss_ldap's connection to ldap was the primary issue. The other stuff was merely fluff.
Believe it or not, I actually have that book.
I just looked on page 112 where Carter mentions the one level directory search.
I'll dig deeper. I didn't think (didn't look either) that it covered nss_ldap as well as it does.
Peter
On Wed, Dec 16, 2009 at 1:45 PM, Craig White craigwhite@azapple.com wrote:
On Wed, 2009-12-16 at 13:38 -0800, Peter Serwe wrote:
Which part did I discard that was relevant?
I don't have a People container at the moment.
There was something that looked like ?one on the end of the string, I couldn't make sense of it.
Which part are you offended by the discard of?
After we fix the nss-ldap stuff, you change the DSA. I have to laugh.
You are flailing and changing things and configurations far beyond where you were an hour ago and so there is no way to know where you are at.
Suggestion... LDAP System Administration by Gerald Carter
It will teach you what you need to know. The book is pure spoon feeding and makes it simple. I am sure that you will waste a ton of time if you don't read this book.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
If you're going to be doing LDAP-based authentication on the server that is running the LDAP server, watch out for this bug, which has been around since at least FC5. It's still a problem as of FC10:
https://bugzilla.redhat.com/show_bug.cgi?id=182464
The best way to avoid it so far is to have LDAP served by a machine that doesn't use LDAP. If that's not feasible for you, then you can use the soft bind described at https://bugzilla.redhat.com/show_bug.cgi?id=182464#c10 however that has some undesirable side effects (like user's mail might bounce with "no such user" if the LDAP server is down, instead of giving a transient lookup failure).
You don't have to worry about the above bug until after you've got a working config, though.
On other fronts, I prefer to edit configs manually too, but if you're just starting out you might want to start with the system-config-authentication GUI, and then edit /etc/ldap.conf for the "ou=People" and "ou=Group" stuff after that. Look at the before & after configs.
Turning on various debugging options in slapd.conf can work wonders if you understand (at least in principle) what LDAP does. It can be very verbose but also very helpful. Don't forget to turn the verbose stuff off again once you solve your problem.
Remember that while most LDAP clients use /etc/openldap/ldap.conf, PAM uses /etc/ldap.conf. If they're not both suitably configured, then what ldapseach is telling you has no correspondence to what PAM is seeing.
As someone else mentioned, turn off the SSL stuff and just use localhost until you've got it working.
In /etc/ldap.conf when you set rootbinddn, don't forget to configure /etc/ldap.secret, mode 0600.
Here's an example of a full working /etc/ldap.conf from CentOS 5.4, domain changed, comments stripped, using SSL:
base dc=EXAMPLE,dc=ca rootbinddn cn=manager,dc=EXAMPLE,dc=ca timelimit 120 bind_timelimit 120 idle_timelimit 3600 nss_base_passwd ou=People,dc=EXAMPLE,dc=ca?one nss_base_shadow ou=People,dc=EXAMPLE,dc=ca?one nss_base_group ou=Group,dc=EXAMPLE,dc=ca?one nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm uri ldaps://ldap1.EXAMPLE.ca ldaps://ldap2.EXAMPLE.ca/ ssl on tls_cacertfile /etc/pki/tls/certs/ca-bundle-EXAMPLE.crt pam_password md5
Devin
On Thu, 17 Dec 2009, Devin Reade wrote:
If you're going to be doing LDAP-based authentication on the server that is running the LDAP server, watch out for this bug, which has been around since at least FC5. It's still a problem as of FC10: https://bugzilla.redhat.com/show_bug.cgi?id=182464
I disagree that this is a bug. It's not a problem if you configure ldap.conf properly. For example, using
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
-Steve
On Thu, 17 Dec 2009, Devin Reade wrote:
If you're going to be doing LDAP-based authentication on the server that is running the LDAP server, watch out for this bug, which has been around since at least FC5. It's still a problem as of FC10: https://bugzilla.redhat.com/show_bug.cgi?id=182464
I disagree that this is a bug. It's not a problem if you configure ldap.conf properly. For example, using
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
Actually, if this is in a business setting, and esp. if they're in server rooms, turn *off* avahi-daemon, and fix iptables so that there's no hole for it.
mark
Steve Thompson smt@vgersoft.com wrote:
I disagree that this is a bug. It's not a problem if you configure ldap.conf properly. For example, using
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
That was identified fairly early on, and you'll notice the example config I sent includes those users (and is in fact the default config in CentOS 5.4). It doesn't seem to always solve the problem. This problem seems to be very sensitive to configs (some sites exhibit it, some don't) and also sensitive to changes in boot sequence from release to release. If it works for you, great. It doesn't seem to be globally sufficient, though. It's been closed a few times but just keeps popping up.
Note this paragraph from https://bugzilla.redhat.com/show_bug.cgi?id=182464#c10 which, to the best of my knowledge, has not been addressed:
I did some splunking with strace, followed by code inspection of libnss_ldap. It turns out that the information referenced by nss_initgroups_ignoreusers is only used _after_ the library attempts to connect to the ldap server.
However, that said, this is getting a bit off topic from the original question, so I won't dwell on it any more.
Devin
Devin Reade wrote:
If you're going to be doing LDAP-based authentication on the server that is running the LDAP server, watch out for this bug, which has been around since at least FC5. It's still a problem as of FC10:
https://bugzilla.redhat.com/show_bug.cgi?id=182464
The best way to avoid it so far is to have LDAP served by a machine that doesn't use LDAP. If that's not feasible for you, then you can use the
How bout disabling messagebus? I disable it on all of my systems as part of kickstart. Never needed it. Maybe it's more useful in a desktop situation(all of my systems are servers).
nate
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Tried webmin. Blew out my whole ldap database and used webmin to create a new tree, and an example user. Guess what? My example user fails the same way.
I'm running slapd with -d 128 as well..
Peter
-- Peter Serwe http://truthlightway.blogspot.com/
You wrote:
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
Tried webmin. Blew out my whole ldap database and used webmin to create a new tree, and an example user. Guess what? My example user fails the same way.
I'm running slapd with -d 128 as well..
Can you use webmin on the server? If so, that's good. Then, can you use it from a client? If not, what errors is it showing, or what is it not able to find? There are two or three different places to go in webmin (not happy with that, though I like it in general).
mark
I am largely, vehemently against webmin or any other gui tools for system administration, including the X11 tools..
And, to be honest, it pisses me off that virt-install is broken, but virt-manager can create a new VM for me just fine, even though it hangs on granular package selection..
gui tools don't script so easily, #!/bin/bash is my favorite tool.
And webmin is a big hairy security hole.
It was useful for a moment though.
Peter
On Wed, Dec 16, 2009 at 1:46 PM, m.roth@5-cent.us wrote:
You wrote:
On Wed, Dec 16, 2009 at 11:33 AM, m.roth@5-cent.us wrote:
First question: do you have tls enabled on the client, and not the server, or vice versa?
Second question: on the server, can you do a search?
Handy tool: webmin has a whole ldap section, and can give you a *lot* of clues as to what's going wrong.
Tried webmin. Blew out my whole ldap database and used webmin to create a new tree, and an example user. Guess what? My example user fails the same way.
I'm running slapd with -d 128 as well..
Can you use webmin on the server? If so, that's good. Then, can you use it from a client? If not, what errors is it showing, or what is it not able to find? There are two or three different places to go in webmin (not happy with that, though I like it in general).
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I am largely, vehemently against webmin or any other gui tools for system administration, including the X11 tools..
I'm not vehemently, but I do almost all of my sysadmin work in shell, also. <snip>
And webmin is a big hairy security hole.
It was useful for a moment though.
Yes - it was *really* helpful three years ago, when I was fighting openldap.
mark
Peter Serwe wrote:
I've been unsuccessfully trying to get nss_ldap to work. I've chased down hundreds of google searches over the last 3 days, and I can't seem to get a centos system to authenticate against ldap.
Every daemon on the system is running into the same problem:
Disable all SSL/TLS functions on the server and client and try it in the most basic mode, if it still doesn't work run tcpdump to look at what is actually being sent and what the response is.
nate
I'm not really seeing what the response is, running tcpdump -vvv -i lo, output of a whole transaction is:
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 12:33:48.197928 IP (tos 0x0, ttl 64, id 61456, offset 0, flags [DF], proto: TCP (6), length: 60) ldap.48322 > ldap.ssh: S, cksum 0xaa05 (correct), 805740654:805740654(0) win 32792 <mss 16396,sackOK,timestamp 129781886 0,nop,wscale 7> 12:33:48.204532 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) ldap.ssh > ldap.48322: S, cksum 0x1510 (correct), 807996569:807996569(0) ack 805740655 win 32768 <mss 16396,sackOK,timestamp 129781886 129781886,nop,wscale 7> 12:33:48.198050 IP (tos 0x0, ttl 64, id 61457, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: ., cksum 0xfd33 (correct), 1:1(0) ack 1 win 257 <nop,nop,timestamp 129781886 129781886> 12:33:48.209188 IP (tos 0x0, ttl 64, id 23780, offset 0, flags [DF], proto: TCP (6), length: 72) ldap.ssh > ldap.48322: P, cksum 0xfe3c (incorrect (-> 0x4771), 1:21(20) ack 1 win 256 <nop,nop,timestamp 129781888 129781886> 12:33:48.209315 IP (tos 0x0, ttl 64, id 61458, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: ., cksum 0xfd1b (correct), 1:1(0) ack 21 win 257 <nop,nop,timestamp 129781888 129781888> 12:33:48.209523 IP (tos 0x0, ttl 64, id 61459, offset 0, flags [DF], proto: TCP (6), length: 72) ldap.48322 > ldap.ssh: P, cksum 0xfe3c (incorrect (-> 0x4757), 1:21(20) ack 21 win 257 <nop,nop,timestamp 129781891 129781888> 12:33:48.209529 IP (tos 0x0, ttl 64, id 23781, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: ., cksum 0xfd02 (correct), 21:21(0) ack 21 win 256 <nop,nop,timestamp 129781891 129781891> 12:33:48.209772 IP (tos 0x0, ttl 64, id 61460, offset 0, flags [DF], proto: TCP (6), length: 764) ldap.48322 > ldap.ssh: P 21:733(712) ack 21 win 257 <nop,nop,timestamp 129781891 129781891> 12:33:48.209778 IP (tos 0x0, ttl 64, id 23782, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: ., cksum 0xfa2e (correct), 21:21(0) ack 733 win 268 <nop,nop,timestamp 129781891 129781891> 12:33:48.211826 IP (tos 0x0, ttl 64, id 23783, offset 0, flags [DF], proto: TCP (6), length: 756) ldap.ssh > ldap.48322: P 21:725(704) ack 733 win 268 <nop,nop,timestamp 129781891 129781891> 12:33:48.212006 IP (tos 0x0, ttl 64, id 61461, offset 0, flags [DF], proto: TCP (6), length: 76) ldap.48322 > ldap.ssh: P, cksum 0xfe40 (incorrect (-> 0xc918), 733:757(24) ack 725 win 268 <nop,nop,timestamp 129781891 129781891> 12:33:48.214205 IP (tos 0x0, ttl 64, id 23784, offset 0, flags [DF], proto: TCP (6), length: 204) ldap.ssh > ldap.48322: P 725:877(152) ack 757 win 268 <nop,nop,timestamp 129781891 129781891> 12:33:48.215046 IP (tos 0x0, ttl 64, id 61462, offset 0, flags [DF], proto: TCP (6), length: 196) ldap.48322 > ldap.ssh: P 757:901(144) ack 877 win 279 <nop,nop,timestamp 129781891 129781891> 12:33:48.221627 IP (tos 0x0, ttl 64, id 23785, offset 0, flags [DF], proto: TCP (6), length: 772) ldap.ssh > ldap.48322: P 877:1597(720) ack 901 win 279 <nop,nop,timestamp 129781893 129781891> 12:33:48.222696 IP (tos 0x0, ttl 64, id 61463, offset 0, flags [DF], proto: TCP (6), length: 68) ldap.48322 > ldap.ssh: P, cksum 0xfe38 (incorrect (-> 0xe90b), 901:917(16) ack 1597 win 290 <nop,nop,timestamp 129781893 129781893> 12:33:48.256082 IP (tos 0x0, ttl 64, id 23786, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: ., cksum 0xf335 (correct), 1597:1597(0) ack 917 win 279 <nop,nop,timestamp 129781903 129781893> 12:33:48.256088 IP (tos 0x0, ttl 64, id 61464, offset 0, flags [DF], proto: TCP (6), length: 100) ldap.48322 > ldap.ssh: P 917:965(48) ack 1597 win 290 <nop,nop,timestamp 129781903 129781903> 12:33:48.256092 IP (tos 0x0, ttl 64, id 23787, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: ., cksum 0xf2fb (correct), 1597:1597(0) ack 965 win 279 <nop,nop,timestamp 129781903 129781903> 12:33:48.256269 IP (tos 0x0, ttl 64, id 23788, offset 0, flags [DF], proto: TCP (6), length: 100) ldap.ssh > ldap.48322: P 1597:1645(48) ack 965 win 279 <nop,nop,timestamp 129781903 129781903> 12:33:48.256407 IP (tos 0x0, ttl 64, id 61465, offset 0, flags [DF], proto: TCP (6), length: 116) ldap.48322 > ldap.ssh: P 965:1029(64) ack 1645 win 290 <nop,nop,timestamp 129781903 129781903> 12:33:48.257338 IP (tos 0x0, ttl 64, id 36372, offset 0, flags [DF], proto: TCP (6), length: 254) ldap.36363 > ldap.ldap: P 545516257:545516459(202) ack 552281149 win 257 <nop,nop,timestamp 129781903 129725986> 12:33:48.258726 IP (tos 0x0, ttl 64, id 17236, offset 0, flags [DF], proto: TCP (6), length: 66) ldap.ldap > ldap.36363: P, cksum 0xfe36 (incorrect (-> 0x9e99), 1:15(14) ack 202 win 273 <nop,nop,timestamp 129781903 129781903> 12:33:48.258735 IP (tos 0x0, ttl 64, id 36373, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.36363 > ldap.ldap: ., cksum 0xe62d (correct), 202:202(0) ack 15 win 257 <nop,nop,timestamp 129781903 129781903> 12:33:48.264465 IP (tos 0x0, ttl 64, id 23789, offset 0, flags [DF], proto: TCP (6), length: 132) ldap.ssh > ldap.48322: P 1645:1725(80) ack 1029 win 279 <nop,nop,timestamp 129781903 129781903> 12:33:48.296113 IP (tos 0x0, ttl 64, id 61466, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: ., cksum 0xf226 (correct), 1029:1029(0) ack 1725 win 290 <nop,nop,timestamp 129781913 129781903> 12:33:56.841644 IP (tos 0x0, ttl 64, id 61467, offset 0, flags [DF], proto: TCP (6), length: 196) ldap.48322 > ldap.ssh: P 1029:1173(144) ack 1725 win 290 <nop,nop,timestamp 129784050 129781903> 12:33:56.881279 IP (tos 0x0, ttl 64, id 23790, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: ., cksum 0xe0d0 (correct), 1725:1725(0) ack 1173 win 290 <nop,nop,timestamp 129784060 129784050> 12:33:59.378221 IP (tos 0x0, ttl 64, id 23791, offset 0, flags [DF], proto: TCP (6), length: 132) ldap.ssh > ldap.48322: P 1725:1805(80) ack 1173 win 290 <nop,nop,timestamp 129784684 129784050> 12:33:59.378239 IP (tos 0x0, ttl 64, id 61468, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: ., cksum 0xdb96 (correct), 1173:1173(0) ack 1805 win 290 <nop,nop,timestamp 129784684 129784684> 12:34:03.949451 IP (tos 0x0, ttl 64, id 61469, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: F, cksum 0xd71f (correct), 1173:1173(0) ack 1805 win 290 <nop,nop,timestamp 129785826 129784684> 12:34:03.952113 IP (tos 0x0, ttl 64, id 23792, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.ssh > ldap.48322: F, cksum 0xd2a7 (correct), 1805:1805(0) ack 1174 win 290 <nop,nop,timestamp 129785827 129785826> 12:34:03.952132 IP (tos 0x0, ttl 64, id 61470, offset 0, flags [DF], proto: TCP (6), length: 52) ldap.48322 > ldap.ssh: ., cksum 0xd2a6 (correct), 1174:1174(0) ack 1806 win 290 <nop,nop,timestamp 129785827 129785827>
Peter
On Wed, Dec 16, 2009 at 11:47 AM, nate centos@linuxpowered.net wrote:
Peter Serwe wrote:
I've been unsuccessfully trying to get nss_ldap to work. I've chased
down
hundreds of google searches over the last 3 days, and I can't seem to get
a
centos system to authenticate against ldap.
Every daemon on the system is running into the same problem:
Disable all SSL/TLS functions on the server and client and try it in the most basic mode, if it still doesn't work run tcpdump to look at what is actually being sent and what the response is.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Craig White -
Devin Reade -
m.roth＠5-cent.us -
nate -
Peter Serwe -
Steve Thompson