[prev in list] [next in list] [prev in thread] [next in thread]
List: ldap
Subject: [ldap] Re: Solaris 9 and using SSL
From: Roy Butler <roy.butler () jpl ! nasa ! gov>
Date: 2004-10-01 21:36:12
Message-ID: LYRIS-886202-910363-2004.10.01-17.36.14--ldap#progressive-comp.com () listserver ! itd ! umich ! edu
[Download RAW message or body]
Jim,
> I am trying to see if I can get my Solaris 9 clients to use ssl,
> and I have been doing a lot of reading on the subject. It's not
> really clear to me all of the steps that need to be done for this
> to happen, so I am trying to put it all together. If you guys see
> anything missing here, please let me know. =-]
I've recently implemented the same and sympathize with you. :)
> I have a signed certificate, and with this on the client:
> ldap.conf
> TLS_REQCERT demand
> TLS_CACERT /local/etc/openldap/cacert.pem
> HOST manetheren.cs.rit.edu
> BASE dc=cs,dc=rit,dc=edu
It sounds like you've built PADL's PAM and NSS modules for Solaris. I
chose to use Sun's native libraries, so my advice would be a change of
course, but hearing it may clear some things up no matter which
direction you take.
> and this in slapd.conf
> # SSL Stuff
> #TLSCipherSuite HIGH
> TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3
> TLSCACertificateFile /local/etc/openldap/keys/cacert.pem
> TLSCertificateFile /local/etc/openldap/keys/servercrt.pem
> TLSCertificateKeyFile /local/etc/openldap/keys/serverkey.pem
I'm guessing you're referring only to the server, here. I was able to
stick with "TLSCipherSuite HIGH" and didn't include "TLSCACertificateFile".
> I can do things like ldapsearch -x -LLL -ZZ and get what I am looking
> for.
>
> Through Greg's guidance, I am able to connect to the server with a client
> with this command:
>
> ldapclient manual -a domainname=cs.rit.edu \
> -a proxydn=cn=proxyagent,ou=profile,dc=cs,dc=rit,dc=edu \
> -a defaultsearchbase=dc=cs,dc=rit,dc=edu \
> -a serviceSearchDescriptor="password:ou=People,dc=cs,dc=rit,dc=edu" \
> -a serviceSearchDescriptor="shadow:ou=People,dc=cs,dc=rit,dc=edu" \
> -a serviceSearchDescriptor="gid:ou=Group,dc=cs,dc=rit,dc=edu" \
> -a defaultserverlist=129.21.36.128 \
> -a proxypassword=cleartext \
> -a profilename=tear_test
>
>
> as long as the profile tear_test has this set:
>
> authenticationMethod none
> credLevel anonymous
>
> and the profile has a password in cleartext
>
>
> Things get dicey when I try to change this:
> authenticationMethod tls:sasl/digest-MD5
I haven't used profiles, though I'm sure they could simplify new client
set-ups. I'm not sure what LDAP server you're using, but I've heard
Sun/Netscape's LDAP server helps you create these profiles, while
OpenLDAP does not (to my knowledge). Also, I haven't used proxies. I
don't fully understand their implementation, but they seemed a little
less secure than necessary.
> In my reading, I notice that certificatePath wants to point to
> a directory where the key database files are kept.
> Since I have been using openldap to create my keys, I don't have
> a cert7.db or a key3.db file.
>
> 1) am I barking up the wrong tree
> or
> 2) how does one actually generate the .db files from the .pem files
> I have ??
You can (temporarily) run Apache w/SSL using your certificate (this
would be a-whole-nother FAQ - I'm assuming you're already familiar with
it or will go to the docs) on your LDAP server, download an old 4-series
Netscape browser, go to your web site with it, accept the certificate
(forever), and then use the corresponding ~/.netscape/cert7.db and
~/.netscape/key3.db files. Also, I think if you create your certificate
to expire in a year, your authentication will probably go boom after
that time, so make it as long as you feel safe with.
--------------------
Here's how I got Solaris 9 (native library) clients working with a
Linux-hosted OpenLDAP server, overlaying information relevant to your
environment. If it doesn't work quickly for you, you may want to start
with a clean, newly-installed client:
> cp /etc/nsswitch.ldap /etc/nsswitch.conf
> vi /etc/nsswitch.conf
##(modify)
hosts: ldap dns [NOTFOUND=return] files
##(import manetheren's cert through https first)
> cp ~/.netscape/cert7.db ~/.netscape/key3.db /var/ldap
> chmod 444 /var/ldap/*.db
> vi /etc/hosts
##(add)
129.21.36.128 manetheren.cs.rit.edu
> ldapclient manual -a domainName=dc=cs,dc=rit,dc=edu -a
credentialLevel=anonymous -a defaultSearchBase=dc=cs,dc=rit,dc=edu -a
serviceAuthenticationMethod=pam_ldap:tls:simple 129.21.36.128
> vi /var/ldap/ldap_client_file
##(modified)
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 129.21.36.128
NS_LDAP_SEARCH_BASEDN= dc=cs,dc=rit,dc=edu
NS_LDAP_CACHETTL= 3600
NS_LDAP_CREDENTIAL_LEVEL= anonymous
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple
> vi /etc/pam.conf
##(changed to)
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth required pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_dial_auth.so.1
login auth sufficient pam_unix_auth.so.1
login auth required pam_ldap.so.1 try_first_pass
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth required pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth sufficient pam_unix_auth.so.1
rlogin auth required pam_ldap.so.1 try_first_pass
#
# rsh service (explicit because of pam_rhost_auth)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_authtok_get.so.1
rsh auth required pam_dhkeys.so.1
rsh auth sufficient pam_unix_auth.so.1
rsh auth required pam_ldap.so.1 try_first_pass
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth required pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_dial_auth.so.1
ppp auth sufficient pam_unix_auth.so.1
ppp auth required pam_ldap.so.1 try_first_pass
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authenctication
#
other auth required pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_unix_auth.so.1
other auth required pam_ldap.so.1 try_first_pass
#
# passwd command (explicit because of a different authentication module)
#
passwd auth sufficient pam_passwd_auth.so.1
passwd auth required pam_ldap.so.1 try_first_pass
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_projects.so.1
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_projects.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password
#
other password required pam_dhkeys.so.1
other password required pam_authtok_get.so.1
other password required pam_authtok_check.so.1
other password sufficient pam_authtok_store.so.1
other password required pam_ldap.so.1
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin auth optional pam_krb5.so.1 try_first_pass
#login auth optional pam_krb5.so.1 try_first_pass
#other auth optional pam_krb5.so.1 try_first_pass
#cron account optional pam_krb5.so.1
#other account optional pam_krb5.so.1
#other session optional pam_krb5.so.1
#other password optional pam_krb5.so.1 try_first_pass
--------------------
Another thing is that I had to run OpenLDAP on both port 389 and 636,
since Solaris seems to still split encrypted/unencrypted connections. I
did this by including both "ldap:///" and "ldaps:///" in the server's
start-up. Last, but not least, I found that my uid's in the People ou
needed to include the shadowAccount objectClass in addition to the top,
account, and posixAccount objectClasses in order for Solaris to play
with them.
Best of luck,
Roy
---
You are currently subscribed to ldap@umich.edu as: [ldap@progressive-comp.com]
To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the \
SUBJECT of the message.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic