Kerberos Utilities Integration

[Ryan Slominski]

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

[Robbie Harwood]

Ryan Slominski via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt;
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

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Ryan Slominski]

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(a)lists.fedorahosted.org&gt; 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(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...

[Robbie Harwood]

hedrick--- via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt;
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