Tags:
create new tag
, view all tags

Trennung von Mailbox und AD-Account

Beteiligte Personen: Mathias Füglistaler, Swen Vermeul

Ausgangslage

Zur Zeit bekommen folgende Personenkategorien automatisch einen AD Account mit Mailbox:
  • Studenten
  • Mitarbeiter
  • Dozenten
  • ETH-Gäste
  • Angehörige ETH-naher Organisationen
  • Hörer

Bei sehr vielen Accounts (z.B. externe Dozenten, Hörer) wird die Mailbox jedoch nie verwendet. Anstatt dessen wird ein Forward auf eine externe E-Mail-Adresse gesetzt. Gleichwohl wird eine Mailbox eingerichtet und welche von Exchange unnötigerweise gepflegt werden muss. Forwards können entweder durch ein Mail-enabled User oder durch einen einfachen contact realisiert werden.

Nachteile der jetzigen Situation

  • unnötiger Verbrauch von Systemressourcen
  • unübersichtliches und überladenes Admin-GUI zur Anpassung der Attribute
  • Mailbox-Service kann nicht entfernt werden, ohne dass AD-Account entfernt wird

geplante Änderungen

Die folgende Tabellle zeigt, welche AD-Objekte bisher im Admin-Tool verwaltet werden:

Objekt-Typ Beschreibung
User, mailbox-enabled nethz-User mit «Mailbox»-Service sind automatisch mailbox-enabled, auch wenn sie gar keine Mailbox auf Exchange benötigen
Group, global, security Mailverteiler, welcher auch für Berechtigungszwecke verwendet werden kann
Contact, mail-enabled Listen-Mitglieder von externen Kontakten, aber auch contacts von ETH-Angehörigen mit OUTBOUND-E-Mail-Adresse

AD und Exchange unterscheiden differenzierter zwischen den verschiedenen Objekt-Typen. Die Neuregelung von Forwards (Erstellung eines altRecipient, welcher auf einen contact zeigt anstelle der bisherigen targetAddress) ist unbefriedigend, vor allem wenn eine E-Mail-Domäne migriert wird. Das Admin-Tool sollte möglichst direkt die Verhältnisse im AD widerspiegeln (was zur Zeit leider nicht der Fall ist). In Zukunft sollten im Admin-Tool folgende AD-Objekte unterschieden werden können:

zukünftige AD-Objekte

Objekt-Typ Beschreibung
User, mailbox-enabled nethz-User, die den Mailbox-Service haben
User, mail-enabled alle nethz-User, die den AD-Service haben. Kann eine targetAddress enthalten, welche auf eine OUTBOUND-Adresse zeigt
Contact, mail-enabled bleibt unverändert. ETH-User mit einer OUTBOUND-Adresse werden aber neu in mail-enabled Userobjekte umgewandelt statt wie bisher mailbox-enabled User mit einem Contact als altRecipient
Group, universal, security für Exchange 2010 zwingend. Allerdings belastet dieser Gruppentyp die Domänencontroller erheblich (es wird kein Kerberos Ticket erzeugt!)
Group, universal, distribution Standard für Massen-Verteilerlisten und manuell generiete Mailverteiler (bereits realisiert)

Use-Cases

User ohne AD-Service wird Mailbox-Service zugewiesen

In der Tabelle SERVICE_DEPENDENCY werden die Service-Abhängigkeiten abgebildet. Für eine Mailbox ist ein AD-Account unabdingbar. Ein automatischer Mechanismus stellt sicher, dass beim Granten eines Mailbox-Services automatisch auch der AD-Service vergeben wird.

User mit Mailbox und AD-Service wird AD-Service gelöscht

Die oben genannte Service-Abhängigkeitstabelle wird beim Löschen des Services geprüft. Im Falle einer manuellen Löschung wird darauf hingewiesen, dass der Mailbox-Service (und eventuell noch andere Services!) auf den AD-Service angewiesen sind. Der AD-Service kann also nicht gelöscht werden, bevor die darauf aufbauenden Services ebenfalls gelöscht worden sind.

Beim automatisierten Abbau eines nethz-Kontos (Austritt aus der ETH) sollte eine rekursive Löschung in Betracht gezogen werden, d.h. eine Löschung des AD-Services hat automatisch eine Löschung des Mailbox-Services zur Folge.

User mit externer E-Mail-Adresse, aber ohne Mailbox

