diff options
Diffstat (limited to 'crypto/krb5/doc/html/_sources/admin/conf_ldap.rst.txt')
| -rw-r--r-- | crypto/krb5/doc/html/_sources/admin/conf_ldap.rst.txt | 133 |
1 files changed, 0 insertions, 133 deletions
diff --git a/crypto/krb5/doc/html/_sources/admin/conf_ldap.rst.txt b/crypto/krb5/doc/html/_sources/admin/conf_ldap.rst.txt deleted file mode 100644 index 908dfd1e7e09..000000000000 --- a/crypto/krb5/doc/html/_sources/admin/conf_ldap.rst.txt +++ /dev/null @@ -1,133 +0,0 @@ -.. _conf_ldap: - -Configuring Kerberos with OpenLDAP back-end -=========================================== - - - 1. Make sure the LDAP server is using local authentication - (``ldapi://``) or TLS (``ldaps``). See - https://www.openldap.org/doc/admin/tls.html for instructions on - 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:: - - ldapadd -Y EXTERNAL -H ldapi:/// -f /path/to/kerberos.openldap.ldif - - 3. Choose DNs for the :ref:`krb5kdc(8)` and :ref:`kadmind(8)` servers - to bind to the LDAP server, and create them if necessary. Specify - these DNs with the **ldap_kdc_dn** and **ldap_kadmind_dn** - directives in :ref:`kdc.conf(5)`. The kadmind DN will also be - used for administrative commands such as :ref:`kdb5_util(8)`. - - Alternatively, you may configure krb5kdc and kadmind to use SASL - authentication to access the LDAP server; see the :ref:`dbmodules` - relations **ldap_kdc_sasl_mech** and similar. - - 4. Specify a location for the LDAP service password file by setting - **ldap_service_password_file**. Use ``kdb5_ldap_util stashsrvpw`` - to stash passwords for the KDC and kadmind DNs chosen above. For - example:: - - kdb5_ldap_util stashsrvpw -f /path/to/service.keyfile cn=krbadmin,dc=example,dc=com - - Skip this step if you are using SASL authentication and the - mechanism does not require a password. - - 5. Choose a DN for the global Kerberos container entry (but do not - create the entry at this time). Specify this DN with the - **ldap_kerberos_container_dn** directive in :ref:`kdc.conf(5)`. - Realm container entries will be created underneath this DN. - Principal entries may exist either underneath the realm container - (the default) or in separate trees referenced from the realm - container. - - 6. Configure the LDAP server ACLs to enable the KDC and kadmin server - DNs to read and write the Kerberos data. If - **disable_last_success** and **disable_lockout** are both set to - true in the :ref:`dbmodules` subsection for the realm, then the - KDC DN only requires read access to the Kerberos data. - - Sample access control information:: - - access to dn.base="" - by * read - - access to dn.base="cn=Subschema" - by * read - - # Provide access to the realm container. - 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=adm-service,dc=example,dc=com" write - by * none - - # Provide access to principals, if not underneath the realm container. - 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=adm-service,dc=example,dc=com" write - by * none - - access to * - by * read - - If the locations of the container and principals or the DNs of the - service objects for a realm are changed then this information - should be updated. - - 7. In :ref:`kdc.conf(5)`, make sure the following relations are set - in the :ref:`dbmodules` subsection for the realm:: - - db_library (set to ``kldap``) - ldap_kerberos_container_dn - ldap_kdc_dn - ldap_kadmind_dn - ldap_service_password_file - ldap_servers - - 8. Create the realm using :ref:`kdb5_ldap_util(8)`: - - kdb5_ldap_util create -subtrees ou=users,dc=example,dc=com -s - - Use the **-subtrees** option if the principals are to exist in a - separate subtree from the realm container. Before executing the - command, make sure that the subtree mentioned above - ``(ou=users,dc=example,dc=com)`` exists. If the principals will - exist underneath the realm container, omit the **-subtrees** option - and do not worry about creating the principal subtree. - - For more information, refer to the section :ref:`ops_on_ldap`. - - The realm object is created under the - **ldap_kerberos_container_dn** specified in the configuration - file. This operation will also create the Kerberos container, if - not present already. This container can be used to store - information related to multiple realms. - - 9. Add an ``eq`` index for ``krbPrincipalName`` to speed up principal - lookup operations. See - https://www.openldap.org/doc/admin/tuning.html#Indexes for - details. - -With the LDAP back end it is possible to provide aliases for principal -entries. Beginning in release 1.22, aliases can be added with the -kadmin **add_alias** command, but it is also possible (in release 1.7 -or later) to provide aliases through direct manipulation of the LDAP -entries. - -An entry with aliases contains multiple values of the -*krbPrincipalName* attribute. Since LDAP attribute values are not -ordered, it is necessary to specify which principal name is canonical, -by using the *krbCanonicalName* attribute. Therefore, to create -aliases for an entry, first set the *krbCanonicalName* attribute of -the entry to the canonical principal name (which should be identical -to the pre-existing *krbPrincipalName* value), and then add additional -*krbPrincipalName* attributes for the aliases. - -Principal aliases are only returned by the KDC when the client -requests canonicalization. Canonicalization is normally requested for -service principals; for client principals, an explicit flag is often -required (e.g., ``kinit -C``) and canonicalization is only performed -for initial ticket requests. |