[Freeipa-users] Re: user/admin

2018-02-19 Thread Alexander Bokovoy via FreeIPA-users

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-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.

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

2018-02-19 Thread Charles Hedrick via FreeIPA-users
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

2018-02-19 Thread 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 
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] Re: user/admin

2018-02-14 Thread Charles Hedrick via FreeIPA-users
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 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


[Freeipa-users] Re: user/admin

2018-02-13 Thread Rob Crittenden via FreeIPA-users
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

2018-02-13 Thread Charles Hedrick via FreeIPA-users
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 Hedrick  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.
> 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org