LDAP (Lightweight Directory Access Protocol), po zaimplementowaniu na serwerze w konkretnej sieci lokalnej stanowić ma fragment rozproszonego ogólnouczelnianego systemu informacji o zasobach sieciowych i użytkownikach sieci komputerowej UMK. Celem jego implementacji jest dalsza racjonalizacja zarządzania sieciami lokalnymi, a także rozbudowa możliwości i ułatwienie pozyskiwania informacji znajdującej się w sieci. Zatem zadaniem takiego systemu jest z jednej strony dostarczanie informacji na żądanie systemu nadrzędnego, o ile spełnione są odpowiednie warunki, ale również na żądanie serwisów lokalnych dla danej sieci.

Przykład 1: ogólnouczelniany serwis informacji o pracownikach otrzymuje pytanie o Jana Kowalskiego; wówczas niezbędne jest, by za pomocą referali uzyskać informacje od poszczególnych serwerów sieci lokalnych, na których zainstalowany jest LDAP.

Przykład 2: Wydział Prawa zakupił prawo dostępu do bazy danych o aktach prawnych i orzecznictwie dla komputerów użytkowanych w siedzibie Wydziału oraz dla służbowych laptopów pracowników wydziału (niezależnie od tego gdzie taki pracownik będzie musiał skorzystać z w/w bazy). W takiej sytuacji - dla celów autoryzacji/autentykacji wystarcza bezpośredni dostęp do lokalnego serwisu LDAP-a posadowionego na serwerze wydziału.

Ogólnouczelniany System Uwierzytelniania (Autentykacji) Pracowników

Jednym z najbardziej naturalnych zastosowań LDAP-a wydają się być wszelakie systemy typu "white pages" - o pracownikach, studentach, absolwentach itp. Część spośród nich niekoniecznie musi być użytkownikami jakiegokolwiek serwera tak ogólnouczelnianego, czy też lokalnego. Zakładamy, że informacje o osobach nie będących użytkownikami do takich systemów pozyskujemy drogą importu z zasobów centralnych (np. bazy kadrowe, systemy pomocy materialnej dla studentów itp.), a dane o użytkownikach serwerów z LDAP-a..
Na poziomie ogólnouczelnianym musimy więc zajmować się obiektami typu "student", "pracownik", "absolwent", a nie tylko obiektami typu "użytkownik".
Do tego, by móc stworzyć kompletny system brakuje jeszcze informacji o użytkownikach serwerów sieci lokalnych.
W tym przypadku LDAP jest rozwiązaniem, które w naturalny sposób wpisuje się w każdą koncepcję takiego systemu (biorąc pod uwagę takie czynniki jak: rozproszenie danych, efektywność rozwiązania i bezpieczeństwo).

Dodatkowym argumentem przemawiającym za zastosowaniem tu LDAP-a jest to, że dostęp do takiego systemu - zgodnie z rzeczywistością prawną - musi być zróżnicowany pod względem zakresu dostępnej informacji:

• w zależności od klienta wyszukującego informację,
• w zależności od pracownika będącego przedmiotem poszukiwań.

Czyli, przy dostępie do takiego systemu należy stosować zaawansowane techniki uwierzytelniania w oparciu o nietrywialne reguły.

Ewidentnym więc zastosowaniem LDAP-a w sieciach lokalnych będzie uwierzytelnianie użytkowników, poprzez lokalny system uwierzytelniania (realizując również zlecenia analogicznych systemów nadrzędnych), zarówno dla potrzeb zastosowań lokalnych dla sieci, jak również dla potrzeb informacyjnych systemów nadrxędnych (ogólnouczelniany i ponadśrodowiskowy) .

Jeśli w sieci lokalnej istnieje system LDAP - wówczas włączenie go w strukturę ogólnouniwersytecką nie powinno wymagać specjalnych działań.

Dla potrzeb tego systemu stosujemy klasę eduPerson z niezbędnymi rozszerzeniami. Istotne wydają się rozszerzenia definiujące klasy i atrybuty specyficzne dla polskiego środowiska akademickiego (zarówno bezpośrednio opisujące obiekt, jak również powiązane z nimi atrybuty o charakterze operacyjnym), gdyż determinują one (na ogół implicite) różnorodne uprawnienia użytkownika, bowiem zależne są one od tytułu (stopnia) naukowego, a także stanowiska zajmowanego przez użytkownika (np. takie atrybuty jak personalTitle, pleduPersonDegree, pleduPersonposition, a także pleduPersonPublic, czy pleduStatus).

