Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Martin Kosek 
On 04/11/2014 02:53 PM, Petr Viktorin wrote:
 On 04/11/2014 02:36 PM, Simo Sorce wrote:
 On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:
 On 04/10/2014 05:29 PM, Petr Viktorin wrote:
 On 04/10/2014 03:04 PM, Martin Kosek wrote:
 On 04/10/2014 02:52 PM, Simo Sorce wrote:
 On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
 On 04/09/2014 12:25 PM, Martin Kosek wrote:
 On 04/03/2014 12:09 PM, Petr Viktorin wrote:
 Hello,
 This adds read permissions to read hosts.

 Read access is given to all authenticated users.
 For reading host membership info, there is a separate permission that
 also
 defaults to all authenticated users.

 The userPassword attribute is not included for obvious reasons.

 1) We decided to show hosts only to authenticated users by default. I
 am just
 thinking - should some portion of hosts be readable just like groups 
 and
 users
 are? For example at least the host core defined by nsHost objectlass?

 objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
 objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
 nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

 Are application supposed to be able to anonymously read that 
 information?

 I'm not sure. Simo?

 Good question, probably not by default, we offer DNS and do not
 recommend people to rely on exposed host maps.

 Question is if should have a separate permission like System: Read Host 
 Core
 Attributes, System: Read Host, System: Read Host Membership or we are
 fine
 with just System: Read Host, System: Read Host Membership.

 If we do not expect people and programs to often read the list of host or 
 the
 basic host information anonymously, I would stick with the latter.

 Let's do that then. It's easy enough to add a custom permission.

 2) Do we want to count enrolledBy and managedBy attribute to System: 
 Read
 Host
 Membership permission or should it be included in the Read Hosts
 permission?

 If we want to stick with previous behavior, we would want to have only
 memberOf listed as this is how our original member handling ACI looks
 like:

 install/share/default-aci.ldif:aci: (targetattr = memberOf ||
 memberHost ||
 memberUser)(version 3.0; acl No anonymous access to member 
 information;
 deny
 (read,search,compare) userdn != ldap:///all;;

 What was the reasoning behind enrolledBy and managedBy? I got it from
 the notes from devconf; I don't think there was much discussion.

 I have no recollection :(

 There was no discussion about these particular attributes. I added then to
 Membership permission because they were DN-ish, but when I think more
 about it,
 it does not seem as a membership in the sense of the ACI above. I would
 personally only keep member/memberOf in the Membership attributes.

 Moved to Read Host.

 3) I could not functionally test if e.g. clients and replicas still
 enroll as
 we do not have an ACI for krbtpolicy/krbRealmContainer yet and
 ipa-client-install searches for it.

 Speaking of which, we will need to have an ACI for reading a portion of
 krbRealmContainer anonymously to enable IPA client autodiscovery
 (cn+objectclass should be sufficient).

 Sad we ended up depending on this, I would have preferred to not depend
 on keeping this around if we ever want to change something.

 Yeah... But we should be OK with exposing just the CN which is not really 
 a
 secret as we know what is the realm name...

 Martin


 The basis looks good now. However, when I was checking host's objectclass 
 and
 attributes we allow, I saw many attributes not listed in our DevConf meeting
 minutes, but which are now missing in the entry when I read it as 
 authenticated
 used.

 As an admin, or as a regular user ?

 krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
 krbLastAdminUnlock, krbLastFailedAuth...
 We may want to list them all, except the ones we chose to now show, like
 krbPrincipalKey :) I would welcome Simo's recommendation in this place.

 I do not think we necessarily need to expose most of them to regular
 users (which include keytab bearing services) by default.

 krbTicketPolicyAux attributes like krbMaxRenewableAge

 Objectclasses for reference:

 objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' 
 AUXILIAR
   Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ 
 krbPrincipalKey
   $ krbTicketPolicyReference $ krbPrincipalExpiration $ 
 krbPasswordExpiration $
krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ 
 krbLastPwdChange
   $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ 
 krbLoginF
   ailedCount $ krbExtraData $ krbLastAdminUnlock ) )

 Of these we may want to show krbPrincipalName, krbCanonicalName,
 krbPrincipalAliases by default.
 
 Added.
 
 I am uncertain about krbPrincipalExpiration, krbPasswordExpiration,
 krbLastPwdChange, but they may be needed for clients like SSSD to do
 proper checking and for power users to figure out

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Petr Viktorin 

On 04/14/2014 10:54 AM, Martin Kosek wrote:

On 04/11/2014 02:53 PM, Petr Viktorin wrote:

On 04/11/2014 02:36 PM, Simo Sorce wrote:

On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:

On 04/10/2014 05:29 PM, Petr Viktorin wrote:

On 04/10/2014 03:04 PM, Martin Kosek wrote:

On 04/10/2014 02:52 PM, Simo Sorce wrote:

On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:

On 04/09/2014 12:25 PM, Martin Kosek wrote:

On 04/03/2014 12:09 PM, Petr Viktorin wrote:

Hello,
This adds read permissions to read hosts.

Read access is given to all authenticated users.
For reading host membership info, there is a separate permission that
also
defaults to all authenticated users.

The userPassword attribute is not included for obvious reasons.


1) We decided to show hosts only to authenticated users by default. I
am just
thinking - should some portion of hosts be readable just like groups and
users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?


I'm not sure. Simo?


Good question, probably not by default, we offer DNS and do not
recommend people to rely on exposed host maps.


Question is if should have a separate permission like System: Read Host Core
Attributes, System: Read Host, System: Read Host Membership or we are
fine
with just System: Read Host, System: Read Host Membership.

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.


Let's do that then. It's easy enough to add a custom permission.


2) Do we want to count enrolledBy and managedBy attribute to System: Read
Host
Membership permission or should it be included in the Read Hosts
permission?

If we want to stick with previous behavior, we would want to have only
memberOf listed as this is how our original member handling ACI looks
like:

install/share/default-aci.ldif:aci: (targetattr = memberOf ||
memberHost ||
memberUser)(version 3.0; acl No anonymous access to member information;
deny
(read,search,compare) userdn != ldap:///all;;


What was the reasoning behind enrolledBy and managedBy? I got it from
the notes from devconf; I don't think there was much discussion.


I have no recollection :(


There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more
about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.


Moved to Read Host.


3) I could not functionally test if e.g. clients and replicas still
enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).


Sad we ended up depending on this, I would have preferred to not depend
on keeping this around if we ever want to change something.


Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin



The basis looks good now. However, when I was checking host's objectclass and
attributes we allow, I saw many attributes not listed in our DevConf meeting
minutes, but which are now missing in the entry when I read it as authenticated
used.


As an admin, or as a regular user ?


krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
krbLastAdminUnlock, krbLastFailedAuth...
We may want to list them all, except the ones we chose to now show, like
krbPrincipalKey :) I would welcome Simo's recommendation in this place.


I do not think we necessarily need to expose most of them to regular
users (which include keytab bearing services) by default.


krbTicketPolicyAux attributes like krbMaxRenewableAge

Objectclasses for reference:

objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR
   Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey
   $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $
krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange
   $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF
   ailedCount $ krbExtraData $ krbLastAdminUnlock ) )


Of these we may want to show krbPrincipalName, krbCanonicalName,
krbPrincipalAliases by default.


Added.


I am uncertain about krbPrincipalExpiration, krbPasswordExpiration,
krbLastPwdChange, but they may be needed for clients like SSSD to do
proper checking and for power users to figure out themselves when they
need to change

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Simo Sorce 
On Mon, 2014-04-14 at 10:54 +0200, Martin Kosek wrote:
 On 04/11/2014 02:53 PM, Petr Viktorin wrote:
  On 04/11/2014 02:36 PM, Simo Sorce wrote:
  On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:
  On 04/10/2014 05:29 PM, Petr Viktorin wrote:
  On 04/10/2014 03:04 PM, Martin Kosek wrote:
  On 04/10/2014 02:52 PM, Simo Sorce wrote:
  On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
  On 04/09/2014 12:25 PM, Martin Kosek wrote:
  On 04/03/2014 12:09 PM, Petr Viktorin wrote:
  Hello,
  This adds read permissions to read hosts.
 
  Read access is given to all authenticated users.
  For reading host membership info, there is a separate permission 
  that
  also
  defaults to all authenticated users.
 
  The userPassword attribute is not included for obvious reasons.
 
  1) We decided to show hosts only to authenticated users by default. I
  am just
  thinking - should some portion of hosts be readable just like groups 
  and
  users
  are? For example at least the host core defined by nsHost objectlass?
 
  objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
  objectclass'
  SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ 
  l $
  nsHostLoc
  ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
 
  Are application supposed to be able to anonymously read that 
  information?
 
  I'm not sure. Simo?
 
  Good question, probably not by default, we offer DNS and do not
  recommend people to rely on exposed host maps.
 
  Question is if should have a separate permission like System: Read 
  Host Core
  Attributes, System: Read Host, System: Read Host Membership or we 
  are
  fine
  with just System: Read Host, System: Read Host Membership.
 
  If we do not expect people and programs to often read the list of host 
  or the
  basic host information anonymously, I would stick with the latter.
 
  Let's do that then. It's easy enough to add a custom permission.
 
  2) Do we want to count enrolledBy and managedBy attribute to 
  System: Read
  Host
  Membership permission or should it be included in the Read Hosts
  permission?
 
  If we want to stick with previous behavior, we would want to have 
  only
  memberOf listed as this is how our original member handling ACI 
  looks
  like:
 
  install/share/default-aci.ldif:aci: (targetattr = memberOf ||
  memberHost ||
  memberUser)(version 3.0; acl No anonymous access to member 
  information;
  deny
  (read,search,compare) userdn != ldap:///all;;
 
  What was the reasoning behind enrolledBy and managedBy? I got it from
  the notes from devconf; I don't think there was much discussion.
 
  I have no recollection :(
 
  There was no discussion about these particular attributes. I added then 
  to
  Membership permission because they were DN-ish, but when I think more
  about it,
  it does not seem as a membership in the sense of the ACI above. I would
  personally only keep member/memberOf in the Membership attributes.
 
  Moved to Read Host.
 
  3) I could not functionally test if e.g. clients and replicas still
  enroll as
  we do not have an ACI for krbtpolicy/krbRealmContainer yet and
  ipa-client-install searches for it.
 
  Speaking of which, we will need to have an ACI for reading a portion 
  of
  krbRealmContainer anonymously to enable IPA client autodiscovery
  (cn+objectclass should be sufficient).
 
  Sad we ended up depending on this, I would have preferred to not depend
  on keeping this around if we ever want to change something.
 
  Yeah... But we should be OK with exposing just the CN which is not 
  really a
  secret as we know what is the realm name...
 
  Martin
 
 
  The basis looks good now. However, when I was checking host's objectclass 
  and
  attributes we allow, I saw many attributes not listed in our DevConf 
  meeting
  minutes, but which are now missing in the entry when I read it as 
  authenticated
  used.
 
  As an admin, or as a regular user ?
 
  krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
  krbLastAdminUnlock, krbLastFailedAuth...
  We may want to list them all, except the ones we chose to now show, like
  krbPrincipalKey :) I would welcome Simo's recommendation in this place.
 
  I do not think we necessarily need to expose most of them to regular
  users (which include keytab bearing services) by default.
 
  krbTicketPolicyAux attributes like krbMaxRenewableAge
 
  Objectclasses for reference:
 
  objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' 
  AUXILIAR
Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ 
  krbPrincipalKey
$ krbTicketPolicyReference $ krbPrincipalExpiration $ 
  krbPasswordExpiration $
 krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ 
  krbLastPwdChange
$ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ 
  krbLoginF
ailedCount $ krbExtraData $ krbLastAdminUnlock ) )
 
  Of these we may want to show krbPrincipalName, krbCanonicalName,
  krbPrincipalAliases

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-11 Thread Martin Kosek 
On 04/10/2014 05:29 PM, Petr Viktorin wrote:
 On 04/10/2014 03:04 PM, Martin Kosek wrote:
 On 04/10/2014 02:52 PM, Simo Sorce wrote:
 On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
 On 04/09/2014 12:25 PM, Martin Kosek wrote:
 On 04/03/2014 12:09 PM, Petr Viktorin wrote:
 Hello,
 This adds read permissions to read hosts.

 Read access is given to all authenticated users.
 For reading host membership info, there is a separate permission that 
 also
 defaults to all authenticated users.

 The userPassword attribute is not included for obvious reasons.

 1) We decided to show hosts only to authenticated users by default. I am 
 just
 thinking - should some portion of hosts be readable just like groups and
 users
 are? For example at least the host core defined by nsHost objectlass?

 objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined 
 objectclass'
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
 nsHostLoc
ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

 Are application supposed to be able to anonymously read that information?

 I'm not sure. Simo?

 Good question, probably not by default, we offer DNS and do not
 recommend people to rely on exposed host maps.

 Question is if should have a separate permission like System: Read Host Core
 Attributes, System: Read Host, System: Read Host Membership or we are 
 fine
 with just System: Read Host, System: Read Host Membership.

 If we do not expect people and programs to often read the list of host or the
 basic host information anonymously, I would stick with the latter.
 
 Let's do that then. It's easy enough to add a custom permission.
 
 2) Do we want to count enrolledBy and managedBy attribute to System: Read
 Host
 Membership permission or should it be included in the Read Hosts
 permission?

 If we want to stick with previous behavior, we would want to have only
 memberOf listed as this is how our original member handling ACI looks 
 like:

 install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost 
 ||
 memberUser)(version 3.0; acl No anonymous access to member information;
 deny
 (read,search,compare) userdn != ldap:///all;;

 What was the reasoning behind enrolledBy and managedBy? I got it from
 the notes from devconf; I don't think there was much discussion.

 I have no recollection :(

 There was no discussion about these particular attributes. I added then to
 Membership permission because they were DN-ish, but when I think more about 
 it,
 it does not seem as a membership in the sense of the ACI above. I would
 personally only keep member/memberOf in the Membership attributes.
 
 Moved to Read Host.
 
 3) I could not functionally test if e.g. clients and replicas still 
 enroll as
 we do not have an ACI for krbtpolicy/krbRealmContainer yet and
 ipa-client-install searches for it.

 Speaking of which, we will need to have an ACI for reading a portion of
 krbRealmContainer anonymously to enable IPA client autodiscovery
 (cn+objectclass should be sufficient).

 Sad we ended up depending on this, I would have preferred to not depend
 on keeping this around if we ever want to change something.

 Yeah... But we should be OK with exposing just the CN which is not really a
 secret as we know what is the realm name...

 Martin


The basis looks good now. However, when I was checking host's objectclass and
attributes we allow, I saw many attributes not listed in our DevConf meeting
minutes, but which are now missing in the entry when I read it as authenticated
used.

krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
krbLastAdminUnlock, krbLastFailedAuth...
We may want to list them all, except the ones we chose to now show, like
krbPrincipalKey :) I would welcome Simo's recommendation in this place.

krbTicketPolicyAux attributes like krbMaxRenewableAge

Objectclasses for reference:

objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR
 Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey
 $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $
  krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange
 $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF
 ailedCount $ krbExtraData $ krbLastAdminUnlock ) )

objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI
 LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) )

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-11 Thread Simo Sorce 
On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:
 On 04/10/2014 05:29 PM, Petr Viktorin wrote:
  On 04/10/2014 03:04 PM, Martin Kosek wrote:
  On 04/10/2014 02:52 PM, Simo Sorce wrote:
  On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
  On 04/09/2014 12:25 PM, Martin Kosek wrote:
  On 04/03/2014 12:09 PM, Petr Viktorin wrote:
  Hello,
  This adds read permissions to read hosts.
 
  Read access is given to all authenticated users.
  For reading host membership info, there is a separate permission that 
  also
  defaults to all authenticated users.
 
  The userPassword attribute is not included for obvious reasons.
 
  1) We decided to show hosts only to authenticated users by default. I 
  am just
  thinking - should some portion of hosts be readable just like groups and
  users
  are? For example at least the host core defined by nsHost objectlass?
 
  objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined 
  objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
  nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
 
  Are application supposed to be able to anonymously read that 
  information?
 
  I'm not sure. Simo?
 
  Good question, probably not by default, we offer DNS and do not
  recommend people to rely on exposed host maps.
 
  Question is if should have a separate permission like System: Read Host 
  Core
  Attributes, System: Read Host, System: Read Host Membership or we are 
  fine
  with just System: Read Host, System: Read Host Membership.
 
  If we do not expect people and programs to often read the list of host or 
  the
  basic host information anonymously, I would stick with the latter.
  
  Let's do that then. It's easy enough to add a custom permission.
  
  2) Do we want to count enrolledBy and managedBy attribute to System: 
  Read
  Host
  Membership permission or should it be included in the Read Hosts
  permission?
 
  If we want to stick with previous behavior, we would want to have only
  memberOf listed as this is how our original member handling ACI looks 
  like:
 
  install/share/default-aci.ldif:aci: (targetattr = memberOf || 
  memberHost ||
  memberUser)(version 3.0; acl No anonymous access to member 
  information;
  deny
  (read,search,compare) userdn != ldap:///all;;
 
  What was the reasoning behind enrolledBy and managedBy? I got it from
  the notes from devconf; I don't think there was much discussion.
 
  I have no recollection :(
 
  There was no discussion about these particular attributes. I added then to
  Membership permission because they were DN-ish, but when I think more 
  about it,
  it does not seem as a membership in the sense of the ACI above. I would
  personally only keep member/memberOf in the Membership attributes.
  
  Moved to Read Host.
  
  3) I could not functionally test if e.g. clients and replicas still 
  enroll as
  we do not have an ACI for krbtpolicy/krbRealmContainer yet and
  ipa-client-install searches for it.
 
  Speaking of which, we will need to have an ACI for reading a portion of
  krbRealmContainer anonymously to enable IPA client autodiscovery
  (cn+objectclass should be sufficient).
 
  Sad we ended up depending on this, I would have preferred to not depend
  on keeping this around if we ever want to change something.
 
  Yeah... But we should be OK with exposing just the CN which is not really a
  secret as we know what is the realm name...
 
  Martin
 
 
 The basis looks good now. However, when I was checking host's objectclass and
 attributes we allow, I saw many attributes not listed in our DevConf meeting
 minutes, but which are now missing in the entry when I read it as 
 authenticated
 used.

As an admin, or as a regular user ?

 krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
 krbLastAdminUnlock, krbLastFailedAuth...
 We may want to list them all, except the ones we chose to now show, like
 krbPrincipalKey :) I would welcome Simo's recommendation in this place.

I do not think we necessarily need to expose most of them to regular
users (which include keytab bearing services) by default.

 krbTicketPolicyAux attributes like krbMaxRenewableAge
 
 Objectclasses for reference:
 
 objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR
  Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey
  $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $
   krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange
  $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF
  ailedCount $ krbExtraData $ krbLastAdminUnlock ) )

Of these we may want to show krbPrincipalName, krbCanonicalName,
krbPrincipalAliases by default.

I am uncertain about krbPrincipalExpiration, krbPasswordExpiration,
krbLastPwdChange, but they may be needed for clients like SSSD to do
proper checking and for power users to figure out themselves when they

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-11 Thread Petr Viktorin 

On 04/11/2014 02:36 PM, Simo Sorce wrote:

On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:

On 04/10/2014 05:29 PM, Petr Viktorin wrote:

On 04/10/2014 03:04 PM, Martin Kosek wrote:

On 04/10/2014 02:52 PM, Simo Sorce wrote:

On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:

On 04/09/2014 12:25 PM, Martin Kosek wrote:

