Tags:
create new tag
, view all tags

Neuorganisation des Globalen Adressbuches (GAL) in Outlook

Ausgangslage

Das Adressbuch im Outlook Client wird GAL genannt (Global Address List). Genauer handelt es sich nicht um ein einzelnes Adressbuch, sondern um eine Sammlung von mehreren Adressbüchern. Die im zur Zeit im GAL publizierten Adressbücher werden aufgrund von Werten in den Attributen company und department erstellt. Diese Attribute stammen aus der nethz Datenbank. Die Herleitung dieser Werte ist komplex, schwer nachvollziehbar und fehleranfällig (siehe auch CompanyDepartment). Die Probleme sind vielfältig:

  1. Personen mit mehreren Beziehungen zur ETH können nur genau 1x aufgeführt werden
  2. es wird bloss zwischen den Personenkategorien Student und Mitarbeiter unterschieden. Dozenten, ETH-nahe, ETH-Gäste und andere fehlen
  3. Personenkategorie reflektiert nicht die Hauptbeziehung gemäss PDB
  4. die Adressbücher sind sehr unübersichtlich organisiert, unvollständig, teilweise sogar leer
  5. dass die E-Mail-Adresse darüber entscheidet, in welchem Adressbuch eine Person landet, weiss niemand
  6. für die Verwaltung der Adressbücher ist zur Zeit niemand zuständig
  7. über einen Root Task im Admin-Tool können solche Adressbücher zwar manuell erstellt und verwaltet werden, diese Funktion ist aber fast niemandem bekannt
  8. Leute vom ETH-Rat gelangen über einen gänzlich anderen Mechanismus ins Adressbuch (Mitgliedschaft der nethz-Usergruppe 00001 ETH-Rat, welche manuell gepflegt wird!)

Grundlagen: wie GAL-Adressbücher funktionieren

Im Active Directory (AD) sind Adressbücher in der Form von sog. AddressBookContainer gespeichert. Die Mitglieder eines Adressbuches werden aufgrund eines LDAP-Suchfilters generiert. Das Attribut purportedSearch enthält diesen LDAP-Suchfilterstring. Datenbanktechnisch könnte man solche AddressBookContainer auch als Views bezeichnen, als eingeschränkte Sicht auf die gewünschten Datensätze.

Der Filter ist in den folgenden Attributen gespeichert:

  • purportedSearch enthält einen LDAP-Filter
  • msExchPurportetSearchUI ist multivalue (d.h. kann mehrere Werte enthalten), enthält den Wert des Attributs purportedSearch sowie einige andere Parameter für das Windows GUI
  • msExchQueryFilter enthält den Filter von purportetSearch in der sog. OPATH-Schreibweise
Bei der Anzeige wird jedoch nicht einfach der LDAP-Filter ausgeführt. Wenn nämlich dieser nicht optimal definiert (z.B. Platzhalter * vor dem Suchbegriff) wird oder nicht indizierte Attribute beinhaltet, kommt das AD mächtig ins Schwitzen. Deshalb werden in den Objekten selbst Verweise auf die Adressbücher gespeichert:
  • showInAddressBook multivalue, enthält den distinguishedName der Adressbücher, in welchen dieses Objekt angezeigt wird
  • msExchHideFromAddressList wenn auf TRUE gesetzt, sollte das Objekt nicht angezeigt werden.

Damit die Adressbücher nachgeführt werden, reicht es nicht, bloss die Attribute in den Objekten (aufgrund deren Werte die Adressbücher basieren) zu ändern. Bei einer Änderung muss das Objekt mit einem Update-recipient Befehl aktualisiert werden. Dabei wird aktiv geprüft, bei welchen Adressbüchern der jeweilige purportedSearch Filter für das gegebene Objekt zutrifft. Die distinguishedName werden anschliessend in das Attribut showInAddressBook des Objekts eingetragen.

Bei der (nicht gecachten) Anzeige in Outlook wird immer folgende Suche ausgeführt: showInAddressBook=«DN des Adressbuches»

Lösungsansatz Multivalue-Attribut OU

