Problémy s lepší autentizací

LDAP se ukazuje jako standard, který nezajistí potřebnou interoperabilitu. V průběhu realizace našeho projektu, jehož c


LDAP se ukazuje jako standard, který nezajistí potřebnou interoperabilitu.
V průběhu realizace našeho projektu, jehož cílem je zavedení dvoufaktorové
autentizace zajišťující přístup k našim kritickým serverům s Unixem a Windows
NT, se setkáváme se střídavými úspěchy a neúspěchy. Chceme vytvořit systém,
který bude po uživatelích vyžadovat, aby pro administrátorský přístup k našim
produkčním serverům se Solarisem, Windows NT a Windows 2000 používali tokeny
SecurID. Ukázalo se však, že cesta k takovému řešení je přehrazena několika
překážkami.
První problém se objevil na straně Solarisu. Naše společnost používá v roli
podnikových adresářových služeb systém eDirectory od Novellu. Ten je založen na
protokolu LDAP (Lightweight Directory Access Protocol). Jak jsme ale zjistili,
využití standardu LDAP zde negarantuje interoperabilitu.
Chtěli jsme nakonfigurovat všechny naše servery se Solarisem tak, aby si sahaly
do serveru eDirectory pro autentizační informace. Zvažovali jsme, že použijeme
specializovaný software označovaný jako PAM (Pluggable Authentication Module)
od australské společnosti PADL Software. Tato sada open source knihoven
umožňuje komunikaci prostřednictvím LDAP mezi systémem Solaris 2.8 a
eDirectory. Kvůli chybějící podpoře ze strany PADL a strachu ohledně
kompatibility s budoucími záplatami a softwarovými updaty jsme se ale nakonec
rozhodli dát přednost standardnímu řešení využití technologií integrovaných v
obou produktech.

Ach ten klient
Distribuce Solarisu obsahuje nativního LDAP klienta, který by měl pracovat s
ostatními adresářovými servery odpovídajícími standardu LDAP. Když se tedy
teoreticky nějaký administrátor přihlásí, systém eDirectory by měl umožnit
porovnání přihlašovacích údajů s údaji v databázi. Pokud má účet administrátora
správně nastavená práva a použije platný token SecurID, server eDirectory by
měl jeho majiteli schválit přístup k příslušným zdrojům.
Taková funkčnost by nám naprosto vyhovovala, protože by nám umožnila vyhnout se
jinak nezbytné správě lokálních účtů na každém systému se Solarisem. Mohli
bychom také použít Network Information Service Solarisu, ale k tomuto řešení se
nepřikláníme, protože jsou známy jeho bezpečnostní slabiny.
Naše společnost standardně používá systém eDirectory, dává tedy smysl používat
se Solarisem ten samý úložný systém a přidat jen odpovídající autorizační
mechanismus, který umožní zajistit centralizované řízení přístupu k našemu
produkčnímu prostředí, jež se skládá z více než 300 serverů se systémem
Solaris. Jenže jsme narazili na problém s nativním klientem LDAP u Solarisu
2.8. Má zjevné problémy s komunikací s eDirectory. Kontaktovali jsme technickou
podporu Novellu a její zaměstnanci nám potvrdili, že problém existuje a že o
něm vědí. Takže tolik ke standardům.
Celý problém přestane existovat v okamžiku, kdy upgradujeme všechny své servery
na Solaris 9, protože jeho nativní klient LDAP pracuje dobře. Jenže v tomto
okamžiku mohu říci, že než s takovým upgradem začneme, uplyne ještě minimálně 8
měsíců. Do té doby máme několik možných variant řešení celého problému. Mohli
bychom použít dirXML od Novellu, což je služba pro obousměrné sdílení dat v
metaadresáři, která by nám pravděpodobně umožnila používat eDirectory k
distribuci nových a updatovaných adresářových informací do našich serverů se
Solarisem. Jestliže problém nevyřešíme s Novellem, budeme muset použít jiný
LDAP server, který tuto funkci zastane.

Alternativa
Adresářový server iPlanet od Netscape Communications je schopen pracovat s LDAP
klientem Solarisu 2.8, ale pokud bychom se rozhodli jej nasadit, měli bychom ve
firmě další adresářový server, který bychom museli spravovat. To zase nevypadá
jako tak velký problém koneckonců bude třeba nastavit práva jen asi 30
administrátorům.
Jde ale také o velké politické rozhodnutí. Firemní oddělení pro řešení v
oblasti e-businessu nainstalovalo nedávno vlastní adresářový server iPlanet a
oddělení IT operací se ho snažilo přimět k přechodu na podnikový standard tedy
eDirectory. Kdybychom spustili další instanci serveru iPlanet, dalo by to
skupině e-businessu další argument k tomu, aby si ponechala řešení, které má.

A ještě Windows
Další problém vyvstal v našem prostředí s Windows. Abychom mohli v rámci tohoto
prostředí zajistit centralizovanou autentizaci, používáme Active Directory od
Microsoftu, a to společně s terminálovými službami pro vzdálenou správu. Nyní
chceme přidat autentizaci administrátorů prostřednictvím tokenů SecurID.
V době, kdy jsme ještě používali Windows NT 4.0, pracoval s touto konfigurací
bez problémů Ace Agent od RSA Security. Ten samý agent však nebude bez problémů
chodit spolu Windows 2000 a Active Directory. Místo toho společnost RSA
vytvořila speciálního klienta pro Active Directory. Získali jsme jednu jeho
kopii a všechno se zdálo pěkně fungovat.
Klient Terminal Services se připojil ke vzdálenému serveru a vyvolal
přihlašovací okno. Vložili jsme naše uživatelská jména a hesla, přičemž jsme
uvedli i doménu. V tomto okamžiku se měl objevit separátní dialogový box, který
po nás měl chtít použití tokenu SecurID. Teprve potom měl přihlašovací proces
pokračovat.
To se ovšem nestalo. Proč? Záznam událostí, který jsme následně procházeli,
obsahoval hlášení "certificate mismatch error". Vzdáleně prostě nejsme schopni
se serveru autentizovat. Technická podpora RSA potvrdila, že problém existuje,
a konstatovala, že se pracuje na jeho řešení. Dokud nebude hotovo, musíme
zakázat dvoufaktorovou autentizaci.
Jestliže bude problém přetrvávat ještě několik týdnů, budeme se muset
poohlédnout po nějakém konkurenčním řešení. O výsledku dám vědět v některém ze
svých příštích příspěvků.
Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.