Kerberos a SSO: Jednotné účty v LDAP

20. 5. 2008 | Jiří Mlíka

Články - Kerberos a SSO: Jednotné účty v LDAP  

Další díl seriálu o centrální správě účtů popisuje jednoduchou konfiguraci LDAP (LDAP schema, Directory Information Tree), včetně vytvoření databáze, uživatelů a skupin a nastavení klienta.

Obsah

• Úvod
• LDAP schema
• Directory Information Tree
• Konfigurace serveru
  • Instalace softwaru
  • Konfigurace
  • Vytvoření databáze
  • Vytvoření uživatelů a skupin
    • Pár pravidel
    • Uživatelské účty
    • Skupiny
    • Přeci jenom dojde na LDIF
  • Odskok do Kerbera
• Konfigurace klienta
  • Instalace softwaru
  • Konfigurace
  • Testování
• Závěr

Úvod

Že lze sdílet informace o uživatelských účtech pomocí LDAPu není žádná novinka. Existuje spousta návodů, jak používat LDAP přímo pro autentizaci do systému pomocí PAM modulu pam_ldap nebo pro autentizaci na webu pomocí autentizačního modulu Apache auth_ldap. Další skupina návodů se soustředí na využítí LDAPu jako úložiště účtů pro Sambu. Tyto návody jsou fajn, zavádí však pro nás zbytečnou míru složitosti tím, že se odkazují na další technologie. Nakonfigurujeme si superjednoduše LDAP server, který nebude zatím sloužit k ničemu jinému než ke sdílení informací, které obvykle na samostatném systému najdeme v souborech /etc/passwd a /etc/group. Na straně serveru použijeme OpenLDAP.

Oblíbenou součástí těchto návodů bývá vytvoření základní struktury Directory Information Tree importem dat ve formátu LDIF. Tak to my tedy rozhodně dělat nebudeme. My to (s)prostě "naklikáme". Existují nástroje, které přímo podporují vytváření uživatelských účtů v LDAPu (např. Directory Administrator, LUMA, phpLDAPadmin). Já však použiji obecný LDAP editor JXplorer tak, aby popisované postupy byly zcela nezávislé na konkrétním softwaru. Pokud by náhodou někdo nevěděl, co to ten LDAP vlastně je, doporučuji přečíst si článek Lukáše Cirkvy Adresářové služby, který vyšel na AbcLinuxu.cz.

LDAP schema

Objekty, které budeme do LDAPu ukládat, budou představovat uživatelské účty a skupiny. Každý uživatelský účet má v /etc/passwd několik důležitých atributů (analogicky skupiny v /etc/group). V LDAPu je struktura objektů a formát jejich atributů popsán pomocí tzv. schema. Definice schemat jsou uloženy v záhadných souborech, na které se při konfiguraci serveru odkážeme. Definujeme tak možné typy objektů, které se v našem adresáři mohou objevit. Nemusíme jim příliš rozumět, stačí, když je budeme umět použít. Umět použít znamená vědět, na které z těchto souborů se musíme odkázat při konfiguraci našeho LDAP serveru. Definice všech užitečných schema se nainstalují spolu s OpenLDAP serverem.

Schema definující objekty a atributy UNIXových účtů a skupin se jmenuje nis.schema. Toto schema je dále zavislé na core.schema a cosine.schema, proto je v naší konfiguraci použijeme také. Pro uložení uživatelských účtů použijeme objekty definované pomocí tříd posixAccount a inetOrgPerson (definováno v inetorgperson.schema). Objekty třídy posixGroup použijeme pro skupiny.

Pozn.: Kdo zodpoví otázku, proč nemůžeme použít pro uživateský účet samotnou třídu possixAccount dostane jedničku! :-)

Directory Information Tree

Před tím, než náš adresář budeme plnit uživatelskými účty a skupinami, musíme navrhnout jeho strukturu. Tzn. navrhnout Directory Information Tree (DIT). Vytvoříme jednoduchý DIT, který bude mít ve svém kořeni dvě organizační jednotky - jednotku ou=people,dc=firma,dc=local, kam budme ukládat uživatelské účty, a jednotku ou=groups,dc=firma,dc=local, kam budem ukládat skupiny.

Konfigurace serveru

Instalace softwaru

Nainstalujeme tyto balíky (na Mandrivě):

• openldap
• openldap-clients
• openldap-servers
• libldap

Já, protože jsem se rozhodl adresář spravovat pomocí grafického nástroje, jsem ještě nainstaloval LDAP editor JXplorer a samozřejmě Javu, bez které JXplorer neběží.

Konfigurace

Konfigurace OpenLDAP serveru se nachází v souboru /etc/openldap/slapd.conf a může být i poměrně rozsáhlá a složitá. My však budeme tak zákeřní, že nenakonfigurujeme prakticky nic a ono to přesto poběží. Netvrdím, že ideálně, ale pro naše účely to stačit bude.

# Soubor /etc/openldap/slapd.conf na stroji srv-infra1.firma.local

include /usr/share/openldap/schema/core.schema
include /usr/share/openldap/schema/cosine.schema
include /usr/share/openldap/schema/inetorgperson.schema
include /usr/share/openldap/schema/nis.schema

pidfile         /var/run/ldap/slapd.pid
argsfile        /var/run/ldap/slapd.args

database        bdb
suffix          "dc=firma,dc=local"
rootdn          "uid=ldapadmin,dc=firma,dc=local"
rootpw          MojeLdapAdminHeslo

directory       /var/lib/ldap

Na začátku souboru jsme pomocí direktivy include zahrnuli do konfigurace všechna potřebná schemata. Jako typ databáze (database) zvolíme doporučenou Berkeley DB (bdb). Přípona (suffix) identifikující naši databázi bude dc=firma,dc=lokal, což odpovídá, jak je zvykem, jménu naší DNS domény firma.local. Administrátor se bude k LDAP serveru přihlasovat jako "uid=ldapadmin,dc=firma,dc=local" s heslem MojeLdapAdminHeslo. Vlastní databázi pak najdeme v adresáři /var/lib/ldap.

Server nastartujeme příkazem:

[root@srv-infra1 ~]# service ldap start

...jeho automatické spuštění po startu počítače zajistíme příkazem:

[root@srv-infra1 ~]# chkconfig ldap on

... a zkontrolujeme příkazem:

[root@srv-infra1 ~]# chkconfig --list | grep ldap
ldap    0:off   1:off   2:on    3:on    4:on    5:on    6:off

Vytvoření databáze

V úvodu jsem slíbil, že obsah databáze vyrobíme klikáním, pojďme tedy na to.

Spustíme LDAP editor (v mém případě JXplorer) a připojíme se k LDAP serveru.

JXplorer trošku nadává, protože v databázi nic není. Tím se nenecháme zastrašit a směle pokračujeme dál.

Vytvoříme nový objekt přímo pod uzlem local. Bude jím objekt dc=firma,dc=local třídy Organization a třídy dcObject. Nenechte se zmást tím, že v předchozím screenshotu je již teď tento objekt vidět. Pojmenovali jsme tak náš adresář v konfiguračním souboru. Žádná data vztahující se k tomuto uzlu zatím v adresáři nejsou.

Chytrý editor ještě automaticky přidá třídu top. Vyplníme povinný atribut o. Ostatní atributy můžeme ponechat prázdné.

Pod uzlem dc=firma,dc=local vytvoříme organizační jednotku ou=people,dc=firma,dc=local (objekt třídy organizationalUnit), kam budeme ukládat uživatelské účty. Žádné extra atributy vyplňovat nemusíme.

Analogicky vytvoříme organizační jednotku ou=groups,dc=firma,dc=local pro skupiny.

Struktura našeho DIT je hotova. Můžeme začít vytvářet uživatele a skupiny.

Vytvoření uživatelů a skupin

Pár pravidel

Před vlastním zakládáním účtů a skupin uděláme několik rozhodnutí ohledně designu naší databáze:

• UID 1 až 1 000 rezervujeme pro lokální uživatelské účty.
• GID 1 až 1 000 rezervujeme pro lokální skupiny.
• Pro uživatelské účty vyhradíme UID a 10 001 až 19 999.
• Pro skupiny uživatelů vyhradíme GID 20 001 až 29 999.
• Uživatelská jména budeme psát ve formátu jmeno_prijmeni (bez diakritiky). Uživatelská jména musí být samozřejmě unikátní. Pokud by se nám náhodou sešli dva uživatelé stejného jména, můžeme je rozlišit třeba číslicí na konci uživatelského jména.
• DN uživatelského účtu bude ve tvaru uid=*,ou=people,dc=firma,dc=local, kde atribut uid bude představovat uživatelské jméno.
• DN skupiny bude ve tvaru cn=*,ou=groups,dc=firma,dc=local, kde atribut cn bude představovat jméno skupiny.
• Do atributu cn uživatelského účtu budeme ukládat jméno a příjmení bez diakritiky.
• Do atributu sn uživatelského účtu budeme ukládat příjmení s diakritikou.
• Do atributu givenName uživatelského účtu budeme ukládat křestní jméno s diakritikou.
• Do atributu displayName uživatelského účtu budeme ukládat křestní jméno a příjmení s diakritikou.
• GID primární skupiny bude u všech uživatelů 20 0001 a bude patřit skupině firma_users, kterou za chvíli vytvoříme. Nepoužíváme koncept "user private group".

Uživatelské účty

Vytvoříme uživatelský účet pro uživatele Františka Hnipírda. Použijeme k tomu zmíněné třídy posixAccount a inetOrgPerson.

Vyplníme další povinné atributy cn, gidNumber, homeDirectory, uidNumber. Nepovinný atribut loginShell nastavíme na obligátní /bin/bash.

Aby mu v adresáři nebylo smutno, vytvoříme analogicky uživatelský účet i pro jeho kolegu Pepu Vosáhla.

Skupiny

Vytvoříme skupinu firma_users, jejímiž členy budou všichni uživatelé.

Dále vytvoříme skupiny vyroba a finance; jejich členy budou pouze uživatelé z odpovídajících podnikových útvarů.

Všiměte si, že členství ve skupině se zadává pomocí atributu memberUid. Tento atribut u objektu třídy posixGroup uvedeme tolikrát, kolik máme členů dané skupiny.

Přeci jenom dojde na LDIF

Celá naše databáze ve formátu LDIF vypadá takto:

# Organizace
dn: dc=firma,dc=local
objectClass: organization
objectClass: dcObject
objectClass: top
dc: firma
o: Firma

# Organizační jednotky
dn: ou=people,dc=firma,dc=local
objectClass: organizationalUnit
objectClass: top
ou: people

dn: ou=groups,dc=firma,dc=local
objectClass: organizationalUnit
objectClass: top
ou: groups

# Uživatelské účty
dn: uid=frantisek_hnipirdo,ou=people,dc=firma,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: person
objectClass: top
cn: Frantisek Hnipirdo
displayName:: RnJhbnRpxaFlayBIbmlww61yZG8=
gidNumber: 20001
givenName:: RnJhbnRpxaFlaw==
homeDirectory: /home/frantisek_hnipirdo
loginShell: /bin/bash
sn:: SG5pcMOtcmRv
uid: frantisek_hnipirdo
uidNumber: 10001

dn: uid=josef_vosahlo,ou=people,dc=firma,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: person
objectClass: top
cn: Josef Vosahlo
displayName:: Sm9zZWYgVm9zw6FobG8=
gidNumber: 20001
givenName: Josef
homeDirectory: /home/josef_vosahlo
loginShell: /bin/bash
sn:: Vm9zw6FobG8=
uid: josef_vosahlo
uidNumber: 10001

# Skupiny
dn: cn=firma_users,ou=groups,dc=firma,dc=local
objectClass: posixGroup
objectClass: top
cn: firma_users
gidNumber: 20001
memberUid: frantisek_hnipirdo
memberUid: josef_vosahlo

dn: cn=vyroba,ou=groups,dc=firma,dc=local
objectClass: posixGroup
objectClass: top
cn: vyroba
gidNumber: 20003
memberUid: frantisek_hnipirdo

dn: cn=finance,ou=groups,dc=firma,dc=local
objectClass: posixGroup
objectClass: top
cn: finance
gidNumber: 20002
memberUid: josef_vosahlo

Odskok do Kerbera

Pro oba pány vytvoříme také Kerberos principal. Spustíme utilitu kadmin.

[root@srv-infra1 ~]# kadmin -p krbadmin/admin@FIRMA.LOCAL
Authenticating as principal krbadmin/admin@FIRMA.LOCAL with password.
Password for krbadmin/admin@FIRMA.LOCAL:

Nyní se nacházíme v příkazové řádce kadmin. Principaly vytvoříme nám již známým příkazem addprinc.

kadmin: addprinc frantisek_hnipirdo
WARNING: no policy specified for frantisek_hnipirdo@FIRMA.LOCAL; defaulting to no policy
Enter password for principal "frantisek_hnipirdo@FIRMA.LOCAL":
Re-enter password for principal "frantisek_hnipirdo@FIRMA.LOCAL":
Principal "frantisek_hnipirdo@FIRMA.LOCAL" created. kadmin: addprinc josef_vosahlo
WARNING: no policy specified for josef_vosahlo@FIRMA.LOCAL; defaulting to no policy
Enter password for principal "josef_vosahlo@FIRMA.LOCAL":
Re-enter password for principal "josef_vosahlo@FIRMA.LOCAL":
Principal "josef_vosahlo@FIRMA.LOCAL" created.


