eTrust Directory jest w dużej mierze zarządzany za pośrednictwem interfejsu linii poleceń. Połączenie Telnet z lokalną konsolą byłoby może całkiem dobre, gdyby nie duża liczba codziennych modyfikacji.

Zarządzanie Global Directory Server jest przejrzyste po stronie X.500, ale integracja serwera LDAP z serwerem X.500 okazała się bardzo przeciętna. W schemacie LDAP zdarzały się błędy typograficzne. Zespół testujący nie był zresztą w stanie wyłapać wszystkich usterek. Zarejestrowanie większości szczegółów dotyczących "spoiwa" LDAP z X.500 było dosyć trudnym zadaniem.

W NDS eDirectory Novella napotkano na nieco inne problemy. Do zmian schematu używa się w NDS eDirectory standardowego GUI, który uaktywnia swój edytor schematów. Z kolei edytor nie jest przystosowany do zmian schematu LDAP. Ten ostatni musi więc być odwzorowywany ręcznie - atrybut po atrybucie - z NDS do LDAP. Ponieważ typy pól w NDS różnią się od typów w LDAP, kompatybilność każdego typu pól trzeba sprawdzić ręcznie, krok po kroku.

Różnorodność interfejsów zarządzających w NDS eDirectory utrudnia pracę. Do konfigurowania i zarządzania serwerem LDAP trzeba ich używać co najmniej czterech. NDS eDirectory jest mocno związany z koncepcją systemu operacyjnego i zarządzania zasobami przedsiębiorstwa. I tak każdy obiekt w NDS eDirectory uczestniczy w modelu bezpieczeństwa praw dostępu systemu operacyjnego, pytając: kto i co może zrobić. Administratorzy odpowiedzialni za ustawianie katalogów sieciowych powitają zapewne z zadowoleniem taki obszerny model, ale kiedy stosuje się NDS eDirectory w środowisku LDAP, wtedy trzeba liczyć się z komplikacjami.

Dalej, opierający się na Javie interfejs Console One nie może być uznany za jedyny interfejs zarządzający. Użytkownik otrzymuje w rzeczywistości wiele interfejsów, a wszystkie działają w różny sposób i prezentują niezbyt wygodną metodę wizualizacji i modyfikacji informacji. Zespół testujący był także rozczarowany tym, że niektóre podstawowe narzędzia zawarte w NDS eDirectory zostały pominięte w wersji dla Windows NT. Dotyczy to głównie zdolności kontrolowania, które z atrybutów katalogu są indeksowane. Novell zapewnia, że własności te zostaną dołączone do kolejnej wersji produktu, zapowiedzianej na koniec roku.

Bardziej praktyczny w zarządzaniu był OID (Oracle Internet Directory) Oracle. Ale żeby pracować z OID, trzeba zdobyć tytuł Oracle Database Administrator, co trochę martwi. Ponadto podczas instalacji zabiera on jednak 800 MB powierzchni dyskowej. Natomiast GUI w wykonaniu Oracle jest bardzo czytelny. System ten prezentuje najlepszy interfejs do zarządzania serwerem i jego schematem, wyprzedzając na tym polu innych dostawców.

Kolejną testowaną własnością było monitorowanie wydajności serwera, szczególnie ważne w pracy z wielkimi katalogami. W iPlanet można monitorować operacje serwera za pośrednictwem SNMP lub za pomocą samego serwera LDAP w kliencie albo aplikacji LDAP. Serwer eTrust Directory funkcjonował na podobnej zasadzie, ale statystyki można otrzymywać przez SNMP i przez CMIP (Common Management Information Protocol) - opartym na ISO skomplikowanym ekwiwalencie SNMP modelu TCP/IP.

Usługi wspierające (back-end)

Administratorzy sieciowi mogą mieć różne potrzeby. Na przykład dla przedsiębiorstw z rozproszonymi oddziałami wygodne są serwery rozprowadzające dane automatycznie. Z kolei zdecentralizowany model zarządzania może narzucać katalogowi wsparcie skomplikowanych modeli bezpieczeństwa. Korporacje tworzące własne sieci ekstranetowe mogą natomiast potrzebować usług katalogowych razem z usługami proxy i bezpieczeństwa.

Testowane katalogi charakteryzowały się różnymi poziomami rozbudowy cech wspierających usługi (back-end). Najogólniej X.500 oferuje dużo więcej tych cech niż LDAP. Serwer katalogowy iPlanet ma możliwość wykrywania włamań i wprowadzania strategii hasła. Wszystkie katalogi oparte na X.500 miały pełny zestaw narzędzi replikujących, podczas gdy Directory Server został ograniczony tylko do schematu master-slave. Szczególnie mocny w tej dziedzinie był eTrust Directory. W jego własnościach znalazło się nie tylko replikowanie między różnymi katalogami X.500, ale także między X.500 a LDAP. Jest on także jedynym katalogiem, który w pełni przerzuca mosty nad przepaściami - między tymi dwoma protokołami i to w obydwu kierunkach.

Tworzenie łańcuchów (chaining) i odwoływanie (referral) są dwiema kolejnymi właściwościami, które podczas testowania zróżnicowały serwery. Odwoływanie ma miejsce wówczas, kiedy serwer nie zna odpowiedzi na skierowane do niego zapytanie, ale jest w stanie wskazać, gdzie można ją znaleźć. Przykład: klient zwraca się do serwera LDAP o adres e-mail osoby zatrudnionej w dziale księgowości. Serwer może nie znać odpowiedzi, ale może wiedzieć, gdzie jest ulokowany serwer LDAP dla działu księgowości. W tym przypadku serwer ułatwia klientowi znalezienie informacji zamiast odpowiedzieć "nie wiem". Wszystkie testowane produkty wspierały tę funkcję.

Tworzenie łańcucha jest jak gdyby przedłużeniem opisanej funkcji odwoływania. W zainscenizowanym poszukiwaniu adresu poczty elektronicznej serwer LDAP nie podpowie klientowi, gdzie można otrzymać ten adres, lecz sam rozpocznie poszukiwanie w jego imieniu, a następnie prześle klientowi gotowe dane. Tworzenie łańcuchów jest związane ze środowiskiem X.500, ale nie z LDAP. Jedynie IDDS wspierał tę funkcję w nie-X.500 katalogu. Tworzenie łańcuchów może być użyte także do tworzenia katalogu proxy. Innosoft proponuje proxy LDAP z dosyć skomplikowaną metodą kontroli dostępu jako oddzielny produkt. Computer Associates także wbudował niektóre cechy proxy w swoim eTrust Directory.

Protokół dla wszystkich

LDAP powstał na Uniwersytecie Michigan i jest oficjalnym protokołem IETF, opisanym pierwotnie w RFC 1777. Stanowi on podzbiór protokołu DAP, wykorzystywanego do tworzenia katalogów X.500. DAP jednak funkcjonuje tylko w strukturach OSI i wymaga komputerów o relatywnie dużej mocy przetwarzania. LDAP jest przejrzysty i "lekki", nie pochłania pasma jak X.500 i mocy obliczeniowej jak DAP w X.500. Dlatego warto się nim posługiwać.