Several staff and I have separate principals that we use for privileged 
operations. Rather than completely separate users I would prefer things like 
hedrick/admin, where it’s immediately obvious that they’re connected. In 
general I don’t see why IPA should prevent me from using perfectly legal 

> On Feb 15, 2018, at 3:34 AM, Alexander Bokovoy <> wrote:
> On ke, 14 helmi 2018, Charles Hedrick via FreeIPA-users wrote:
>> I have two identifies, one a normal user and one with privileges in
>> IPA. The normal Kerberos convention is for them to be hedrick and
>> hedrick/admin.
> This convention is only used in the Kerberos world because there is a
> particular issue with kadmin protocol/implementations: they do not allow
> dynamic access control. Instead, a static access control is set up with
> kadm5.acl file so it became customary to set ACL once and for everyone
> with something like
> */admin     *
> Which allows <user>/admin principal to perform all allowed kadmin
> operations except extraction of the principal's keys.
> Due to a lack of any API inside kadmin that would have allowed a KDB
> driver to see who is accessing the principal data, we cannot really
> implement real access controls in IPA for it too.
> In FreeIPA we don't really need to allow direct kadmin use because most
> of its tasks can be done through IPA CLI/Web UI already, so the need for
> */admin-like names is reduced.
> Do you have any other need for it?
>>> On Feb 13, 2018, at 5:03 PM, Rob Crittenden <> wrote:
>>> Charles Hedrick via FreeIPA-users wrote:
>>>> There’s a convention of creating admin instances for users, usually named 
>>>> user/admin. IPA doesn’t seem to allow such instances. Is there a way to 
>>>> make them work?
>>>> As far as I can tell the instance can only be a hostname. That doesn’t 
>>>> seem like a sensible restriction.
>>> To be used for what purpose?
>>> rob
>> _______________________________________________
>> FreeIPA-users mailing list --
>> To unsubscribe send an email to
> -- 
> / Alexander Bokovoy

FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to