UMC Passwörter (Schüler)/Passwörter(Lehrer) zurücksetzen

UCS@school
#1

Hallo zusammen,

Wir haben einen UCS-Master 4.1-4 (Multi-Server-Umgebung) errata353 mit UCS@School 4.1 R2 v8 und Samba4 und dazugehörig mehrere DC-Slaves’s in ihren OU’s.

Ich möchte als angemeldeter normaler Lehrer an der UMC des DC-Slave das Passwort eines Schülers zurücksetzen. Dazu wähle ich in der UMC -> Schul-Administration -> Passwörter(Schüler).
Da die ‘automatische Suche’ aktiviert und ‘Alle Klassen und Arbeitsgruppen’ und standardmäßig ausgewählt ist, werden alle Schüler der Schule/OU angezeigt. Nach Auswahl des Schülers ist der Button ‘Passwort zurücksetzen’ aktiv.

Jetzt das Problem:
Wähle ich eine Klasse oder Arbeitsgruppe aus und klicke auf Suche (auch mit einem bekannten Schüler bei Name eingetragen), wird nichts gefunden. Die Liste bleibt leer und als Zusatz wird unten ‘Es konnten keine Einträge gefunden werden’ angezeigt.

Bin ich Lehrer und admin- habe ich bei Passwörter(Lehrer) ebenfalls das Problem.

Diese Funktionen werden von unseren Lehrern in unserem noch bestehenden UCS4.0.4-System sehr oft benutzt und sollten im neuen System auch funktionieren.

Wo liegt der Fehler?
Vielen Dank

Gruss
Detlef Stang

#2

Hallo,

dank unserer Testumgebung (hier gab es dieses Problem nicht) konnte ich den Fehler nachvollziehen.:

Für den Import der Lehrer/Schüler benutzen wir immer noch das Standard-CSV-Format lt. docs.software-univention.de/ucss … mportusers.

In unserer Testumgebung habe ich die Lehrer/Schüler über das Script /usr/share/ucs-school-import/scripts/import_user eingefügt.
Dabei wurden jede Menge Informationen angezeigt, obwohl der Debug-Level nicht verändert wurde. Daraufhin benutzten wir das Script /usr/share/ucs-school-import/scripts/ucs-school-import für den Import - funktionierte ohne sonstige Meldungen.

In unserem neu aufgesetzten Lifesystem wurden die Lehrer/Schüler über das Script /usr/share/ucs-school-import/scripts/ucs-school-import eingefügt.

Den Unterschied zwischen beiden Scripten sieht man in den Benutzerdetails in der UMC-DC Master.

Variante import_user:

  • unter Optionen wird entsprechend der Rolle/Gruppe (Schüler,Lehrer usw.) der Punkt UCS@school-xxxxxx markiert und unter UCS@school die Schule eingetragen.
    !!! genanntes Problem ist nicht vorhanden !!!

Variante ucs-school-import:

  • es wird keine Option UCS@school-xxxxxx gesetzt und damit ist auch keine Option UCS@school vorhanden
    !!! genanntes Problem besteht !!!

Muss ich für das ImportScript ucs-school-import weitere Optionen benutzen?

Weiterhin fiel mir Folgendes auf:
Wähle ich einen ‘Lehrer und Mitarbeiter’, dann in den Benutzerdetails -> Optionen -> UCS@school-Schüler aus -> Speichern -> keine Fehlermeldung. Umgekehrt, bei einem Schüler kann ich unter Optionen UCS@school-Lehrer auswählen -> Speichern -> keine Fehler.
Bei Kombination UCS@school-Schüler mit UCS@school-Lehrer kommt eine Fehlermeldung.

Welche Auswirkungen hat dies auf das Sytem/Rechte usw. ?

Gruss
Detlef Stang

#3

[quote]Weiterhin fiel mir Folgendes auf:
Wähle ich einen ‘Lehrer und Mitarbeiter’, dann in den Benutzerdetails -> Optionen -> UCS@school-Schüler aus -> Speichern -> keine Fehlermeldung. Umgekehrt, bei einem Schüler kann ich unter Optionen UCS@school-Lehrer auswählen -> Speichern -> keine Fehler.
Bei Kombination UCS@school-Schüler mit UCS@school-Lehrer kommt eine Fehlermeldung.[/quote]

