However, by following a nose-hair-pulling list of steps, which I shall describe herein, you can use third-party modules to browbeat solaris into doing the right thing.
If I'm missing any steps, please use the link at the bottom of the page to email me. I HAVE IT WORKING NOW, so it's simply a matter of me adequately documenting for you.
All the following should work on both intel and sparc. Making shared libraries for openldap MIGHT require gcc (unless you like rewriting makefiles). Otherwise, it shouldn't matter which compiler you use.
You will need the following modules from www.padl.com:
Additionally, you will need GNU make, and (if you havent done a full install of solaris 8, or arent running solaris 8) zlib, and perl.
The rest of this page is a collection of sections. Read the header for each section. Some day soon I'll actually make an index for this page.READ ALL THE SECTIONS AT LEAST ONCE
As I said earlier, this is a nasty long horrible sequence of steps, so even if you think you know the information in a particular section, read it anyway. There are special compile tweaks needed at pretty much every step of the way.
# cp /usr/lib/nss_ldap.so.1 /usr/lib/nss_ldap.so.1-sun # cp /usr/lib/security/pam_ldap.so.1 /usr/lib/security/pam_ldap.so.1-sun
You'll want to first grab openssl, and then make sure you compile a shared library version of it. It defaults to compiling a static library. However, unless you want to recompile all your binaries the next time an update to openssl comes out, I suggest you make a dynamic library.
Unfortunately, the latest versions of openssl (0.9.6a) don't make this easy.
Note that this is the one component that does NOT use GNU configure
First edit the Configure script, and find the "solaris-x86-gcc" line. [adjust similarly for solaris-sparcv9-gcc, etc. as needed]
./Configure solaris-x86-gcc shared make make install
If you have done this correctly, you should be able to do
LD_LIBRARY_PATH=/usr/lib ldd /usr/local/ssl/lib/libssl.soand see libcrypto linked okay.
./configure --with-ssl=/usr/lib/sslDo NOT have /usr/local/ssl/lib set in your LD_LIBRARY_PATH, or anywhere else.
Important notes on BerkeleyDB
1. Use v3.2, not v3.3!. I have heard rumors that
sleepycat changed the whole interface in 3.3, or something like that.
Bottom line: 3.2 compiles with openldap happily, and 3.3 does not.
(openldap v2.0.11)
2. Rather than fiddling with compiles, the really simple thing to do is
just add the package from the latest solaris
"Companion CD".
Otherwise, if you are compiling from source, do yourself a favour and
configure it with
./configure --prefix=/usr/local --enable-shared[or --prefix=/opt/sfw, and optionally, --enable-compat185].
export LDFLAGS CPPFLAGS LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib" LDFLAGS="$LDFLAGS -R/usr/local/ssl/lib:/usr/local/lib" CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/include" # If solaris 9, take out ssl entries[If you are using Sun's "companion CD", you are presumably using /opt/sfw/bin/gcc, which should automatically pick up that particular library. But you may want to add
LDFLAGS=-R/opt/sfw/lib
]
You should then carefully watch the output of ./configure to verify that it picks up berkeleyDB and SSL support. It probably helps to force things with
./configure --with-tls [other-options]That way, if it doesnt find it, it will complain and stop.
Unfortunately, their "libtool" is pretty damn stupid, so there's another
step to do if you want to keep going and run pam_ldap/nss_ldap on top of
openldap. AFTER you've run configure, but
BEFORE
doing a make, edit libtool
, and change LD="/usr/ccs/bin/ld" to
LD="/usr/ccs/bin/ld -R/usr/local/ssl/lib:/usr/local/lib"
Additionally, in case Sun ever fixes their client code, you'll want to add this special patch to make OpenLDAP solaris-ldap compatible for future use. (It makes your base dn show up as a "namingcontext" in the rootDSE automatically)
NOW you can run a 'make depend
', followed by 'make
'
When you're all done, and have run make install
, you know
you've done it right if you can do
LD_LIBRARY_PATH=/usr/lib ldd /usr/local/lib/libldap.soand have no "file not found" lines, AND you see libssl + libcrypto successfully mentioned. If not, go to the top of this page, start recompiling everything, and follow the instructions more carefully.
Here's a quickie method that gets you up and running with TLS (SSL) encrypted connections supported.
[First, edit /usr/local/etc/openldap/slapd.conf, play with it, and get it running happily with no frills. Then...]
You have to generate a key+certificate, like for an apache SSL cert:
cd /usr/local/etc/openldap ln -s /usr/local/ssl/bin/openssl . ln -s /usr/local/ssl/misc/CA.pl . PATH=$PATH:. CA.pl -newca [press return, then answer prompts] CA.pl -newreq [enter info you want your LDAP server to have. Ignore "extra" attributes. Note: you HAVE TO PUT IN A NAME for "commonName"] CA.pl -signreq mv newreq.pem ldapkey.pem # or, "openssl rsa -in newreq.pem -out ldapkey.pem" to remove any passphrase chmod 0600 ldapkey.pem mv newcert.pem ldapcert.pem[yes, you MUST add "." to your path, or put openssl in your PATH some other way.]
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/ldapcert.pem TLSCertificateKeyFile /usr/local/etc/openldap/ldapkey.pem TLSCACertificateFile /usr/local/etc/openldap/demoCA/cacert.pem
Then you should be able to start your ldap server with
slapd -h "ldap:/// ldaps:///"
If you want to force TLS-only, then leave out the ldap:///
. If
you have passwords in your LDAP database, I suggest you do just that.
Much thanks to John Weekley for helping me debug this section :-) There's also a bug in the openldap 2.0.7 server, that you may or may not want to patch: http://www.bayour.com/kerberos/openldap.patch
Unfortunately, solaris 8 does not natively support TLS and LDAP. So if you want to actually use TLS, you'll have to follow all the steps in this page, and use the padl pam_ldap and nss_ldap modules mentioned further down on this page.
export LDFLAGS CPPFLAGS LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib" LDFLAGS="$LDFLAGS -R/usr/local/ssl/lib:/usr/local/lib" CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/include"
Then just run ./configure
, followed by
gmake
(GNU make), and you'll get good binaries.
Warning for solaris 64-bit folks
Please note that you need to compile two versions of the PAM library;
a 32-bit one for /usr/lib/security
, and a 64-bit one to put
in /usr/lib/security/sparcv9
If you have netscape directory server on the same machine, you'll have to
specify ./configure --with-ldap-lib=openldap
so that you do
not use the netscape LDAP libraries.
The interesting bit is in installation. I would have preferred to add "open" somewhere in the names for both of them. Unfortunately, solaris nsswitch.conf will not recognize arbitrary names, therefore you MUST install the new nss_ldap, as "/usr/lib/nss_ldap.so.1". (Save the old version first).
Once you've done this add "ldap" to whatever entries you like in
/etc/nsswitch.conf
. This will enable things like "finger"
to work, once you actually put some user info in the LDAP database.
Happily, Solaris is more forgiving about PAM modules. So copy the padl PAM
module to /usr/lib/security/pam_openldap.so.1
, rather than
pam_ldap.so.
I recommend copying the sample ldap.conf over to /etc first, [since it has fairly copious comments] and then adding the following lines. Note that the ssl line is undocumented, but essential.
# Seem to need BOTH of these, PLUS port spec. # You may need to put in your FQDN here host 127.0.0.1 uri ldaps://127.0.0.1 # # Undocumented, REQUIRED element for using TLS ssl true # base dc=yourdom,dc=com rootbinddn cn=Manager,dc=yourdom,dc=com # Dont forget to put the LDAP Manager password in /etc/ldap.secret port 636 # The rest of these are primarily for the nss stuff # You'll probably want to add all the other lines mentioned in the comments # too, but this will get "finger" and login working pam_password exop nss_base_passwd ou=People,dc=yourdom,dc=com?one nss_base_shadow ou=People,dc=yourdom,dc=com?one # You may also want to adjust 'bindcn' and 'bindpw', but they were # not neccessary for my experiments.
Except that the whole point of this is to get encrypted passwords. So you'd never allow a non-encrypted medium to log in, right? So here's how to allow ssh to use the information in your LDAP data source:
sshd auth sufficient pam_openldap.so.1 sshd account sufficient pam_openldap.so.1 sshd password sufficient pam_openldap.so.1Relatively painless... as long as you remembered to compile ssh with
./configure --enable-pamIf you didn't... well, go recompile ssh now.
Keep reading for information on that stuff. Then you're all done. Have fun!
First you mkdir /etc, Then you create the file. Then you start putting
things in the file.
The difference with LDAP and x.500 is that instead of paths separate by
slashes, you have paths separated by commas and '=' signs.
For example, if you want to make an object
"cn=ldaphost,ou=hosts,dc=yourdom,dc=com", you first have to make sure
"dc=yourdom,dc=com" exists.
Then make sure
"ou=hosts,dc=yourdom,dc=com" exists.
THEN you can try
"cn=ldaphost,ou=hosts,dc=yourdom,dc=com"
include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/solaris.schemaYou then need to create the "solaris.schema" file, with the following contents at minimum:
attributetype ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' DESC 'NIS domain' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY DESC 'Associates a NIS domain with a naming context' MUST nisDomain )
Or you can download a fuller version, from http://www.tzone.org/~okapi/up2/solaris.schema
[The reason for this is that most, but not all, of the information in rfc2307 is already in "nis.schema". If you need to add any extra stuff from rfc2307, this is the place to put it. Then please let me know, so I can update the page!]
You are now ready to start populating your LDAP server like an unsecure NIS server.
Here's how to get from ground zero, to having a host and a user in your
LDAP tables.
Note that "yourpassword" is whatever you set as the rootdn password in
slapd.conf
ldapadd -D cn=Manager,dc=yourdom,dc=com -w yourpassword dn: dc=yourdom,dc=com objectclass: top objectclass: nisDomainObject nisDomain: yourdom.comPS: "dc" stands for "Domain Component"
ldapadd -D cn=Manager,dc=yourdom,dc=com -w yourpassword dn: ou=hosts,dc=yourdom,dc=com objectclass: top
ldapadd -D cn=Manager,dc=yourdom,dc=com -w yourpassword dn: cn=ldaphost,ou=hosts,dc=yourdom,dc=com cn: ldaphost ipHostNumber: 10.3.4.5 objectclass: ipHostAfter you add "ldap" to the "hosts:" entry in /etc/nsswitch.conf, you should then be able to do
telnet ldaphostand have solaris pull up the correct IP address.
Now, if you'd like to do this the EASY way, getting the "nsimport" script
from the iPlanet server distribution should populate things from your
files in /etc .
(kinda similar to nispopulate -F)
"ldapadd -Z -x -D cn=Manager,dc=yourdom,dc=com -W"
# if you havent already defined the "people" entry, do so now #ldapadd -D cn=Manager,dc=yourdom,dc=com -w yourpassword #dn: ou=people,dc=yourdom,dc=com #objectclass: top dn: cn=testuser,ou=people,dc=yourdom,dc=com objectClass: posixaccount objectClass: shadowaccount cn: testuser uid: testuser uidNumber: 820 gidNumber: 10 homeDirectory: /home/testuser userPassword: {CRYPT}9QuV2A3KTACwI loginShell: /bin/kshVarious standard container/"map" names
LDAP container | expected LDAP object types held |
---|---|
ou=aliases | mailGroup |
ou=people | posixAccount,shadowAccount |
ou=group | posixGroup |
ou=services | ipService |
ou=protocols | ipProtocols |
ou=rpc | oncRPC |
ou=hosts | ipHost |
ou=ethers | ieee802Device,bootableDevice |
ou=networks | ipNetwork |
ou=netgroup | nisNetwork |
ou=profiles | SolarisNamingProfile |
ou=projects | SolarisProject |
ou=solarisauthattr | [special] |
ou=solarisprofattr | [special] |
ou=nismapname=auto_* | (Automounter info) |
Data collected from http://www.sun.com/blueprints/1000/ldap-sol8.html . But turns out you can get similar info from
ldaplist -helpldaplist is similar to nisls
/usr/local/bin/ldapsearch -x -ZZ -b 'dc=yourdomain,dc=com' '(objectclass=*)'(assuming you have already added a few objects to your LDAP directory)
I have successfully used this command to observe TLS in action, using solaris 8 and openldap 2.0.7.
Now I just have to get the SOLARIS ldapsearch to use TLS somehow. (or 'ldaplist', or...) Sigh. Putting "NS_LDAP_TRANSPORT_SEC= NS_LDAP_SEC_TLS" in /var/ldap/ldap_client_file does NOT seem to work, oddly enough.
For a presention on "What is LDAP", you can look at a Kalamazoo Linux User group presentation by Adam Williams
For basic and not-so-basic questions on OpenLDAP, be sure to take a look at the official OpenLDAP QuickStart Page, and also their other documentation at http://www.OpenLDAP.org/support/ . Use the "FAQ-O-Matic" link on that page.
Sun has a semi-informative page on LDAP at its Sun Blueprints website. There is also a more generic "LDAP Basics" article in this Sun BluePrints article.
NOTE: Key OpenLDAP patch for Solaris here!
p.mayers also has a page dealing with
solaris 8
and ldap . This lists the actual source code hack to make
OpenLDAP 2.0.7 talk to the solaris native ldap tools.
However, you cannot cut-n-paste it, because it needs tabs in there.
Here is the patch in downloadable form
Apply it by doing
patch < ldap_patch.txtin the servers/slapd directory. This gets "ldapclient" past the initial "Can't find rootDN/namingcontexts" unhappiness, but then gets stuck later on, for various reasons. One is that it expects the optional "virtual views" LDAP spec implemented. The other is that it wont do TLS.
SOME of the puzzle pieces can be found in the object definitions in
RFC2307 at
ftp://ftp.isi.edu/in-notes/rfc2307.txt or
http://www.padl.com/~lukeh/rfc2307bis.txt
Most of the objects there are now covered by "nis.schema". Unfortunately, the remaining objects need some definitions/coding that has not been found yet. namely, handling of "nisSecretKeySyntax"
If you're wondering what the heck a particular "OID" number means, you can look for it at http://www.alvestrand.no/harald/objectid/
Actually, you can also use PUBLIC LDAP servers, like ldap://root.openldap.org/dc=openldap,dc=org
Here's a little info on setting up LDAP to be a Netscape Roaming Server
Or for a GTK-based one, http://biot.com/gq/
If you would prefer to run a daemon, instead of installing a kernel module, you can install PRNGD instead.
Also, if you would like to rename the padl nss and pam modules to nss_padl.so and pam_padl.so, Kevin Currie has contributed the following script to run in the two source directories:
#!/bin/sh # # NSS # for i in `fgrep "nss_ldap.so" * | awk -F: '{print $1}' | sort | uniq` ; do cat ${i} | sed -e 's/nss_ldap\.so/nss_padl.so/g' > ${i}.padl cp ${i}.padl ${i} rm ${i}.padl done for i in `egrep "_nss_ldap_.+_constr" * | awk -F: '{print $1}' | sort | uniq` ; do cat ${i} | sed -e 's/_nss_ldap_\(.*\)_constr/_nss_padl_\1_constr/g' > ${i}.padl cp ${i}.padl ${i} rm ${i}.padl done # # PAM # for i in `fgrep "pam_ldap.so" * | awk -F: '{print $1}' | sort | uniq` ; do cat ${i} | sed -e 's/pam_ldap\.so/pam_padl.so/g' > ${i}.padl cp ${i}.padl ${i} rm ${i}.padl done
Right now, the way of using the solaris 8 "ldapclient" to nicely configure
things is not known. Or rather, a possible way
has been mentioned on the "OpenLDAP" mailing list, but requires a
source patch, and does not seem to be the 100% solution anyway, since solaris
wants to use an "optional" part of the LDAP standard that openldap doesnt
implement.
The obvious problem is that "ldapclient" complains about not finding
"namingcontexts". But there IS a hardcode sneaky way to set up
ldap with the standard solaris 8 tools. You ignore 'ldapclient', and do
some file editing yourself. ldapearch -h servername -b '' -s base objectclass=\*or simply point netscape at ldap://servername
To halfway hack the sun ldap client routines, create /var/ldap/ldap_client_file with the following lines, adjusted appropriately for your environment NS_LDAP_SERVERS=10.1.2.3:389 NS_LDAP_SEARCH_BASEDN=dc=yourdomain,dc=com You can then add "ldap" to various entries in /etc/nsswitch.conf, and use ldap to look up things instead of other alternatives, once you actually put data in the LDAP server. Warning You may now in theory have the capability of putting user passwords in ldap. DO NOT DO THIS, even "crypted", since this is the equivalent of making /etc/shadow readable. This needs to wait until a method is found to have the encrypted communications activated. [like the PAM module: see the appropriate section of this page!]
|
For any comments or bug reports for this page:
Author:
More Solaris stuff
Bolthole Top