Wie bereits ausgeführt reichen die bisherigen Filter nicht, um die verschiedensten Mehrfachbeziehungen der ETH-Angehörigen befriedigend abzubilden. Glücklicherweise existiert jedoch im AD bereits ein indiziertes Multivalue-Attribut, welches wir für unsere Zwecke verwenden können: ou (Organizational Unit). Damit können nicht nur Adressbücher viel flexibler aufgebaut werden. Auch sog. dynamische E-Mail-Verteiler (welche heute noch selten in Gebrauch sind) werden so zum Kinderspiel. Nun, da wir ein Attribut haben, welches wir mit allen erdenklichen Zuordnungen füllen können, stellt sich die Frage, was genau wir denn hineinschreiben wollen.

Die Einträge sollten in etwa dem company-Eintrag entsprechen, allerdings sollten alle Personenkategorien, Anstellungen und Einschreibungen vorkommen. Die Details können weggelassen werden, sofern sie nicht für die Generierung der Adressbücher verwendet werden.

  • Mitarbeiter, ETH-nahe und ETH-Gäste: Personenkategorie DEPTKZ, Institut (Leitzahl)
  • Mitarbeiter (falls keinem Departement zugeordnet): Personenkategorie «übergeordnete OE der Karten-LZ», OE (Leitzahl)
  • Dozenten: Personenkategorie DEPTKZ, Dozentenrang (Leitzahl)
  • Studenten: Personenkategorie DEPTKZ, Studiengang Studiengantyp
  • Beispiele:
    • Dozent D-GESS, Ordentliche/r Professor/in (03783)
    • Dozent D-GESS, Emeritierte/r Professor/in (03140)
    • Mitarbeiter D-GESS, Archiv f. Zeitgesch. (02872)
    • Mitarbeiter Informatikdienste, ID IAM & eServices (06065)
    • Mitarbeiter Informatikdienste, ID D-GESS (06035)
    • Student D-ARCH, Architektur BSc
    • ETH-nahe ASVZ (04838)
    • ETH-Gast ID Basisdienste (00077)

Dies ergibt für die Generierung von Adressbüchern viele Möglichkeiten:

Suchstring Ergebnis
ou=Mitarbeiter D-GESS* Alle Mitarbeiter des D-GESS
ou=Dozent D-GESS* Alle Dozierenden des D-GESS
(|(ou=Mitarbeiter D-GESS*)(ou=Dozent D-GESS*)) Alle Mitarbeiter und Dozenten des D-GESS
ou=Student D-GESS* Alle Studierenden des D-GESS 
ou=Student D-GESS, Doktorat* Alle Doktoranden des D-GESS
ou=ETH-Gast* Alle ETH-Gäste

Neue Organisation der Adressbücher

Die Anzahl der Adressbücher wird reduziert, die Drop-Down-Liste soll bloss noch folgende Einträge haben:

  • Departemente (enthalten jeweils alle Mitarbeiter und Dozenten)
  • Studenten MOVED TO... entfällt
  • ETH-Gäste
  • ETH-nahe Organisationen
    • ETH-Rat
    • ASVZ
    • einige andere wichtige ETH-nahe Organisationen

Studenten werden besser über ad-hoc generierte Verteiler im Admin-Tool generiert.

Abgrenzung zum OU Attribut im LDAPS (AAI)

Die Kontos im LDAPS-Server kennen ebenfalls ein Attribut namens ou, welches zur Zeit vor allem für Authorisierungszwecke im WCMS genutzt wird. Neben den «direkten» Leitzahlen werden auch alle übergeordneten Leitzahlen eines Mitarbeiters aufgeführt (Die Erklärungen in Klammern werden im LDAPS nicht aufgeführt):

  • 06065 (ID-Identity Management und Web-Applik.)
  • T0077 (Total Basisdienste)
  • T0070 (Total Informatikdienste)
  • T0025 (Total Bereich VPPR)
  • T0003 (Total Schulleitung und Dienste)
  • T0002 (Total ETH Zürich)
  • T0000 (Total Gesamthierarchie)

Das Attribut enthält neben den Leitzahlen auch die Namen aller Gruppen (und übergeordneten Gruppen), bei welchen dieser User Mitglied ist.

Die Attribute company und department

Wenn die Adressbücher nicht mehr durch die Attribute company und department generiert werden, kann man sie mit aussagekräftigeren Werten füllen. Zur Zeit enthalten sie beispielsweise folgendes:

company department
ETH Zentrale Organe Zentrale Organe
ETH D-ARCH D-ARCH
ETH Studierende Stud. D-ITET