On 04/03/2014 12:09 PM, Petr Viktorin wrote:

Hello,
This adds read permissions to read hosts.

Read access is given to all authenticated users.
For reading host membership info, there is a separate permission that also
defaults to all authenticated users.

The userPassword attribute is not included for obvious reasons.


1) We decided to show hosts only to authenticated users by default. I am just
thinking - should some portion of hosts be readable just like groups and
users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
nsHostLoc
ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?


I'm not sure. Simo?


Good question, probably not by default, we offer DNS and do not
recommend people to rely on exposed host maps.


Question is if should have a separate permission like System: Read Host Core
Attributes, System: Read Host, System: Read Host Membership or we are fine
with just System: Read Host, System: Read Host Membership.

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.


Let's do that then. It's easy enough to add a custom permission.


2) Do we want to count enrolledBy and managedBy attribute to System: Read
Host
Membership permission or should it be included in the Read Hosts
permission?

If we want to stick with previous behavior, we would want to have only
memberOf listed as this is how our original member handling ACI looks like:

install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
memberUser)(version 3.0; acl No anonymous access to member information;
deny
(read,search,compare) userdn != ldap:///all;;


What was the reasoning behind enrolledBy and managedBy? I got it from
the notes from devconf; I don't think there was much discussion.


I have no recollection :(


There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.


Moved to Read Host.


3) I could not functionally test if e.g. clients and replicas still enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).


Sad we ended up depending on this, I would have preferred to not depend
on keeping this around if we ever want to change something.


Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin



The basis looks good now. However, when I was checking host's objectclass and
attributes we allow, I saw many attributes not listed in our DevConf meeting
minutes, but which are now missing in the entry when I read it as authenticated
used.


As an admin, or as a regular user ?


krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
krbLastAdminUnlock, krbLastFailedAuth...
We may want to list them all, except the ones we chose to now show, like
krbPrincipalKey :) I would welcome Simo's recommendation in this place.


I do not think we necessarily need to expose most of them to regular
users (which include keytab bearing services) by default.


krbTicketPolicyAux attributes like krbMaxRenewableAge

Objectclasses for reference:

objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR
  Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey
  $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $
   krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange
  $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF
  ailedCount $ krbExtraData $ krbLastAdminUnlock ) )


Of these we may want to show krbPrincipalName, krbCanonicalName,
krbPrincipalAliases by default.


Added.


I am uncertain about krbPrincipalExpiration, krbPasswordExpiration,
krbLastPwdChange, but they may be needed for clients like SSSD to do
proper checking and for power users to figure out themselves when they
need to change passwords or ask for an account validity extension etc..


Let's show them then, to make their lives

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-10 Thread Petr Viktorin 

On 04/09/2014 12:25 PM, Martin Kosek wrote:

On 04/03/2014 12:09 PM, Petr Viktorin wrote:

Hello,
This adds read permissions to read hosts.

Read access is given to all authenticated users.
For reading host membership info, there is a separate permission that also
defaults to all authenticated users.

The userPassword attribute is not included for obvious reasons.


1) We decided to show hosts only to authenticated users by default. I am just
thinking - should some portion of hosts be readable just like groups and users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
  SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc
  ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?


I'm not sure. Simo?


2) Do we want to count enrolledBy and managedBy attribute to System: Read Host
Membership permission or should it be included in the Read Hosts permission?

If we want to stick with previous behavior, we would want to have only
memberOf listed as this is how our original member handling ACI looks like:

install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
memberUser)(version 3.0; acl No anonymous access to member information; deny
(read,search,compare) userdn != ldap:///all;;


What was the reasoning behind enrolledBy and managedBy? I got it from 
the notes from devconf; I don't think there was much discussion.



3) I could not functionally test if e.g. clients and replicas still enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).

We can wait with the functional testing until you get to krbRealmContainer 
though.


Yes, it's still quite early for functional testing.


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-10 Thread Simo Sorce 
On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
 On 04/09/2014 12:25 PM, Martin Kosek wrote:
  On 04/03/2014 12:09 PM, Petr Viktorin wrote:
  Hello,
  This adds read permissions to read hosts.
 
  Read access is given to all authenticated users.
  For reading host membership info, there is a separate permission that also
  defaults to all authenticated users.
 
  The userPassword attribute is not included for obvious reasons.
 
  1) We decided to show hosts only to authenticated users by default. I am 
  just
  thinking - should some portion of hosts be readable just like groups and 
  users
  are? For example at least the host core defined by nsHost objectlass?
 
  objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined 
  objectclass'
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ 
  nsHostLoc
ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
 
  Are application supposed to be able to anonymously read that information?
 
 I'm not sure. Simo?

Good question, probably not by default, we offer DNS and do not
recommend people to rely on exposed host maps.

  2) Do we want to count enrolledBy and managedBy attribute to System: Read 
  Host
  Membership permission or should it be included in the Read Hosts 
  permission?
 
  If we want to stick with previous behavior, we would want to have only
  memberOf listed as this is how our original member handling ACI looks 
  like:
 
  install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
  memberUser)(version 3.0; acl No anonymous access to member information; 
  deny
  (read,search,compare) userdn != ldap:///all;;
 
 What was the reasoning behind enrolledBy and managedBy? I got it from 
 the notes from devconf; I don't think there was much discussion.

I have no recollection :(

  3) I could not functionally test if e.g. clients and replicas still enroll 
  as
  we do not have an ACI for krbtpolicy/krbRealmContainer yet and
  ipa-client-install searches for it.
 
  Speaking of which, we will need to have an ACI for reading a portion of
  krbRealmContainer anonymously to enable IPA client autodiscovery
  (cn+objectclass should be sufficient).

Sad we ended up depending on this, I would have preferred to not depend
on keeping this around if we ever want to change something.

  We can wait with the functional testing until you get to krbRealmContainer 
  though.
 
 Yes, it's still quite early for functional testing.



-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-10 Thread Martin Kosek 
On 04/10/2014 02:52 PM, Simo Sorce wrote:
 On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
 On 04/09/2014 12:25 PM, Martin Kosek wrote:
 On 04/03/2014 12:09 PM, Petr Viktorin wrote:
 Hello,
 This adds read permissions to read hosts.

 Read access is given to all authenticated users.
 For reading host membership info, there is a separate permission that also
 defaults to all authenticated users.

 The userPassword attribute is not included for obvious reasons.

 1) We decided to show hosts only to authenticated users by default. I am 
 just
 thinking - should some portion of hosts be readable just like groups and 
 users
 are? For example at least the host core defined by nsHost objectlass?

 objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined 
 objectclass'
   SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ 
 nsHostLoc
   ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

 Are application supposed to be able to anonymously read that information?

 I'm not sure. Simo?
 
 Good question, probably not by default, we offer DNS and do not
 recommend people to rely on exposed host maps.

Question is if should have a separate permission like System: Read Host Core
Attributes, System: Read Host, System: Read Host Membership or we are fine
with just System: Read Host, System: Read Host Membership.

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.

 
 2) Do we want to count enrolledBy and managedBy attribute to System: Read 
 Host
 Membership permission or should it be included in the Read Hosts 
 permission?

 If we want to stick with previous behavior, we would want to have only
 memberOf listed as this is how our original member handling ACI looks 
 like:

 install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
 memberUser)(version 3.0; acl No anonymous access to member information; 
 deny
 (read,search,compare) userdn != ldap:///all;;

 What was the reasoning behind enrolledBy and managedBy? I got it from 
 the notes from devconf; I don't think there was much discussion.
 
 I have no recollection :(

There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.

 3) I could not functionally test if e.g. clients and replicas still enroll 
 as
 we do not have an ACI for krbtpolicy/krbRealmContainer yet and
 ipa-client-install searches for it.

 Speaking of which, we will need to have an ACI for reading a portion of
 krbRealmContainer anonymously to enable IPA client autodiscovery
 (cn+objectclass should be sufficient).
 
 Sad we ended up depending on this, I would have preferred to not depend
 on keeping this around if we ever want to change something.

Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-10 Thread Petr Viktorin 

On 04/10/2014 03:04 PM, Martin Kosek wrote:

On 04/10/2014 02:52 PM, Simo Sorce wrote:

On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:

On 04/09/2014 12:25 PM, Martin Kosek wrote:

On 04/03/2014 12:09 PM, Petr Viktorin wrote:

Hello,
This adds read permissions to read hosts.

Read access is given to all authenticated users.
For reading host membership info, there is a separate permission that also
defaults to all authenticated users.

The userPassword attribute is not included for obvious reasons.


1) We decided to show hosts only to authenticated users by default. I am just
thinking - should some portion of hosts be readable just like groups and users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
   SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc
   ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?


