标签：dn end Kerberos dc OpenLDAP ldap container realm example

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/admin24/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 krb5kdc and kadmind 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 kdc.conf. The kadmind DN will also be used for administrative commands such as kdb5_util.

   Alternatively, you may configure krb5kdc and kadmind to use SASL authentication to access the LDAP server; see the [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 kdc.conf. 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 [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 kdc.conf, make sure the following relations are set in the [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 kdb5_ldap_util (see Creating a Kerberos realm):

   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 Operations on the LDAP database.

   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/admin24/tuning.html#Indexes for details.

With the LDAP back end it is possible to provide aliases for principal entries. Currently we provide no administrative utilities for creating aliases, so it must be done by 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.

标签：dn,end,Kerberos,dc,OpenLDAP,ldap,container,realm,example
来源： https://www.cnblogs.com/felixzh/p/16269110.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。