[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GOsa] last(?) missing bit to use gosa in debian-edu out of the box

On Tue, May 18, 2010 at 09:52:08AM +0200, Ronny Aasen wrote:
> Holger Levsen wrote:
> > On Montag, 10. Mai 2010, Andreas B. Mundt wrote:
> >>> after having thought a bit more about the password issue, I think
> >>> we perhaps should add one more question during
> >>> installation/configuration of the main server: Enter the LDAP
> >>> password. 
> > 
> > I think thats a bad idea, as we already ask for the root password.
> > 
> > We didnt want a(nother) password ldap-admin with lwat, so I dont see why we 
> > want it with gosa.
> > 
> >>> What do you think? Any better ideas?
> >> next idea: how about creating this (gosa-) password randomly and use
> >> the "old" root pw in addition for command line tools?
> > 
> > so the gosa password would be for an account with the same right as ldap 
> > admin, but with another name? (So that password can be random..)
> I think a spesific service account similar to smbadmin (gosadmin?) with
> random password is the best option.
> Why does gosa need this access anyway ? Could gosa not ask the user for
> the password to bind to ldap? In the same way that lwat does it today ?
> Or are there cronjobs _writing_ to ldap ?

Well, gosa handles the access permissions in a different way than
lwat. Where Lwat used access rules in slapd.conf, gosa handles its own 
access control lists (ACLs). So you can define pretty accurate what
rights a user has and which objects and attributes he is allowed to
read and/or write to.   

I haven't tested too much yet, but currently there is the super-admin
account which can do anything. All other accounts are allowed to
change only their password curently. I started defining predefined
ACLs for junior-admins and admins, but there is some more work needed.
Some more info is here:


Concerning the password access to ldap:  
I am happy with the way it is done now, with a random password which
is saved on disk but you need read access to the key to decrypt it.  

I am looking forward to have all these things running in our testing
installation and to discuss improvements.



Reply to: