beargiles/openldap repository overview

This is a fork of osixia/openldap that adds autoconfiguration of MIT KDC. It is nearly entirely automatic - at the moment you must execute one script post-launch.

IMPORTANT: there's a pull request to merge this feature into osixia/openldap and it's still a little rough. This image will go away once that happens. If you need this feature I strongly encourage you to fork https://github.com/beargiles/docker-openldap⁠.

IMPORTANT: this is a work in progress and some of the details will remain in flux until mid-May 2019. I've pushed this so we can start using it on several projects at work so we can find the rough spots.

MIT KDC is configured via the following environment variables:

• KRB_REALM (defaults to LDAP_DOMAIN in upper case)
• KDC_SERVER (defaults to localhost)
• ADM_SERVER (defaults to KDC_SERVER)
• KDC_ADMIN (defaults to admin)
• ADM_ADMIN (defaults to KDC_ADMIN)
• KRB_MASTER_PASSWORD (defaults to 'password')

It's unlikely that someone will want to use different KDC and ADM entries, esp. the admin values, so using separate values is primarily intended as documentation for anyone extending this project. I don't know if you can still use krb5_ldap_util with different ADMIN values.

The changes to osixia/openldap are:

1. Adding kerberos.schema
2. Adding krbPrincipalName as an indexed attribute
3. Creation of /etc/krb5.conf, /etc/krb5kdc/kdc.conf, and /etc/krb5kdc/kadm5.acl
4. Creation of a script at /usr/local/bin/01-kdc.sh.

The script must be run manually - it needs to be run after the LDAP server is running but only the first time the docker image is started. Auto-execution (and auto-deletion) is an open task.

A few additional changes must be run before the LDAP server is started. The current approach makes a few assumptions so it's located in /assets/config/bootstrap/ldif/custom to allow easy modification. This is subject to change.

1. Create two organizationalUnits, users and services.
2. Temporarily create several KDC entries.
3. Modify the LDAP ACLs to grant access to those OUs to KDC_ADMIN and ADM_ADMIN
4. Modify the LDAP ACLs to limit access to the KDC's sensitive information to only KDC_ADMIN and ADM_ADMIN
5. Delete the KDC entries so kdb5_ldap_util can be run later.

The /usr/local/bin/01-kdc.sh script:

1. (possibly) create the organizationalUnits that will contain krbPrincipalNames
2. Execute kdb5_ldap_util to create the initial KDC entries.

Configuring client systems

1. Copy /etc/krb5.conf from the container. You don't need the /etc/krb5kdc entries.

Bootstrapping kadmin

1. Launch kadmin.local on the container and use 'addprinc' to create at least one user with '/admin', e.g., 'beargiles/admin'.
2. You should now be able to run kadmin from any system with the appropriate /etc/krb5.conf file.

Required changes to LDAP entries

1. Add 'objectClass krbPrincipal'
2. Add 'krbPrincipalName' attribute.

Creating an user or service entry

1. Launch kadmin or kadmin.local
2. 'addprinc -pw (users) or 'addprinc -randkey (services)
3. cn can be either the user's cn or cn/service where 'service' is a specific service. For instance 'bgiles' or 'bgiles/admin'.

Limitations

1. I don't know if it's possible to set other mandatory attributes when creating entries via kadmin.
2. I don't know if it's possible to create the LDAP entry first and then use kadmin to populate the rest of the KDC LDAP entries.
3. I don't know if you can share user and service .ldif files between different KDCs that use the same master password. It's possible that there's a salt value that's not present in the these .ldif files.

Final notes

1. Service Kerberos Principals always contain the hostname or IP address. This could be problematic in a dockerized environment where systems may be stopped and relaunched at a different IP address. This is usually solved by using a local DNS server that provides the necessary abstraction.