I'm not sure. Simo?


Good question, probably not by default, we offer DNS and do not
recommend people to rely on exposed host maps.


Question is if should have a separate permission like System: Read Host Core
Attributes, System: Read Host, System: Read Host Membership or we are fine
with just System: Read Host, System: Read Host Membership.

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.


Let's do that then. It's easy enough to add a custom permission.


2) Do we want to count enrolledBy and managedBy attribute to System: Read Host
Membership permission or should it be included in the Read Hosts permission?

If we want to stick with previous behavior, we would want to have only
memberOf listed as this is how our original member handling ACI looks like:

install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
memberUser)(version 3.0; acl No anonymous access to member information; deny
(read,search,compare) userdn != ldap:///all;;


What was the reasoning behind enrolledBy and managedBy? I got it from
the notes from devconf; I don't think there was much discussion.


I have no recollection :(


There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.


Moved to Read Host.


3) I could not functionally test if e.g. clients and replicas still enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).


Sad we ended up depending on this, I would have preferred to not depend
on keeping this around if we ever want to change something.


Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin




--
Petr³
From 043c9023eac6bf9142b1fc5c98368bf61d49aeaf Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 15:58:08 +0100
Subject: [PATCH] Add managed read permissions to host

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 ipalib/plugins/host.py | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py
index 1e339acfc55820db232ba189275a05957ef8ebbd..8c7772f8fce17185c040e271510fa1eda3a40f48 100644
--- a/ipalib/plugins/host.py
+++ b/ipalib/plugins/host.py
@@ -252,6 +252,29 @@ class host(LDAPObject):
 }
 password_attributes = [('userpassword', 'has_password'),
('krbprincipalkey', 'has_keytab')]
+managed_permissions = {
+'System: Read Hosts': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'description', 'fqdn', 'ipaclientversion',
+'ipakrbauthzdata', 'ipasshpubkey', 'ipauniqueid',
+'krbprincipalname', 'l', 'macaddress', 'nshardwareplatform',
+'nshostlocation', 'nsosversion', 'objectclass',
+'serverhostname', 'usercertificate', 'userclass',
+'enrolledby', 'managedby',
+},
+},
+'System: Read Host Membership': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'memberof',
+},
+},
+}
 
 label = _('Hosts')
 label_singular =

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-09 Thread Martin Kosek 
On 04/03/2014 12:09 PM, Petr Viktorin wrote:
 Hello,
 This adds read permissions to read hosts.
 
 Read access is given to all authenticated users.
 For reading host membership info, there is a separate permission that also
 defaults to all authenticated users.
 
 The userPassword attribute is not included for obvious reasons.

1) We decided to show hosts only to authenticated users by default. I am just
thinking - should some portion of hosts be readable just like groups and users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?

2) Do we want to count enrolledBy and managedBy attribute to System: Read Host
Membership permission or should it be included in the Read Hosts permission?

If we want to stick with previous behavior, we would want to have only
memberOf listed as this is how our original member handling ACI looks like:

install/share/default-aci.ldif:aci: (targetattr = memberOf || memberHost ||
memberUser)(version 3.0; acl No anonymous access to member information; deny
(read,search,compare) userdn != ldap:///all;;


3) I could not functionally test if e.g. clients and replicas still enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).

We can wait with the functional testing until you get to krbRealmContainer 
though.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel