Keine Domäne

NatÃ14rlich ist der Betrieb auch ohne eine Domäne denkbar, ähnlich des Modells, welches derzeit im Einsatz ist. Auch in diesem Falle ist eine windowsnative Authentifizierung gegen ein externes Kerberos-System möglich, in dem die oben beschriebenen Anpassungen der Registry des Clientensystems durchgefÃ14hrt werden. Da der Rechner dann allerdings nicht Mitglied einer Domäne ist, mÃ14ssen auf allen Clienten-PCs jeweils alle Nutzereinträge gepflegt werden, zumindest beschränkt auf den Nutzerkreis derer, die sich am entsprechenden Rechner authentifizieren können sollen. Dies bedeutet einen erheblichen Mehraufwand und sicher auch hardwareseitigen Mehrbedarf (Festplattenkapazität fÃ14r jedes Nutzerprofil auf jedem einzelnen Clienten), der in einer Umgebung von mehreren tausend Nutzern inakzeptabel erscheint.
AuÃerdem wird dadurch dem Ziel der Arbeit nicht Rechenschaft getragen, da somit vorerst weiterhin kein Verzeichnisdienst mit den Daten aller Nutzer bereitgestellt wird, wie er durch eine zentrale GroupWare-Lösung und auch andere Anwendungen genutzt werden kann. Noch weniger wird man dem Bedarf mancher Anwendungen nach einem nativen Active Directory gerecht.

Grundsätzlich läÃt sich wohl zusammenfassen, dass viele Aspekte eines Active Directorys durch andere Systeme ersetzbar sind, ein vollständiger Ersatz allerdings nur schwerlich zu erreichen sein wird, um Windows-Clienten in diesem ohne gröÃere Anpassungen nativ betreiben zu können.
Dem Wunsch zur Integration der bereits vorhandenen Insellösungen in das Identity Management des URZs beziehungsweise der Eingliederung in einen Domänenbaum, der eine zentral als Dienst betriebene AD-Domäne als Wurzel hat, wird durch keine der Alternativen ausreichend nachgekommen.