Schüler dürfen nicht gleich Lehrer sein, das ist eine Einschränkung in @School. Hat das bei Ihnen schon einmal funktioniert? Können Sie mir schildern, warum Sie Schüler-Lehrer benötigen (ggf. kann das anders durch Bordmittel gelöst werden)? Die LDAP Berechtigungen stellen sich folgendermaßen dar (das ist nur eine Auswahl der relevantesten Rechte):

Freigaben anlegen - (Lehrer ja, Mitarbeiter ja, Schüler nein)
Arbeitsgruppen anlegen - (Lehrer ja, Mitarbeiter ja, Schüler nein)
Raum-Gruppen anlegen - (Lehrer ja, Mitarbeiter ja, Schüler nein)
Lehrer-/Mitarbeiter-Passwörter setzen - (Lehrer nein, Mitarbeiter nein, Schüler nein) --> Nur “Schuladmin”
Schüler-Passwörter setzen - (Lehrer ja, Mitarbeiter ja, Schüler nein)
Eigenes Passwort setzen - (Lehrer ja, Mitarbeiter ja, Schüler ja)

Nun zu dem Import Script:

Edit für Klarheit:
Bis Version @School Version 4.1 R2 gab es nur ein Importscript “ucs-school-import” und einen Symlink auf dieses Script namens: “import_user”. Der Symlink, von dem es mehrere gab, hat bestimmte Teile des “großen” Scripts ausgeführt. Wenn das “ucs-school-import” an sich ausgeführt wird, kann das zu dem Verhalten führen, wie Sie beobachten. Die direkte Verwendung von “ucs-school-import” ist nicht dokumentiert und auch nicht empfohlen. Das Skript sollte weder in der Vergangenheit noch in Zukunft direkt genutzt werden. Die Dokumentation: docs.software-univention.de/ucss … 4.1R2.html ist ausschliesslich für den “ucs-school-user-import” gedacht.

Der Code von “import_user” hat sich zu 4.1R2 wenig geändert. D.h. die Doku (docs.software-univention.de/ucss … mportusers) gilt weiterhin für “import_user”.

Hat das soweit Ihre Fragen beantwortet?

#4

Guten Morgen Herr Thorp-Hansen,

ich teile meine Antwort:
Das mit den Rechten ist mir schon klar, dafür arbeiten wir schon seit 2010 (UCS2.3) mit diesem System.

Wir wollen kein Schüler zum Lehrer machen. Es geht darum, das es funktioniert, jedenfalls auf der UMC-Seite.

Ich kann in der UMC einen Schüler auswählen - unter Optionen UCS@school-Administrator und UCS@school-Lehrer oder UCS@school-Lehrer auswählen und speichern.


Es kommt keine Fehlermeldung, die Einstellungen werden übernommen!

Dies funktioniert auch mit einem Lehrer, dem ich die Option UCS@school-Schüler zuweise.
Welche Auswirkung hat dies auf das System? Welche Rechte hat jetzt der Schüler oder der Lehrer???

Ich wollte Sie nur auf einen eventuellen Fehler hinweisen.

Nebenbei habe ich den Sinn diese Optionen anzuzeigen noch nicht verstanden, die ja eigentlich nach einem Import mit import_user gesetzt sein sollten und Standard sind. Ich habe dazu auch noch keine Dokumentation gefunden.

Gruss
Detlef Stang

#5

Sie können Benutzerkonten überprüfen indem Sie auf Konsolenebene sich das Benutzerobjekt selbst anschauen (ich hänge ein Beispiel aus meiner Testumgebung an für einen Benutzer der korekt über die Schuladministration gepflegt wurde). Wichtig sind die objectClasses - daran können Sie auch festmachen, welche Rechte das Objekt hat (ucsschoolStudent oder ucsschoolTeacher/ucsschoolStaff) - in Ihrem Fall ersetzen Sie das “paulp” durch einen Benutzernamen in Ihrer Umgebung:

root@master:~# univention-ldapsearch uid=paulp objectClass
[...]
# paulp, schueler, users, weihnachtsmann, ucsschool.demo
dn: uid=paulp,cn=schueler,cn=users,ou=weihnachtsmann,dc=ucsschool,dc=demo
objectClass: krb5KDCEntry
objectClass: ucsschoolStudent
objectClass: person
objectClass: automount
objectClass: top
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: univentionPWHistory
objectClass: univentionMail
objectClass: univentionSAMLEnabled
objectClass: ucsschoolType
objectClass: shadowAccount
objectClass: krb5Principal
objectClass: posixAccount
objectClass: univentionObject
[...]

Ich habe nun mit diesem Benutzer in UCS 4.1-3 versucht manuell in dem Benutzerobjekt den Lehrer-Haken zu setzen - das wurde mit einer Fehlermeldung abgebrochen. Daher habe ich ein Update auf 4.1-4 und der neusten @School Version durchgeführt um das Verhalten ggf. nachzustellen. Das ist mir nicht gelungen. Auch nach dem Update konnte das Objekt nicht als Schüler und Lehrer gleichzeitig gespeichert werden.

Die Administration von @School soll normalerweise vollständig in der @School Oberfläche passieren, da @School selbst im Hintergrund sehr viel an den Benutzerobjekten anpasst und verändert, das man zwar theoretisch manuell durchführen könnte, dann aber sehr fehleranfällig wäre. Ein korrektes @School Benutzerobjekt zum Beispiel bekommt man sicher über die @School Oberfläche oder einen @School Import. Trotzdem ist die Ebene “UMC - UCS” noch vorhanden und nicht standardgemäß deaktiviert, daher kann unter Umständen ein Objekt auch über die Benutzersteuerung der UMC bearbeitet werden. Wir wollen diese Möglichkeiten nicht verbieten und setzen dann eher auf Empfehlungen oder wie in diesem Fall auf präventive Maßnahmen um Fehlbedienung zu vermeiden.

#6

Hallo,

mich wundert, dass es bei Ihnen mit einer Fehlermeldung abbricht.
Ich habe im Live-System und in der Testumgebung eben einen neuen ‘Lehrer und Mitarbeiter’ über /usr/…/import_user <xxx.csv> erstellt.
Hier das Benutzerkonto vorher:

# extended LDIF
#
# LDAPv3
# base <dc=ssvaffo,dc=local> (default) with scope subtree
# filter: uid=ei-lehrermit01
# requesting: objectClass 
#

# ei-lehrermit01, lehrer und mitarbeiter, users, EINST, ssvaffo.local
dn: uid=ei-lehrermit01,cn=lehrer und mitarbeiter,cn=users,ou=EINST,dc=ssvaffo,
 dc=local
objectClass: krb5KDCEntry
objectClass: organizationalPerson
objectClass: automount
objectClass: top
objectClass: univentionObject
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: person
objectClass: ucsschoolTeacher
objectClass: univentionMail
objectClass: univentionSAMLEnabled
objectClass: ucsschoolType
objectClass: univentionPWHistory
objectClass: ucsschoolStaff
objectClass: univentionFreeAttributes
objectClass: krb5Principal
objectClass: posixAccount
objectClass: shadowAccount

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Dann habe ich diesen Benutzer in der UMC -> Optionen -> beabeitet:
Haken raus bei UCS@school-Lehrer und UCS@school-Mitarbeiter
Haken setzen bei UCS@school-Schüler

Benutzerkonto danach:

# extended LDIF
#
# LDAPv3
# base <dc=ssvaffo,dc=local> (default) with scope subtree
# filter: uid=ei-lehrermit01
# requesting: objectClass 
#

# ei-lehrermit01, lehrer und mitarbeiter, users, EINST, ssvaffo.local
dn: uid=ei-lehrermit01,cn=lehrer und mitarbeiter,cn=users,ou=EINST,dc=ssvaffo,
 dc=local
objectClass: krb5KDCEntry
objectClass: ucsschoolStudent
objectClass: person
objectClass: automount
objectClass: top
objectClass: univentionSAMLEnabled
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: univentionPWHistory
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: ucsschoolType
objectClass: univentionMail
objectClass: univentionFreeAttributes
objectClass: krb5Principal
objectClass: posixAccount
objectClass: univentionObject

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Wir haben die aktuelleste Version:

