Currently the only way to administer a PKI dirsrv instance is to use a DM password (which is stored into a file). This makes it hard to integrate access control for user coming via API that also uses GSSAPI for authentication instead of simple binds normally.
There a re few ways to handle this, the two most prominent options are:
Store the DM password encrypted in the IPA LDAP server and have a special extendedoperation/search control implement by the ipa-pwd-extop password plugin to do access control and release the unencrypted password when the right user asks for it. This has the advantage of giving out a long term secret.
Create a special keytab for the CS instance, and use v3's ipa-kdb to restrict through LDAP ACLs which suer can get a ticket for that service so that only administrative accounts can get a ticket. Then use GSSAPI auth in the CS dirsrv instance and map GSSAPI auth always to the DM user. This is possible only if SASL libraries will allow us to use an arbitrary principal name when used from openldap and may requires changes to dirsrv to use a keytab for a service different than ldap/
The advantage of this approach is that it will probably require much less coding and will not give a way a long term secret.
Follow up on 2. Ldap client libraries do hardcode the service name passed into sasl_client_new, but it would be easy to patch them to add a new sasl settable option in struct ldapoptions and then expose it via ldap_set_options()
This is to investigate at the beginning of the 2.2 cycle.
Moving the ticket to the next month iteration.
With the consolidated CS/DS instances this should just go away.
Is this resolved by IPA and dogtag sharing the same 389-ds instance?
Fully resolved as now we can use normal GSSAPI binds and ACIs referencing the users in the ipa database as they reside in the same instance.
Closing as resolved.
Metadata Update from @simo: - Issue assigned to simo - Issue set to the milestone: FreeIPA 3.1 Stabilization
Login to comment on this ticket.