nss_ldap under Solaris 10

[Paul B. Henson]

We are trying to integrate Solaris 10 into an existing openLDAP based
system currently used by our Linux servers. We use nss_ldap for Linux
(obviously) which has worked very well for us.

I thought I'd try to get the native client working under Solaris just for
support purposes (even though I didn't like it upon first sight), but have
run into two showstopper problems.

First, there is no way to use TLS encryption for the client unless you are
also authenticating to the LDAP server.

It seems to me these two options should not be intertwined and serve
different purposes. The only reason to authenticate to the LDAP server is
if the naming services information required is not publicly readable.
However, you should *always* use TLS to verify the authenticity of the LDAP
server and prevent a malicious man in the middle from spoofing your
directory and feeding you invalid information. We are not going to deal
with the management overhead of creating/maintaining service accounts for
every Solaris server on campus that wishes to avail of central naming
services, that is ridiculous. However, it is unacceptable to run the client
in a mode that does not verify the server.

Second, our LDAP group implementation is based on rfc2307bis, and uses
groupOfName/member to store group information, not posixGroup/memberUid.
nss_ldap supports this perfectly, and in general I think it's a better
approach. The Solaris client does not support this, and hence is unable to
determine group memberships.

So, at this point I decided to try and rip out the native client and
install nss_ldap. Reviewing the documentation for the current version, the
ANNOUNCE file only mentions Solaris 2.4-9. The README file indicates it has
been built under Solaris 10 though.

I was able to compile it successfully with the Sun bundled gcc using the
Sun LDAP libraries, and some initial testing with plaintext looks
promising. I haven't gotten TLS working yet, as the Sun libraries require
annoying cert8.db and key3.db files rather than simple plain text PEM
certificate files.

Are there any caveats or potential problems with running nss_ldap under
Solaris 10? I found some problem reports via Google but it wasn't clear
whether those were actual issues are simply local configuration mistakes.
Any commentary be much appreciated...

I apologize if this has been recently discussed, I tried to search the
archives at http://www.netsys.com/nssldap/, but that server seems
unresponsive.

Thanks...


--
Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@...
California State Polytechnic University  |  Pomona CA 91768

[Matthew Hardin]

Hi Paul,

Paul B. Henson wrote:

> We are trying to integrate Solaris 10 into an existing openLDAP based
> system currently used by our Linux servers. We use nss_ldap for Linux
> (obviously) which has worked very well for us.
>
> I thought I'd try to get the native client working under Solaris just for
> support purposes (even though I didn't like it upon first sight), but have
> run into two showstopper problems.
>
> First, there is no way to use TLS encryption for the client unless you are
> also authenticating to the LDAP server.
>
> [snip]  

We at Symas have successfully built and packaged pam_ldap and nss_ldap
for Solaris 10. There have been no reported issues with our current
releases, and the packages appear to be working well at a number of
large and small sites.

One thing to watch for in the standard build for nss_ldap that uses SSL,
particularly on Solaris, is the namespace pollution that takes place if
nss_ldap is loaded directly into a process's namespace. This can cause
segfaults and other anomalous behavior in programs like sshd. Using
Sun's (broken) LDAP libraries may mitigate this somewhat. We worked
around this through a different approach.
> I apologize if this has been recently discussed, I tried to search the
> archives at http://www.netsys.com/nssldap/, but that server seems
> unresponsive.
>
>  
Hasn't been discussed in recent memory...
> Thanks...
>
>  
--

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

[Dan Am-3]

Hello,
we compiled nss_ldap on Solaris  with Openldap Libraries a couple of years ago. Only issue was the
CDE Screensaver, which crashed and had to be replaced with xsreensaver by fiddling the /etd/dt files.
This authentices againt MS-AD, which also implements rfc2307bis.
Out of plain lazyless we tried the libraries on Solaris 10 and they worked fine.
HTH
Dan

2008/1/19, Matthew Hardin <mhardin@... >:

Hi Paul,

Paul B. Henson wrote:

> We are trying to integrate Solaris 10 into an existing openLDAP based
> system currently used by our Linux servers. We use nss_ldap for Linux
> (obviously) which has worked very well for us.
>
> I thought I'd try to get the native client working under Solaris just for
> support purposes (even though I didn't like it upon first sight), but have
> run into two showstopper problems.
>
> First, there is no way to use TLS encryption for the client unless you are
> also authenticating to the LDAP server.
>
> [snip]

We at Symas have successfully built and packaged pam_ldap and nss_ldap
for Solaris 10. There have been no reported issues with our current
releases, and the packages appear to be working well at a number of
large and small sites.

One thing to watch for in the standard build for nss_ldap that uses SSL,
particularly on Solaris, is the namespace pollution that takes place if
nss_ldap is loaded directly into a process's namespace. This can cause
segfaults and other anomalous behavior in programs like sshd. Using
Sun's (broken) LDAP libraries may mitigate this somewhat. We worked
around this through a different approach.
> I apologize if this has been recently discussed, I tried to search the
> archives at http://www.netsys.com/nssldap/, but that server seems
> unresponsive.
>
>
Hasn't been discussed in recent memory...
> Thanks...
>
>
--

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

--
================================================================
Daniel Amthor (Projektmanagement, Technische Leitung); http://www.linworks.de

LINworks GmbH; Postanschrift: Postfach 100121, 64201 Darmstadt
Hausanschrift: Robert-Koch-Str. 9; 64331  Weiterstadt DE
Tel.: [phone], Fax: -299
Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB 85202
Geschäftsführer: Metin Dogan, Oliver Michel
________________________________________________________________

GPG-Fingerprint: BFB0 2A88 7930 E52B B20A  1FCC 5211 7A54 0BAA BD5C

[Paul B. Henson]

On Sat, 19 Jan 2008, Matthew Hardin wrote:

> We at Symas have successfully built and packaged pam_ldap and nss_ldap
> for Solaris 10. There have been no reported issues with our current
> releases, and the packages appear to be working well at a number of large
> and small sites.

Thanks for the feedback. I did some initial testing compiled against the
native Sun LDAP libraries, I got it working in plain text okay but not with
SSL. I knew I had the certificates configured correctly for the Sun
libraries because the native ldapsearch command worked fine, but nss_ldap
would only complain it could not contact the server. I saw traffic to the
SSL port, I'm assuming some incompatibility between nss_ldap and the Sun
SSL stuff.

Unfortunately my budget precludes purchasing your packages :)...


> One thing to watch for in the standard build for nss_ldap that uses SSL,
> particularly on Solaris, is the namespace pollution that takes place if
> nss_ldap is loaded directly into a process's namespace. This can cause

I've actually had similar issues under Linux. One time I ended up with
nss_ldap linked against an older version of openSSL than sshd, with rather
annoying failures. That is the one thing I think Sun got right, splitting
up the process actually contacting the LDAP server away from the client
calling it. It would be nice if nss_ldap could evolve such a mechanism with
a dedicated daemon for LDAP communications and a small nss stub
communicating via basic sockets to prevent namespace pollution...

Thanks...


--
Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@...
California State Polytechnic University  |  Pomona CA 91768

[Jacob Pszonowsky]

You might take a look at nss_ldapd. I haven't used it yet, but it  
splits the nss calls from the ldap library.

http://ch.tudelft.nl/~arthur/nss-ldapd/

-jake

Jacob Pszonowsky

jdp16@...
(c) 415.225.2647
(f) 415.358.5918



On Jan 22, 2008, at 5:14 PM, Paul B. Henson wrote:

> On Sat, 19 Jan 2008, Matthew Hardin wrote:
>
>> We at Symas have successfully built and packaged pam_ldap and  
>> nss_ldap
>> for Solaris 10. There have been no reported issues with our current
>> releases, and the packages appear to be working well at a number of  
>> large
>> and small sites.
>
> Thanks for the feedback. I did some initial testing compiled against  
> the
> native Sun LDAP libraries, I got it working in plain text okay but  
> not with
> SSL. I knew I had the certificates configured correctly for the Sun
> libraries because the native ldapsearch command worked fine, but  
> nss_ldap
> would only complain it could not contact the server. I saw traffic  
> to the
> SSL port, I'm assuming some incompatibility between nss_ldap and the  
> Sun
> SSL stuff.
>
> Unfortunately my budget precludes purchasing your packages :)...
>
>
>> One thing to watch for in the standard build for nss_ldap that uses  
>> SSL,
>> particularly on Solaris, is the namespace pollution that takes  
>> place if
>> nss_ldap is loaded directly into a process's namespace. This can  
>> cause
>
> I've actually had similar issues under Linux. One time I ended up with
> nss_ldap linked against an older version of openSSL than sshd, with  
> rather
> annoying failures. That is the one thing I think Sun got right,  
> splitting
> up the process actually contacting the LDAP server away from the  
> client
> calling it. It would be nice if nss_ldap could evolve such a  
> mechanism with
> a dedicated daemon for LDAP communications and a small nss stub
> communicating via basic sockets to prevent namespace pollution...
>
> Thanks...
>
>
> --
> Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/ 
> ~henson/
> Operating Systems and Network Analyst  |  henson@...
> California State Polytechnic University  |  Pomona CA 91768

[Tony Earnshaw-4]

Jacob Pszonowsky skrev, on 23-01-2008 05:12:

> You might take a look at nss_ldapd. I haven't used it yet,

I use it on a regular basis on 32-bit FC and RHEL5; on these platforms
its very good, but segfaults when built on RHEL5 x86_64 platforms with a
64-bit libnss_ldap.so.2 (the author is aware of this).

> but it splits
> the nss calls from the ldap library.

No it doesn't, it "splits" nss from pam. All nss calls still do whatever
/etc/nsswitch.conf is configured for.

> http://ch.tudelft.nl/~arthur/nss-ldapd/

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Paul B. Henson]

On Tue, 22 Jan 2008, Jacob Pszonowsky wrote:

> You might take a look at nss_ldapd. I haven't used it yet, but it
> splits the nss calls from the ldap library.
>
> http://ch.tudelft.nl/~arthur/nss-ldapd/

I actually came across that a while back, but at the time it was very
alpha. Looks like it's come quite a ways and might soon be a viable
alternative. Of course, given one of their initial goals was to remove all
of the portability code in favor of simplicity, it's unlikely to work under
Solaris anytime soon :)...


--
Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@...
California State Polytechnic University  |  Pomona CA 91768

[Paul B. Henson]

On Tue, 22 Jan 2008, Tony Earnshaw wrote:

> I use it on a regular basis on 32-bit FC and RHEL5; on these platforms
> its very good, but segfaults when built on RHEL5 x86_64 platforms with a
> 64-bit libnss_ldap.so.2 (the author is aware of this).

Hmm, all of our production Linux is 64-bit.

> > but it splits the nss calls from the ldap library.
>
> No it doesn't, it "splits" nss from pam. All nss calls still do whatever
> /etc/nsswitch.conf is configured for.

I believe what he means is that the client code making nss calls does not
involve the LDAP library.


--
Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@...
California State Polytechnic University  |  Pomona CA 91768