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:
- 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.
- 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.
- 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.
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.
- 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.