| View previous topic :: View next topic |
| Author |
Message |
bone
Apprentice
Joined: 07 Jun 2002
Posts: 255
Location: Midwest, USA
|
 Posted: Mon Mar 21, 2005 1:56 pm Post subject: LDAP recently not working |
 |
|
Ok. Up until about a month ago, my LDAP was working properly. All of a sudden, my ldap users couldnt log in via password, only if they had already had public key auth set up. Now, after a reboot I cant even su to those users as root.
| Code: |
*[root@bordergw:~] su - bone
Unknown id: bone
*[root@bordergw:~]
|
ldapsearch seems to work properly so I know the system should be able to query the ldap server (it's localY).
Note, I have removed a few lines from the output below:
| Code: |
*[root@bordergw:~] ldapsearch
# bone, People, bone.ath.cx
dn: uid=bone,ou=People,dc=bone.ath,dc=cx
uid: bone
cn: bone
homeDirectory: /home/bone
uidNumber: 1000
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
gidNumber: 1000
gecos: bone
sn: bone
loginShell: /bin/bash
shadowLastChange: 12859
# search result
search: 2
result: 0 Success
# numResponses: 21
# numEntries: 20
*[root@bordergw:~]
|
/etc/nsswitch.conf looks like hte following:
| Code: |
*[root@bordergw:~] cat /etc/nsswitch.conf
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo-src/rc-scripts/etc/nsswitch.conf,v 1.4 2002/11/18 19:39:22 azarah Exp $
#passwd: compat
#shadow: compat
#group: compat
# passwd: db files nis
# shadow: db files nis
# group: db files nis
passwd: files ldap
shadow: files ldap
group: files ldap
hosts: files dns ldap
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
*[root@bordergw:~]
|
Now at this point I would say that everything was set up right, but let me paste some of my pam.d files:
| Code: |
*[root@bordergw:/etc/pam.d] cat login
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
# If you want to enable pam_console, uncomment the following line
# and read carefully README.pam_console in /usr/share/doc/pam*
#session optional /lib/security/pam_console.so
*[root@bordergw:/etc/pam.d]
*[root@bordergw:/etc/pam.d] cat sshd
#%PAM-1.0
auth required pam_stack.so service=system-auth
auth required pam_shells.so
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
*[root@bordergw:/etc/pam.d]
*[root@bordergw:/etc/pam.d] cat su
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
# If you want to restrict users begin allowed to su even more,
# create /etc/security/suauth.allow (or to that matter) that is only
# writable by root, and add users that are allowed to su to that
# file, one per line.
#auth required /lib/security/pam_listfile.so item=ruser sense=allow onerr=fail file=/etc/security/suauth.allow
# Uncomment this to allow users in the wheel group to su without
# entering a passwd.
#auth sufficient /lib/security/pam_wheel.so use_uid trust
# Alternatively to above, you can implement a list of users that do
# not need to supply a passwd with a list.
#auth sufficient /lib/security/pam_listfile.so item=ruser sense=allow onerr=fail file=/etc/security/suauth.nopass
# Comment this to allow any user, even those not in the 'wheel'
# group to su
#auth required /lib/security/pam_wheel.so use_uid
auth required /lib/security/pam_stack.so service=system-auth
auth sufficient /lib/security/pam_stack.so service=wheel
auth sufficient /lib/security/pam_stack.so service=wheel-ldap
auth required /lib/security/pam_deny.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_xauth.so
*[root@bordergw:/etc/pam.d]
*[root@bordergw:/etc/pam.d] cat system-auth
#%PAM-1.0
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok nodelay
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so
account sufficient /lib/security/pam_unix.so
account sufficient /lib/security/pam_ldap.so
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/pam_ldap.so use_authtok
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session optional /lib/security/pam_ldap.so
session required /lib/security/pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=077
*[root@bordergw:/etc/pam.d]
|
Does anyone else see anything I am missing?
HELP....
jt |
|
| Back to top |
|
 |
bone
Apprentice
Joined: 07 Jun 2002
Posts: 255
Location: Midwest, USA
|
| Posted: Mon Mar 21, 2005 2:02 pm Post subject: |
|
|
Also note, since pam was upgraded recently, I have even went the step to add package.mask entries for pam-login and pam in /etc/portage and downgrade these packages. This unfortunately did not help at all.
*[root@bordergw:/etc/portage] emerge -p world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild UD] sys-apps/pam-login-3.14 [3.17]
[ebuild UD] sys-libs/pam-0.78 [0.78-r2]
*[root@bordergw:/etc/portage] |
|
| Back to top |
|
|
bone
Apprentice
Joined: 07 Jun 2002
Posts: 255
Location: Midwest, USA
|
| Posted: Wed Mar 23, 2005 9:22 pm Post subject: |
|
|
It looks like after messing around with a few ebuilds and downgrading versions, I have fixed the problem. After downgrading nss_ldap the system started to atempt to work correctly. I then downgraded a few other packages recompiling them in the process.
*[root@bordergw:~] cat /etc/portage/package.mask
>=sys-libs/cracklib-2.8.2
>=sys-apps/pam-login-3.17
>=sys-libs/pam-0.78
>=net-libs/nss_ldap-233
*[root@bordergw:~]
Here are the last few ebuild versions that I downgraded/emerged.
-rw-r--r-- 1 root root 1269 Mar 22 18:30 /var/db/pkg/net-libs/nss_ldap-226/nss_ldap-226.ebuild
-rw-r--r-- 1 root root 37296 Mar 22 20:34 /var/db/pkg/sys-libs/glibc-2.3.4.20050125-r1/glibc-2.3.4.20050125-r1.ebuild
-rw-r--r-- 1 root root 2876 Mar 22 20:36 /var/db/pkg/sys-apps/pam-login-3.17/pam-login-3.17.ebuild
-rw-r--r-- 1 root root 10742 Mar 22 20:38 /var/db/pkg/sys-libs/pam-0.78-r2/pam-0.78-r2.ebuild
-rw-r--r-- 1 root root 1420 Mar 22 20:39 /var/db/pkg/sys-libs/cracklib-2.8.2/cracklib-2.8.2.ebuild
Hope this comes in handy for someone else.
jt |
|
| Back to top |
|
|
mrness
Retired Dev
Joined: 17 Feb 2004
Posts: 375
Location: bucharest.ro
|
| Posted: Fri Apr 01, 2005 8:49 pm Post subject: |
|
|
Today I tried nss_ldap/pam_ldap and I can say you definitely don't need any downgrades to make it work.
All you have to do is:
- make sure passwords are stored with {crypt} and visible to the client machine
- if ldapsearch does not return the proper results, try stopping slapd, run slapindex and start back the slapd daemon
of course ymmv... |
|
| Back to top |
|
|
bone
Apprentice
Joined: 07 Jun 2002
Posts: 255
Location: Midwest, USA
|
| Posted: Thu May 05, 2005 11:41 pm Post subject: |
|
|
| mrness wrote: | Today I tried nss_ldap/pam_ldap and I can say you definitely don't need any downgrades to make it work.
All you have to do is:
- make sure passwords are stored with {crypt} and visible to the client machine
- if ldapsearch does not return the proper results, try stopping slapd, run slapindex and start back the slapd daemon
of course ymmv... |
crypt? I use MD5. Maybe that's my problem. When did this switch, and what do I need to change to make my system work properly with the newer stuff. |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sun Aug 07, 2005 4:58 pm Post subject: |
|
|
| mrness wrote: | Today I tried nss_ldap/pam_ldap and I can say you definitely don't need any downgrades to make it work.
All you have to do is:
- make sure passwords are stored with {crypt} and visible to the client machine
- if ldapsearch does not return the proper results, try stopping slapd, run slapindex and start back the slapd daemon
of course ymmv... |
Why should I downgrade to {crypt}? can't nss just try to BIND? Personaly I use SMD5 and it worked fine... |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sat Sep 17, 2005 1:56 pm Post subject: |
|
|
I tried again, but didn't get it to work.....
ldap-search worked, getent passwd worked, but sshd couldn't find the user.....
downgraded to 226 solved everything...
any idea what is wrong? |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Thu Oct 27, 2005 3:51 pm Post subject: |
|
|
| I got 239 to work... had something to do with SSL here |
|
| Back to top |
|
|
|
Networking & Security
