Univention Bugzilla – Bug 26021
Entfernen von ucsschoolRole
Last modified: 2012-06-11 06:29:44 CEST
Um die LDAP-ACLs zu vereinfachen, soll das LDAP-Attribut ucsschoolRole von den Importskripten nicht mehr gepflegt werden. Die entsprechenden Codeteile sind aus ucs-school-import zu entfernen. Aus Kompatibilitätgründen sollte das entsprechende LDAP-Schema weiterhin in UCS@school enthalten bleiben. Die LDAP-ACLs sollen eine Replikation des Mitarbeiter-Containers nur von Verwaltungs-DCs/Memberservern zulassen, während der Lehrer-Container nur von Edukativ-DCs/Memberservern repliziert werden darf. Eine Unterscheidung anhand von ucsschoolRole soll nicht mehr stattfinden. Es soll ein zusätzlicher Container eingeführt werden, der Objekte beinhaltet, die von beiden DCs/Memberservern repliziert werden dürfen (Mitarbeiter+Lehrer). Dieser muss sowohl von den LDAP-ACLs abgebildet werden als auch vom Importskript automatisch angelegt werden.
Der neue Container lautet "cn=lehrer und mitarbeiter,cn=users,ou=XXX,BASEDN". ("+" im RDN erzeugt Probleme in den UDM-Modulen). Dafür wurde eine neue UCR-Variable eingeführt (ucsschool/ldap/default/container/teachers-and-staff), die auf den Defaultwert "lehrer und mitarbeiter" gesetzt wird. Diese Variable wird, wie die übrigen ucsschool/ldap/default/container/* Variablen auch, von den LDAP-ACLs und dem Importskript ausgewertet. Die LDAP-ACLs wurden angepasst: Die Systeme des Verwaltungsnetzes replizieren jetzt den Container "mitarbeiter" und "lehrer und mitarbeiter". Die Systeme des Edukativnetzes replizieren die Container "lehrer und mitarbeiter", "lehrer" sowie "schueler". Weiterhin wurden alle anderen bestehenden ACLs angepasst, damit Benutzer aus diesem Container die gleichen Rechte wie vorher mit der Vereinigung der Rollen "staff" und "teacher". Beispiel-Importdatei: A pupil1 Krause Daniel ou1 ou1-7C pupil1@example.com 0 1 0 A teacher1 Lehmann Daniel ou1 ou1-7C teacher1@example.com 1 1 0 A tstaff1 Krause Gabriele ou1 ou1-7C tstaff1@example.com 1 1 1 A staff1 Lehmann Gabriele ou1 ou1-7C staff1@example.com 0 1 1 Bedeutung der letzten 3 Werte: isTeacher, isActivated, isStaff Die Benutzer werden damit wie folgt auf die Container und Gruppen verteilt: Container cn=schueler: pupil1 Container cn=lehrer: teacher1 Container cn=lehrer und mitarbeiter: tstaff1 Container cn=mitarbeiter: staff1 Gruppe cn=schueler-ou1: pupil1 Gruppe cn=lehrer-ou1: teacher1, tstaff1 Gruppe cn=mitarbeiter-ou1: tstaff1, staff1 Gruppe cn=Domain Users ou1: pupil1, teacher1, tstaff1, staff1 Das alte LDAP-Schema wird weiterhin mit ausgeliefert. Das alte Extended Attribute wird vom Joinskript während des Updates automatisch entfernt. Changelogeintrag wurde erstellt ucs-school-import (8.0.38-1) unstable; urgency=low ucs-school-ldap-acls-master (7.0.1-1) unstable; urgency=low
*** Bug 15074 has been marked as a duplicate of this bug. ***
Das Skript ucs-school-add-role wurde aus dem Paket entfernt und wird im Joinskript nicht mehr aufgerufen. ucs-school-import (8.0.38-2) unstable; urgency=low
FAILED - Die Systeme des Verwaltungsnetzes replizieren jetzt den Container "mitarbeiter" und "lehrer und mitarbeiter". Die Systeme des Edukativnetzes replizieren die Container "lehrer und mitarbeiter", "lehrer" sowie "schueler". -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "cn=lehrer,cn=users,ou=s02,dc=as,dc=df" "univentionObjectType/read" read access to univentionObjectType: ALLOWED DC-Verwaltungsnetz:*:5037:dcs01v-01$,masterv$,dcs02v-01$ DC-Edukativnetz:*:5039:dcs01-01$,dcs02-01$ Soweit ich das verstehe, liegt es an dieser ALC, das der Zugriff erlaubt wird: # Slave-Controller duerfen Eintraege Ihrer ou lesen und schreiben... # Lehrer und Memberserver duerfen sie lesen, ou-eigene bekommen Stand... access to dn.regex="^(.+,)?ou=([^,]+),dc=as,dc=df$$" ... OK - Container wird angelegt -> /usr/share/ucs-school-import/scripts/create_ou s02 -> univention-ldapsearch -b ou=s02,dc=as,dc=df cn="lehrer und mit*" \ dn -LLL dn: cn=lehrer und mitarbeiter,cn=users,ou=s02,dc=as,dc=df OK - Accounts werden in den entsprechenden Containern abgelegt -> univention-ldapsearch -b ou=s02,dc=as,dc=df dn -LLL| grep uid dn: uid=p010,cn=schueler,cn=users,ou=s02,dc=as,dc=df dn: uid=t110,cn=lehrer,cn=users,ou=s02,dc=as,dc=df dn: uid=x111,cn=lehrer und mitarbeiter,cn=users,ou=s02,dc=as,dc=df dn: uid=s011,cn=mitarbeiter,cn=users,ou=s02,dc=as,dc=df OK - Weiterhin wurden alle anderen bestehenden ACLs angepasst, damit Benutzer aus diesem Container die gleichen Rechte wie vorher mit der Vereinigung der Rollen "staff" und "teacher". OK - Das alte LDAP-Schema wird weiterhin mit ausgeliefert. -> univention-ldapsearch -b "cn=subschema" -s base \ "(objectclass=subschema)" '*' + univentionObjectType $ univentionUMCHelpdeskCategory $ ucsschoolRole $ univen univentionObjectType $ univentionUMCHelpdeskCategory $ ucsschoolRole $ unive attributeTypes: ( 1.3.6.1.4.1.10176.4000.2.5101 NAME 'ucsschoolRole' DESC 'Rol p AUXILIARY MAY ucsschoolRole ) OK - Das Skript ucs-school-add-role wurde aus dem Paket entfernt... OK - Das alte Extended Attribute wird vom Joinskript während des Updates automatisch entfernt. OK - Changelog
(In reply to comment #4) > FAILED - Die Systeme des Verwaltungsnetzes replizieren jetzt den Container > "mitarbeiter" und "lehrer und mitarbeiter". Die Systeme des Edukativnetzes > replizieren die Container "lehrer und mitarbeiter", "lehrer" sowie > "schueler". > > -> slapacl -f /etc/ldap/slapd.conf \ > -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ > -b "cn=lehrer,cn=users,ou=s02,dc=as,dc=df" "univentionObjectType/read" > read access to univentionObjectType: ALLOWED > > DC-Verwaltungsnetz:*:5037:dcs01v-01$,masterv$,dcs02v-01$ > DC-Edukativnetz:*:5039:dcs01-01$,dcs02-01$ > > Soweit ich das verstehe, liegt es an dieser ALC, das der Zugriff > erlaubt wird: > # Slave-Controller duerfen Eintraege Ihrer ou lesen und schreiben... > # Lehrer und Memberserver duerfen sie lesen, ou-eigene bekommen Stand... > access to dn.regex="^(.+,)?ou=([^,]+),dc=as,dc=df$$" ... Das ist auch korrekt, dass der Verwaltungs-DC das Containerobjekt selbst auslesen kann. Allerdings kann er die Objekte darunter nicht replizieren: root@singlemaster:/etc/ldap# ldapsearch -x -D cn=dc711v-01,cn=dc,cn=server,cn=computers,ou=711,dc=univention,dc=qa -w univention -b cn=users,ou=711,$ldap_base dn | ldapsearch-wrapper | grep ^dn dn: cn=users,ou=711,dc=univention,dc=qa dn: cn=schueler,cn=users,ou=711,dc=univention,dc=qa dn: cn=lehrer,cn=users,ou=711,dc=univention,dc=qa dn: cn=admins,cn=users,ou=711,dc=univention,dc=qa dn: cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: uid=mitlehrer1,cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: uid=mitarbeiter1,cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: uid=admin1,cn=admins,cn=users,ou=711,dc=univention,dc=qa root@singlemaster:/etc/ldap# ldapsearch -x -D cn=dc711-01,cn=dc,cn=server,cn=computers,ou=711,dc=univention,dc=qa -w QhIyI0cf -b cn=users,ou=711,$ldap_base dn | ldapsearch-wrapper | grep ^dn dn: cn=users,ou=711,dc=univention,dc=qa dn: cn=schueler,cn=users,ou=711,dc=univention,dc=qa dn: cn=lehrer,cn=users,ou=711,dc=univention,dc=qa dn: cn=admins,cn=users,ou=711,dc=univention,dc=qa dn: cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: uid=lehrer1,cn=lehrer,cn=users,ou=711,dc=univention,dc=qa dn: uid=mitlehrer1,cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa dn: uid=schueler1,cn=schueler,cn=users,ou=711,dc=univention,dc=qa dn: uid=admin1,cn=admins,cn=users,ou=711,dc=univention,dc=qa root@singlemaster:/etc/ldap#
(In reply to comment #5) > (In reply to comment #4) > > FAILED - Die Systeme des Verwaltungsnetzes replizieren jetzt den Container > > "mitarbeiter" und "lehrer und mitarbeiter". Die Systeme des Edukativnetzes > > replizieren die Container "lehrer und mitarbeiter", "lehrer" sowie > > "schueler". > > > > -> slapacl -f /etc/ldap/slapd.conf \ > > -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ > > -b "cn=lehrer,cn=users,ou=s02,dc=as,dc=df" "univentionObjectType/read" > > read access to univentionObjectType: ALLOWED > > > > DC-Verwaltungsnetz:*:5037:dcs01v-01$,masterv$,dcs02v-01$ > > DC-Edukativnetz:*:5039:dcs01-01$,dcs02-01$ > > > > Soweit ich das verstehe, liegt es an dieser ALC, das der Zugriff > > erlaubt wird: > > # Slave-Controller duerfen Eintraege Ihrer ou lesen und schreiben... > > # Lehrer und Memberserver duerfen sie lesen, ou-eigene bekommen Stand... > > access to dn.regex="^(.+,)?ou=([^,]+),dc=as,dc=df$$" ... > > Das ist auch korrekt, dass der Verwaltungs-DC das Containerobjekt selbst > auslesen kann. Allerdings kann er die Objekte darunter nicht replizieren: > > root@singlemaster:/etc/ldap# ldapsearch -x -D > cn=dc711v-01,cn=dc,cn=server,cn=computers,ou=711,dc=univention,dc=qa > -w univention -b cn=users,ou=711,$ldap_base dn | ldapsearch-wrapper | grep ^dn > dn: cn=users,ou=711,dc=univention,dc=qa > dn: cn=schueler,cn=users,ou=711,dc=univention,dc=qa > dn: cn=lehrer,cn=users,ou=711,dc=univention,dc=qa > dn: cn=admins,cn=users,ou=711,dc=univention,dc=qa > dn: cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: uid=mitlehrer1,cn=lehrer und > mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: uid=mitarbeiter1,cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: uid=admin1,cn=admins,cn=users,ou=711,dc=univention,dc=qa > > root@singlemaster:/etc/ldap# ldapsearch -x -D > cn=dc711-01,cn=dc,cn=server,cn=computers,ou=711,dc=univention,dc=qa > -w QhIyI0cf -b cn=users,ou=711,$ldap_base dn | ldapsearch-wrapper | grep ^dn > dn: cn=users,ou=711,dc=univention,dc=qa > dn: cn=schueler,cn=users,ou=711,dc=univention,dc=qa > dn: cn=lehrer,cn=users,ou=711,dc=univention,dc=qa > dn: cn=admins,cn=users,ou=711,dc=univention,dc=qa > dn: cn=mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: cn=lehrer und mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: uid=lehrer1,cn=lehrer,cn=users,ou=711,dc=univention,dc=qa > dn: uid=mitlehrer1,cn=lehrer und > mitarbeiter,cn=users,ou=711,dc=univention,dc=qa > dn: uid=schueler1,cn=schueler,cn=users,ou=711,dc=univention,dc=qa > dn: uid=admin1,cn=admins,cn=users,ou=711,dc=univention,dc=qa > root@singlemaster:/etc/ldap# OK Verwaltungsrechner sehen nur die Objekte aus "cn=lehrer und mitarbeiter" und cn=mitarbeiter # dcs02v-01 ist in DC-Verwaltungsnetz -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df -b "uid=t110,cn=lehrer,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: DENIED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=p010,cn=schueler,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: DENIED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=x111,cn=lehrer und mitarbeiter,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: ALLOWED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02v-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=s011,cn=mitarbeiter,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: ALLOWED OK - EdukativRechner sehen nur Objekte in "lehrer und mitarbeiter", "lehrer" sowie "schueler". # dcs02-01 ist in DC-Edukativnetz -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=s011,cn=mitarbeiter,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: DENIED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=p010,cn=schueler,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: ALLOWED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=t110,cn=lehrer,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: ALLOWED -> slapacl -f /etc/ldap/slapd.conf \ -D cn=dcs02-01,cn=dc,cn=server,cn=computers,ou=s02,dc=as,dc=df \ -b "uid=x111,cn=lehrer und mitarbeiter,cn=users,ou=s02,dc=as,dc=df" "uid/read" read access to uid: ALLOWED
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"