Obsah databáze si pro kontrolu vypíšeme.

kadmin: listprincs
K/M@FIRMA.LOCAL
frantisek_hnipirdo@FIRMA.LOCAL
josef_vosahlo@FIRMA.LOCAL
kadmin/admin@FIRMA.LOCAL
kadmin/changepw@FIRMA.LOCAL
kadmin/history@FIRMA.LOCAL
kadmin/srv-infra1.firma.local@FIRMA.LOCAL
krbadmin/admin@FIRMA.LOCAL
krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
user0@FIRMA.LOCAL

Konfigurace klienta

Instalace softwaru

Nainstalujeme balíky:

• openldap-clients
• openldap
• libldap
• nss_ldap

Konfigurace

Konfigurací Name Service Switch v souboru /etc/nsswitch.conf se Linux se dá snadno přesvědčit, aby hledal informace o uživateli kromě lokálních souborů také v adresáři LDAP. Seznam zdrojů u položek passwd: a group: obohatíme o zdroj ldap.

# Soubor /etc/nsswitch.conf na stroji pc1.firma.local

passwd:         files ldap
shadow:         files
group:          files ldap

hosts:          files dns
networks:       files

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files

Samozřejmě musíme říct, na kterém serveru se adresář nachází. To provedeme v souboru /etc/ldap.conf.

# Soubor /etc/ldap.conf na stroji pc1.firma.local

host srv-infra1.firma.local
base dc=firma,dc=local


Než se uživatel bude moci přihlásit, musíme zajistit, aby měl na stroji, ke kterému se přihlašuje, domácí adresář. Adresář vytvoříme automaticky při prvním přihlášení uživatele pomocí PAM modulu pam_mkhomedir. Upravíme konfigurační soubor /etc/pam.d/system-auth.

# Soubor /etc/pam.d/system-auth na stroji pc1.firma.local

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     sufficient    pam_unix.so
account     required      pam_deny.so

password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    sufficient    pam_krb5.so
password    required      pam_deny.so

session     required      pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     required      pam_unix.so

Testování

Nyní můžeme vyzkoušet, zda náš klientský systém účty ze serveru vidí. Příkaz getent nám zobrazí v jednom výpisu jak lokální, tak síťové účty.

[root@pc1 ~]# getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/sh
...
user0:x:501:501::/home/user0:/bin/bash
frantisek_hnipirdo:*:10001:10001:Frantisek Hnipirdo:/home/frantisek_hnipirdo:/bin/bash
josef_vosahlo:*:10002:10002:Josef Vosahlo:/home/josef_vosahlo:/bin/bash

To samé můžeme provést pro skupiny.

[root@pc1 ~]# getent group
root:x:0:
bin:x:1:
...
user0:x:501:
firma_users:*:20001:frantisek_hnipirdo,josef_vosahlo
finance:*:20002:josef_vosahlo
vyroba:*:20003:frantisek_hnipirdo

Nebude na škodu, když zkontrolujeme, zda klient správně rozumí členství ve skupinách.

[root@pc1 ~]# groups frantisek_hnipirdo
frantisek_hnipirdo : firma_users vyroba [root@pc1 ~]# groups josef_vosahlo
josef_vosahlo : firma_users finance

Nyní se můžeme přihlásit např. jako uživatel josef_vosahlo k pc1.firma.local. Pokud se nám to povede, zkontrolujeme, zda jsme při přihlášení obdrželi TGT.

[josef_vosahlo@pc1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_10002_XuY3on
Default principal: josef_vosahlo@FIRMA.LOCAL

Valid starting     Expires            Service principal
04/20/08 19:44:25  04/21/08 05:44:25  krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
        renew until 04/21/08 19:42:59

Závěr

Uživatel se přihlásil. TGT dostal. Vše nám funguje tak, jak má. Příště si ukážeme, jak se přihlášený uživatel bez dalšího obtěžování dostane na jiný stroj v síti pomocí SSH. Pomůže mu v tom samozřejmě Kerberos. V dílech o souborových serverech s výhodou využijeme jednotných UID a GID v naší síti, která jsme právě získali nasazením LDAPu.

Seriál Centrální správa účtů a Single Sign-On (dílů: 8)

První díl: Centrální správa účtů a Single Sign-On v Linuxu, poslední díl: Kerberos a LDAP.
Předchozí díl: Kerberos: přihlašování snadno a rychle
Následující díl: Kerberos a SSO: služby - SSH

Diskuse k tomuto článku

[VSi]

Mám jen jeden dotaz:

Oba uživatelelé mají primární skupinu firma_users (GID=20001), tj. v LDAPu mají gidNumber: 20001:

# Uzivatele:

dn: uid=frantisek_hnipirdo,ou=people,dc=firma,dc=local
...
gidNumber: 20001

dn: uid=josef_vosahlo,ou=people,dc=firma,dc=local
...
gidNumber: 20001

V definici skupiny jsou oba účty opět explicitně vypsány v atributu memberUid:

# Skupina -- firma_users:

dn: cn=firma_users,ou=groups,dc=firma,dc=local
...
gidNumber: 20001
memberUid: frantisek_hnipirdo
memberUid: josef_vosahlo

Mám vyzkoušeno, že do primární skupiny uživatele není nutné přiřazovat pomocí memberUid, ale stačí atribut gidNumber u uživatele. Tedy alespoň v Debianu přes NSS to funguje (tj. přes groups josef_vosahlo i všude jinde). Má uvedená metoda nějaké výhody? Přijde mi, že pokud mám v jedné primární skupině třeba 200 uživatelů, pak je duplicitní je všechny uvádět jako "memberUid".

Jinak se těším na další díly seriálu. Bude zmíněna i integrace Kerbera s Windows?

[Mudrc]

Žádný zvláštní záměr v tom nehledejte - není tam.

Díl o integraci Kerbera a Windows zvažuji. Udělal jsem pár zajímavých pokusů. Pomocí lionuxového Kerberos serveru a lokálního účtu ve Windows se dá do Windows hezky přihlašovat. Je to analogické konfiguraci, kterou jsme popsal ve druhém díle. Otázkou zůstává, jak do těch Windows dostat informace o účtech z nějakého jiného zdroje, než je Active Directory. Moje naděje se upírají směrem k pGina, ale to jsme zatím blíže nezkoumal.

[jdobry]

Dostat ucty do Windows zcela urcite lze pomoci LDAP navazaneho na Sambu v rezimu PDC i bez Kerbera. Me to tak funguje.

[Mudrc]

Tento scénář je samozřejmě možný a funkční, ale trošku nezapadá do mojí koncepce. Nejsem si jist, zda uživatel při přihlášení na Windowsový stroj v doméně Samba v3 by dostal TGT. Vzhledem k tomu, že Samba v3 se jako DC chová spíše jako NT4, tak tipuji, že ne. Samba v4 je jiná věc.

Líbilo by se mi řešení, kde se server nepřizpůsobuje klientovi. Zvlášť, když klient není tak úplně "open" a musí se používat reverzní inženýrství.

[VSi]

Mám nasazenou Sambu v3 jako PDC pro cca 120 PC s Windows XP (funguje to naprosto bez problémů). Rád bych to rozšířil o Kerberos, hlavně kvůli SSO ověřování různých webových služeb nebo třeba IMAPu. Zatím to řeším přes NTLM a to není úplně ideální. Problém bude asi v tom, že Samba v3 je NT4-style doména u které s Kerberem není počítáno.

Vím, že to řeší Active Directory, ale do toho se mi nechce, protože stávající řešení je spolehlivé a dostačující.

Když jsem se díval na možnosti pGINA, tak se mi zdálo, že to řeší jen ověření hesla (analogie PAM v Linuxu), ale není to možné použít jako zdroj účtů (něco jako NSS). Jak jsem to pochopil, tak při úspěšném ověření hesla třeba na LDAPu se vytvoří lokální Windows účet, což se pro nějaké větší nasazení moc nehodí.

[Mudrc]

To jsem měl právě na mysli, že by se pGina mohla použít alespoň k automatickému vytvoření lokálního účtu, protože bez účtu se do Windows přihlásit nejde, přestože vás Windows úspěšně ověří proti MIT nebo Heimdal Kerberu, což ve Windows jde nakonfigurovat a dokonce to i funguje.

[timeos]

Mohli by ste sen hodit aspon jeden link s howto, ktory sa prave tejto kombinacii venuje? (Win + MIT Krb)

[Mudrc]

http://technet.microsoft.com/en-us/library/bb742433.aspx#EDAA

[Ondar]

Tedy já osobně nejsem příliš velký příznivce Windows, ale jedno se tomuto OS nedá upřít: Active Directory. Nic ani vzdáleně podobného zkrátka ve světe Unixu není. A přitom to není nic extra - jen LDAP databáze velmi elegantně provázaná s Kerberos a DNS. Bylo by škoda, kdybychom se tu zabývali takovými "vykopávkami" jako NTLM nebo NIS. Vždyť AD v nativním režimu 2007 již obsahuje Unixové atributy dle doporučení RFC2307! Co více si ještě přát?

Já bych si spíše přál vidět (a jsem schopen i v tomto smyslu s autorem tohoto bezva článku spolupracovat) návod jak donutit Linux aby autentikoval pomocí AD a z tohoto zdroje čerpal i ostatní informace (ostatní NIS mapy, mapy pro automounter, Kerberos service tickety pro služby jako SSH, Apache nebo NFSv4).

Přiznávám, že tohoto se nedá snadno dosáhnout jen za použití striktně opensource nástrojů, ale po letech zkušeností bych to ani nežádal - když to nebude extra drahé ale zato extrémně jednoduché na administraci a spolehlivé, tak proč ne.

[hubitch]

To by bylo super takhle sladit naši firemní AD síť se zbytkem *nixových služeb a prostředků - moc prosím o nakopávač

[Ondar]

Neco jsem vyplodil zde. Snad to bude nekomu k uzitku

[Kyosuke]

Nic ani vzdáleně podobného zkrátka ve světe Unixu není. A přitom to není nic extra - jen LDAP databáze velmi elegantně provázaná s Kerberos a DNS. Bylo by škoda, kdybychom se tu zabývali takovými "vykopávkami" jako NTLM nebo NIS. Vždyť AD v nativním režimu 2007 již obsahuje Unixové atributy dle doporučení RFC2307! Co více si ještě přát?

Možná mi něco uniká, ale LDAP, Kerberos i DNS na Linuxu koneckonců existují a viděl jsem pohromadě v síti, aniž by se do ní cpalo NTLM (nebyly tam žádné windowsí stroje), ani NIS (aneb k čemu NIS, když je LDAP). Tedy ne že by na nšco takového v tuhle chvíli bylo klikátko (to jo, k tomu by se někdo musel dokopat ), ale pořád ještě nevidím, proč by AD mělo tomu, co už (pravda - po kouskách ) máme, být tak strašně "vzdáleně nepodobné".

[Ondar]

Mno, to je sice pravda, že Linux si s DNS, Kerberosem i LDAP krásně rozumí, ale furt to bere jako na sobě nezávislé služby. Jinými slovy k tomu, abyste dostali něco podobného k AD, tak to musíte zvlášť nakonfigurovat a když třeba přidáváte uživatele, konfigurujete zvlášť Kerberos a zvlášť LDAP. K tomu je nutno hafo konfiguráků. AD si to pěkně drží v DNS takže koncové stanice už mnoho nepotřebují.
Taky nepotřebuji extra klikátko, ale na něco zkrátka šikne. Ale jak říkám, to je maličkost. Mě šlo o princip jak se všechny tyto služby v AD krásně doplňují.

[Kyosuke]

Díky. Já se v tomhle musím vzdělat , ale už docela dlouho je mi jasné, že domácí síť na hraní budu řešit opravdu hodně "po svém". Takže možná za pár měsíců budu mluvit jinak, až to poznám na vlastní kůži. Ale zrovna teď mě to začalo zajímat, tak je možné, že z toho i něco vyleze. Hmm, update: Teď se koukám na to, co společného má AD s DNS a možná tak úplně bezbolestný nebude. (Asi bych si měl v první řadě přečíst základní literaturu. )

[Mudrc]

Počkejte si na jeden z připravovaných dílů seriálu. Uvidíte, že ani pod Linuxem se klient příliš konfigurovat nemusí a vše potřebné o Kerberu a možná i o LDAPu si najde v DNS.

[Raduz]

Tedy já osobně nejsem příliš velký příznivce Windows, ale jedno se tomuto OS nedá upřít: Active Directory. Nic ani vzdáleně podobného zkrátka ve světe Unixu není.

eDirectory od Novellu potřebné nároky nesplňuje? To neni ironická otázka, ptám se z opravdového zájmu. Já ji teda používám přímo pod Netware pro běžné přihlašovaní uživatelů k fileserveru, takže to nejjednodušší možné nasazení, ale pokud vím, funguje i pro Linuxem (minimálně tedy pod Suse a Red Hatem), a co jsem zběžně viděl, podporuje i Kerberos. Ale mluvím jako člověk, který si jen přečetl seznam funkcí, a neměl zatím potřebu řešit to nějak do hloubky, tudíž nevím jak moc je to funkční.

[Ondar]

eDirectory od Novellu potřebné nároky nesplňuje?

Vím, že jak Suse, tak RedHat mají svůj (snad už společný) projekt odvozený od bývalého iPlanet LDAP serveru od Sunu, ale do jaké míry se jedná o podobně elegantní záležitost jako AD, to opravdu neumím říci, ale pochybuji.

[Raduz]

Pozor, eDirectory je něco jiného. Novell tomu původně říkal Novell Directory Services, a poprvé je uvedl s Netware 4.0, kde šlo o výrazný upgrade z klasické bindery uživatelské databáze v trojkovém Netware. Pak se z toho vyvinula značně komplexní záležitost pro identity management, který ale běžel primárně na Netware, a posléze i na Win. MS ve svě době vytvořil AD jako přímou odpověď právě na eDir. Poté co se Novell začal angažovat v OSS přeportoval eDir do Linuxu, a dnes je to pro něj primární platforma, a odvážil bych se tvrdit, že po stránce funkčnosti může eDirectory s Active Directory zdatně soutěžit, a to i na Linuxu, nebo tedy na podporovaných UNIX systémech obecně.

[Ondar]

Nevím, neznám. Rád se poučím

[Raduz]

http://www.novell.com/products/edirectory/

http://www.novell.com/products/edirectory/whitepapers.html

Ty whitepapers psal pochopitelně Novell, takže v porovnání s AD u nich vítězí eDir na celé čáře, ale co už by taky člověk měl čekat jiného Nicméně bych řekl, že Linux v něm má produkt který snese příme srovnání s Active Directory. Samozřejmě se nebavíme o open source, ale o komerčním řešení, ale to už je zase jiná pohádka.

[trekker.dk]

Uživatelská jména budeme psát ve formátu jmemo_prijmeni (bez diakritiky)

---

Škoda, že tenhle seriál vychází až teď, nedávno jsem se trápil s rozběháním LDAPu a tohle by mi hodně ušetřilo práci. (Naštěstí to bylo jenom ve vritualboxu a jenom cvičně)

[disorder]

mal si pogooglit, ja som nasiel pekne howto a bez preoblemov som sa v tom zorientoval

[trekker.dk]

To já něco našel taky a dokonce něco i tady, akorát to nebylo tak srozumitelné, jednoduché a přehledné jako tenhle článek. (I když přiznávám, že se mi možná trochu změnil úhel pohledu, protože o LDAPu teď už něco málo vím.)

[msk]

Tak napr ja som googlil 2 dni a nerozchodil som to. Vsade len nejake polonavody predpokladajuce ze clovek vie, co robi. O existencii schem som sa dozvedel len nedavno a o tom, ako prebieha autorizacia pomocou hesla ( napr. pre apache, ssh, imap ... ) nemam najmensiu potuchu... Trpezlivo ocakavam pokracovanie serialu, kde to uz snad konecne pochopim a rozchodim.

[disorder]

ano, s LDAP su tazke zaciatky, ale staci sa do toho kus ponorit, zaexperimentovat a da sa to pochopit

tie tvoje priklady, no neviem ci sa tu bude vysvetlovat nastavenie PAM... ale taky dovecot sa tiez da miesto PAM nastavit rovno na LDAP, ale je to trochu zbytocne :) a apache jedine cez modul, ten standardne pouziva len .htpasswd

