Kerberos a SSO: Jednotné účty v LDAP (diskuse)

[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ť :)