Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Solaris clients + eDirectory 8.7.1/LDAP?

34 views
Skip to first unread message

Ryan Anderson

unread,
Dec 15, 2003, 1:57:06 PM12/15/03
to
Based on all the posts I've read, I've not seen one person say
affirmatively that they've gotten Solaris clients to work with
eDirectory as an LDAP server. Does anyone out there have this working?
If so, what did you have to modify to get it to work? What version of
eDirectory are you using?

The boiler-plate response to most every posting is 'look at the 6/02
appnote', or 'look at the TIDs that say how to do this on Linux'. While
the 6/02 appnote is very _helpful_, its instructions apply to an older
version of eDirectory, and using the Netscape libraries. I followed them
faithfully, and got no joy. For example, on 8.7.1 you do not need to
modify the attribute mappings like you did then--I'm not clear the
_right_ way, but I know that it does not apply anymore. Linux clients
work out-of-the-box for LDAP authentication on eDirectory 8.7.1; Solaris
does not. Also, I've compiled Padl Pty's pam_ldap and nss_ldap against
the openldap libraries, not Netscape's (SunONE now), so I can keep
consistency between Linux and Solaris. Aside from this, you're only
legally supposed to use the SunONE libraries against a SunONE directory
server (read the license). BTW: I can't get authentication with the
SunONE libs to work either.

I've worked for >2 weeks on this, and what I've gotten thus far is:

Bad
* I can't login to the Solaris clients with telnet, ssh, or on the
console as an LDAP user
* I've traced the failure to login to a posixGroup issue, Linux works
great, but Solaris doesn't. Here's the part of the dstrace logs where RH
Linux 9 and Solaris 8 clients differ:

NOT successful login from Solaris:
[2003/12/15 8:05:51] Search request:
base: "o=BAR"
scope:2 dereference:0 sizelimit:0 timelimit:10 attrsonly:0
filter: "(&(objectclass=posixGroup)(memberUid=luser))"
attribute: "cn"
attribute: "userPassword"
attribute: "memberUid"
attribute: "gidNumber"

Successful on Linux:
[2003/12/15 8:07:26] Search request:
base: "o=BAR"
scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter:
"(&(objectclass=posixGroup)(|(memberUid=luser)(uniqueMember=cn=luser,ou=FOO,o=BAR)))"
attribute: "cn"
attribute: "userPassword"
attribute: "memberUid"
attribute: "uniqueMember"
attribute: "gidNumber"

Doing 'getent group' on Linux shows the group members, ie:
linux:x:6000:lduser,meathead,testuser,luser

On solaris it doesn't:
linux:x:6000:


Good
* As root I can su to an LDAP user
* The UID <--> username mappings work (ie, nss_ldap works; I do 'ls -l'
and can see the LDAP owners of files)
* The dstrace logs show that data is being sent Solaris client
* 'getent passwd' correctly shows me the LDAP users
* TLS/SSL works. However I don't have it working as the 6/02 appnote
says, nor like in TID 10081706 (which is wrong--they don't even say to
copy a certificate file over!). I used the way in the link below.
* I have a ticket open with Novell, and they've been _very_ helpful, but
nonetheless unsuccessful in getting my Solaris clients to work.
* I've found one guy who got this to work with eDir 8.6.2 (I still can't
get it to work on 8.7.1 though!):
http://www.wright.edu/~mike.corcoran/htmldocs/applications/pam_ldap/configuring_pam_ldap_and_nss_ldap.html


Any help appreciated!


Ryan Anderson

Jim Willeke

unread,
Dec 15, 2003, 5:55:41 PM12/15/03
to
We have setup PADL on several customers Solaris servers without any
major issues.

We have not used the SOalris client as it has several "SUN" Specific
schema modifications that do not work with other clients.
-jim

Ryan Anderson

unread,
Dec 16, 2003, 9:06:20 AM12/16/03
to
This is comforting to hear. I'm trying very hard to use Padl's pam_ldap
and nss_ldap, Sun's included LDAP client functionality is very lacking
for what I need to do.

