[Freeipa-users] Re: user/admin
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 aliases: kinit admin ipa user-add-principal foo foo/ad...@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/ad...@example.com: $ klist -A Ticket cache: KEYRING:persistent:980138753:krb_ccache_LT6Pbr6 Default principal: aboko...@example.com Valid starting Expires Service principal 19.02.2018 22.48.34 20.02.2018 22.48.30 krbtgt/example@example.com $ kadmin Authenticating as principal abokovoy/ad...@example.com with password. Password for abokovoy/ad...@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 canonicalization. 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-userswrote: 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 principals. Each IPA user is a separate principal. In traditional Kerberos setup each 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, etc. Making two separate principals comprise of the same identity theoretically is possible but practically is harder to implement than one identity per principal. 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 /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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- / Alexander Bokovoy ___ FreeIPA-users mailing list --
[Freeipa-users] Re: user/admin
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. > On Feb 19, 2018, at 4:11 PM, Charles Hedrick via FreeIPA-users >wrote: > > 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 > principals. > >> 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 /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 -- freeipa-users@lists.fedorahosted.org >>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org >> >> -- >> / Alexander Bokovoy > > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: user/admin
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 principals. > On Feb 15, 2018, at 3:34 AM, Alexander Bokovoywrote: > > 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 /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 -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > > -- > / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: user/admin
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. > On Feb 13, 2018, at 5:03 PM, Rob Crittendenwrote: > > 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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: user/admin
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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: user/admin
I can actually create a principal foo/admin by creating a user foo-admin and change the principal. But kinit can’t use it, so it’s not terribly useful. > On Feb 13, 2018, at 4:52 PM, Charles Hedrickwrote: > > 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. > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org