[msk]

Snazime sa na firme rozchodit centralnu spravu uctov ( takze asi cez ldap ), pricom sa voci nemu musia dat overovat:

- apache

- trac

- ucty na unix serveroch

- samba pdc

Idealne by este bolo:

- svn ( to bude asi suvisiet s apache )

- imap

- jabber ucty

Mam strach, ze sa nam podari co len polovica z uvedenych technologii...

[disorder]

ten svn (apache), imap a jabber bude asi v pohode :) trac by sa cez apache mohol dat tiez, predpokladam, ze velmi podobnym sposobom, ja som si trac vyriesil zatial inak... posixAccount/shadowAccount je zaklad a so sambou nerobim, ale verim, ze je to caste pouzitie. ja som navyse k niektorym z vymenovanych dorabal malu schemu s par informaciami a smtp auth (cyrus sasl cez PAM). ale mas stastie, ze nechces mysql, lebo to zrejme tak skoro nepojde...

ja by som si dal ale pozor na imap (radsej povolit vyhradne imaps) a http (apache, trac), treba asi povytvarat samostatne accounty s roznymi heslami, lebo plaintext po sieti nie je velmi bezpecny :) pekne sa mi to ale hovori, ja som to takto (este) neriesil, kde sa da povinne sifrujem, inde umoznujem pouzivat aj ine heslo (len ten trac riesim mimo ldap)