Have you used eDirectory 8.7.1 in any of your successful installations?
Did you need to make any modifications to the LDAP group attribute
mappings to get it to work with Solaris 8 clients? Did you need to put
any special pam or nss attribute mappings or filters in the client's
/etc/ldap.conf files?

I have RH Linux 9 clients working flawlessly using a stock eDirectory
8.7.1 install, but making Solaris 8 clients has eluded me, so any help
is appreciated.


Regards,

Ryan

David Gersic

unread,
Dec 16, 2003, 3:32:19 PM12/16/03
to
On Mon, 15 Dec 2003 18:57:06 GMT, Ryan Anderson <ryan.a...@udlp.com> wrote:

>Based on all the posts I've read, I've not seen one person say
>affirmatively that they've gotten Solaris clients to work with
>eDirectory as an LDAP server. Does anyone out there have this working?

I haven't done it lately, but I've used OpenLDAP on Solaris against eDir via
LDAP with no problems. I'm currently using OpenLDAP on Linux against eDir.

>If so, what did you have to modify to get it to work?

Get *what* to work?


---------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu

I'm tired of receiving rubbish in my mailbox, so the E-mail address is
munged to foil the junkmail bots. Humans will figure it out on their own.

Ryan Anderson

unread,
Dec 16, 2003, 5:01:23 PM12/16/03
to
My first post was too verbose ;-) The problem was buried deep in it.

I can't login (ssh/telnet/etc) directly as an LDAP user on Solaris
clients (I can on Linux), though I can do 'getent passwd' and see the
users, doing 'ls -l' on files I created with LDAP user UID numbers show
their UIDs, and as root I can su to LDAP users.

The issue seems to be a 'group' issue. Doing 'getent group' on Solaris
will list the groups, but with no members. Doing the same on Linux lists
the groups + members. Making 'ldap' not be a name service for group in
/etc/nsswitch.conf doesn't help either. I can see from the eDirectory
LDAP logs that Linux gives LDAP a uniqueMember attribute to the
posixGroup class, but Solaris does not. Both OS's use Padl's pam_ldap
and nss_ldap.

Thanks,
Ryan

Matt Ross

unread,
Dec 17, 2003, 6:29:48 AM12/17/03
to
"Ryan Anderson" <ryan.a...@udlp.com> wrote in message
news:TgLDb.5763$Rl1....@prv-forum2.provo.novell.com...

> My first post was too verbose ;-) The problem was buried deep in it.
>
> I can't login (ssh/telnet/etc) directly as an LDAP user on Solaris
> clients (I can on Linux), though I can do 'getent passwd' and see the
> users, doing 'ls -l' on files I created with LDAP user UID numbers show
> their UIDs, and as root I can su to LDAP users.
>
> The issue seems to be a 'group' issue. Doing 'getent group' on Solaris
> will list the groups, but with no members. Doing the same on Linux lists
> the groups + members. Making 'ldap' not be a name service for group in
> /etc/nsswitch.conf doesn't help either. I can see from the eDirectory
> LDAP logs that Linux gives LDAP a uniqueMember attribute to the
> posixGroup class, but Solaris does not. Both OS's use Padl's pam_ldap
> and nss_ldap.
>
> Thanks,
> Ryan

Have you given [Public] trustee rights of Read to the following attributes?

cn
homeDirectory
gecos
uidNumber
gidNumber
loginShell
memberUid
uniqueID

I have some notes I wrote when I was setting up Solaris 8 boxes with
eDirectory 8.7 (not 8.7.1). They are based on the iPlanet SDK but I have
since switched to OpenLDAP with few problems. Let me know if you're
interested and I can e-mail it to you.

--
Matt Ross

-=I haven't lost my mind; it's backed up on tape.=-


Matt Ross

unread,
Dec 17, 2003, 10:42:46 AM12/17/03
to
In a follow-up e-mail I asked Ryan to check all the necessary libraries were
accessible, using ldd under Solaris.

Ryan Anderson

unread,
Dec 19, 2003, 12:05:56 PM12/19/03
to
Matt Ross wrote:
> In a follow-up e-mail I asked Ryan to check all the necessary libraries were
> accessible, using ldd under Solaris.
>
My ldd listings were correct and didn't need any mods.

