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

Seznam podporovaných systémů CzechIDM

K CzechIdM je možné připojit libovolný systém, který je dostupný po síti a je známa struktura identit. CzechIdM umožňuje spravovat uživatelské účty na vzdálených systémech prostřednictvím vhodných konektorů. Jedná se o komunikační rozhraní využívající standardní protokoly ke komunikaci se spravovaným systémem.

Děláme Identity Management přes 10 let, dříve jako konzultanti, 6 let pod vlastní firmou. Začali jsme s pevnou sadou konektorů, kterou postupně rozšiřujeme, vyvíjíme si i vlastní. Většinu informačních systémů na trhu jsme již připojovali a aktivně je naše Identity Managery spravují.czechidm

Pokud konektor  pro správu koncového systému nemáme, využijeme některý obecný nebo jej na míru vyvineme. U složitějšího systému, jako je  například SAP, je náročnost vlastního vývoje odpovídacící pracnosti v nižších jednotkách dní vývojáře.

Zde je seznam nejčastěji připojovaných systémů

Veřejné správa a samospráva – agendové systémy a spisové služby :
  • Marbes Proxio
  • Gordic Ginis
  • ICZ eSpis
  • ICTBrains Matrix
  • BBM iFIS – finanční řízení
  • Vera
Akreditované certifikační autority v ČR:
  • eIdentity.cz
  • Postsignum.cz QCA
Doménové řadiče a adresářové služby:
  • Microsoft Active Directory
  • Kerberos
  • OpenLDAP
  • Novell eDirectory
  • Red Hat Directory
Mailové systémy:
  • MS Exchange
  • Office 365
  • Linux postfix
  • Communigate
Databáze:
  • Microsoft SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
  • Progres
  • Sybase
Operační Systémy:
  • HP-UX
  • Linux distribuce bez omezení – Red Hat, Debian, SuSE,…
  • Microsoft Windows všech verzí
  • Solaris
  • S/400
Personalistiky:
  • HRIS
  • Mysys HRMS
  • Navision
  • SAP
  • Vema
  • Helios
Web Single Sign On (SSO) a Access Management:
  • OpenAM
  • IBM/Tivoli Access Manager
  • Oracle Acces Manager
  • Sun Java System Access Manager
  • Kerberos
Zdravotnické systémy:
  • StaproMEDEA NIS
  • StaproPANAKEA
  • OpenLIMS
  • LEKIS
  • TESCO SW FaMa

Ostatní:

  • různé LDAPy
  • Plone
  • SAMBA

 

Pokud jste níže nenašli svůj systém, nezoufejte, seznam není kompletní. Napište nám na info@bcvsolutions.eu, zašleme Vám ínformaci jak je pracné Váš systém napojit.

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