3:45 p.m.
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).
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)
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
4. Create Kerberos Service (kadmin.local addprinc)
Probably no need to ever use kadmin.local to create a service? Then again, maybe there
is?
4:29 p.m.
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
9:26 a.m.
New subject: Service Account vs System Account vs User Account
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?
10:42 a.m.
New subject: Service Account vs System Account vs User Account
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
11:13 a.m.
New subject: Service Account vs System Account vs User Account
If I create an IPA Service is the default state for the keys in the keytab to never
expire?
How do I set a password policy max life to never expire? Use "0"? Leave that
field blank in the GUI?
Since the keys and password are separate it sounds like I can't use an IPA service as
an LDAP bind user if I need to know the password plaintext. Even if I use the trick where
I set the password when I execute "ipa-getkeytab -P" I assume the password
I'm setting is really a key and not the userPassword in LDAP? Or can I still bind
using that plain text password?
You mentioned that both the userPassword and Kerberos keys are updated when ipa-getkeytab
is executed. Does that mean it is a bug that the IPA command line shows "Password:
False" and the GUI shows Password and Password Expiration fields as blank after
executing ipa-getkeytab?
It would be nice to say in all cases when you need an account for a script or application
just use an IPA service account. It still isn't clear if that is the case.
2006
days inactive
2007
days old
freeipa-users@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
Alexander Bokovoy -
Ryan Slominski