I can telnet/ssh into my Solaris 8 boxes now. My compiled libraries
weren't an issue all along. Getting rid of the Account Management Unix
snap-in to ConsoleOne, then extending each user manually with
posixAccount and shadowAccount solved the issue. You also need to add in
loginShell in the 'other' tab. I was also missing shadowAccount <-->
shadowAccount mappings in the LDAP Group. From here on out, I'm using
LDIF files to create users: GUI = EVIL.

Interestingly, Linux clients didn't care, which miffs me because they
are using the same Padl libs. From the DSTRACE logs it looks almost like
their padl library calls a full search like you would with 'ldapsearch'
and nabs what it needs, while the Solaris one is more strictly limited
by every object being where its supposed to be... Conspiracy theory anyone??

I have only one issue remaining: groups. Doing 'getent group' on Solaris
shows each posixGroup from the LDAP server, but it shows no members.
Doing the same command on Linux shows the members. Also, as a logged-in
LDAP user, if I do the command 'groups' on Solaris, it only shows my
default group. If I do the same on Linux, it shows all the groups I'm a
member of.

Any ideas?


THANKS!

Ryan

Jim Henderson [SysOp]

unread,
Dec 23, 2003, 3:18:15 AM12/23/03
to
On Fri, 19 Dec 2003 17:05:56 +0000, Ryan Anderson wrote:

> Also, as a logged-in
> LDAP user, if I do the command 'groups' on Solaris, it only shows my
> default group. If I do the same on Linux, it shows all the groups I'm a
> member of.

I'd probably take a LAN trace, or look in DSTRACE at the request through
the LDAP server and see what differences there are in the request/reply
packets.

Jim

--
Jim Henderson, Novell Support Forums Volunteer SysOp
Homepage at http://hendersj.dyndns.org
Sorry, no support provided via e-mail

Ryan Anderson

unread,
Jan 12, 2004, 5:16:59 PM1/12/04
to
I can do a successful TLS connection to eDirectory 8.7.1 from Unix if I
do something like:

ldapsearch -h server1 -ZZ "cn=ldapuser" cn gecos loginshell (the -ZZ
option forces TLS, and fails if it can't get a secure connection)

However, getting TLS to work via Padl's pam_ldap.so, configured through
/etc/ldap.conf is eluding me. I've tried this on Solaris and Linux (RH
9) with no success. I've followed this Cool Solutions article to a 'T'
also:
http://www.novell.com/coolsolutions/nds/features/a_linux_auth_ldap_edir.html

Does anyone out there have this working out there?


Thanks,

Ryan

Ryan Anderson

unread,
Jan 12, 2004, 5:12:12 PM1/12/04
to
I have Solaris authentication working now. It only started working after
I added the --enablerfc2307bis to the compilation options to nss_ldap. I
also found a cool hack to get pam_ldap.so and nss_ldap.so to be named
something different so the naming services will be unique--and won't
clobber Sun's included LDAP files. If anyone is interested, I can send
my documentation offline.

Only thing know is that I can't get SSL/TLS working via pam_ldap... I'm
going to make a new post for this.

Regards,

Ryan

Rodrick Brown

unread,
Jan 12, 2004, 10:12:09 PM1/12/04
to
send it here rbrown<at>doitt.nyc.gov

Thanks!!!


"Ryan Anderson" <ryan.a...@udlp.com> wrote in message

news:0ZEMb.12171$VM1....@prv-forum2.provo.novell.com...

Jim Henderson [SysOp]

unread,
Jan 13, 2004, 1:01:35 PM1/13/04
to
Do you see anything in the server's log files?

One thing I've found that is quite significant is that you use the correct
certificate - if the server's DNS name is used, you have to be sure to use
the CertificateDNS and not the CertificateIP.

Ryan Anderson

unread,
Jan 13, 2004, 1:24:59 PM1/13/04
to
I changed my mind. No one should have to go through what I did to get
Solaris clients working with eDirectory 8.7.1. Here is what I have so
far (note: TLS/SSL is not working yet, but everything else is):