Aktualny schemat kont na serwerach lokalnych nadaje się bez modyfikacji do współpracy z LDAP-em.

Uwaga:

Przy realizacji tego aspektu zastosowań LDAP-a zadania Pracowni Sieci Lokalnej ograniczają się w zasadzie do współpracy przy dopasowaniu lokalnych i ogólnouczelnianych struktur informacyjnych.

Aktualnie informacja o zasobach sprzętowych jest umieszczona w różnych miejscach. Na dodatek wiadomo, że informacje na temat tego samego obiektu, pochodzące z różnych źródeł, mogą być sprzeczne. Nawet jeśli informacja występuje w jednym miejscu i jest jednoznaczna, to może się zdarzyć, że uzyskanie jej jest trudne.

Typowym zagadnieniem jest wyszukanie lokalizacji komputera na podstawie adresu IP. Informacji takich można poszukiwać w tablicach DHCP na serwerach lokalnych (komentarze), a także na serwerze helpdesku (baza jest tworzona na podstawie sprawozdań z interwencji). Teoretycznie tego rodzaju informacja jest wiarygodna - w praktyce jednak tak nie musi być, bowiem pracownik otrzymując nowy komputer, może przekazać stary innemu pracownikowi i informacje o tym mogą nie dotrzeć do UCI.

Jedynym w miarę jednoznacznym sposobem identyfikacji komputera jest identyfikacja na podstawie adresów sprzętowych kart sieciowych (MAC). Poza tym istnieją lokalizacje, gdzie nie ma serwerów sieci lokalnej (w tym serwera DHCP).
W takiej sytuacji rozwiązaniem może być LDAP. Mamy tu do czynienia z różnymi serwisami DHCP, niektóre mogą współpracować bezpośrednio z LDAP-em inne nie. Ponadto nie w każdym przypadku uda się uzyskać wszystkie pożądane informacje.

Dla celów helpdesku oraz administratorów sieci lokalnych (serwerów sieci lokalnych) potrzebne są następujące informacje (którym odpowiadają obowiązkowe klasy obiektów):

• adres MAC (sprzętowy) karty sieciowej komputera,
• adres IP topologicznie najmniej odległy od końcowego użytkownika - adres IP koncentratora, do którego jest przyłączony komputer, lub IP routera, gdy np. obiekt jest przyłączony do huba pozbawionego jakiejkolwiek "inteligencji",
• numer odpowiedniego gniazda koncentratora.

• adres IP komputera,
• numer gniazdka sieci komputerowej, do którego przyłączony jest komputer,
• informacja o systemie operacyjnym komputera (np. w przypadku epidemii wirusa atakującego konkretną wersję systemu Doors z ServicePack 4),
• informacja o dysponencie komputera (nazwisko, imię, adres email, telefon).

Ponieważ LDAP może być stosowany w różnych obszarach, wskazane jest zatem, by można było rozdzielać struktury danych, które nie są w sposób ścisły hierarchiczne.
I tu mamy do czynienia właśnie z takim przypadkiem. Wystarczy więc, by zamiast tej informacji umieścić odwołanie (alias) do odpowiedniego DN w strukturze odpowiedniego "osobowego" poddrzewa (np. jako wartość dla atrybutu aliassedObjectName klasy alias).
Jak widać informacje sklasyfikowane jako nieobowiązkowe są mniej wiarygodne lub szybciej (łatwiej) zmieniają się.
Wydaje się, że najbardziej korzystne będzie użycie w tym przypadku zmodyfikowanego schematu nis.schema. Zawiera on definicje klas dla IP i MAC (ieee802Device, a także klasy alias z atrybutem aliassedObjectName).

Autoryzacja/autentykacja dla lokalnych sieci domów studenckich