appcenter/apps/nagios/version: 3.4
appcenter/apps/samba4/version: 4.5
appcenter/apps/ucsschool/version: 4.1 R2 v8
repository/online/component/4.1-3-errata/version: 4.1
repository/online/component/4.1-4-errata/version: 4.1
repository/online/component/ucsschool_20161111162209/version: current
update/umc/nextversion: true
version/erratalevel: 353
version/patchlevel: 4
version/releasename: Vahr
version/version: 4.1

Beide Ausgaben sind im Live-System und in der Testumgebung gleich.
Dann ist in unseren beiden Systemen grundsätzlich etwas falsch.

Gruss
Detlef Stang

#7

Die Änderung am Benutzerobjekt erfolgt erst beim “Speichern”, das heißt Sie würden die Fehlermeldung nur bekommen, wenn Sie zum Zeitpunkt des Speicherns die Haken “Lehrer” und “Schüler” gleichzeitig aktiv hätten.
Die Benutzerobjekte mit univention-ldapsearch betrachtet sehen korrekt aus.

#8

Hallo,
wann die Fehlermeldung kommt, hatte ich ja schon erwähnt.

Ich verstehe den Sinn folgender Kombination nicht:

  • Benutzer ist uid=ei-lehrermit01,cn=lehrer und mitarbeiter,cn=users,ou=EINST,dc=ssvaffo,dc=local kann aber auch die objectClass: ucsschoolStudent besitzen
    oder
  • Benutzer ist uid=ei-schueler,cn=schueler,cn=users,ou=EINST,dc=ssvaffo,dc=local kann aber auch die objectClass: ucsschoolStaff/ucsschoolTeacher/ucsschoolAdministrator besitzen

Gibt es dafür eine erklärende Dokumentation?

Gruss
Detlef Stang

#9

Ich denke Sie haben die Position hier mit der Objektklasse vermischt. Es ist nicht möglich die Objektklassen Lehrer und Schüler zu vermischen. Es ist theoretisch im Moment noch möglich einem Benutzer an der Position “Schüler” die Objektklasse Lehrer zu geben. Das macht jedoch keinen Sinn und ist in keiner Form empfohlen: Wie ich bereits gesagt habe, sollte die Benutzersteuerung in @School komplett in den @School Modulen erfolgen - das setzen der Haken im UMC Benutzermodul geht komplett an @School vorbei und setzt quasi manuell Objektklassen.

Wir arbeiten im Moment daran in zukünftigen Versionen die alleinige Abhängigkeit von Funktionen an Objektklassen zu hängen. Im Moment ist es noch theoretisch möglich, aber nicht empfohlen, eine wie von Ihnen geschilderte Kombination manuell zu erstellen. Im Moment sollten Sie darauf achten, dass Objektklassen und Orte synchron bleiben.

Mit freundlichem Gruß,
Jens Thorp-Hansen

#10

Hallo Herr Thorp-Hansen,

ok, dann wäre mein Vorschlag, diese Optionen nicht anzuzeigen.

Für den Teil Scripte habe ich Ihnen eine Mail über das Kontaktformular zukommen lassen.

Mit freundlichen Gruessen
Detlef Stang

#11

Noch ein Hinweis zu Ihrer letzten Frage:
Die Umstellung zu UCS@school 4.1 R2 war sehr umfangreich und komplex. Trotz sehr umfangreicher Tests wir nicht 100%ig ausschließen, dass ein Sonderfall, der in einer Kundenumgebung im Einsatz ist, nicht von uns
getestet wurde. Da der automatische Import für die meisten Kunden sehr kritisch ist, haben wir uns dazu entschlossen, die Funktion create_user(), die in ucs-school-import enthalten ist, zum 4.1R2-Release explizit nicht zu entfernen. Wir hatten damit die Möglichkeit, im Falle eines Fehlverhalten schnell wieder auf das alte Skript/Verhalten zurückzuschalten.

Wir werden die create_user()-Funktion in ucs-school-import sowie weitere Kompatibilitätsfunktionen in UCS@school in einem der nächsten Releases entfernen.

Mastodon