Re: Admin roles in Debian Edu
Hi,
Petter Reinholdtsen wrote:
What kind of admin roles should we provide out of the box in Debian
Edu/Squeeze?
I suggest:
admin or admins
jradmin or jradmins
teacher or teachers
student* or students*
additionally we could think of (lazy - omit plural):
professor
pupil*
assistant
tutor
lecturer
examinee
Personally I do not like plural here, but in any case:
1) we should use the old ones
2) we should either use plural or singular not both.
*) In Germany we would like to distinguish between student
(university) and pupil (school).
In Squeeze, this setup is partly represented in slapd.conf, but
because we have changed the LDAP structure quite a bit, I suspect we
have lost some of these settings.
For Gosa, Andreas has proposed a completely different setup, if I
understand this correctly.
super-admin LDAP user
This user can do anything with every LDAP object. Its default
password is the installation root password.
Gosa admin role
Entities with this role can do anything to every LDAP object. Not
quite sure what these entities are, if they are members of a group
or something else.
So this is the same as super-admin LDAP user?
No subtree for Admins?
Why two different kind of role assignment methods?
Gosa jradmin role
Entities with this role can modify some attributes of user and
group objects.
How is this implemented?
user objects in teachers subtree
Users here got the Gosa jradmin role over all objecst in the
students subtree.
user objects in students subtree
Users in this subtree can only change their own password.
I do not now the actual implementation with GOSA, please correct me
if my following guesses are wrong.
In terms of "order" the storage of objects in "its" subtree make
sense at the first thought.
However it might have disadvantages.
1) if we want give the access to some service, for example PAM to an
entity for example "posixAccount" we have to add 2 entries, one per
sub tree to point to all accounts. I do not know how many hooks PAM
has, but this probably do not scale.
2) a uidNumber should of course be unique. If you have 2 subtrees
you may have to query 2 subtrees to do that. So this might be a
small performance penalty. But the "uid" attribute may likely become
_non_ unique!
We just shuold think about the following scenario:
a) [2 role problem] A student "alfred" is in the ou=Students subtree
and should act sometimes as teacher. What will we do? add uid=alfred
to ou=Students and ou=Teachers ? Will probably be a mess in regards
to uidNumber or homeDirectory. Or we need to have posix and non
posix accounts? ... Or we have to come to the conclusion, that a
user can just have one role. Which I think is huge disadvantage
compared to the old system.
b) [role change] The next question would be: what happens when a
university student gets promoted to a teacher? Of course the entry
dn can renamed and the object can be transfered into a different
subtree. Then you have to find all reference entries to that object like
member: uid=alfred,ou=Students,dc=skole,dc=skolelinux,dc=no
and this need to be renamed all over the place (or have to be
deleted) in respect to there meaning to the object which they contain.
c) [add role] On other think is that it if we add more roles, we
will have more subtrees. OK, there is not a shortage on it, but it
will make it more difficult to answer the question: "list all users
on the system".
In regard to PAM, we can not add a role with an LDAP (web) GUI. Yes
we can add a new ou (a different question though which ou is a role
and which not) but we can (or should not) touch the PAM mechanism in
files with a LDAP (Web) GUI. (If I need to explain why one should
not, please ask - I skip it here)
Conclusion: if we use the Tree=Role approach we will lose a lot of
flexibility in adding, maintaining, assigning roles. And we loose
the ability to have more the one role per posix object.
Even if I am wrong in some of my assumptions that the subtree
determines the role, then I think a subtree do not add functionality
and should be omitted. Only one subtree for users!
It is the task of the GUI to present objects in suitable manner to
the admin not the LDAP tree. The LDAP tree is a representation of
the logical structure of the data in regard to machines not humans.
The access control with Gosa is done by Gosa itself, and not by
OpenLDAP/slapd, while the original setup enforced the access control
using the LDAP server.
I'm not sure which setup make most sense, but the original setup is
simpler and I suspect it fits schools better, allowing the sysadmin to
grant privileges on an individual basis instead of granting it to all
teachers. I also suspect it is best to control access on the LDAP
level, to make sure any LDAP tool can be used to update LDAP with the
correct privileges.
I think Petter you are right. If we want additionally access by
other tools to the LDAP server - and this is one good reason to use
a LDAP server - we have to make sure that the ACLs are set
correctly. Even if some tools like GOSA or CipUX decide to implement
its own access.
Like Petter I would say, the old layout was quite able to server the
demands for schools. And keep it simple.
Any opinions on what the future setup for administrative privileges
should look like?
good, flexible and changeable by the local admin via GUI.
Best regards
Christian
Reply to: