Monday, November 19th, 2007...10:28 pm

Porównanie OpenLDAP i ADAM – polemika, cz.1

Jump to Comments

Kilka tygodni temu na stronach firmy Symas pojawiło się porównanie OpenLDAP i ADAM jako platform serwerów LDAP. Spytałem o opinię o tym dokumencie jedną z osób, która włożyła dużo pracy w stworzenie ADAM. Poniżej kawałek odpowiedzi:

(…) I looked at the paper, and it was not technical enough for me to be seriously considered. (…)

I w zasadzie na tym moglibyśmy skończyć :). Jednak ja uparłem się i postanowiłem ten dokument przeczytać :). Wynikiem tego jest poniższa notka zawierająca kilka moich uwag dotyczących treści dokumentu. W żadnym wypadku nie jest to porównanie OpenLDAP i ADAM :). Uznałem po prostu, że dobrze będzie kilka rzeczy z tego dokumentu wyjaśnić, aby czytelnikowi mojego bloga, który przypadkiem (a może zainspirowany tym wpisem) przeczyta dokument Symas,przybliżyć kilka kwestii.

Na początek wyjaśnienie, czym zajmuje się firma Symas. Otóż Symas wspiera development, wdraża i wspiera serwer OpenLDAP oraz rozwiązania oparte o to rozwiązanie. Jak sami piszą na swojej stronie:

(…) Over 70% of OpenLDAP code funded by or through Symas (…)

Czym zajmuje się Microsoft chyba nie muszę pisać.

Jeszcze jedno zastrzeżenie, którego zwykle tutaj nie robiÄ™. Niektórzy zapewne wiedzÄ…, a niektórzy nie (w zasadzie chciaÅ‚em odesÅ‚ać tutaj do notki o autorze, ale przypomniaÅ‚em sobie, że jeszcze jej nie napisaÅ‚em 🙂 ) – pracujÄ™ w Microsoft, jednak opinie tutaj wyrażane w żaden sposób nie sÄ… powiÄ…zane z tÄ… firmÄ… – to moje osobiste zdanie na opisywany temat. Ponieważ notka dotyczy porównania dwóch produktów, w tym produktu konkurencji, i nie chciaÅ‚bym, żeby potem ktoÅ› stwierdziÅ‚ że “Microsoft Polska powiedziaÅ‚” :).

Tyle tytuÅ‚em przydÅ‚ugiego wstÄ™pu. Teraz – co mi siÄ™ podoba, a co nie w tym dokumencie.

Na początek tytuł:

Assessment of Microsoft’s Active Directory Application Mode (ADAM) as a Potential Enterprise Directory Technology versus OpenLDAP and Other LDAP Offerings

TytuÅ‚ jak to tytuÅ‚ – jakiÅ› musi być. Problem w tym, że ten nie do koÅ„ca oddaje faktycznÄ… treść dokumentu. Tam gdzie byÅ‚o to wygodne, Symas odnosi siÄ™ do Active Directory jako caÅ‚ej usÅ‚ugi, a nie do ADAM jako czystego serwera LDAP. Prawo autora swobodnie traktować temat – ale porównywanie AD (jako caÅ‚ego rozwiÄ…zania) z ADAM i OpenLDAP jest troche chybione. Dlaczego? Ponieważ AD to usÅ‚uga katalogowa w ramach NOS, której serwer LDAP jest jednym ze skÅ‚adników – faktem jest, że jednym z ważniejszych :).

Ogólnie z pierwszÄ… częściÄ… dokumentu trudno polemizować, ponieważ opiera siÄ™ ona tylko i wyÅ‚Ä…cznie na autorytatywnych stwierdzeniach autora bez podania faktów. A żeby polemizować – trzeba mieć jakiÅ› punkt odniesienia.

Skupmy sie wiÄ™c na części bardziej konkretnej czyli “Architectural Issues with ADAM” (s.10) .

1/ Zmiana schematu katalogu

W ramach tej części znowu znajdujemy odniesienie do AD zamiast ADAM. W dokumencie (s.11) czytamy więc:

(…)We can only conclude that there are obstacles to changing Active Directory’s schema or configuration. We should not conclude as they intend us to that there are barriers to changing schema or configuration on enterprise-grade LDAP servers. (…)

