Hi IPA Users,
What is the status of the IPA integration with Kerberos utilities such as kadmin (kadmin.local) and kdb5_util? Can they be used or are they not supported. If not supported maybe they should report an error or warning.
It seems setting a user's password expiration with kadmin works in the short term, but is later overwritten perhaps by multi-master replication? I was testing password expiration and I set a value using kadmin modprinc yesterday and noticed today that the value has reverted back to what it was earlier. As an aside using ipa user-mod --setattr=krbPasswordExpiration=20180715011529Z is clumsy and admin user doesn't even have the privilege to execute it successfully. LDAP modify with directory manager has the privilege, but LDIF is even more clumsy. With kadmin.local modprinc I can use -pwexpire 1day.
Also, importing an existing database of principals with password hashes would make migration from a standalone KDC much less painful. Any chance that feature is added at some point? Looks like one challenge might be what appears to be the 389 directory server storing user passwords in two separate fields (userPassword and krbPrincipalKey), which are presumably hashed differently.
Ryan
Ryan Slominski via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
What is the status of the IPA integration with Kerberos utilities such as kadmin (kadmin.local) and kdb5_util? Can they be used or are they not supported. If not supported maybe they should report an error or warning.
They *can* be used, but it's generally the wrong thing to do. IPA has a lot of specific requirements that aren't defaults for these tools, and these tools aren't IPA-aware. We generally don't support their direct use, but IPA will on occasion use them for things.
(I will leave it to others to better reply to the rest of your message.)
Thanks, --Robbie
Hi,
On ma, 16 heinä 2018, Ryan Slominski via FreeIPA-users wrote:
Hi IPA Users,
What is the status of the IPA integration with Kerberos utilities such as kadmin (kadmin.local) and kdb5_util? Can they be used or are they not supported. If not supported maybe they should report an error or warning.
It seems setting a user's password expiration with kadmin works in the short term, but is later overwritten perhaps by multi-master replication? I was testing password expiration and I set a value using kadmin modprinc yesterday and noticed today that the value has reverted back to what it was earlier. As an aside using ipa user-mod --setattr=krbPasswordExpiration=20180715011529Z is clumsy and admin user doesn't even have the privilege to execute it successfully. LDAP modify with directory manager has the privilege, but LDIF is even more clumsy. With kadmin.local modprinc I can use -pwexpire 1day.
In general, it is not supported. For long time kadmin lacked pluggable interface to allow modules to override how ACLs are managed. The interface was only added last year and we haven't yet implemented a plugin for that (http://web.mit.edu/kerberos/krb5-latest/doc/plugindev/kadm5_auth.html)
kadmin.local does all operations under root as cn=Directory Manager. We have few checks in place to disallow direct operations that can be overridden (ipa-server-install does it) but otherwise you need to be extremely careful.
krbPasswordExpiration is definitely not excluded from replication agreements, so its change should replicate to consumers.
ACI "Admins can write passwords" allows members of admins group to change krbPasswordExpiration (set on the $SUFFIX dn):
aci:(targetattr = "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || ipaNTHash || krbPasswordExpiration")(version 3.0; acl "Admins can write passwords"; allow (add,delete,write) groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
Also, importing an existing database of principals with password hashes would make migration from a standalone KDC much less painful. Any chance that feature is added at some point? Looks like one challenge might be what appears to be the 389 directory server storing user passwords in two separate fields (userPassword and krbPrincipalKey), which are presumably hashed differently.
Yes, they hashed differently but that's not the only reason why is it hard to add. You can dig a deeper rabit's hole there, for sure. Any help with creating a migration tool is welcome. Right now this is not on our radar for various reasons -- if you have serious considerations on contributing development to that, you are welcome to freeipa-devel@ to discuss things in detail.
Hi Alexander and Robbie,
Thanks for the responses. I'm not quite ready to start hacking IPA just yet as I'm still trying to get it setup and running. I'll try to re-create the weirdness with password expiration not sticking with kadmin.local and I'll post back if I'm able to reproduce that. Sounds like the utilities should generally be avoided though and the IPA command line interface should be used instead.
Ryan
Here are our instructions for setting passwords to not expire. With obvious adjustments it should let you set any expiration
To allow staff to set password that don't expire, in GUI
• add permission Rutgers set expiration, write, type user, check "krbpasswordexpiration" • add privilege Rutgers set expiration and add permission Rutgers set expiration to it, and add role administrator to it • go to role Administrator and add group admins to it
The group “admins” contains admin, and in our case other users that we want to be basically “root.” If you’re a member of admins you can do almost everything. However you can’t set password expirations, which is the reason for setting up a new permission for that group. Once things are set up:
Here's an example of setting no expiration (actually a very long expiration) ipa user-mod clh --setattr=krbpasswordexpiration=20380101000000Z
You can actually set dates beyond 2038, but I'm not sure whether all the code understands it.
As you may know, the kerberos dates run out of bits around 2038. A lot of the code now handles long dates, but I’m not sure that all of it does. At one time kadmin.local didn’t.
On Jul 17, 2018, at 8:19 AM, Ryan Slominski via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi Alexander and Robbie,
Thanks for the responses. I'm not quite ready to start hacking IPA just yet as I'm still trying to get it setup and running. I'll try to re-create the weirdness with password expiration not sticking with kadmin.local and I'll post back if I'm able to reproduce that. Sounds like the utilities should generally be avoided though and the IPA command line interface should be used instead.
Ryan _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
hedrick--- via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
Here are our instructions for setting passwords to not expire. With obvious adjustments it should let you set any expiration
To allow staff to set password that don't expire, in GUI
• add permission Rutgers set expiration, write, type user, check "krbpasswordexpiration" • add privilege Rutgers set expiration and add permission Rutgers set expiration to it, and add role administrator to it • go to role Administrator and add group admins to it
The group “admins” contains admin, and in our case other users that we want to be basically “root.” If you’re a member of admins you can do almost everything. However you can’t set password expirations, which is the reason for setting up a new permission for that group. Once things are set up:
Here's an example of setting no expiration (actually a very long expiration) ipa user-mod clh --setattr=krbpasswordexpiration=20380101000000Z
You can actually set dates beyond 2038, but I'm not sure whether all the code understands it.
As you may know, the kerberos dates run out of bits around 2038. A lot of the code now handles long dates, but I’m not sure that all of it does. At one time kadmin.local didn’t.
We expect krb5-1.16 and onwards to be y2038-aware. (RHEL 7.5+ are also y2038-aware).
It is not, however, expected to work for dates past about 2106.
Thanks, --Robbie
freeipa-users@lists.fedorahosted.org