==
eDirectory Installation Notes
-----------------------------
$Id: ldap_install_notes_scrubbed.txt,v 1.1 2004/01/13 18:15:52 anderson
Exp $

These instructions will allow you to authenticate Solaris 8 hosts
hosts to use LDAP authentication from eDirectory 8.7.1. Linux clients
are a lot easier because it comes pre-built with the Padl LDAP libraries
and you can use the same ldap.conf below.


MODIFY THE LDAP GROUP OBJECT IN EDIRECTORY
1. Find the container with the server objects, and find the object labeled:
'LDAP Group - <hostname of master>'

2. Rename it to something more all-encompassing, as this LDAP server
group will be the LDAP group for all servers and clients (Get
rid of the annoying white spaces!):

3. Right-click the LDAP Group object and:
a) Make the proxy user you created the 'Proxy Username' in the
General tab.
b) Add any servers in the same workforce tree into the Server List
tab.
c) Remove the LDAP Group objects you will not be using
d) Under the Class Mappings tab, add mappings for:
posixAccount <--> posixAccount
shadowAccount <--> shadowAccount
posixGroup <--> posixGroup

4. Open 'LDAP Server - <hostname>' for each LDAP server.
a) SSL/TLS Configuration --> Select SSL Certificate DNS
for 'Server Certificate'
COMPILE AND CONFIGURE THE PADL OPEN SOURCE LIBRARIES
* These instructions apply to Solaris only; Linux already comes with
the Padl libraries by default, so we will use them instead. However,
the /etc/ldap.conf is the same on each platform

* For Solaris, I put LDAP software into /opt/ldap so it does not
clobber Sun's software, or get lost in /usr/lib. I then make
links, but you can do it however you choose.

* Quick tutorial: nss_ldap is a replacement name service switch library
that comes with Solaris. On Linux the included one is what we will
use,
it comes from PADL also. nss_ldap simply maps UIDs to names from LDAP
in the same way /usr/lib/nss_nis.so maps UIDs and names from NIS. When
you do 'ls -l' in a directory, the OS knows to look in the naming
services
listed in nsswitch.conf, and if it has 'ldap' listed after the 'passwd'
entry, it will query /usr/lib/nss_ldap.so, which in turn looks at its
config in /etc/ldap.conf to look to the LDAP server you specify to get
UID to name mapping; NO AUTHENTICATION.

pam_ldap.so is a replacement pluggable authentication module (PAM)
library that replaces the one on Solaris at /usr/lib/security. The
sole job of this is to provide authentication. It too looks at
/etc/ldap.conf to know what server(s) to authenticate to.

1. Download openssl-0.9.7c (openssl.org), openldap-1.2.23 (openldap.org),
pam_ldap-1.66, and nss_ldap-212 (padl.com)

2. Get the right tools: A recent gcc compiled on the OS you are compiling
on (I used 3.2.3; the compile will fail if you use gcc compiled on
Solaris
2.6 on Solaris 8), gnu m4, gnu make, perl, autoconf 1.6.

3. Fix the gotchas:
a) Temporarily rename /usr/lib/libldap.so.4 during
compilation so you don't link against it (it doesn't work w/eDir),
b) You must rename /usr/ccs/bin/m4, then make a sym-link from
/usr/ccs/bin/m4 to gnu m4: cd /usr/ccs/bin; ln -s /usr/local/bin/m4
* Fix these when done compiling

4. Set your PATH to be: <path to gcc>:<path to gnu
tools>:/usr/ccs/bin:$PATH

5. Set gcc env variables to compile everthing in 32-bit mode:
export CFLAGS="-mcpu=v7 -m32"
export LDFLAGS="-mcpu=v7 -m32"

6. Compile openssl:
a) untar openssl into /var/tmp/ossl, then cd into it
b) ./Configure --prefix=/var/tmp/ossl solaris-sparcv9-gcc
c) make depend
d) make
e) make install
f) copy /var/tmp/ossl/bin/openssl to /opt/ldap/bin

