On ma, 29 loka 2018, Ryan Slominski via FreeIPA-users wrote:

It is not always clear the best way to create an account for a script or application to use. Generally this special type of account has no password expiration (or a very long expiration window). For example, some applications require a bind user to connect to LDAP. It seems there are a half a dozen ways to do it. When should each be used? Here are the options I'm aware of:

1. Create IPA Service (ipa service-add)

My understanding is an IPA Service cannot reveal the plaintext password (keytab only) and must be tied to a single host. This doesn't work when the bind user password plaintext must be known (unless I missed that somewhere). Also, you can't assign a service to the "admins" user group, which is a special user group - so if you want a "root-like" service you can't use an IPA service (maybe you could cobble together some roles that mostly did what admins members get).

All of the above is not true with FreeIPA 4.7.0.

https://pagure.io/freeipa/issue/7513 allows to have services as group members for the purpose of role management

https://pagure.io/freeipa/issue/7514 allows to create services detached from a specific host object.

ipa-getkeytab also allows to force a specific plaintext password instead of a randomly generated one.

2. Create IPA User (ipa user-add)

There are few ways to make a special password expiration (not clear which is best): A. You can use a special password policy where the password doesn't expire for a very long time (must be done before setting password). B. Use kadmin.local to set password expiration to never (or a very long time). C. Use ldapmodify (dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com) to set expiration to a very long time D. If you never set a password, but execute the ipa getkeytab command then there doesn't appear to be any expiration on the user account password (though web interface says there is no password so not sure if this is a bug or what)

I think A is best. For D I'd like you to open an issue and describe what you see and what you expect to see.

3. Create LDAP System Account (ldapmodify - dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com)

This seems like a back door and only works if your "application account" needs LDAP, but not Kerberos. Account does not show up in the web interface anywhere.

See: https://www.freeipa.org/page/HowTo/LDAP

The latter (LDAP system account) is not a backdoor. It is rather a normal behavior for LDAP servers. An LDAP schema allows you to have bindable objects and aside from some bugs in treating password policies for them when setting kerberos attributes, they are normal LDAP objects.

4. Create Kerberos Service (kadmin.local addprinc)

Probably no need to ever use kadmin.local to create a service? Then again, maybe there is?

I'd recommend against using kadmin.local in day to day activities. We have majority of its functions represented through IPA API already. kadmin.local only can create principals in a default sub-tree (don't remember which one off the top of my head right now), there is no real authentication when you run as root and it is easy to wipe the data.

On ti, 30 loka 2018, Ryan Slominski via FreeIPA-users wrote:

As far as option D goes I'm now starting to understand IPA makes a distinction between a password and Kerberos keys. If you don't set a password, but use ipa-getkeytab followed by ipa user-show the "Kerberos keys available" attribute changes from Fasle to True, but "Password" remains False. The web GUI doesn't seem to show whether keys were deployed for user accounts and I was expecting to see some indication that I had used ipa-getkeytab, but now see I can only tell using the command line. Can a user have a separate random key as well as a known plain text password simultaneously? Does the krblastpwdchange apply to both password and keys or do keys never expire?

I don't think you can have an independent password and a random key. When a password is set via LDAP, a special plugin will propagate it to Kerberos attributes (by setting hashes of it using specific algorithms for those attributes). When a password is updated via Kerberos kadmin protocol, the same happens for LDAP password too.

When ipa-getkeytab is used to generate a random key the very same plugin in LDAP server is placing this random key to both the userPassword attribute and to the Kerberos attributes. So they should be synchronized all the time.

When password expires is defined by the password policy. At that point both Kerberos keys and the userPassword in LDAP are expired and unusable for authentication (other than a request to change the password).

Obviously, you can create a policy that avoids expiring a password and that would be an equivalent to a never expiring key for a user.