Jakie to więc przeszkody stoją na drodze do zmiany schematu lub konfiguracji AD\ADAM? Jedyne, jakie istnieją w przypadku AD w zakresie zmiany schematu lub konfiguracji, to:

  • Konieczność utrzymania dostarczonego schematu w przypadku Active Directory: AD korzysta z pre-definiowanego schematu, jak każda aplikacja korzystajÄ…ca z LDAP. Jeżeli ten schemat zostanie naruszony i nie bÄ™dÄ… dostÄ™pne klasy i atrybuty, jakie zakÅ‚adano tworzÄ…c Active Directory, możemy siÄ™ spodziewać kÅ‚opotów – ale Å›miem twierdzić, że tak bÄ™dzie w przypadku każdej aplikacji opartej na LDAP, która zakÅ‚ada pewien schemat danych. Po to tworzy siÄ™ schemat.
  • Brak możliwoÅ›ci usuniÄ™cia wprowadzonego rozszerzenia schematu. W AD atrybut lub klasa może zostać wyÅ‚Ä…czona (de-funct) ale nie kompletnie usuniÄ™ta. Nie oznacza to jednak, że nie można modyfikować raz wprowadzonego rozszerzenia schematu.
  • Najważniejszy czynnik – opory osób utrzymujÄ…cych tÄ… usÅ‚ugÄ™. Schemat AD jest rozszerzalny i jeżeli tylko jest taka potrzeba, możemy go bez obaw rozszerzyć. OczywiÅ›cie w takim wypadku przydaje siÄ™ wiedza jak to zrobić. W wiÄ™kszoÅ›ci przypadków jedyny problem to obawy przed wykonaniem tego typu zmiany (tutaj należy przyznać, że wina leży po stronie Microsfot, który na poczÄ…tku istnienia AD zaszczepiÅ‚ gÅ‚Ä™boko lÄ™k przed wykonywaniem tego typu zmian).

Z kronikarskiego obowiązku wspomnę tylko, że ADAM przychodzi bez zdefiniowanego schematu LDAP (poza podstawowymi klasami i atrybutami) i można go dowolnie kształtować dostosowując do własnych potrzeb. Można zaimportować pre-definiowaną definicję schematu przygotowaną przez Microsoft i dostarczaną wraz z ADAM, ale nie jest to obowiązkowe.

2/ Architektura aplikacji korzystajÄ…cych z ADAM jako z katalogu LDAP

Jako przykład błędów w architekturze usługi ADAM pokazany został schemat potencjalnej konfiguracji aplikacji opartej na ADAM (s.12). Schemat ten, zgodnie z tym co piszą autorzy dokumentu, na pierwszy rzut oka wygląda dosyć skomplikowanie:

Szczególnie, gdy porównamy go do prostej i czystej architektury aplikacji opartej na OpenLDAP prezentowanej w dokumencie:

Należy jednak zwrócić uwagę na to, że schemat architektury aplikacji opartej na ADAM przedstawia wszystkie możliwe warianty a więc:

  • Aplikacja korzysta tylko z ADAM
  • Aplikacja korzysta z ADAM i lokalnych kont systemowych
  • Aplikacja korzysta z ADAM i kont w usÅ‚udze Active Directory
  • Aplikacja korzysta z ADAM i kont w domenie NT
  • Aplikacja korzysta tylko z kont lokalnych / domenie NT / katalogu AD
  • Wariacje powyższych wariantów.

Aplikacja może więc posługiwać się tylko katalogiem ADAM, tylko kontami systemowymi lub zarówno kontami systemowymi jak i obiektami ADAM. Mechanizmy tej usługi pozwalają na uwierzytelnienie użytkowników z użyciem kont systemowych \ katalogu AD \ domeny NT poprzez zastosowanie obiektów klasy userProxy.

Zmodyfikujmy więc rysunek przedstawiający architekturę aplikacji korzystającej z OpenLDAP i w miejsce tego serwera wstawmy ADAM. Przy okazji ograniczymy się tylko do tych połączeń, które będą miały zastosowanie w scenariuszu wskazanym na rysunku aplikacji korzystającej z OpenLDAP.

W zasadzie uzyskujemy ten sam rysunek i funkcjonalność. Bez dodatkowej usÅ‚ugi gateway dla domeny NT. Cóż … kwestia odpowiedniego użycia technologii.

3/ Wirtualne atrybuty obiektów

W dokumencie, w ramach opisu możliwości oferowanych przez OpenLDAP dla aplikacji czytamy dalej (s.13):