Zusammengefasst ergeben sich folgende Schwachpunkte:

  • die Werte der Attribute company und department sind beinahe redundant
  • die Zentralen Organe (ZO) tauchen in keiner offiziellen Organisationsstruktur auf
  • welche Leitzahlen zur ZO dazugehören muss manuell gepflegt werden

neue Werte für company und department

Das Active Directory und die Clients geben die Rahmenbedingungen vor. Die Attribute company und department stehen zur Verfügung und werden in Outlook dargestellt, sie können aber nur einen Wert enthalten (sog. single valued) und dieser Wert darf nicht länger als 64 Zeichen sein.

Das Adressbuch von Apple zeigt leider nur, was in company steht. Es gibt zwar die Möglichkeit, die Abteilung anzuzeigen, aber leider wird dann fälschlicherweise die Anrede angezeigt, das Mapping lässt sich nicht korrigieren. Wie andere Clients das AD auslesen weiss ich nicht, aber ich befürchte, dass dort die Situation nicht besser ist. Die Folgerung daraus lautet, dass nur das Attribut company automatisch mit vernünftigen Werten gefüllt werden soll. Das Attribut department wird dadurch frei und kann von den Administratoren bei Bedarf selber gesetzt werden (z.B. für die Arbeitsgruppe).

Im company-Feld sollte eine Information stehen, welche die Person möglichst gut charakterisiert. Folgendes Schema wird generell vorgeschlagen:

Bereich Personenkategorie Organisatorische Zuordnung, Details

Für jeden ETH-Angehörigen gibt es eine primäre Personenkategorie, die auch für die Art der ETH-Karte entscheidend ist. Im Folgenden Abschnitt werden diese Personenkategorien erläutert und gezeigt, wie jeweils das Company-Feld generiert wird.

Mitarbeiter und ETH-nahe

BEREICH PERSKAT OE_NAME_KURZ(KARTEN_LZ), OE_NAME_KURZ(LZ)

Die Werte für BEREICH und KARTEN_LZ kommen direkt aus der PDB. BEREICH kann zur Zeit die Werte «ETH» und «ETH-nahe» haben.

KARTEN_LZ ist die übergeordnete Leitzahl der Abteilung, die auch auf der ETH-Karte aufgedruckt ist. Die Werte für KARTEN_LZ werden in der PDB durch die Funktion F_KARTEN_LEITZAHL generiert. Die nethz-DB übernimmt diese Werte direkt in der View DLDB_ORGEINHEIT. Die Logik in dieser Funktion wird bereits an mehreren Orten verwendet, u.a. in der Personensuche.

Falls KARTEN_LZ mit der LZ identisch ist oder es zuwenig Platz hat, wird OE_NAME_KURZ(LZ) weggelassen.

Beispiele:

ETH Mitarbeiter Informatikdienste, ID IAM & eServices (06065)
ETH Mitarbeiter Informatikdienste (00070)
ETH-nahe ETH-Rat (00001)
ETH Mitarbeiter Bereich VPPR (00025)

Dozenten, Akademische Gäste und Emeriti

Für diese Personenkategorien gibt es in der Tabelle DOZ_PERIODE folgende interessante Werte:

  • Departements-Kürzel
  • Dozrang-Text
  • Professoren-Leitzahl

Der Dozentenrang-Text kann 10 verschiedene Werte haben, er erscheint hinter dem Departements-Kürzel. Eine allfällig vorhandene Professoren-Leitzahl wird in Klammern angegeben.

Beispiele:

ETH Dozent DEPTKZ, DOZRANG_TEXT
ETH Dozent D-MATH, Dozent/in (08813)
ETH Dozent D-MAVT, Ordentliche/r Professor/in (03737)
ETH Dozent D-ARCH, Ausserordentliche/r Professor/in (03715)
ETH Dozent D-ARCH, Emeritierte/r Professor/in (03423)
ETH Dozent D-USYS, Titularprofessor/in im Ruhestand (08744)
ETH Dozent D-ARCH, Gastprofessor/in

Somit werden also alle Personen der Personenkategorien Dozent, Emeritus und Gast zunächst gleichwertig als Dozenten bezeichnet und die genauere Differenzierung hintenangestellt. Der Grund für dieses Vorgehen ist der, weil die Personenkategorien Emeritus und Gast nur wenige Hundert Personen umfassen, letztere aber dennoch immer wieder für Verwirrung sorgt (vgl. nethz-Gast, ETH-Gast).

Studierende

Studierende haben - im Gegensatz zu allen übrigen ETH-Angehörigen keine Leitzahl. Folgende Angaben in der Tabelle EINSCHREIBUNG können aber für die Generierung des company-Feldes verwendet werden:

  • Departements-Kürzel
  • Studiengang
  • Studiengang-Typ

Das ergibt:

ETH PERSKAT DEPTKZ STUDIENGANTYP STUDIENGANGNAME

Beispiele:

ETH Student D-MATH GS Mathematik (Mobilität)
ETH Student D-ARCH MSC Architektur MSc

Die Schwierigkeit besteht darin, die aktuell gültige Einschreibung zu finden, da man in einem einzigen Semester mehrfach eingeschrieben sein kann. Zu diesem Zweck muss zunächst eine Art Rangliste der Studiengang-Typen erstellt werden:

  1. DR (Doktorat)
  2. MSC (Master)
  3. BSC (Bachelor)
  4. NDS (Nachdiplomstudium, MAS)
  5. WBZ (Weiterbildungs-Zertifikat, DAS)
  6. GS (Gaststudium)
  7. SHE (Lehrdiplom für Maturitätsschulen)
  8. DZ (Didaktik-Zertifikat)
  9. DID (Didaktischer Ausweis)

Bei mehrfachen Einschreibungen wird nun einfach die «höchstwertige» Einschreibung genommen.

Hörer

Für Hörer gibt es weder eine Leitzahl noch eine Zuteilung zu einem Departement. Für alle Hörer sollte folgender Eintrag gelten:

ETH Hörer

ETH-Gäste

Offizielle ETH-Gäste stammen aus der Tabelle DLDB_GASTPERIODE und sind stets einer Leitzahl zugeordnet. Somit kann dasselbe Schema wie bei den Mitarbeitern angewandt werden:

BEREICH PERSKAT OE_NAME_KURZ(KARTEN_LZ), OE_NAME_KURZ(LZ)
ETH-Gast Informatikdienste, ID Service Delivery (00074)
ETH-nahe Gast vdf Hochschulverlag (04829)

Fazit für company und department Attribute

  • es soll nur noch das company Attribut automatisch gefüllt werden
  • dieses dafür mit sinnvolleren Werten als bisher, mit Angaben über den Bereich, die Personenkategorie und die organisatorische Zuordnung
  • das Attribut department kann frei verwendet werden
  • für die Werte von company werden die Felder BEREICH und KARTEN_LZ aus der PDB verwendet

Deutsch oder Englisch?

Für viele (wenn nicht alle) Organisationseinheiten existieren neben 3 verschiedenen deutschen Namensvarianten (Kurz, Mittel, Lang) auch 3 verschiedene englische Übersetzungen. Ob die englische oder deutsche Bezeichnung übernommen wird, muss entschieden werden. Die nethz-DB übernimmt zur Zeit nur jeweils die deutsche Schreibweise.

Aufwandschätzung

company-Attribut anpassen

Aufgabe Aufwand (in Tagen)
Übernahme und Synchronisation der neuen Daten für DLDB_ORGEINHEIT 1
Abschalten des bisherigen Algorithmus zur Generierung von COMPANY und DEPARTMENT 2
Änderungen an DOZRANG_TEXT registrieren  
Änderungen an PERSKAT synchronisieren und registrieren  
Änderungen an EINSCHREIBUNG, ETH_NAHE und GAST_PERIODE ebenso  
schreiben des OU-Attributes ins AD  
Adressbücher neu generieren und testen  
AD::AddressBook.pm überarbeiten  
Änderung der bestehenden AD-Konten 1
schreiben des neuen company-Attributes ins AD  
Änderung des GUI (Freigabe des department-Attributes) 1

bestehende Unklarheiten

  • ist das neue Attribut msExchQueryFilter mit der OPATH-Abfragemuster notwendig?
  • Konvertieren von ldap-Queries in OPATH-Queries (und umgekehrt) möglich?
  • Performance-Tests

-- SwenVermeul - 2013-01-07

Topic revision: r24 - 2014-07-11 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback