[Freeipa-devel] [PATCH] a step closer to the final directory layout

[Simo Sorce]

On Wed, 2007-08-29 at 15:59 -0700, Pete Rowley wrote:
> > +dn: uid=admin,cn=users,cn=accounts,$SUFFIX
> >   
> #PARPAR: I think this should be in cn=sysaccounts, cn=etc

Right, missed this.

> > +changetype: add
> >  objectClass: top
> > +objectClass: person
> > +objectClass: organizationalPerson
> >   
> #PARPAR: I also think it should _not_ be an organizationalPerson (or 
> person), this is truly an account unrelated to meat space

But it will still be posixAccount ? Sounds ok for me.

> > -dn: cn=admin,ou=groups,ou=default,$SUFFIX
> > +dn: cn=admins,cn=groups,cn=accounts,$SUFFIX
> >  changetype: add
> > -description: ou=users administrators
> >   
> #PARPAR: description: Account administrator group

ACK

> >  objectClass: top
> >  objectClass: groupofuniquenames
> >  objectClass: posixGroup
> > -gidNumber: 500
> > -cn: admin
> > +cn: admins
> >   
> #PARPAR: Account Admins?

ACK

> > +gidNumber: 1001
> > +uniqueMember: uid=admin,cn=sysaccounts,cn=etc,$SUFFIX
> >   
> #PARPAR: strictly speaking this admin doesn't need to be here - it's the 
> uber acount

This is true, but I'd like it to have any access that is given to admins
group as well, or do we risk it to have restrictions by way of unwissely
set ACIs ? Uhmmm the problem is that I need a primary group (pesky unix
conventions) for posixAccount, what should we use ?

> > +
> > +dn: cn=ipausers,cn=groups,cn=accounts,$SUFFIX
> > +changetype: add
> > +objectClass: top
> > +objectClass: groupofuniquenames
> > +objectClass: posixGroup
> > +gidNumber: 1002
> > +cn: ipausers
> > diff -r 7aba398c4d98 -r ded52fae8158 ipa-server/ipa-install/share/default-aci.ldif
> > --- a/ipa-server/ipa-install/share/default-aci.ldif	Tue Aug 28 10:46:03 2007 -0400
> > +++ b/ipa-server/ipa-install/share/default-aci.ldif	Wed Aug 29 18:07:05 2007 -0400
> > @@ -3,12 +3,9 @@ changetype: modify
> >  changetype: modify
> >  replace: aci
> >  aci: (targetattr!="userPassword || krbPrincipalKey ||sambaLMPassword || sambaNTPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
> #PARPAR: I think the anonymous aci should be limited to the cn=accounts 
> entry and we need to look through the current schema and whitelist 
> things that seem less sensitive and/or are required for common systems 
> like email to work rather than this blacklist a few approach.

This will require a lot of testing, whitelisting is much more difficult
then just blacklisting, and will require admins to put their hands in
the ACI as soon as they want to extend the schema, so I am unsure if
this in practice would be wise, while I agree it would be better
security wise.

> > +aci: (targetattr=*)(version 3.0; acl "Admin has mighty powers"; allow (all) userdn="ldap:///uid=admin,cn=sysaccounts,cn=etc,$SUFFIX";)
> >   
> #PARPAR: mighty they may be but "Admin can do anything" is more descriptive

ACK

> > +aci: (targetattr="krbPrincipalName || krbUPEnabled || krbPrincipalKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData")(version 3.0; acl "KDC System Account"; allow (read, search, compare) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";)
> > +aci: (targetattr="krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount")(version 3.0; acl "KDC System Account"; allow (read, search, compare, write) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";)
> > +aci: (targetattr="userPassword || krbPrincipalKey ||sambaLMPassword || sambaNTPassword || krbPasswordExpiration || krbPwdHistory || krbLastPwdChange")(version 3.0; acl "Kpasswd access to passowrd hashes for passowrd changes"; allow (read, search, compare, write) userdn="ldap:///krbprincipalname=kadmin/changepw@$REALM,cn=$REALM,cn=kerberos,$SUFFIX";)
> >   
> #PARPAR: hmm, skeptical about allowing anything to search on a password 
> - why is this needed?

this is the account used by kpasswd to change the password, it must be
able to read it to store it in the history, but probably search and
compare are not needed, I'll remove them and will test.

> > -dn: cn=kerberos,cn=mapping,cn=sasl,cn=config
> > +dn: cn=fullprinc,cn=mapping,cn=sasl,cn=config
> >   
> #PARPAR: cn=full principal more descriptive

ACK
  
> > +dn: cn=justname,cn=mapping,cn=sasl,cn=config
> >   
> #PARPAR: cn=name only?

ACK

Will send a revised patch with these corrections.
Simo.