On ma, 19 helmi 2018, Charles Hedrick wrote:
From the point of view of managing users, it would be nice to be able
to add it as a secondary principal for the user. It’s not important
enough for a major implementation effort.
We already support adding principal
ipa user-add-principal foo foo/admin(a)EXAMPLE.COM
However, this is not going to be useful because while KDC will accept
foo/admin principal in AS-REQ, a returned ticket will be issued in the
canonical name of the principal (foo). A client has to be prepared for
that: while kinit has option for canonicalization, kadmin doesn't.
$ kinit abokovoy/admin
Password for abokovoy/admin(a)EXAMPLE.COM:
$ klist -A
Ticket cache: KEYRING:persistent:980138753:krb_ccache_LT6Pbr6
Default principal: abokovoy(a)EXAMPLE.COM
Valid starting Expires Service principal
19.02.2018 22.48.34 20.02.2018 22.48.30 krbtgt/EXAMPLE.COM(a)EXAMPLE.COM
Authenticating as principal abokovoy/admin(a)EXAMPLE.COM with password.
Password for abokovoy/admin(a)EXAMPLE.COM:
kadmin: KDC reply did not match expectations while initializing kadmin interface
The response from kadmin is exactly this: kadmin client doesn't support
Using GSSAPI authentication with a TGT obtained using Kerberos principal alias
will not be different from using a canonical name for the same principal:
neither acceptor nor initiator will mention an aliased principal name; it only
is usable with kinit. There is no real benefit in having this kind of alias for
user principals (on contrary, Kerberos principal aliases are very useful for
services as targets).
Note that the behavior demonstrated above is the same with other Kerberos
systems that support aliases. This is a protocol behavior.
> On Feb 19, 2018, at 4:11 PM, Charles Hedrick via FreeIPA-users
> 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
Each IPA user is a separate principal. In traditional Kerberos
hedrick and hedrick/admin are different principals too. They aren't the same,
singular, user, they are completely different principals that happen to have
the same password associated with them. Since Kerberos deals with principals
only, there are no identities associated with them in Kerberos perspective; any
such identity is beyond Kerberos world. IPA extends this by making sure that
each separate principal is a separate identity too: a user, a service, a host,
Making two separate principals comprise of the same identity theoretically is
possible but practically is harder to implement than one identity per
>> On Feb 15, 2018, at 3:34 AM, Alexander Bokovoy
>> 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
>> 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 <rcritten(a)redhat.com>
>>>> 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
>>>>> 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?
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>> / Alexander Bokovoy
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
/ Alexander Bokovoy