Archiv pro rubriku: Adresářové služby

CzechIdM a autentizace proti koncovému systému

CzechIdM nabízí svým uživatelům webové rozhraní, ve kterém mohou zažádat o přístupy nebo měnit svá hesla na koncových systémech. V článku, jehož úvod si právě čtete, se podíváme, jak je zajištěna bezpečnost přihlášení do CzechIdM, jaké možnosti přihlášení CzechIdM poskytuje a jaká je jejich technická implementace. Administrátoři CzechIdM tu rovněž naleznou návod, jak ověřovat uživatele pomocí hesla z některého koncového systému.

Pokračování textu

Migrujeme Sun DS na 389 Directory server

Stojíte-li před podobným úkolem, najdete v tomto článku pár informací jak jsme my řešili migraci pro našeho zákazníka. Cílem bylo nahradit zastaralý adresářový server Sun Directory Server (dále jen Sun DS) verze 5.2 za novější software, který bude možné dále patchovat a udržovat. V našem případě se jednalo o nahrazení dvou multi-master serverů a několik kusů pobočkových replik za nový software.
Dobrou zprávou je, že Fedora Directory server a Sun DS mají stejný původní základ. Tento fakt migrace celkově usnadnil. Špatnou zprávou je změna replikačního protokolu mezi produkty Sun DS a 389 DS. Tedy replikaci nativní cestou mezi těmito sw produkty není možné bezpečně provozovat. Co se týče operačních systémů pod vlastní adresářové servery, tak se přechází ze Solaris 10 na Linux, konkrétně na Oracle Linux verze 6.2.

Pokračování textu

CzechIdM správa SAMBA domény II.

V tomto článku si ukážeme konkrétní scénáře při správě domény pomocí CzechIdM a technologie doménového řadiče SAMBA.
V minulém článku jsme nastínili, jak jednoduše je možné pomocí Identity Manageru CzechIdM spravovat doménu postavenou na Sambě. Pokud jste článek dosud nečetli, doporučuji tak nyní udělat: http://blog.bcvsolutions.eu/czechidm-sprava-domeny/.

Pokračování textu

Doménový řadič a další služby sítě – Adresářový server I

Tento článek je pokračováním k předchozím článkům (1,2), které popisují jak vybudovat Doménový řadič a další služby sítě.

Stavíme síť, která má více vzdálených poboček a chceme nabídnout uživatelům možnost přecházet z jednoho pracoviště na druhé. Abychom mu toto mohli nabídnout, je třeba, aby jeho uživatelský účet (jméno a heslo) byl dostupný napříč všemi pobočkami. Pokud k tomu přidáme ještě skutečnost, že pobočky jsou propojeny s centrálou například přes ADSL, tak nezbývá než všechny uživatelské účty uchovávat lokálně na pobočkových serverech. Pokud by tomu tak nebylo, pobočka by byla závislá na propojení s centrálou, a  každý si zřejmě dokáže představit rozladění uživatele, který přijde do práce a zjistí že se nepřihlásí, protože někdo překopl kabel od ADSL a internet prostě nejde.

Uživatelé jsou v OS Linux standardně založeni do souboru /etc/passwd, hesla mají v šifrované podobě v souboru /etc/shadow. Z hlediska doménového řadiče je jméno a heslo pouze malá část potřebných informací, další – podstatně větší množství – si Samba uchovává v lokálním souboru. Samozřejmě takto zapsané informace se velmi špatně replikují na další servery (pobočky). Pokračování textu

Mám použít CzechIdM nebo LDAP? Oba!

V diskuzi nad způsobem správy uživatelských účtů ve větším prostředí jsem se několikrát setkal s argumente, že identity manager je přece zbytečný, když je možné nasadit „LDAP“. Zkusím tedy sepsat pár svých myšlenek na toto téma, třeba to někomu ze čtenářů pomůže.

Aby se dalo „rozhodnout“ co je lepší použít, je nutné si nejdřív ujastnit k čemu Identity Manager a „LDAP“ slouží.

Pokračování textu

„Virtuální“ atributy v adresářovém serveru

Pro uživatele používáme adresářový server (~LDAP) z CentOSu. V LDAPu máme všechny uživatelské účty jak pro maily, tak i pro upload na web případně další služby. Pro každý mailový účet jsou v LDAPu vedené informace o kvótě, kterou přebírá Dovecot. Vznikl požadavek na nastavení doménových kvót, nikoliv jen pro jednotlivé schránky. Ke každému mailovému účtu je tedy nutné přidat informaci o celkovém místě, které může doména využívat. Ke každému mailovému účtu je to kvůli dovecotu, neumí se (nebo nevím jak) zeptat vícekrát na jednotlivé kvóty. Jenže zapisovat jednu hodnotu, která se vztahuje k doméně, ke každému z mailových účtů je čuňárna. Muselo by se to při každé změně všude přepisovat. Snadnější je schopností vlastností adresářového serveru aby informace přenášel z jednoho místa – ze záznamu domény.

Pokračování textu

Zabezpečený přístup k LDAPu pomocí JNDI.

V tomto příspěvku je nastíněno, jak lze pracovat s LDAPem v jazyku java. Protože se často přenáší citlivá data je zde ukázáno, jak se připojit přez ssl.

Předpokládáme, že je na LDAP serveru povolena možnost připojovaní přez protokol LDAPS na portu 636. Navíc klient musí mít ve své keystore uložen certifikát serveru nebo jeho certifikační autority.

Pokračování textu