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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