7. Setup shell environment in preparation for openldap:
a) unset LD_LIBRARY_PATH
b) export CPPFLAGS="-I/var/tmp/ossl/include"
c) export LDFLAGS="$LDFLAGS -L/var/tmp/ossl/lib"
d) Fix your PATH to remove any instance of 'cc'. OpenLDAP will
use 'cc' even if gcc is in your path first!

8. Compile openldap-2.1.23:
a) cd <temp dir w/openldap>
b) ./configure --prefix=/opt/ldap --enable-syslog --disable-slapd \
--with-tls --enable-static=no
c) make
d) make depend
e) make install
NOTE: If you get errors about not finding a valid TLS/SSL library,
its probably because its trying to compile 64-bit! Make
sure you still have the 32-bit env vars from step 5.

9. Rename all occurrences of 'pam_ldap' or 'nss_ldap' in the pam_ldap and
nss_ldap source files to pam_nldap and nss_nldap (or whatever) so that
the files when compiled don't clobber files by the same name that are
part of Solaris.
a) cd <dir w/pam_ldap-166>
b) Run this shell script:
FILES=`ls`
for file in $FILES; do
perl -p -i.sav -e "s:nss_ldap:nss_nldap:g" $file
perl -p -i.sav -e "s:pam_ldap:pam_nldap:g" $file
done
c) Rename pam_ldap.* files to pam_nldap.* (or whatever)
d) cd <dir w/nss_ldap 2.12>
e) Run the same shell script after doing: FILES=`ls`
f) Rename nss_ldap.spec to nss_nldap.spec

10. Compile pam_ldap 1.66:
a) Reset your shell to have the same environmental variables
from step 5
b) cd <dir w/pam_ldap-166>
c) ./configure --prefix=/opt/ldap --enable-debug --with-ldap-dir=\
/opt/ldap --with-ldap-lib=openldap
d) make
e) Do 'ldd pam_ldap.so' and verify its linked correctly.
f) As root (set /usr/local/bin in PATH): make install

11. Compile nss_ldap 2.12:
a) cd <dir w/nss_ldap-212>
b) ./configure --prefix=/opt/ldap --enable-debug --with-ldap-dir= \
/opt/ldap --with-ldap-lib=openldap --enable-rfc2307bis
c) make
d) chmod +x install-sh
e) As root (set /usr/local/bin in PATH): make install

EXPORT AND CONVERT THE TRUSTED ROOT CERTIFICATE
[NOTE: SSL/TLS is not working yet; ignore this for now]

1. Export the Trusted Root from ConsoleOne: Open the container with the
certificate objects and right-click 'SSL CertificateDNS - <host of
Trusted Root server>', click on the Certificates tab, then click
'Export' and save out the file in binary DER format.

2. Convert it to PEM format:
/opt/ldap/bin/openssl x509 -inform DER -in <name of cert.der> \
-out <name of cert.pem> -outform PEM

3. Copy this .pem file to /etc/tls/certs


MAKE LINKS

1. Make the following sym links:
/usr/lib/nss_nldap.so.1 -> /opt/ldap/lib/nss_nldap.so.1
/usr/lib/nss_nldap.so -> /usr/lib/nss_nldap.so.1
/usr/lib/security/pam_nldap.so.1 -> /opt/ldap/lib/nss_nldap.so.1
/usr/lib/security/pam_nldap.so -> /usr/lib/security/pam_nldap.so.1
/usr/lib/security/sparcv9/pam_nldap.so.1 ->
/opt/ldap/lib/security/pam_ldap.so.1
/usr/lib/security/sparcv9/pam_nldap.so ->
/usr/lib/security/pam_ldap.so.1
SETUP THE /etc/ldap.conf FILE
On Solaris and Linux the contents are the same. Contents of the file:

*******************************************************
# @(#)Id: ldap.conf.nldap,v 1.5 2004/01/12 20:36:24 andersrc Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library (nss_ldap) and the LDAP PAM module (pam_ldap).
# PADL Software http://www.padl.com

# LDAP servers
host server1 server2

# The distinguished name of the search base.
base ou=FOO,o=BAR

ldap_version 3