[Karel Benák]

Skvěle napsané. Svého času jsem se taky pokoušel o něco podobného, ale je to vlastně už 5 let. Co se grafických LDAP klientů týče, nemůžu si vynachválit Apache Directory Studio.

[Peter Lehotsky]

nebo fedora directory server

[Peter Lehotsky]

V ubuntu/debianu jsou potrebne baliky:

aptitude install slapd libldap

/etc/ldap/slapd.conf se musi zmenit na:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

modulepath      /usr/lib/ldap
moduleload      back_bdb
backend         bdb
database        bdb

suffix          "dc=firma,dc=local"
rootdn          "uid=ldapadmin,dc=firma,dc=local"
rootpw          heslo

directory       /var/lib/ldap

Jxplorer nejde nainstalovat z binarniho instalatoru, musi se pouzit deploy balicek

wget http://surfnet.dl.sourceforge.net/sourceforge/jxplorer/JXv3.2deploy.tar.bz2

[leon]

Zdravím,

članek je pěkný a srozumitelný, nicméně opět jako většina zdrojů co se mi podařilo najít na internetu, nenaznačí jednoduchým způsobem nejpoužívanější existující schémata v inetorgperson.schema.

Pozn.: Kdo zodpoví otázku, proč nemůžeme použít pro uživateský účet samotnou třídu possixAccount dostane jedničku! mně naprosto dostala :)

