Need method for creating passwords for service principals

[jonrober]

The OpenLDAP directory service currently does not allow simple binds to the directory. GSSAPI authentication is required for all authenticated connections. Some applications are incapable of GSSAPI authentication and can only connect with a simple build. The directory team is planning on bringing up a limited access directory service that requires SSL and allows simple binds to the directory. The preferred method of creating a password to be used in this situation would be to have it generated as a wallet object.

An intermediate solution that involved manually creating the password would really be helpful to the test and development of this support on the directory servers.

[macrotex]

A way for wallet to create or manage a krb5 keytab object with a specific password might be helpful here.

[rra]

Under what circumstances would you want a keytab created from a password?

[macrotex]

The keytab is not really created from a password, rather, a principal is instantiated using wallet and instead of giving the principal a random password you give it a specific one. There are times when I want to create a kerberos principal with a specific password rather than a random one. For example, when creating a cross-realm trust.

Another use case would be the "bootstrapping" problem: how do you get the host principal's keytab on a newly-build server server. If it is being built manually, you can use your own credentials. For fully-automated builds, you could embed another keytab that has the right to download the keytab. An alternative solution would be to embed the password for that host's principal in the build process.

Finally, the use case we use most often is when setting up access to our OpenLDAP servers to applications that can connect only using simple bind. Bill set this up the process before he left: create a kerberos principal, assign it a known password, set the userPassword attribute for the principal in LDAP.

What we do now is store the password in a separate wallet file object, but it would more convenient to store the password with the wallet object for that principal.

[rra]

So for the last case, you don't care about the keytab itself, since nothing uses it. You just want to create a Kerberos principal with a known password and return the password as a wallet object, correct? That makes sense -- a way to manage a service account with a known password. I think that's what this issue was asking for originally, so that's a great clarification. Thank you!

I'm having a hard time seeing why you would ever want to create a keytab when setting up cross-realm trust. The credentials for the cross-realm trust should never leave the two KDCs involved. That's more of a one-time thing where you do a one-time share of a secret key with the other KDC administrator.

I don't think this helps for bootstrapping. If you can embed the password in the build process, you can just embed the keytab in the build process; the indirection through a password doesn't seem useful to me. But maybe I'm missing some subtlety?