I tried various approached to get Renewable tickets :
modifying the kdc
modifying krb5.conf
using kadmin.local on every replica to modify the principal; which is not
working - as designed (?)- in IPA
What should I do to get a ticket with the correct R flag from IPA ?
I don't think this is SSSD related (the service needing the renewable
ticket this way is Apache Storm)
Thanks a lot!
I'm curious if you ever got an answer or solved this problem? I have users that
will need Kerberos tickets for long running batch jobs.
I found this post from 2012, and am wondering if it is still accurate. Reading through
these archives to see if there are any recent changes/updates.
>Simo Sorce simo at
redhat.com
>Fri May 18 15:27:57 UTC 2012
>
> Previous message (by thread): [Freeipa-users] howto modify krb principal
attributes without kadmin.local
> Next message (by thread): [Freeipa-users] Problems replicating with Windows 2008
AD
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
>On Wed, 2012-05-16 at 15:08 -0700, Thomas Jackson wrote:
>>
>>
>> On Tue, May 15, 2012 at 3:24 PM, Simo Sorce <simo at redhat.com> wrote:
>> On Tue, 2012-05-15 at 14:21 -0700, Thomas Jackson wrote:
>> > So going through the documentation it's clearly laid out not
>> to use
>> > kadmin or kadmin.local when using freeipa. I have been
>> unable to find
>> > how to replace this functionality in the documentation.
>> >
>> > If I could use kadmin.local on my kdc I would like to run
>> the
>> > following command....
>> >
>> > modprinc +requires_hwauth user
>> >
>> > Am I going to need to extend/modify the krb5 schema to
>> modify
>> > principals attributes in this way?
>> >
>>
>> For this specific change you can use kadmin.local, but the IPA
>> UI will
>> not report you anything about it.
>>
>> The flags part is still a weak point of the Web UI, if you
>> want you can
>> open a RFE ticket to ask for better support for these flags,
>> we need to
>> do it at some point we simply haven't yet as we concentrated
>> on more
>> important and pressing issue this far.
>>
>> Simo.
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>>
>>
>> The following errors lead me to believe I am missing something as
>> kadmin.local appears to have access issues when trying to modify a
>> principle.
>>
>> kadmin.local: modprinc +requires_hwauth user
>> modify_principal: User modification failed: Insufficient access while
>> modifying "user".
>>
>> For good measure I've modified /var/kerberos/krb5kdc/kadm5.
>> acl with the correct ACLs for the domain and still encounter the same
>> errors.
>>
>> -ipa 2.1.3
>
>Ok I took a second look at how to make it simple.
>
>First of all I misremembered about the fact these flags were saved in
>the krbExtraData field. They are not, there is a specific attribute for
>all ticket flags that is called krbTicketFlags.
>
>This attribute is normally not set on entries, as the defaults for the
>realm are used, however the requires_hwauth flag is not a default and
>you want to enable it only for user principals, not all principals on
>the server.
>
>That can be easily done by adding the krbTicketFlags attribute.
>However in order to do this properly you need to calculate what value to
>set based on this (partial) table:
>
>KRB5_KDB_DISALLOW_POSTDATED 0x00000001
>KRB5_KDB_DISALLOW_FORWARDABLE 0x00000002
>KRB5_KDB_DISALLOW_TGT_BASED 0x00000004
>KRB5_KDB_DISALLOW_RENEWABLE 0x00000008
>KRB5_KDB_DISALLOW_PROXIABLE 0x00000010
>KRB5_KDB_DISALLOW_DUP_SKEY 0x00000020
>KRB5_KDB_DISALLOW_ALL_TIX 0x00000040
>KRB5_KDB_REQUIRES_PRE_AUTH 0x00000080
>KRB5_KDB_REQUIRES_HW_AUTH 0x00000100
>KRB5_KDB_REQUIRES_PWCHANGE 0x00000200
>
>The default flag for IPA user is KRB5_KDB_REQUIRES_PRE_AUTH, so in order
>to properly set the flag you need to combine it with the flag you want
>that is KRB5_KDB_REQUIRES_HW_AUTH.
>
>So 0x0100 + 0x0080 = 0x0180
>
>In decimal 0x0180 becomes 384
>
>So you need to change the entry to set krbTicketFlags to 384
>
>Now, normally I would tell you to do that using the following command:
>ipa user-mod <username> --setattr=krbticketflags=384
>
>However, we do restrict even admin from touching that attribute, so you
>have 2 options:
>
>1. change the default ACI to allow admin to edit that attribute.
>2. do an ldapmodify operation instead using the Directory Manager
>credentials.
>
>Simo.
>
>--
>Simo Sorce * Red Hat, Inc * New York
>
>