Lokalna sieć domów studenckich to płaska topologicznie sieć, obejmująca jeden lub więcej domów studenckich, z wyjściem na świat przez unixowy router/firewall. Początkowo stosowano adresy prywatne - jednak doświadczenia okazały się negatywne. Rozwiązaniem będzie zastosowanie autoryzacji/autentykacji za pomocą LDAP-a każdorazowo przy rozpoczęciu pracy z komputerem przez użytkownika. Użytkownik po autoryzacji/autentykacji uzyska dostęp na zewnątrz sieci lokalnej. Autoryzacja/autentykacja polegać ma na zalogowaniu się i otwarciu połączenia sieciowego i tak długo jak będzie ono utrzymywane, tak długo komputer, z którego użytkownik się zalogował będzie miał dostęp do internetu na zewnątrz sieci lokalnej.
W ten sposób z logów systemowych firewalla będzie można uzyskać dane o tym, kto i z jakiego IP miał dostęp do internetu w danej chwili. Jest to informacja kluczowa przy wszelkiego rodzaju procedurach identyfikujących użytkowników korzystających z dostępu do sieci w sposób nieregulaminowy, lub niezgodny z prawem. Dane do logowania autoryzacyjnego będą konfrontowane z danymi uzyskiwanymi z LDAP-a z systemu, na którym będą mieć konta wszyscy studenci chcący mieć dostęp do internetu z prywatnych komputerów z domów studenckich.

Aktualnie lokalne sieci domów studenckich działają bez autoryzacji. Przewiduje się, że w pierwszym etapie wdrażania systemu autoryzacji przetwarzane będą jedynie login i hasło studenta. W dalszym etapie przewiduje się bardziej zaawansowaną kontrolę i uzyskiwanie podczas autoryzacji informacji, która w prosty sposób umożliwi (a co najmniej znacząco ułatwi) fizyczną lokalizację komputera, z którego loguje się student.

Przetestowano dwa rozwiązania (slogin i www) służące do autoryzacji, pozwalające uzyskać i utrzymać możliwość dostępu do Internetu poza sieć lokalną.

Uwagi:

• można sobie wyobrazić tu autoryzację bez LDAP-a - wszyscy użytkownicy (studenci) mają (będą mieli) konta na jednym serwerze i na początek wystarczy jedynie informacja o loginie i haśle. Jednak w dalszym etapie - ze względu np. na przewidywane wyszukiwanie fizycznej lokalizacji np. komputerów zarażonych wirusem, niezbędne będzie przetwarzanie znacznie szerszego zakresu informacji.
• zauważmy, że nie ma potrzeby instalowania serwera LDAP-a na serwerze dostępowym do lokalnej sieci domów studenckich. Wystarcza prosty klient.

Mowa o klastrach bezdyskowych komputerów. Przepływ danych odbywa się tu za pośrednictwem routera/firewalla/serwera dostępowego, który również pełni rolę serwera DHCP dla komputerów klienckich.

Aktualnie mamy do czynienia z dwoma rodzajami obiektów tego typu: bezpłatną kawiarenką dostępną dla studentów konkretnego wydziału (donacja) oraz płatną pracownią dostępową dostępną dla studentów (za symboliczną opłatą) i pracowników (bezpłatnie). Obiekty te to klastry stanowisk, gdzie dostępna jest jedynie przeglądarka internetowa. Doświadczenia wykazały konieczność poszerzenia oferty o dodatkowe usługi. Zastosowanie SAMBY z LDAP-em pozwala z jednej strony ułatwić zarządzanie tymi obiektami, a poza tym umożliwia użytkownikom dostęp do swoich katalogów domowych. Paradoksalnie pozwoli to też lepiej wykorzystać sprzęt dzięki przeniesieniu części funkcji i oprogramowania nie tylko na serwer, ale również na montowany dysk użytkownika.

Mechanizm rozpoczęcia sesji wygląda następująco:

Użytkownik jest autoryzowany przez LDAP na serwerze centralnym i po pozytywnej autoryzacji uzyskuje profil ze swojego katalogu domowego, oraz możliwość montowania tego katalogu. Na serwerze centralnym znajduje się więc informacja o czasie rozpoczęcia i zakończenia sesji, oraz informacja niezbędna do autoryzacji użytkownika (w tym np. pozostałym limicie opłaconego czasu).

Uwagi:

• podobnie jak w przypadku sieci lokalnych domów studenckich, nie ma tu wymogu instalowania LDAP-a na serwerze dostępowym. Jest on de facto przezroczysty. Autoryzacja odbywa się - podobnie jak w przypadku sieci lokalnych domów studenckich - na centralnym serwerze przeznaczonym dla studentów,
• wymagana jest SAMBA z wkompilowaną obsługą LDAP-a. W pliku smb.conf na serwerze dostępowym kawiarenki (pracowni dostępowej) określona jest pełna informacja niezbędna dla rozpoczęcia pracy stanowisku klienckim. Początkowo przypuszczano, że opcjonalne skrypty, które mogą być uruchamiane przy otwieraniu (zamykaniu) połączenia mogą być przydatne do bardziej wyrafinowanego przetwarzania danych autoryzacyjnych. Skrypty te jednak uruchamiają się po uzyskaniu autoryzacji, więc należy unikać stosowania ich dla potrzeb autoryzacji.

To zastosowanie podobne do poprzedniego, różniące się jednak tym, że użytkownik co prawda loguje się, ale bez możliwości dostępnych dzięki SAMBIE. Autoryzacja/autentykacja służy do tego, by z danej biblioteki mieli dostęp jedynie uprawnieni użytkownicy (wydział lub inna jednostka organizacyjna może sobie zastrzec, by biblioteka zakładowa nie była ogólnodostępna). Na razie nie przewiduje się tu żadnej autoryzacji, ale może do tego dojść np. w przypadku zastrzeżeń donatora sprzętu dla Biblioteki Zakładowej. Tu autoryzacja będzie jednak prostsza niż w przypadku kawiarenek (pracowni dostępowych).

Opisujemy tu specyficzny przypadek: wydział kupił prawo do użytkowania specjalizowanej bazy danych kluczowej dla dziedziny nauki, która jest na nim uprawiana. Z warunków umowy licencyjnej wynika, że dostęp do bazy może mieć miejsce z komputerów usytuowanych w obiektach uczelni - poza miejscami publicznymi, oraz ze służbowych laptopów pracowników wydziału. Dostawca bazy dostarczył kompletny system z bazą, aktualizowaną co miesiąc przez dostawcę.

Ruch do bazy jest kontrolowany przez firewall. Pierwotna koncepcja zakładała kontrolę wg adresu IP, z którego ma miejsce próba dostępu. Jednak, by umożliwić dostęp z laptopów pracowników (np. z domu) potrzebna jest autoryzacja po LDAP-ie. W tym przypadku wystarcza jednak, by firewall komunikował się z lokalnym LDAP-em zainstalowanym na właściwym serwerze sieci lokalnej.

Zakłada się, że pozostaje pierwotny sposób autoryzacji wg IP zgodnego z wymogami umowy licencyjnej, a dla przypadku laptopów uzyskujących adresy IP spoza domeny będącej w dyspozycji UMK trzeba wprowadzić dodatkową autoryzację. Użytkownik łącząc się ze stroną aplikacji będzie najpierw musiał wprowadzić login i  hasło, a następnie jego żądanie zostanie przekierowane do właściwego serwisu.

Autoryzacja wg IP jest przeprowadzana standardowymi środkami firewalla.

Podsumowując dotychczas wykonane prace można stwierdzić, że jesteśmy dobrze przygotowani do kontynuacji tematu. Wykonano szereg eksperymentów, testowano skrypty, zdobywano doświadczenia.

W bliskiej perspektywie należy oczekiwać implementacji rozwiązania problemu dostępu do specjalizowanej bazy danych.

Następne w kolejności będą uruchamiane projekty związane z dostępem do Internetu z domów studenckich i pracowni dostępowych (kawiarenek). Tu warunkiem jest powszechność kont studenckich na ogólnouczelnianym serwerze "student" przeznaczonym dla studentów.

Wspomaganie helpdesku informacją uzyskiwaną z LDAP-a jest najbardziej złożonym projektem, nie tyle ze względów technicznych ile organizacyjnych. Należy zatem spodziewać się, że na uzyskanie zadowalających efektów niestety trzeba będzie poczekać.

Scalanie lokalnych LDAP-ów z systemem ogólnouczelnianym w ujednolicony system informacyjny jest już w stadium realizacji.