(…) OpenLDAP offers additional opportunities. The Web portal’s authentication and application data directory can either be on the same server or it can be somewhere else in the fabric of the enterprise. OpenLDAP offers translucency so that attributes can be “added” to the Active Directory objects and stored in the OpenLDAP instance. Nothing is changed in the Active Directory. All translucent attributes remain in the OpenLDAP database. (…)

Prawda, że bardzo pożyteczna funkcja? Mamy niezależne źródło uwierzytelnienia i partycję aplikacji przechowującą zestaw atrybutów w OpenLDAP. Użytkownik nadal uwierzytelnia się w AD, a nie ma potrzeby rozszerzenia schematu katalogu tej usługi w celu przechowywania dodatkowych danych..

W ADAM nazywa siÄ™ to userProxy i jest możliwe do osiÄ…gniÄ™cia poprzez zaimportowanie do schematu definicji odpowiedniej klasy (pliki LDIF dostarczane sÄ… wraz z ADAM). Utworzenie obiektu tej klasy umożliwia użycie uwierzytelnienia z AD, a sama definicja klasy może zostać rozszerzona o dowolne atrybuty po stronie ADAM. Jak dla mnie wyglÄ…da to na tÄ… samÄ… funkcjonalność, choć może inaczej zaimplementowanÄ… i konfigurowanÄ…. Tutaj przyznam siÄ™, że nie sprawdziÅ‚em dokÅ‚adnie jak dziaÅ‚a to w OpenLDAP – chciaÅ‚em przetestować to na wersji oferowanej przez Symas, jednak przez dwa tygodnie od chwili rejestracji nie uzyskaÅ‚em dostÄ™pu do Å›ciÄ…gniÄ™cia serwera.

4/ Wydajność obu serwerów LDAP

W tym miejscu naprawdę trudno się odnieść do podanych danych, ponieważ porównanie dotyczy AD i OpenLDAP, i opiera się na testach przeprowadzonych w różnych warunkach. Swoją drogą sam bym chętnie zobaczył dane z testów ADAM zgodnie z metodologia slamd. Mimo tego, że testy były wykonane w innych warunkach i jak Symas sam przyznaje dla różnych operacji, pozwala im to wysnuć wniosek (s.15):

(…) Again, this suggests OpenLDAP performance is probably in the range of eight to nine times faster. (…)

Przy okazji, w tekście dotyczącym wydajności można przeczytać ciekawe stwierdzenie (s.15):

(…) Microsoft generally does not access AD through LDAP. That means Windows internally may see better performance than indicated by these preliminary findings. (…)

Hmm … polecam chwilÄ™ z AD i monitorem sieci lub zablokowanie portu LDAP na kontrolerze domeny. MyÅ›lÄ™, że od razu siÄ™ okaże, że Microsoft jednak korzysta z LDAP.

5/ Ograniczenia schematu: zakodowane ograniczenia długości atrybutów

W tekście dokumentu czytamy (s.16):

(…) ADAM imposes hard coded character length limitations to many standard LDAP attributes, and there are no documented means of increasing these limits. Examples include: cn, o and ou attributes limited to 64 characters; displayName limited to 256 characters; description limited to 1024 characters. (…)

Autorzy dokumentu napewno na niejednym serwerze LDAP zęby ostrzyli, powinni więc zwrócic uwagę na to, że nie są to ograniczenia hard coded a domyślne wartości atrybuty rangeUpper, zdefiniowane w ramach domyślnego schematu katalogu. Schemat ten możemy jednak w prosty sposób zmodyfikować (sic!) zwiększając wartość rangeUpper i oto proszę, obiekt z CN znacznie dłuższym niż 64 znaki:

>> Dn: CN=123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890,CN=Roles,O=w2kpl

Zaglądając do definicji atrybutu Common-Name po takiej modyfikacji w schemacie mamy więc:

>> Dn: CN=Common-Name,CN=Schema,CN=Configuration,CN={EF260F13-D6B7-4211-808B-35069A8C535D}
1> cn: Common-Name;
1> distinguishedName: CN=Common-Name,CN=Schema,CN=Configuration,CN={EF260F13-D6B7-4211-808B-35069A8C535D};
1> rangeUpper: 256;
1> name: Common-Name;

Sprawdźmy może jeszcze czy dla displayName również możemy zwiększyć wartość rangeUpper:

>> Dn: CN=Display-Name,CN=Schema,CN=Configuration,CN={EF260F13-D6B7-4211-808B-35069A8C535D}
1> cn: Display-Name;
1> distinguishedName: CN=Display-Name,CN=Schema,CN=Configuration,CN={EF260F13-D6B7-4211-808B-35069A8C535D};
1> rangeUpper: 1024;
1> name: Display-Name;

Jak widać wartości te nie są hard coded a wynikają z definicji schematu, który można zmienić i dostosować do własnych potrzeb.

6/ Ograniczenia dla atrybutów o składni distinguishedName

W dokumencie (s.17) wskazane jest ograniczenie ADAM polegające na tym, że ADAM nie pozwala na umieszczenie w atrybucie o składni distinguishedName wartości atrybutu DN, która odnosi się do obiektu, który nie istnieje w ramach partycji katalogu ADAM:

Powoduje to, że nie można w ramach ADAM, w atrybucie o składni DN umieścić DN do obiektu z zewnętrznego katalogu, a przy operacji importu danych należy zapewnić odpowiednią kolejność importu danych.

Sam z chÄ™ciÄ… widziaÅ‚bym zmianÄ™ w ADAM pozwalajÄ…ca na takie zachowanie jakie opisane jest w dokumencie – czasami uÅ‚atwiÅ‚oby to tworzenie pewnego rodzaju scenariuszy.

Aby mieć jednak peÅ‚ny obraz sytuacji, należy tutaj zaznaczyć, że ograniczenie to nie wynika z prostego “widzimisiÄ™” twórców, a z faktu, że ADAM zapewnia sprawdzanie poprawnoÅ›ci oraz automtycznÄ… akutalizacjÄ™ wartoÅ›ci DN. Wyobraźmy sobie nastÄ™pujÄ…cy scenariusz: obiekt A przypisany jest jako manager do innego obietu B. Z technicznego punktu widzenia, w odpowienim atrybucie obiektu B znajduje siÄ™ DN wskazujÄ…cy na obiekt A.

Co się stanie gdy obiekt A zostanie usunięty lub przesunięty w katalogu? ADAM automatycznie uaktualni link w atrybucie obiektu A, tak aby informacja odpowiadała stanowi rzeczywistemu.

Przykład: wpiszmy do atrybutu lastKnownParent obiektu DN do kontenera istniejącego w ramach naszej instancji ADAM (przyznaję, że przykład nie jest zbyt praktyczny):

>> Dn: CN=Readers,CN=Roles,O=oneidentity
1> lastKnownParent: CN=123456,CN=Roles,O=w2kpl;

Przenieśmy teraz obiekt CN=123456,CN=Roles,O=w2kpl w ramach katalogu do innego kontenera. W wyniku tej operacji DN obiektu ulegnie zmianie na CN=123456,O=w2kpl. Sprawdźmy teraz zawartość atrybutu, który uzupełniliśmy wcześniej:

>> Dn: CN=Readers,CN=Roles,O=oneidentity
1> lastKnownParent: CN=123456,O=oneidentity;

Musicie uwierzyć mi na słowo, że wykonane to zostało automtycznie lub zainstalować instancję ADAM i sprawdzić to zachowanie samodzielnie.

Funkcjonalność ta stanowi więc utrudnienie w pewnych scenariuszach (masowe importy danych itp), ale znacznie ułatwia życie w innych (aplikacje, które nie muszą sprawdzać poprawności linków do obiektu po przesunięciu w ramach katalogu).

Z tego, co udaÅ‚o mi siÄ™ sprawdzić, w OpenLDAP taka funkcjonalność nie istnieje – można by wiÄ™c powiedzieć, że to OpenLDAP w tym scenariuszu posiada mniejszÄ… funkcjonalność. Z tym, że to też nie jest prawdÄ…. Te rozwiÄ…zania sÄ… po prostu inne. Idealnie byÅ‚oby mieć możliwość skorzystania z obu wariantów – mam nadziejÄ™, że oba rozwiÄ…zania kiedyÅ› takiej możliwoÅ›ci nam dostarczÄ….

———–

NiechcÄ…cy wyszedÅ‚ mi z tej notki dosyć dÅ‚ugi artykuÅ‚. PostanowiÅ‚em wiÄ™c podzielić go na dwie części. Tutaj koÅ„czy siÄ™ część pierwsza … druga już wkrótce. Jak to mówiÄ… w amerykaÅ„skich serialach …

… to be continued

3 Comments

Leave a Reply