Soweit aus den Ausführungen der Produktwebseite unter [XAD05]
ersichtlich, arbeitet XAD mit einem dynamischen DNS-System aber auch
einem gepatchten NTP-Server, der signierte Antworten erzeugt, wie sie
von Windows-Clienten erwartet werden. Weiterhin ist das
Heimdal-Kerberos entsprechenden Anforderungen hinsichtlich gepatcht,
so dass ein Ersatz des produkteigenen durch einen bestehenden
ausgeschlossen wird.
Eine Frage, deren Antwort allerdings allein aus dem Studium der
Produktinformationen nicht hervorgeht, bleibt sowohl hier als auch bei
einer möglichen Konstruktion auf eigenen Diensten offen. Wie findet
das ziemlich komplexe und umfangreiche Schema eines ADs Einzug in die
LDAP-Umgebung einer externen Konstruktion und wie kann der steten
Erweiterung durch Microsoft oder externen Produkten Rechenschaft
getragen werden? Vermutlich wird eine entsprechende Konfiguration in
den RPMs der Produktdistribution mitgeliefert, allerdings bleibt
offen, wie umfangreich diese ist, welche Windows-Server-Version dafür
Pate stand und ob eine dynamische Erweiterung durch
Produktinstallationen möglich ist. Auch werden Einschränkungen
bezüglich der Interoperabilität mit "`echten"' Active Directory
Domänen eingeräumt - etwa kann eine XAD-Domäne nicht Mitglied eines
AD-Baumes werden und eine Childbeziehung zu einer solchen kann
ebenfalls nicht aufgebaut werden, nur Cross-Realm-Trusts zu solchen
sind möglich. Datei- und Druckserverdienste werden trotz der
Integration von Samba nicht angeboten, da von Samba nur die
CIFS-Komponenten integriert wurden, um den RPC-Dienst anzubieten. Es
wird aber darauf hingewiesen, dass Samba an XAD gebunden werden kann,
um dessen Dienste zu nutzen. Ebenso ist eine Anbindung eines
OpenAFS-Dienstes an XAD vorgesehen und realisierbar.
Teile der Anpassungen, die PADL an den genutzten Produkten vorgenommen
hat, werden auf der Produktwebseite als kostenloser Download
bereitgestellt.
Trotz allem bleibt es also zu bezweifeln, dass trotz der komplexen
Struktur des Systems und der grundlegenden Bereitstellung aller
notwendigen Komponenten ein vollständiger nativer Windows-AD-Ersatz
durch XAD zu erreichen ist. Spätestens bei der Planung des Einsatzes
von Applikationen, die etwa auf die MAPI-Schnittstelle zurückgreifen,
sind die Grenzen des Verfahrens erreicht.