|
Size: 1227
Comment:
|
Size: 7031
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## Auto-converted by kwiki2moinmoin v2005-10-07 = Configuring LDAP Authentication for Debian = == OpenLDAPSetup == 1. Install the ["OpenLDAP"] package [http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&keywords=slapd slapd] |
## page was renamed from OpenLDAPSetup = Setting up an LDAP server with OpenLDAP = |
| Line 6: | Line 4: |
| Do '{{{apt-get install slapd}}}', answering prompts as required and generaly picking defaults except where they are obviously examples. | == Install the OpenLDAP package slapd == |
| Line 8: | Line 6: |
| 2. Edit the LDAP configuration file | Install the package with: {{{ # apt-get install slapd }}} answering the prompts as follows: |
| Line 10: | Line 12: |
| To make using LDAP utilities like '{{{ldapsearch}}}' a little less painful, edit {{{/etc/ldap/ldap.conf}}} (installed by the '{{{libldap2}}}' package on the stable (a.k.a. 'woody') distribution) to set:{{{ BASE dc=<yourhost>,dc=<your>,dc=<domain> URI ldap://localhost |
* For the DNS domain name, enter your domain name. <<BR>>This will be translated to an LDAP DN (for example, '{{{example.com}}}' would become '{{{dc=example, dc=com}}}'). This becomes what is known as your BaseDN, the root of your database. * For your organzation you can enter any string; this becomes associated the '{{{ou}}}' field of your BaseDN record. * Next enter your LDAP administrator password twice. This will set the password for '{{{cn=admin, BaseDN}}} and give '{{{cn=admin, BaseDN}}}' write access to everything in your LDAP tree. * Accept the default of {{{No}}} to the question {{{Allow LDAPv2}}} protocol For querying the LDAP server utilities like {{{ldapsearch}}} are available. See the [[LDAP/LDAPUtils]] topic for more details. == For better performance do more indexing than the default. == Modify {{{/etc/ldap/slapd.conf}}} to contain the following: {{{ index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index default sub index uidNumber eq index gidNumber eq index mail,givenName eq,subinitial index dc eq |
| Line 15: | Line 36: |
| 3. Tune your LDAP server performance To improve LDAP performance, edit {{{/etc/ldap/slapd.conf}}} to set more indexes than the stable (a.k.a. 'woody') default of just objectClass (taken from the Mandrake documentation):{{{ index objectClass,uid,uidNumber,gidNumber eq index cn,mail,surname,givenName eq,subinitial |
After any new indexes have been defined or other major database changes have been made (e.g. {{{slapadd}}} was used) it is best to recreate the indexes. Note that you should stop {{{slapd}}} before recreating the indexes and should fix the permissions afterward. {{{ # /etc/init.d/slapd stop # slapindex # chown -R openldap:openldap /var/lib/ldap # /etc/init.d/slapd start |
| Line 22: | Line 44: |
| 4. Update the LDAP indexes | == Configuring 'chsh' and 'chfn' to work with LDAP == |
| Line 24: | Line 46: |
| Make sure the indexes are updated by doing (as {{{root}}}):{{{ # /etc/init.d/slapd stop # slapindex # /etc/init.d/slapd start |
Edit '{{{/etc/ldap/slapd.conf}}}' to allow access for users to update their {{{loginShell}}} and {{{gecos}}} entries by adding the following before the '{{{access to *}}}' entry: {{{ access to attrs=loginShell,gecos by dn="cn=admin,dc=example,dc=com" write by self write by * read |
| Line 29: | Line 54: |
== For SAMBA LDAP support == For Samba LDAP, slapd needs the Samba schema. The Debian package seems to have a samba.schema file which is old and out of date, and a samba.schema.gz file which is actually the correct one. Do the following (as {{{root}}}): {{{ # zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > /etc/ldap/schema/samba.schema }}} Now add the following line to /etc/ldap/slapd.conf after the other includes: {{{ include /etc/ldap/schema/samba.schema }}} And restart slapd: {{{ # /etc/init.d/slapd restart }}} == Access controls for subtree-specific LDAP Admins == If you choose to use LDAP for many functions, such as having a single server for DNS, Authentication, and networking flat file database replacement, you may wish to have LDAP administrative users for each subtree in addition to the global admin ({{{dn="cn=admin, dc=example, dc=com}}}). The following example is useful when using a separate authentication tree which includes Samba. {{{ # The manager dn has full write access to the auth subtree # Everyone else has read access to not otherwise protected fields and entries access to dn.sub="ou=auth,dc=example,dc=com" by dn="cn=Manager,ou=auth,dc=example,dc=com" write by * read }}} == Configuring LDAPS == Configuring the certificate (and possibly the CA used) in /etc/ldap/slapd.conf: {{{ TLSCACertificateFile /etc/ssl/certs/whaterver_ca_you_use.pem TLSCertificateKeyFile /etc/ssl/private/example.com.pem.pem TLSCertificateFile /etc/ssl/certs/example.com.pem }}} By default, slapd runs as user/group openldap, so it can't read the key file. On Debian Lenny, the preferred solution to this dilemma seems to be to chown the key to root:ssl-cert, set permissions to 640 and add the user openldap to group ssl-cert. === Symptoms: === In {{{slapd}}} debug output: {{{ [...] TLS: could not set cipher list HIGH:MEDIUM:-SSLv2. (or similar) }}} In /var/log/syslog: {{{ [...] main: TLS init def ctx failed: -1 }}} ==== Diagnosis: ==== If you try to install the OpenLDAP server ({{{slapd}}}) with Debian Lenny, it comes compiled against the GnuTLS library. It means you cannot use an OpenSSL style directive like {{{TLSCipherSuite HIGH:MEDIUM:-SSLv2}}} in {{{slapd.conf}}}. ==== Cure: ==== In {{{/etc/ldap/slapd.conf}}}, either comment out `TLSCipherSuite` option to let gnutls choose rather sane default for you, or use something like: {{{ TLSCipherSuite NORMAL }}} To get all the supported GnuTLS cipher suite names: {{{ # aptitude install gnutls-bin # man gnutls-cli }}} And skipp to `TLS/SSL control options` section of man page. To use only 256 bit cyphers, use this (paranoiac?) setting: {{{ TLSCipherSuite SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC }}} Another useful tool to test server-supported TLS options is to use `gnutls-cli-debug`. First add `ldaps:///` string to the `SLAPD_SERVICES` option in `/etc/default/slapd`, restart `slapd` and then run {{{ gnutls-cli-debug -p 636 <fqdn_of_you_ldap_host> }}} That will show you cryptographic suits your LDAP server supports. === Symptoms (round 2) === If you are getting messages such as {{{ slapd TLS: can't connect: A TLS packet with unexpected length was received.. }}} or {{{ Could not negotiate a supported cipher suite. }}} take a wander by this. ==== Diagnosis: ==== How did you generate your certificates? If you generated them using OpenSSL, you're going to run into problems. Debian switched over to using gnutls a while ago, and it doesn't play nice with OpenSSL certificates. So, to fix this, check out the next section. NOTE: On Debian Squeeze openldap is linked with gnutls as well, but works just fine with certificate generated by openssl. ==== Procedure: ==== You're going to need the gnutls certificate generator: [[http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html|certtool]]. Run these two commands to generate a new self-signed key (into the current working directory): {{{ certtool --generate-privkey --outfile ca-key.pem certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem }}} Then, update your certificate locations in /etc/ldap/slapd.conf ({{{TLSCertificateFile}}} points to ca-cert.pem and {{{TLSCertificateKeyFile}}} points to ca-key.pem), comment out {{{TLSCACertificateFile}}}, and change {{{TLSVerifyClient}}} to {{{never}}}. In /etc/ldap/ldap.conf, comment out {{{TLS_CACERT}}} and change {{{TLS_REQCERT}}} to {{{never}}}. Since the certificate is self-signed, we can't have gnutls trying to verify it (hence the {{{never}}}), otherwise it will never run. Then restart your services, and you're good (assuming all your links point properly to ldaps://url/). |
|
| Line 30: | Line 167: |
| * ["LDAPAuthentication"] | CategorySystemAdministration |
Setting up an LDAP server with OpenLDAP
Install the OpenLDAP package slapd
Install the package with:
# apt-get install slapd
answering the prompts as follows:
- For the DNS domain name, enter your domain name.
This will be translated to an LDAP DN (for example, 'example.com' would become 'dc=example, dc=com'). This becomes what is known as your BaseDN, the root of your database. For your organzation you can enter any string; this becomes associated the 'ou' field of your BaseDN record.
Next enter your LDAP administrator password twice. This will set the password for 'cn=admin, BaseDN and give 'cn=admin, BaseDN' write access to everything in your LDAP tree.
Accept the default of No to the question Allow LDAPv2 protocol
For querying the LDAP server utilities like ldapsearch are available. See the LDAP/LDAPUtils topic for more details.
For better performance do more indexing than the default.
Modify /etc/ldap/slapd.conf to contain the following:
index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index default sub index uidNumber eq index gidNumber eq index mail,givenName eq,subinitial index dc eq
After any new indexes have been defined or other major database changes have been made (e.g. slapadd was used) it is best to recreate the indexes. Note that you should stop slapd before recreating the indexes and should fix the permissions afterward.
# /etc/init.d/slapd stop # slapindex # chown -R openldap:openldap /var/lib/ldap # /etc/init.d/slapd start
Configuring 'chsh' and 'chfn' to work with LDAP
Edit '/etc/ldap/slapd.conf' to allow access for users to update their loginShell and gecos entries by adding the following before the 'access to *' entry:
access to attrs=loginShell,gecos
by dn="cn=admin,dc=example,dc=com" write
by self write
by * read
For SAMBA LDAP support
For Samba LDAP, slapd needs the Samba schema. The Debian package seems to have a samba.schema file which is old and out of date, and a samba.schema.gz file which is actually the correct one. Do the following (as root):
# zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > /etc/ldap/schema/samba.schema
Now add the following line to /etc/ldap/slapd.conf after the other includes:
include /etc/ldap/schema/samba.schema
And restart slapd:
# /etc/init.d/slapd restart
Access controls for subtree-specific LDAP Admins
If you choose to use LDAP for many functions, such as having a single server for DNS, Authentication, and networking flat file database replacement, you may wish to have LDAP administrative users for each subtree in addition to the global admin (dn="cn=admin, dc=example, dc=com). The following example is useful when using a separate authentication tree which includes Samba.
# The manager dn has full write access to the auth subtree
# Everyone else has read access to not otherwise protected fields and entries
access to dn.sub="ou=auth,dc=example,dc=com"
by dn="cn=Manager,ou=auth,dc=example,dc=com" write
by * read
Configuring LDAPS
Configuring the certificate (and possibly the CA used) in /etc/ldap/slapd.conf:
TLSCACertificateFile /etc/ssl/certs/whaterver_ca_you_use.pem TLSCertificateKeyFile /etc/ssl/private/example.com.pem.pem TLSCertificateFile /etc/ssl/certs/example.com.pem
By default, slapd runs as user/group openldap, so it can't read the key file. On Debian Lenny, the preferred solution to this dilemma seems to be to chown the key to root:ssl-cert, set permissions to 640 and add the user openldap to group ssl-cert.
Symptoms:
In slapd debug output:
[...] TLS: could not set cipher list HIGH:MEDIUM:-SSLv2. (or similar)
In /var/log/syslog:
[...] main: TLS init def ctx failed: -1
Diagnosis:
If you try to install the OpenLDAP server (slapd) with Debian Lenny, it comes compiled against the GnuTLS library. It means you cannot use an OpenSSL style directive like TLSCipherSuite HIGH:MEDIUM:-SSLv2 in slapd.conf.
Cure:
In /etc/ldap/slapd.conf, either comment out TLSCipherSuite option to let gnutls choose rather sane default for you, or use something like:
TLSCipherSuite NORMAL
To get all the supported GnuTLS cipher suite names:
# aptitude install gnutls-bin # man gnutls-cli
And skipp to TLS/SSL control options section of man page.
To use only 256 bit cyphers, use this (paranoiac?) setting:
TLSCipherSuite SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC
Another useful tool to test server-supported TLS options is to use gnutls-cli-debug. First add ldaps:/// string to the SLAPD_SERVICES option in /etc/default/slapd, restart slapd and then run
gnutls-cli-debug -p 636 <fqdn_of_you_ldap_host>
That will show you cryptographic suits your LDAP server supports.
Symptoms (round 2)
If you are getting messages such as
slapd TLS: can't connect: A TLS packet with unexpected length was received..
or
Could not negotiate a supported cipher suite.
take a wander by this.
Diagnosis:
How did you generate your certificates? If you generated them using OpenSSL, you're going to run into problems. Debian switched over to using gnutls a while ago, and it doesn't play nice with OpenSSL certificates. So, to fix this, check out the next section.
NOTE: On Debian Squeeze openldap is linked with gnutls as well, but works just fine with certificate generated by openssl.
Procedure:
You're going to need the gnutls certificate generator: certtool.
Run these two commands to generate a new self-signed key (into the current working directory):
certtool --generate-privkey --outfile ca-key.pem certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem
Then, update your certificate locations in /etc/ldap/slapd.conf (TLSCertificateFile points to ca-cert.pem and TLSCertificateKeyFile points to ca-key.pem), comment out TLSCACertificateFile, and change TLSVerifyClient to never.
In /etc/ldap/ldap.conf, comment out TLS_CACERT and change TLS_REQCERT to never.
Since the certificate is self-signed, we can't have gnutls trying to verify it (hence the never), otherwise it will never run.
Then restart your services, and you're good (assuming all your links point properly to ldaps://url/).