pam_ldap and sudo - help if you can

[Steven Romero]

Aaron,

Thanks for the response.  I've got debugging turned on, and pam just spits out:

load_modules: can not open module /usr/lib/security/pam_ldap.so.1

so it seems like it can't find/read the pam_ldap module when I execute sudo.

When I do a truss the only peculiar thing that I see is:

open("/usr/local/lib/lib/libldap.so.2", O_RDONLY) Err#2 ENOENT
open("/usr/lib/libldap.so.2", O_RDONLY)         Err#2 ENOENT

which is not where my libldap.so.2 is located, so I tried to fool the 
system by putting it in the spots that it is looking for them in, but that 
didn't work.  I'm not sure what is telling  pam_ldap to look for them in 
the areas noted above.

The same thing shows up in a core file that is produced when I try to 
telnet to the system with pam_ldap enabled for telnet:

X/usr/local/lib/lib
ld.so.1: login: fatal: libldap.so.2: open failed: No such file or directory 
(YEAH I KNOW BECAUSE THAT'S NOT WHERE IT'S INSTALLED YOU *&^%$^&*#@ PROGRAM!!!)

I never applied the patch you mentioned (I think somebody narrowed it down 
to 108993), but revision 5 of it was already installed on a newly built 
system, so I hope that isn't what's causing this as I can't remove it:

108993    05        20    SunOS 5.8: LDAP2 Patch

bash-2.03# patchrm 108993
Checking installed patches...
Patch 108993 was installed without backing up the original files.
It cannot be backed out.

Somebody on the pam_ldap list suggested I investigate using crle, so I'm 
looking into that now.

Thanks again.  If anything here pokes anybodys' brain into a solution 
please let me know.  In the meantime I will continue pulling out my hair, 
and chewing on tin foil.

Regards,
Steven Romero

At 07:18 PM 7/9/2003 -0500, you wrote:
>Steven,
>
>There are a couple of things to check.  I can't remember anything special 
>about
>the build but it was a while back when I compiled it.
>
>Here are some things to do to help debug the problem:
>
>touch /etc/pam_debug
>echo "auth.debug /etc/pam_debug" >> /etc/syslog.conf
>pkill -HUP syslogd
>
>Then do a tail -f /etc/pam_debug while doing sudo -s.  That should help shed
>some light on things.
>
>Look over your /etc/pam.conf also.  Contrary to popular belief, you don't need
>seperate entries for every potential application.  Pam allows you to have an
>"other" application to pick up unnamed applications.  (Such as Sudo, SSHD, and
>the like).
>
>Another thing you might try is as root do a 'truss sudo -s' to watch what is
>happening.  You can then watch the system calls fly by to help debug the
>problem.  You will probably have to enable root to use sudo in your sudoers
>defaults.
>
>One last thing.  Recently Sun has released a patch in their Latest Recommend
>Patch cluster that blows up most PAM libraries.  I recommend not loading it.
>(I cannot remember the exact patch number - sorry).  The patch is intended to
>make Solaris 8 run like Solaris 9's native pam_ldap.  Trouble is that it 
>munges
>your /etc/pam.conf pretty bad and anything linked against the older libpam has
>to be recompiled.
>
>I hope this helps.
>   - Aaron
>
>I hope this all helps.
>
>  -Aaron
>
>Steven Romero wrote:
>
> > Aaron,
> >
> > Sorry to bother you, but I noticed you guys were in the process of setting
> > up LDAP with a sudo schema.  Sounds cool, but I'm not that far yet.  I'm
> > still haveing problems getting sudo to work with pam_ldap.
> >
> > I keep getting the following error every time I try to execute sudo using
> > pam_ldap:
> >
> > bash-2.03$ sudo -s
> > sudo: pam_authenticate: Dlopen failure
> >
> > pam_ldap is working happily with ssh, so I know I my setup with regards to
> > that subsystem is correct.
> >
> > I've checked everything I can think of (permissions, linking, shared
> > libraries, etc) regarding the sudo problem, but cannot figure out how to
> > get this to work on Solaris 8.  Did you ever have this problem with sudo,
> > or have you heard of it, and if so do you know how to get around it?
> >
> > Again, don't mean to be a pain, but I'm sort of at the end of my rope here.
> >
> > Thanks again.
> >
> > Regards,
> > Steven Romero