"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "doc/admin/conf_ldap.rst" between
krb5-1.17.tar.gz and krb5-1.17.1.tar.gz

About: Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography (MIT implementation). Current release.

conf_ldap.rst  (krb5-1.17):conf_ldap.rst  (krb5-1.17.1)
.. _conf_ldap: .. _conf_ldap:
Configuring Kerberos with OpenLDAP back-end Configuring Kerberos with OpenLDAP back-end
=========================================== ===========================================
1. Set up SSL on the OpenLDAP server and client to ensure secure 1. Make sure the LDAP server is using local authentication
communication when the KDC service and LDAP server are on different (``ldapi://``) or TLS (``ldaps``). See
machines. ``ldapi://`` can be used if the LDAP server and KDC https://www.openldap.org/doc/admin24/tls.html for instructions on
service are running on the same machine. configuring TLS support in OpenLDAP.
2. Add the Kerberos schema file to the LDAP Server using the OpenLDAP
LDIF file from the krb5 source directory
(``src/plugins/kdb/ldap/libkdb_ldap/kerberos.openldap.ldif``).
The following example uses local authentication::
A. Setting up SSL on the OpenLDAP server: ldapadd -Y EXTERNAL -H ldapi:/// -f /path/to/kerberos.openldap.ldif
i) Get a CA certificate using OpenSSL tools 3. Choose DNs for the :ref:`krb5kdc(8)` and :ref:`kadmind(8)` servers
ii) Configure OpenLDAP server for using SSL/TLS to bind to the LDAP server, and create them if necessary. Specify
these DNs with the **ldap_kdc_dn** and **ldap_kadmind_dn**
For the latter, you need to specify the location of CA directives in :ref:`kdc.conf(5)`. The kadmind DN will also be
certificate location in *slapd.conf* file. used for administrative commands such as :ref:`kdb5_util(8)`.
Refer to the following link for more information: Alternatively, you may configure krb5kdc and kadmind to use SASL
https://www.openldap.org/doc/admin23/tls.html authentication to access the LDAP server; see the :ref:`dbmodules`
relations **ldap_kdc_sasl_mech** and similar.
B. Setting up SSL on OpenLDAP client:
4. Specify a location for the LDAP service password file by setting
i) For the KDC and Admin Server, you need to do the client-side **ldap_service_password_file**. Use ``kdb5_ldap_util stashsrvpw``
configuration in ldap.conf. For example:: to stash passwords for the KDC and kadmind DNs chosen above. For
example::
TLS_CACERT /etc/openldap/certs/cacert.pem
2. Include the Kerberos schema file (kerberos.schema) in the
configuration file (slapd.conf) on the LDAP Server, by providing
the location where it is stored::
include /etc/openldap/schema/kerberos.schema kdb5_ldap_util stashsrvpw -f /path/to/service.keyfile cn=krbadmin,dc=exam ple,dc=com
3. Choose DNs for the :ref:`krb5kdc(8)` and :ref:`kadmind(8)` servers Skip this step if you are using SASL authentication and the
to bind to the LDAP server, and create them if necessary. These DNs mechanism does not require a password.
will be specified with the **ldap_kdc_dn** and **ldap_kadmind_dn**
directives in :ref:`kdc.conf(5)`; their passwords can be stashed
with "``kdb5_ldap_util stashsrvpw``" and the resulting file
specified with the **ldap_service_password_file** directive.
4. Choose a DN for the global Kerberos container entry (but do not 5. Choose a DN for the global Kerberos container entry (but do not
create the entry at this time). This DN will be specified with the create the entry at this time). Specify this DN with the
**ldap_kerberos_container_dn** directive in :ref:`kdc.conf(5)`. **ldap_kerberos_container_dn** directive in :ref:`kdc.conf(5)`.
Realm container entries will be created underneath this DN. Realm container entries will be created underneath this DN.
Principal entries may exist either underneath the realm container Principal entries may exist either underneath the realm container
(the default) or in separate trees referenced from the realm (the default) or in separate trees referenced from the realm
container. container.
5. Configure the LDAP server ACLs to enable the KDC and kadmin server 6. Configure the LDAP server ACLs to enable the KDC and kadmin server
DNs to read and write the Kerberos data. If DNs to read and write the Kerberos data. If
**disable_last_success** and **disable_lockout** are both set to **disable_last_success** and **disable_lockout** are both set to
true in the :ref:`dbmodules` subsection for the realm, then the true in the :ref:`dbmodules` subsection for the realm, then the
KDC DN only requires read access to the Kerberos data. KDC DN only requires read access to the Kerberos data.
Sample access control information:: Sample access control information::
access to dn.base="" access to dn.base=""
by * read by * read
access to dn.base="cn=Subschema" access to dn.base="cn=Subschema"
by * read by * read
access to attrs=userPassword,userPKCS12 # Provide access to the realm container.
by self write
by * auth
access to attrs=shadowLastChange
by self write
by * read
# Providing access to realm container
access to dn.subtree= "cn=EXAMPLE.COM,cn=krbcontainer,dc=example,dc=com" access to dn.subtree= "cn=EXAMPLE.COM,cn=krbcontainer,dc=example,dc=com"
by dn.exact="cn=kdc-service,dc=example,dc=com" write by dn.exact="cn=kdc-service,dc=example,dc=com" write
by dn.exact="cn=adm-service,dc=example,dc=com" write by dn.exact="cn=adm-service,dc=example,dc=com" write
by * none by * none
# Providing access to principals, if not underneath realm container # Provide access to principals, if not underneath the realm container.
access to dn.subtree= "ou=users,dc=example,dc=com" access to dn.subtree= "ou=users,dc=example,dc=com"
by dn.exact="cn=kdc-service,dc=example,dc=com" write by dn.exact="cn=kdc-service,dc=example,dc=com" write
by dn.exact="cn=adm-service,dc=example,dc=com" write by dn.exact="cn=adm-service,dc=example,dc=com" write
by * none by * none
access to * access to *
by * read by * read
If the locations of the container and principals or the DNs of If the locations of the container and principals or the DNs of the
the service objects for a realm are changed then this service objects for a realm are changed then this information
information should be updated. should be updated.
6. Start the LDAP server as follows:: 7. In :ref:`kdc.conf(5)`, make sure the following relations are set
in the :ref:`dbmodules` subsection for the realm::
slapd -h "ldapi:/// ldaps:///"
db_library (set to ``kldap``)
7. Modify the :ref:`kdc.conf(5)` file to include LDAP specific items ldap_kerberos_container_dn
listed below:: ldap_kdc_dn
ldap_kadmind_dn
realms ldap_service_password_file
database_module ldap_servers
dbmodules
db_library
db_module_dir
ldap_kdc_dn
ldap_kadmind_dn
ldap_service_password_file
ldap_servers
ldap_conns_per_server
8. Create the realm using :ref:`kdb5_ldap_util(8)` (see 8. Create the realm using :ref:`kdb5_ldap_util(8)` (see
:ref:`ldap_create_realm`):: :ref:`ldap_create_realm`)::
kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees ou=users,dc =example,dc=com -r EXAMPLE.COM -s kdb5_ldap_util create -subtrees ou=users,dc=example,dc=com -s
Use the **-subtrees** option if the principals are to exist in a Use the **-subtrees** option if the principals are to exist in a
separate subtree from the realm container. Before executing the separate subtree from the realm container. Before executing the
command, make sure that the subtree mentioned above command, make sure that the subtree mentioned above
``(ou=users,dc=example,dc=com)`` exists. If the principals will ``(ou=users,dc=example,dc=com)`` exists. If the principals will
exist underneath the realm container, omit the **-subtrees** option exist underneath the realm container, omit the **-subtrees** option
and do not worry about creating the principal subtree. and do not worry about creating the principal subtree.
For more information, refer to the section :ref:`ops_on_ldap`. For more information, refer to the section :ref:`ops_on_ldap`.
The realm object is created under the The realm object is created under the
**ldap_kerberos_container_dn** specified in the configuration file. **ldap_kerberos_container_dn** specified in the configuration
This operation will also create the Kerberos container, if not file. This operation will also create the Kerberos container, if
present already. This will be used to store information related to not present already. This container can be used to store
all realms. information related to multiple realms.
9. Stash the password of the service object used by the KDC and 9. Add an ``eq`` index for ``krbPrincipalName`` to speed up principal
Administration service to bind to the LDAP server using the lookup operations. See
:ref:`kdb5_ldap_util(8)` **stashsrvpw** command (see https://www.openldap.org/doc/admin24/tuning.html#Indexes for
:ref:`stash_ldap`). The object DN should be the same as details.
**ldap_kdc_dn** and **ldap_kadmind_dn** values specified in the
:ref:`kdc.conf(5)` file::
kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/kerberos/
service.keyfile cn=krbadmin,dc=example,dc=com
10. Add ``krbPrincipalName`` to the indexes in slapd.conf to speed up
the access.
With the LDAP back end it is possible to provide aliases for principal With the LDAP back end it is possible to provide aliases for principal
entries. Currently we provide no mechanism provided for creating entries. Currently we provide no administrative utilities for
aliases, so it must be done by direct manipulation of the LDAP creating aliases, so it must be done by direct manipulation of the
entries. LDAP entries.
An entry with aliases contains multiple values of the An entry with aliases contains multiple values of the
*krbPrincipalName* attribute. Since LDAP attribute values are not *krbPrincipalName* attribute. Since LDAP attribute values are not
ordered, it is necessary to specify which principal name is canonical, ordered, it is necessary to specify which principal name is canonical,
by using the *krbCanonicalName* attribute. Therefore, to create by using the *krbCanonicalName* attribute. Therefore, to create
aliases for an entry, first set the *krbCanonicalName* attribute of aliases for an entry, first set the *krbCanonicalName* attribute of
the entry to the canonical principal name (which should be identical the entry to the canonical principal name (which should be identical
to the pre-existing *krbPrincipalName* value), and then add additional to the pre-existing *krbPrincipalName* value), and then add additional
*krbPrincipalName* attributes for the aliases. *krbPrincipalName* attributes for the aliases.
Principal aliases are only returned by the KDC when the client Principal aliases are only returned by the KDC when the client
requests canonicalization. Canonicalization is normally requested for requests canonicalization. Canonicalization is normally requested for
service principals; for client principals, an explicit flag is often service principals; for client principals, an explicit flag is often
required (e.g., ``kinit -C``) and canonicalization is only performed required (e.g., ``kinit -C``) and canonicalization is only performed
for initial ticket requests. for initial ticket requests.
.. seealso:: :ref:`ldap_be_ubuntu`
 End of changes. 14 change blocks. 
87 lines changed or deleted 58 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)