abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 0
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 3
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
7.12. 04:44 | Komunita

Virtualizační nástroj GNOME Boxy ve Fedoře 27 umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vývojová verze GNOME Boxy již umožňuje jednoduše stáhnout a nainstalovat další linuxové distribuce. Ukázka na YouTube. Seznam distribucí a jejich verze, nastavení a cesty k ISO obrazům je udržován v knihovně a databázi libosinfo (GitLab).

Ladislav Hagara | Komentářů: 0
7.12. 03:33 | Nová verze

Google Chrome 63 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 63.0.3239.84 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 37 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 10
6.12. 22:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 147. brněnský sraz, který proběhne v pátek 15. prosince od 18:00 hodin v restauraci Severka na rohu Tučkové a Zahradníkové.

Ladislav Hagara | Komentářů: 0
6.12. 22:33 | Komunita

V roce 2013 byl představen projekt Debsources, jehož cílem bylo a je poskytnout webové rozhraní ke zdrojovým kódům balíčků obsažených v Debianu. Projekt doteď běžel na doméně debian.net. Dnes bylo oznámeno, že projekt byl přesunut na oficiální infrastrukturu Debianu. Služba Debian Sources nově běží na doméně debian.org. V plánů je řada vylepšení. Již dnes je ke službě k dispozici API a procházet lze také patche a licence.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 950 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Kerberos a LDAP

    24. 9. 2008 | Jiří Mlíka | Bezpečnost | 12660×

    V dalším pokračování seriálu si budeme povídat o kerberizaci LDAP serveru OpenLDAP. V úvodu rozebereme, k čemu je dobrá podpora Kerbera u služby LDAP. Následně si ukážeme vlastní konfiguraci.

    Obsah

    Úvod

    link

    K čemu je vlastně podpora Kerbera v LDAP serveru dobrá? Sledujeme tím dva různé cíle. Prvním cílem je umožnit Kerberos autentizaci uživatele při přístupu k LDAP serveru včetně SSO. Tzn. chce-li uživatel z LDAP serveru data číst nebo je do něj zapisovat, budeme před takovou operaci zřejmě vyžadovat autentizaci. Nazvěme tento cíl kerberizací LDAP serveru.

    Druhým cílem je umožnit autentizaci uživatele pomocí jména a hesla (simple bind), pokud z nějakého důvodu nemůže Kerberos autentizaci použít a zároveň umožnit fungování populárního autentizačního mechanismu založeného na ověření uživatelského jména a hesla pomocí LDAP serveru (právě pomocí operace simple bind). Tento mechanismus používá např. PAM modul pam_ldap nebo autentizační modul Apache mod_auth_ldap a spousta dalších aplikací.

    Není-li nasazen Kerberos, jsou hesla uživatelů obvykle uložena v LDAP serveru, a tudíž je LDAP server dokáže pro autentizaci použít. Jak to však udělat v případě, kdy autentizaci obstarává Kerberos a LDAP server žádná hesla nezná? Nazvěme tento cíl delegováním autentizace na Kerberos.

    Jako server a klient nám poslouží naši staří známí stroje srv-infra1.firma.local a pc1.firma.local, perfektně nakonfigurované v předchozích dílech seriálu.

    Kerberizace LDAP serveru

    link

    Jak to funguje

    link

    Scénář fungování je stejný jako u jiných kerberizovaných služeb. Autentizovaný klient (uživatel), který již obdržel TGT, požádá TGS o tiket pro použití služby LDAP, s jehož pomocí se prokáže LDAP serveru. Pokud uživatel nemá možnost získat TGT a tiket služby LDAP, má smůlu a ke službě se nepřihlásí.

    Háček je v tom, že protokol LDAP nepodporuje Kerbera přímo. Spoléhá na Simple Authentication and Security Layer (zkráceně SASL). Obávám se, že bych se dopustil hrubých nepřesností, kdybych se pokoušel popsat SASL vlastními slovy. Pomohu si proto definicí z Wikipedie:

    SASL je autentizační framework pro použití v komunikačních protokolech, který vyděluje autentizační mechanizmus z aplikačního protokolu. Teoreticky je možné, aby jakýkoliv aplikační protokol, který používá SASL, používal libovolný autentizační mechanismus, který SASL podporuje...

    Více o této problematice OpenLDAP versus SASL naleznete na openldap.org.

    Konfigurace serveru

    link

    Instalace softwaru

    link

    V OpenLDAP řeší podporu SASL použitím knihovny libsasl2 pocházející z projektu Cyrus. Cyrus SASL řeší podporu jednotlivých autentizačních mechanizmů formou zásuvných (plug-in) modulů. Podporu Kerbera v SASL zajistíme doinstalováním knihovny (plug-inu) libsasl2-plug-gssapi.

    Na své Mandrivě mám tedy nainstalovány tyto balíky:

    • libsasl2-2.1.22-21mdv2007.1
    • libsasl2-plug-gssapi-2.1.22-21mdv2007.1

    Principal služby

    link

    Vytvoření principalu služby LDAP pomocí nástroje kadmin je pro nás již rutina. Služba se jmenuje ldap a běží na stroji srv-infra1.firma.local tudíž její principal bude ldap/srv-infra1.firma.local.

    kadmin: addprinc -randkey ldap/srv-infra1.firma.local

    Otázkou je, kam uložit klíč principalu, aby byl pro démona služby LDAP (slapd) čitelný. Na Mandrivě běží démon LDAP serveru slapd pod uživatelem ldap. Systémový keytab (/etc/krb5.keytab) je čitelný pouze pro uživatele root. Exportujeme tedy klíč principalu ldap/srv-infra1.firma.local do keytabu přístupného pro slapd (/etc/openldap/ldap.keytab):

    kadmin: ktadd -k /etc/openldap/ldap.keytab ldap/srv-infra1.firma.local

    Keytab má být čitelný pouze pro slapd:

    chown root:ldap /etc/openldap/ldap.keytab
    chmod 640 /etc/openldap/ldap.keytab

    Ještě musíme přesvědčit démona slapd, aby klíč principalu v tomto souboru hledal. Démon se řídí proměnnou prostředí KRB5_KTNAME. Na Mandrivě je slapd startován skriptem /etc/init.d/ldap, který "includuje" soubor /etc/sysconfig/ldap. Ten soubor je de facto konfigurační. Nepřišel jsem na lepší místo, kde bych měl danou proměnnou nastavit, aniž bych musel pozměnit samotný startovací skript. Do souboru /etc/sysconfig/ldap jsem tedy přidal následující řádku:

    export KRB5_KTNAME=/etc/openldap/ldap.keytab

    Samozřejmě slapd je vhodné po těchto konfiguračních změnách restartovat:

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

    Konfigurace klienta

    link

    Instalace softwaru

    link

    Stejně jako u serveru i na klientu potřebujeme knihovny libsasl2 a libsasl2-plug-gssapi.

    Klientský software

    link

    Pro testování budeme používat nástroj ldapwhoami - standardní součást balíku openldap-clients nainstalovaného v dílu Kerberos a SSO: Jednotné účty v LDAP. Tyto programy používají konfigurační soubor /etc/openldap/ldap.conf (nezaměňovat s /etc/ldap.conf, který používá nss_ldap).

    # Soubor /etc/openldap/ldap.conf na stroji pc1.firma.local
    
    base    dc=firma,dc=local
    host    srv-infra1.firma.local
    

    Testování

    link

    Nejprve ověříme, zda LDAP server podporuje autentizační mechanismus Kerberos, příkazem:

    [josef_vosahlo@pc1 ~]$ ldapsearch -H ldap://srv-infra1.firma.local -x -b "" -s base -LLL supportedSASLMechanisms
    dn:
    supportedSASLMechanisms: GSSAPI

    Zdá se, že podpora Kerbera funguje. Při přihlášeni na stroji pc1.firma.local jako uživatel josef_vosahlo jsme získali TGT. Příkazem ldapwhoami se zeptáme LDAP serveru, jak nás autentizuje.

    [josef_vosahlo@pc1 ~]$ ldapwhoami
    SASL/GSSAPI authentication started
    SASL username: josef_vosahlo@FIRMA.LOCAL
    SASL SSF: 56
    SASL installing layers
    dn:uid=josef_vosahlo,cn=gssapi,cn=auth
    Result: Success (0)

    Z výstupu je zřejmé, že autentizace pomocí Kerbera proběhla úspěšně. Dále vidíme, že LDAP server v současné konfiguraci identifikuje uživatele pomocí distinguished name ze jmenného prostoru SASL dn:uid=josef_vosahlo,cn=gssapi,cn=auth, a ne ze jmenného prostoru LDAP stromu. LDAP server si zatím neumí spojit tuto identitu uživatele s objektem představujícím uživatelský účet v LDAP stromu dn:uid=josef_vosahlo,ou=people,dc=firma,dc=local. Co to má za následek? Řekněme například, že jsme vytvořili ACL, které dovoluje uživateli změnit své soukromé telefonní číslo uložené v LDAP stromu v atributu homePhone. Uživatel přihlášený pomocí Kerbera, tj. např. jako dn:uid=josef_vosahlo,cn=gssapi,cn=auth, by v takovém případě nebyl schopen tomuto ACL vyhovět a příslušný atribut změnit. Řešením tohoto problému je mapování identit ze jmenného prostoru SASL na identity ze jmenného prostoru LDAPu.

    Mapování identit

    link

    Konfigurace serveru

    link

    Mapování identit provedeme příkazem authz-regexp v konfiguračním souboru LDAP serveru /etc/openldap/slapd.conf. Regulární výraz nejprve extrahuje uživatelské jméno z distinguished name ve jmenném prostoru SASL. To následně vložíme do distinguished name odpovídajícímu umístění uživatelských účtů ve struktuře našeho DIT. Tím vznikne výsledné distinguished name ve jmenném prostoru LDAPu.

    Pozn.: OpenLDAP umožňuje mimo uvedeného přímého mapování také mapování vyhledáváním. Extrahované uživatelské jméno se vloží do LDAP filtru, jehož výsledek je výsledkem mapování.

    Všimněte si také ACL, která se nám budou hodit při testování.

    # 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
    loglevel        64 
    
    database        bdb
    suffix          "dc=firma,dc=local"
    rootdn          "uid=ldapadmin,dc=firma,dc=local"
    rootpw          heslo
    
    directory       /var/lib/ldap
    
    password-hash   {CLEARTEXT}
    
    
    authz-regexp
            uid=([^,]*),cn=gssapi,cn=auth
            uid=$1,ou=people,dc=firma,dc=local
    
    
    ### ACL####
    #
    # (1) uzivatel muze zmenit sve tel. cislo, ostatni jej mohou jen cist
    access to attrs=homePhone
             by self write
             by * read
    #
    # (2) vsichni mohou cist vsechno
    access to *
            by * read
    

    Testování

    link

    Testování provedeme příkazem ldapwhoami. Nyní LDAP server správně interpretuje identitu uživatele autentizovaného pomocí Kerbera.

    [josef_vosahlo@pc1 ~]$ ldapwhoami
    SASL/GSSAPI authentication started
    SASL username: josef_vosahlo@FIRMA.LOCAL
    SASL SSF: 56
    SASL installing layers
    dn:uid=josef_vosahlo,ou=people,dc=firma,dc=local
    Result: Success (0)

    Následujícím příkazem můžeme vyzkoušet, zda se uživateli podaří změnit své domácí telefonní číslo uložené v LDAPu:

    [josef_vosahlo@pc1 ~]$ ldapmodify -f josef_vosahlo-homePhone.txt
    SASL/GSSAPI authentication started
    SASL username: josef_vosahlo@FIRMA.LOCAL
    SASL SSF: 56
    SASL installing layers
    modifying entry "uid=josef_vosahlo,ou=people,dc=firma,dc=local"

    Kde josef_vosahlo-homePhone.txt je jméno souboru s následujícím obsahem:

    dn: uid=josef_vosahlo,ou=people,dc=firma,dc=local
    changetype: modify
    replace: homePhone
    homePhone: +420777777777

    Delegování autentizace

    link

    Jak to funguje

    link

    Uživatel josef_vosahlo předá při přihlášení k LDAP serveru své distinguished name dn:uid=josef_vosahlo,ou=people,dc=firma,dc=local a heslo v textové podobě (operace"simple bind"). LDAP server se podívá do atributu userPassword. Pokud v něm najde něco jako {SASL}josef_vosahlo@FIRMA.LOCAL, použije tzv. "pass-through" autentizaci, tzn. deleguje provedení autentizace na SASL voláním funkce sasl_checkpass z knihovny libsasl2. Jako uživatelské jméno se v dalším zpracování použije řetězec za závorkou {SASL}, tedy josef_vosahlo@FIRMA.LOCAL.

    Nyní záleží na konfiguraci knihovny, jak si dále s ověřením hesla poradí. V našem případě použije démona saslauthd, který ověří heslo pomocí Kerbera případně jiného podporovaného mechanismu. Pěkně zamotané, že?

    Více o problematice pass-through autentizace v OpenLDAPu naleznete opět na openldap.org.

    Konfigurace

    link

    Instalace softwaru

    link

    Démon saslauthd je obsažen v balíku cyrus-sasl.

    SASL

    link

    Na mojí Mandrivě je konfigurace knihovny SASL uložena v adresáři /etc/sasl2/, ale často se můžete setkat s konfigurací uloženou v adresáři /usr/lib/sasl2/. Chování knihovny SASL lze konfigurovat pro každý volající program zvlášť. Chceme-li tedy konfigurovat chování knihovny pro proces slapd, vytvoříme v konfiguračním adresáři soubor slapd.conf. Tento soubor nemá absolutně nic společného s konfiguračním souborem LDAP serveru /etc/openldap/slapd.conf. Nenechte se tím zmást.

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

    pwcheck_method: saslauthd
    saslauthd_path: /var/lib/sasl2/mux

    Parametr pwcheck_method říká, že bude pro ověření hesla použit démon saslauthd, a parametr saslauthd_path ukazuje cestu k soketu, přes který se s démonem komunikuje.

    saslauthd

    link

    Démon saslauthd potřebuje vědět, které autentizační mechanizmy může pro ověření hesla použít. Podporuje jich více. My chceme použít Kerberos. Na Mandrivě tak učiníme pomocí konfiguračního souboru /etc/sysconfig/saslauthd.

    # Soubor /etc/sysconfig/saslauthd na stroji srv-infra1.firma.local

    SASL_AUTHMECH=kerberos5
    ...

    Ke svému fungování démon saslauthd dále potřebuje principal stroje, na němž běží, a příslušný klíč. Principal stroje vytvoříme opět nástrojem kadmin:

    kadmin.local: addprinc -randkey host/srv-infra1.firma.local

    Saslauthd běží na mé distribuci pod uživatelem root a principal stroje hledá v systémovém keytabu, kam klíč principalu exportujeme:

    kadmin.local: ktadd host/srv-infra1.firma.local

    Démona saslauthd nastartujeme případně restartujeme:

    [root@srv-infra1 ~]# service saslauthd restart

    Je pochopitelně zapotřebí, aby se démon startoval automaticky po startu počítače, stejně jako ostatní služby nezbytné pro správné fungování našeho prostředí:

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

    Atribut userPassword

    link

    Zbývá nastavit atribut userPassword. Můžeme použít příkaz ldapmodify nebo, pokud jako já rádi klikáte, nějaký grafický LDAP editor. Výsledek by měl vypadat následovně:

    dn: uid=josef_vosahlo,ou=people,dc=firma,dc=local
    cn: Josef Vosahlo
    gidNumber: 20001
    givenName: Josef
    homeDirectory: /home/josef_vosahlo
    loginShell: /bin/bash
    objectClass: inetOrgPerson
    objectClass: organizationalPerson
    objectClass: posixAccount
    objectClass: person
    objectClass: top
    sn:: Vm9zw6FobG8=
    uid: josef_vosahlo
    displayName:: Sm9zZWYgVm9zw6FobG8=
    uidNumber: 10002
    userPassword: {SASL}josef_vosahlo@FIRMA.LOCAL
    homePhone: +420777777777

    Testování

    link

    Správnou funkci otestujeme opět příkazem ldapwhoami. Parametr -x vynutí (simple bind) autentizaci pomocí hesla. Přihlašujeme se jako uid=josef_vosahlo,ou=people,dc=firma,dc=local (parametr -D). Parametr -W zajistí zobrazení výzvy k zadání hesla.

    [josef_vosahlo@pc1 ~]$ ldapwhoami -x -D "uid=josef_vosahlo,ou=people,dc=firma,dc=local" -W
    Enter LDAP Password:
    dn:uid=josef_vosahlo,ou=people,dc=firma,dc=local
    Result: Success (0)

    Závěr

    link

    Ukázali jsme si, jak integrovat LDAP server s Kerberem. Jedná se o komplexní problematiku. Poskládat všechny střípky mozaiky a pochopit vazby mezi jednotlivými komponenty není vůbec snadné. Informace na Internetu jsou často neúplné a zavádějící. Dokonalé HOWTO se mi najít nepodařilo. Nyní máme autentizační infrastrukturu kompletní. Můžeme v naší pokusné síti použít autentizaci uživatelů jak pomocí Kerbera, tak pomocí LDAPu a samotný LDAP je kerberizovanou službou. Máme stále pouze jednu databázi hesel, kterou spravuje Kerberos. Pokud bychom chtěli opravdu použít LDAP jako autentizační službu, museli bychom samozřejmě z důvodu bezpečnosti zatáhnout do celé věci ještě SSL/TSL, neboť hesla jsou při simple bind autentizaci přenášena "po drátech" v čitelné podobě.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    24.9.2008 09:28 ch-in-A
    Rozbalit Rozbalit vše Re: Kerberos a LDAP
    velmi hodnotny clanek. cela serie je perfektni!
    diky!
    xkucf03 avatar 24.9.2008 23:28 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Kerberos a LDAP
    Seriál je skvělý, klidně by vydal i na knihu.

    Akorát ohledně Kerbera mám některé pochybnosti. Nevíte někdo, jestli existuje podobný systém, který by ale na rozdíl od něj byl založen na asymetrickém šifrování/podepisování?
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    24.9.2008 16:22 Ondar
    Rozbalit Rozbalit vše Active Directory
    ondrejv@ara ~]$ ldapsearch -H ldap://polaris -x -b "" -s base -LLL supportedSASLMechanisms
    dn:
    supportedSASLMechanisms: GSSAPI
    supportedSASLMechanisms: GSS-SPNEGO
    supportedSASLMechanisms: EXTERNAL
    supportedSASLMechanisms: DIGEST-MD5

    Polaris je muj radic Active Directory domeny. To by me tedy veru zajimalo, jestli by to slo rozchodit i proti AD. Minimalne s zadnym mapovanim identit by tam nemel byt problem....
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.