Projects/HDBBridge
Background
This project extends MIT Kerberos with the capability to dynamically load Heimdal database (HDB) backends. The intent is twofold:
- allow applications with complex HDB backends, such as Samba4, to use the MIT KDC without porting to KDB
- allow kdb5_util to dump a Heimdal database for migration to a native MIT KDB backend
Architecture
A new KDB database plugin, HDB, acts as a bridge between KDB and HDB. Upon instantiation, in dynamically loads Heimdal's HDB library and maps KDB methods to their HDB equivalents.
The bridge also has the ability to bridge policy checking and authorization data signing methods to Heimdal's windc plugin SPI.
Implementation
Code is in plugins/kdb/hdb. Because the bridge needs to dynamically load Heimdal libraries anyway, there is no support for building the bridge statically. The platform needs to support RTLD_LOCAL (or equivalent), otherwise there will be symbol conflicts between the two Kerberos implementations.
One interesting issue is support for master keys. Both Kerberos implementations are similar conceptually, however the interface for reading master keys is not exposed by libhdb and the encryption algorithms differ. This has the following implications:
- the dbekd_decrypt_key_data and dbekd_encrypt_key_data implementations by default forward to hdb_unseal_key and hdb_seal_key, respectively
- methods to return a master key return an empty key with ENCTYPE_NULL, on the presumption this is preferable to poking inside internal Heimdal data structures
- when dumping a Heimdal database with kdb5_util, the -mkey_convert option must be specified
- as a special case to support the above, when the dbekd_encrypt_key_data method is called with a non-NULL master key, the default MIT implementation is used
Open issues
Status
Code is in the users/lhoward/heimmig branch. Presently I have only tested with the HDB flat file backend.