Viele Personen an der ETH benötigen zwar ein AD-Useraccount, aber nicht zwingend eine ETH-Mailbox, z.B. bei Gastdozenten. Anstatt für diese Personen eine Mailbox mit Forward einzurichten ist es sinnvoller, einen normalen AD-Account mir externer Mail-Adresse (Mail-enabled User) einzurichten. Die E-Mail-Adresse darf nicht von Exchange verwaltet werden. Es soll aber möglich sein, auch ETH-interne Adressen als Aliase einzurichten.

Solche mail-enabled User werden von den Exchange -Tools ignoriert. Es besteht somit auch keine Gefahr, dass die sog. targetAddress beim Verschieben mit den Exchange-Tools verloren geht (wie es bei mailbox-enabled Usern leider der Fall ist).

User mit Mailbox und Forward wird Mailbox gelöscht

Die zur Zeit gültigen Forward-Konstrukte bestehen aus 2 AD-Objekten: Einem AD-Userobjekt sowie einem Contact, welcher die externe E-Mail-Adresse enthält. Bei einer Löschung des Mailbox-Services sollte folgendes geschehen:

  • Eintragen aller E-Mail-Adressen des Contacts in das AD-Userobjekt
  • targetAddress (externe E-Mail-Adresse) des Contacts auf das AD-Userobjekt übertragen
  • Listenzugehörigkeiten des Contacts auf das AD-Userobjekt übertragen
  • Löschen des Contacts

User mit externer E-Mail-Adresse wird Mailbox zugewiesen

Im Prinzip soll das Umgekehrte geschehen wie oben: * Contact-Objekt mit der externen E-Mail-Adresse wird eingerichtet * Contact-Objekt wird als altRecipient des Userobjekts eingetragen * Listenzugehörigkeiten bleiben bestehen

Eine Mailbox-Zuweisung ohne Änderung der primären E-Mail-Adresse des Users macht keinen Sinn. Es muss durch einen Mechanismus sichergestellt werden, dass das mailbox-enabled Userobjekt auch tatsächlich eine ETH E-Mail-Adresse bekommt.

technische Todos

  • Auf Seite Active Directory
    • DONE extensionAttribut15 in «nethzTask» umbenennen
    • DONE PowerShell-Skript für die Erstellung von Mailbox-Enabled User erstellen
    • TODO Dokumentation dieses Skriptes
    • TODO In Produktion als scheduled Job einrichten

  • DONE AD-Service einrichten (erzeugt Mail-enabled User)
    • TODO alle ETH-Angehörigen bekommen AD-Service
    • TODO Einträge in Tabelle GRANTED_SERVICE analog zum Mailbox-Service
    • TODO Anpassungen der Tabellen SERVICE_DIRECTIVES und SERVICE_PACKAGE
  • DONE Service-Abhängigkeiten implementieren
    • Mailbox-Service erfordert AD-Service
  • TODO Module neu schreiben
    • Mailbox_SM.pm (Service-Modul)
    • Mailbox.pm (Validation-Modul)
  • TODO AD-GUI
    • Vorname, Nachname, Display-Name
    • Zuweisung Adresse -> Account, sofern mehrere Büroadressen und mehrere Accounts
    • Anzeige im GAL j/n
    • homeDrive, homeDirectory, profilePath
    • description, unixHomeDirectory, loginShell (POSIX-Attribute)
    • Lockout aufheben / lastLogon / badPasswordTime
    • OU-Zugehörigkeit
    • E-Mail-Adresse (OUTBOUND, entspricht der Target-Adresse wie bei einem Contact)
  • TODO Mailbox-GUI (e_post_admin.fastpl) überarbeiten
    • Vorname, Nachname, Display-Name
    • Haupt-E-Mail-Adresse und Aliase
    • Forward
    • Gesperrt / kann keine Mails empfangen
    • Quota
    • IMAP4-Zugriff Attribute
    • «Speichern-und-Weiterleiten» Forward (deliver and redirect)
    • alle AD-spezifischen Attribute nicht anzeigen
  • TODO Mailbox-Service - zu klärende Fragen
    • Passwort ändern entspricht technisch dem Ändern des AD-Passwortes, also kein Passwort ändern mehr möglich für Mailbox?
    • Was soll mit den Mail-Adressen geschehen, wenn Mailbox-Service gelöscht wird?
    • Mail-enabled User vs. Mailbox-enabled User
  • TODO Tests
    • AD-Skript
    • AD::OrganizationalPerson
    • nethz GUI

-- SwenVermeul - 2011-01-25

Topic revision: r10 - 2012-02-01 - 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