# The search scope. Options are: sub, one, base
scope sub

# These were changed from the defaults for fast failover
timelimit 10
bind_timelimit 7

# Applies to SunONE only
pam_lookup_policy no

# Filter to AND with uid=%s
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute member

# RFC2307bis naming contexts
# NOTE: must compile nss_ldap.so with --enable-rfc2307bis to use this!
#
# Unix group admins are a member of; entry belongs on every
# system regardless of NIS domain. This is optional.
nss_base_passwd ou=FOO,o=BAR?sub?groupMembership=cn=admin,ou=FOO,o=BAR
# Group users are in; try to make group name the same as `domainname`
nss_base_passwd
ou=FOO,o=BAR?sub?groupMembership=cn=usersgrp,ou=FOO,o=BAR
# Where the groups are
nss_base_group ou=FOO,o=BAR?one

# attribute/objectclass mapping
# Suggested (not required) for NDS
nss_map_attribute uniqueMember member
# THIS DOESN'T WORK YET
# TLS/SSL settings
#tls_cacertfile /etc/tls/certs/TrustedRootDNS-SERVER1.pem
#tls_cacertdir /etc/tls/certs
#tls_ciphers TLSv1
ssl off
*******************************************************


SETUP THE /etc/pam.conf FILE ON SOLARIS
* No two pam.conf files are the same, and none that I've seen
get you the same behavior as the Solaris default (ie, three
failed attempts, then kicks you off).
* I'm not including one here, so look for one online or make your
own. Your basically going to have to add entries like this:

other auth sufficient pam_unix.so.1
other auth optional pam_nldap.so.1 use_first_pass
#
other account sufficient pam_unix.so.1
other account required pam_nldap.so.1
#
other session required pam_unix.so.1
#
other password required pam_unix.so.1
other password optional pam_nldap.so.1

* BTW: Since 'other' covers all services not explicitly defined,
the above is a working pam.conf

CHANGE /etc/nsswitch.conf FILE
1. passwd: files nldap [NOTFOUND=return] nis

2. group: files nldap [NOTFOUND=return] nis


ADD UNIX USERS OR GROUPS INTO EDIRECTORY OR ADD UNIX
ATTRIBUTES TO EXISTING USERS OR GROUPS

User:
1. Remove the Unix snap-in from ConsoleOne; it doesn't work

2. Create the user in ConsoleOne as is normally done. Remove the Unix
snap-in from ConsoleOne; it doesn't work well.

3. Right-click the user object --> Extensions of this Object...

4. Add Extension... --> Select posixAccount. A 'Generic editing' pop-up
will display say, just click OK. It means there is no Unix snap-in

6. Enter the following:
Name: posixAccount
homeDirectory: /home/<username>
(Create home directory from Unix and update NIS auto.home)
uniqueID: <username>
Common Name: <username>
gidNumber: <Default GID number>
uidNumber: <UID number>

Then click OK

7. Right-click the user object again --> Extensions of this Object...

8. Add Extension... --> shadowAccount. A 'Generic editing' pop-up, click OK

9. Enter the following:
Name: shadowAccount
uniqueID: <username>

Then click OK

Group:
1. Create a group object as is normally done

2. In ConsoleOne, right-click the group object --> Extensions of this
object.. --> Add Extension... --> posixGroup (ignore the
pop-up;click OK)

3. Enter the following:
Name: posixGroup
Common Name: <name of group>
gidNumber: <GID>

Then click OK

4. If a user has this GID as their default, nothing else needs to be done
to associate them with this group. If you want to add a user to the
group, you will need to add them in the Members tab in ConsoleOne.
On Unix, do 'groups' to verify they are in the group.

Michael Fischman

unread,
Jan 15, 2004, 4:33:20 PM1/15/04
to
In the login properties of the GroupWise clients the users are connecting to the IP address and in the properties of the LDAP server we are also using the IP address instead of a DNS name.

The certificates that we exported are from the CertificateDNS object.

Jim Willeke

unread,
Jan 17, 2004, 6:43:29 PM1/17/04
to
Good info
Thanks -jim
0 new messages