LDAP chci použít pro autentizaci IMAP serveru a prostě si ho trochu osahat, nechci do něj hned překlápět systémové účty, ale jen virtuální. Filozofii, instalaci, základní konfiguraci a rozběhnutí jsem nastudoval a zvládl. Nicméně ve všech dalších návodech je prostě už jen přidávaní uživatelů a skupin, bez dalších informací o tom proč zrovna possixAccount a ne inetOrgPerson.

Myslím tím třeba jen základní obrázek těch schámat, aby to člověk začátečník nemusel studovat přímo z definice :)

Můžu tedy poprosit o nějaký odkaz na rozumný zdroj, který by mi umožnil odpovědět na uvedenou otázku? A prosím nechci odkaz na definici nebo normu toho schématu, zatím nechci jedničku, chci si udělat přehled, začít si hrát a k jedničce se dopracovat :)

Díky

[anon123]

Super clanek!

Akorad me zajima, jak kesovat ty kerberos prihlasovaci udaje? Kdyz se odpojim z netu, tak uz se neprihlasim. Poradi nekdo?

[LuděkS]

Dobrý den, chtěl jsem vyzkoušet JXplorer, ale nemohu vytvořit DIT ani přidat objekt:

Unable to read entry dc=firma,dc=local

Zkoušel jsem hledat řešení, změnit práva pro adresáře, ručně vytvořit soubory, ale vše marně.

Používám CentOS 5.1 64 bit.

Děkuji za pomoc.

 

[LuděkS]

Nepodařilo se mi přijít na to, kde byla chyba. Nakonec jsem musel vyrobit vlastní *.ldif soubor,
který jsem do ldapu nahrál pomocí příkazu:

/usr/bin/ldapadd -x -D 'uid=ldapadmin,dc=firma,dc=local' -W -f /etc/openldap/mujldifsoubor.ldif

Nejsem nadšený z toho, že jsem musel postupovat "oklikou",
ale nyní vše funguje jak má... (a třeba se to bude někomu hodit.. )

[Anino]

Keď som to skúšal, mal som takýto problém: Po zadaní

getent passwd

mi vypísalo všetky účty (aj z passwd aj z LDAP). Keď som ale zadal

getent passwd user0

kde user0 bol používateľ z LDAP, nevypísalo nič. Pes bol zakopaný v tom, že nscd (name service cache demon) mal neaktuálne informácie a bolo ho treba reštartovať. (Bol som jeleň z toho, prečo to tak blbne a nakoniec to luskol môj skvelý potomok.) Možno sa to niekomu bude hodiť :)