Kerberos a SSO: Samba

24. 7. 2008 | Jiří Mlíka | Bezpečnost | 13175×

Dnešní díl je o tom, jak si s Kerberem rozumí Samba. Ukážu vám, že si s ním rozumí docela dobře. Nakonfigurujeme si jednoduchý Samba server a pokusíme se k němu přistoupit pomocí linuxového i windowsového klienta. To vše samozřejmě s podporou SSO. Konfigurace Samby, kterou se vám chystám ukázat, je poněkud netypická a myslím, že i dost neznámá.

Obsah

• Úvod
• Konfigurace serveru
  • Instalace softwaru
  • Principal služby
  • Konfigurace Samby
• Konfigurace linuxového klienta
  • smbclient
  • Konqueror
  • Kerenelové VFS smbfs a cifs
    • Příklad použití z řádky
    • Příklad použití z GUI
  • Konfigurace Windows klienta
    • Základní systémová nastavení
    • Windows jako člen Kerberos realmu
      • Krok 1 - vytvoření principalu
      • Krok 2 - nastavení realmu ve Windows
      • Krok 3 - nastavení KDC ve Windows
      • Krok 4 - nastavení hesla principalu stroje
      • Krok 5 - restart
  • Přihlašování uživatelů do Windows pomocí Kerbera
    • Připojení vzdáleného souborového systému
  • Triky, které je dobré znát
    • Logování Kerberos operací ve Windows
    • Krátká versus dlouhá jména
• Závěr

Úvod

Dnešní díl je o tom, jak si s Kerberem rozumí Samba. Ukážu vám, že si s ním rozumí docela dobře. Nakonfigurujeme si jednoduchý Samba server a pokusíme se k němu přistoupit pomocí linuxového i windowsového klienta. To vše samozřejmě s podporou SSO. Konfigurace Samby, kterou se vám chystám ukázat, je poněkud netypická a myslím, že i dost neznámá.

Konfigurace serveru

Jako server použíjeme stroj srv-file1.firma.local, který již dobře posloužil v předchozím dílu jako souborový server NFS4. Kerbera máme na tomto stroji již nakonfigurovaného, takže si jeho "recyklováním" ušetříme práci.

Instalace softwaru

Instalace Samby je opravdu banální záležitost na každé moderní linuxové distribuci. Jeden příkaz je obvykle víc než dost. Nainstalovala se mi verze 3.0.24.

urpmi samba-server

Principal služby

Stejně jako v předchozích případech bude serverová strana služby potřebovat svůj vlastní principal (SPN - Service Principal Name). Vytvoříme principal cifs/srv-file1.firma.local nám dobře známým nástrojem kadmin. Principal vytvoříme s náhodným klíčem...

kadmin:  addprinc -randkey cifs/srv-file1.firma.local
WARNING: no policy specified for cifs/srv-file1.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "cifs/srv-file1.firma.local@FIRMA.LOCAL" created.
kadmin:

...a vyexportujeme jej do "keytabu" na stroji:

srv-file1.firma.local

kadmin:  ktadd cifs/srv-file1.firma.local
Entry for principal cifs/srv-file1.firma.local with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal cifs/srv-file1.firma.local with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.

Výsledný "keytab" vypadá následovně."

[root@srv-file1 ~]# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   4 nfs/srv-file1.firma.local@FIRMA.LOCAL (Triple DES cbc mode with HMAC/sha1) 
   4 nfs/srv-file1.firma.local@FIRMA.LOCAL (DES cbc mode with CRC-32) 
   3 cifs/srv-file1.firma.local@FIRMA.LOCAL (Triple DES cbc mode with HMAC/sha1)
   3 cifs/srv-file1.firma.local@FIRMA.LOCAL (DES cbc mode with CRC-32) 

Zde je třeba poznamenat, že Windows podporují šifrování RC4-HMAC se 128bitovým klíčem, DES-CBC-CRC a DES-CBC-MD5 s 56bitovým klíčem. Pro pokusy doporučuji používat DES-CBC-CRC.

Konfigurace Samby

Stroj srv-file1.firma.local je konfigurován proti Kerberos realmu FIRMA.LOCAL, Samba má v tomto realmu svůj principal. Stroj "zná" UNIXové identity (UID, GID) svých uživatelů z LDAPu přes NSS. Samba není členem žádné domény. Jedná se v podstatě o samostatný (stand alone) server v režimu "security = server". "NT Password Hash", který bývá obvykle uložen v lokálním souboru nebo v LDAP adresáři, se v této konfiguraci vůbec nepoužívá. Možné metody autentizace jsou tudíž omezeny pouze na Kerberos. Jiné ověřovací mechanizmy (např. NTLM) fungovat nebudou.

[global]
   security = user
   realm = FIRMA.LOCAL
   use kerberos keytab = yes
   use spnego = yes
   encrypt passwords = yes

   workgroup = FIRMA

   unix extensions = yes
   case sensitive = yes
   delete readonly = yes
   ea support = yes

   log file = /var/log/samba/%m.log
   max log size = 50
   log level = 1 auth:3

   map to guest = bad user

   printing = bsd

[cifs_share]
   path = /nfs4exports/data
   read only = no

Konfigurace linuxového klienta

Jako linuxového klienta použijeme opět stroj pc1.firma.loal, připravený v předchozích dílech seriálu. Stroj má již nakonfigurováno vše potřebné, co se týká podpory Kerbera a základních systémových nastavení.

smbclient

Řádkový klient SMB/CIFS klient smbclient není zrovna uživatelsky nejpohodlnější, ale za to je poměrně užitečný pro testování. Klient používá stejný konfigurační soubor /etc/smb.conf jako démony Samby. V našem případě není prakticky žádná konfigurace potřeba. Obešli bychom se i bez uvedeného konfiguračního souboru.

# Soubor /etc/samba/smb.conf na stroji pc1.firma.local

[global]
   workgroup = FIRMA

Abychom otestovali použití SSO, přihlásíme se nejprve jako uživatel frantisek_hnipirdo k počítači pc1.firma.local. Při procesu přihlášení ke klientskému počítači jsme získali TGT, tudíž se můžeme směle vrhnout na použití další kerberizované služby v naší pokusné síti. Parametr -k zajistí použití Kerberos autentizace, parametr -d 3 se postará o bohatší výstup pro případ, že bychom narazili na nějaký problém.

[frantisek_hnipirdo@pc1 ~]$ smbclient -k -d 3 //srv-file1.firma.local/cifs_share
lp_load: refreshing parameters
Initialising global parameters
params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
Processing section "[global]"
added interface ip=172.16.51.130 bcast=172.16.51.255 nmask=255.255.255.0
Client started (version 3.0.24).
resolve_lmhosts: Attempting lmhosts lookup for name srv-file1.firma.local<0x20>
resolve_wins: Attempting wins lookup for name srv-file1.firma.local<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name srv-file1.firma.local<0x20>
Connecting to 172.16.51.12 at port 445
Doing spnego session setup (blob length=114)
got OID=1 2 840 113554 1 2 2
got OID=1 2 840 48018 1 2 2
got OID=1 3 6 1 4 1 311 2 2 10
got principal=cifs/srv-file1.firma.local@FIRMA.LOCAL
Doing kerberos session setup
ads_cleanup_expired_creds: Ticket in ccache[FILE:/tmp/krb5cc_10001_hsWMH6] expiration Ne, 22 čen 2008 01:47:18 CEST
OS=[Unix] Server=[Samba 3.0.24]
dos_clean_name []
smb: \> 

Za povšimnutí stojí, že do "Kerberos credential cache" uživatele josef_hnipirdo přibyl ticket pro použití služby cifs na stroji srv-file1.firma.local. To odpovídá fungování Kerbera, jak bylo posáno v úvodu tohoto seriálu.

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

Valid starting     Expires            Service principal
06/21/08 15:47:18  06/22/08 01:47:18  krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
        renew until 06/22/08 15:47:18
06/21/08 15:47:35  06/22/08 01:47:18  cifs/srv-file1.firma.local@FIRMA.LOCAL
        renew until 06/22/08 15:47:18

Konqueror

Konqueror vám naservítruje vzdálená data ve formě uživatelsky výrazně příjemnější, než to dokáže smbclient. Žádnou zvlástní konfiguraci nevyžaduje. Jakmile máme TGT, stačí zadat použe URL ve tvaru smb://jméno_serveru/sdílení.

Kerenelové VFS smbfs a cifs

Daleko zajímavější je možnost vzdálený souborový systém "přimountovat". Proti použití řádkového klienta získáme možnost otevírat a editovat sdílené soubory bez nutnosti otravného kopírování mezi klientem a serverem. K zahození není ani možnost udržovat domácí adresáře uživatelů na souborovém serveru a připojovat je na klientském PC při přihlášení uživatele. V jádře existuje podpora pro dva různé virtuální souborové systémy smbfs a cifs. Tj. v jádře je podpora klienta realizována dvakrát. Virtuální souborový systém smbfs obsahuje podporu Kerbera, ale s cifs, který má smbfs nahradit, je to horší. Podpora Kerbera v cifs byla plánována někde kolem verze 1.48. Na stroji pc1.firma.local (kernel 2.6.17, cifs v. 1.43) toho ohledně cifs mnoho nevyzkoušíme, ale smbfs s Kerberos autentizací chodit bude. Co se týká cifs a Kerbera, tak ani na Mandrivě 2008.1 (kernel 2.6.24, cifs v. 1.52) jsem nebyl úspěšný. Zřejmě si budeme muset ještě počkat.

Příklad použití z řádky

Na následujícím příkladu ukážeme, jak uživatel josef_vosahlo připojí vzdálený souborový systém pomocí SSO. V domácím adresáři uživatele vytvoříme adresář pro připojení vzdáleného souborového systému. Nazvěme jej třeba "smbfs". Adresář musí být vlastněn uživatelem, který bude souborový systém připojovat.

[josef_vosahlo@pc1 ~]$ mkdir smbfs

Souborový systém připojíme příkazem smbmount. Parametr -o krb zajistí použití Kerberos autentizace.

[josef_vosahlo@pc1 ~]$ smbmount //srv-file1/cifs_share ./smbfs/ -o krb,debug=3
Warning: kerberos support will only work for samba servers
mount.smbfs started (version 3.0.24)
added interface ip=172.16.51.130 bcast=172.16.51.255 nmask=255.255.255.0
resolve_lmhosts: Attempting lmhosts lookup for name srv-file1<0x20>
resolve_wins: Attempting wins lookup for name srv-file1<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name srv-file1<0x20>
Connecting to 172.16.51.12 at port 445
Doing spnego session setup (blob length=114)
got OID=1 2 840 113554 1 2 2
got OID=1 2 840 48018 1 2 2
got OID=1 3 6 1 4 1 311 2 2 10
got principal=cifs/srv-file1.firma.local@FIRMA.LOCAL
Doing kerberos session setup
ads_cleanup_expired_creds: Ticket in ccache[FILE:/tmp/krb5cc_10002_CRxQxM] expiration Po, 23 ?en 2008 00:04:12 CEST

Pomocí příkazů mount a ls ověříme, že naše počínání bylo úspěšné.

[josef_vosahlo@pc1 ~]$ mount
...
//srv-file1/cifs_share on /home/josef_vosahlo/smbfs type smbfs (0)

[josef_vosahlo@pc1 ~]$ ls -l /home/josef_vosahlo/smbfs/
celkem 8
drwxr-xr-x 1 josef_vosahlo firma_users 4096 kv? 18 14:50 finance/
drwxr-xr-x 1 josef_vosahlo firma_users 4096 kv? 19 22:05 vyroba/

Příklad použití z GUI

To samé jako v předchozím příkladě lze provést pomocí šikovného programu Smb4K pohodlně z GUI. Nastavíme autentizaci pomocí Kerbera a použití smbfs (ne cifs).

...a po pár mrštných kliknutích se můžeme kochat výsledkem v Konqueroru.

Konfigurace Windows klienta

Když si hrajeme se Sambou, nevyhnutelně musí přijít řeč i na Windows. Můžeme použít Windows jako klienta pro takto nakonfigurovanou Sambu? Můžeme! Vytvoříme si nový testovací stroj pc3.firma.local s nainstalovanými Windows XP.

Základní systémová nastavení

V našem testovacím prostředí jsme dosud nezavedli DNS, musíme tedy i na Windows vyřešit překlad jmen na IP adresy pomocí lokálního souboru hosts.

# Soubor C:\WINDOWS\system32\drivers\etc\hosts na stroji pc3.firma.local

127.0.0.1		localhost
172.16.51.10	srv-infra1.firma.local	srv-infra1
172.16.51.12	srv-file1.firma.local 	srv-file1

Windows jako člen Kerberos realmu

Každý ví, že Windows mouhou být členem domény, ale ne každý ví, že Windows mohou být také členem Kerberos realmu. Zřejmě proto, protože pro druhou možnost neexistuje žádné "klikátko". Budeme postupovat podle návodu přímo od Microsoftu.

Krok 1 - vytvoření principalu

Vytvoříme pro náš Windows stroj principal host/pc3.firma.local opět pomocí nástroje kadmin. Principal vytvoříme s heslem, které si musíme pamatovat. Budeme jej potřebovat při konfiguraci Windows.

kadmin:  addprinc -e des-cbc-crc:normal -pw P@ssw0rd host/pc3.firma.local@FIRMA.LOCAL
WARNING: no policy specified for host/pc3.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "host/pc3.firma.local@FIRMA.LOCAL" created.

Krok 2 - nastavení realmu ve Windows

K nastavení Kerbera slouží ve Windows příkaz ksetup. Tento nástroj je součástí Windows Support Tools, jejichž instalační balík najdeme na instalačním CD Windows XP ve složce \Support\Tools. Support Tools jsem nainstaloval do složky C:\Program Files\Support Tools. Příkaz ksetup pochopitelně spouštíme pod účtem s administrátorským oprávněním. To, že jsou Windows členem realmu FIRNA.LOCAL, jim řekneme následujícím příkazem.

C:\Program Files\Support Tools>ksetup /setdomain FIRMA.LOCAL
Setting Dns Domain
NOTE: /SetDomain requires a reboot to take effect

Krok 3 - nastavení KDC ve Windows

Také musíme Windows sdělit, kde mají hledat KDC...

C:\Program Files\Support Tools>ksetup /addkdc FIRMA.LOCAL srv-infra1.firma.local

NOTE: /AddKdc requires a reboot to take effect on pre-SP1 Win2000 computers

Krok 4 - nastavení hesla principalu stroje

...a také heslo k principalu stroje zadané v kroku 1.

C:\Program Files\Support Tools>ksetup /setmachpassword P@ssw0rd
Setting computer password
NOTE: /SetMachPassword requires a reboot to take effect.

Krok 5 - restart

Restart samozřejmě nesmí chybět .

Přihlašování uživatelů do Windows pomocí Kerbera

Nyní máme Windows nastaveny tak, aby zvládly autentizaci uživatele pomocí Kerbera. Nicméně, uživatel se ještě přihlásit nemůže, neboť nemá žádný uživatelský účet. Windows si bohužel umějí vzít infomrace o uživatelských účtech pouze z řadiče domény, který nemáme, a naše Windows nejsou ani jako člen domény konfigurovány. Zbývají tedy pouze lokální účty. Následující konfigurace je v podstatě analogická ke konfiguraci klienta v 2. dílu seriálu. Windows umožňují vytvořit asociaci mezi principalem a lokálním uživatelským účtem. Můžeme buď vytvořit asociaci mezi konkrétním principalem a konkrétním lokálním účtem, nebo můžeme asociovat všechny principaly a lokální účty stejného jména. My si vybereme druhou variantu. Ke slovu přijde opět příkaz ksetup.

C:\Program Files\Support Tools>ksetup /mapuser * *

Příkazem ksetup bez parametrů lze prohlédnout aktuální konfiguraci Kerbera ve Windows.

C:\Program Files\Support Tools>ksetup
default realm = FIRMA.LOCAL (external)
FIRMA.LOCAL:
        kdc = srv-infra1.firma.local
        Realm Flags = 0x0 none
Mapping all users (*) to a local account by the same name (*).

Nyní zbývá vytvořit zmíněné lokální účty pro jednotlivé uživatele. Lokální uživatelský účet má pochopitelně také své heslo, ale to my využívat nechceme, proto jej nastavíme na něco pekelného, co uživatel nikdy neuhodne. Tím máme Windows nakonfigurované a můžeme začít směle experimentovat.

Připojení vzdáleného souborového systému

Přihlásíme se do Windows jako uživatel josef_vosahlo. Uživatel se autentizuje proti Kerberos realmu FIRMA.LOCAL.

Připojíme vzdálený souborový systém s UNC cestou \\srv-file1.firma.local\cifs_share jako jednotku Z:. Pokud jsem někde neudělali chybu, můžeme procházet disk vzdáleného serveru.

Triky, které je dobré znát

Logování Kerberos operací ve Windows

Hrát si s Kerberem na Windows nemusí být vždy úplně bez problémů. Důležité je vědět, jak Windows donutit logovat Kerberos operace. To hravě zajistí několik odvážných kliků v ďábelském nástroji regedit.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos]
"LogLevel"=dword:00000001
"KerbDebugLevel"=dword:c0000043
"LogToFile"=dword:00000001

Detailnější výpis můžeme mít, pokud nastavíme KerbDebugLevel na hodnotu ffffffff. Log najdeme v souboru C:\Windows\System32\lsass.log.

Krátká versus dlouhá jména

Řekněme, že používáme nástroj Místa v síti. Proklikáme celou dlouhou cestu Místa v síti\Celá síť\Síť Microsoft Windows, klikneme na náš server srv-file1 a posledním mocným klikem se snažíme otevřít složku cifs_share. Místo obsahu složky nás Windows odmění autentizačním dialogem.

To jsme sice v našem SSO prostředí nečekali, nicméně pokorně vyplníme přihlašovací údaje uživatele josef_vosahlo v bláhové naději, že toto snažení nebude marné. Samozřejmě marné je. Proč? Odpověď najdeme v logu našeho KDC (/var/log/kerberos/krb5kdc.log).

...
Jul 17 02:20:44 srv-infra1.firma.local krb5kdc[2977](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 172.16.51.133: ISSUE: authtime 1216254044, etypes {rep=3 tkt=16 ses=1}, josef_vosahlo@FIRMA.LOCAL for krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
Jul 17 02:20:44 srv-infra1.firma.local krb5kdc[2977](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 172.16.51.133: UNKNOWN_SERVER: authtime 1216254044,  josef_vosahlo@FIRMA.LOCAL for cifs/srv-file1@FIRMA.LOCAL, Server not found in Kerberos database
...

Zdá se, že při "klikání na ikony počítačů" Windows XP pracují s krátkým jménem počítače. Principaly v databázi Kerbera mají na pozici instance plné doménové jméno počítače, není tedy divu, že principal služby v zadaném tvaru nemůže být v databázi nalezen. Pokud v adresním řádku zadáme plné doménové jméno serveru, vše funguje správně.

Závěr

V dnešním dílu jsem od Linuxu zabrousil poněkud k Windows. Doufám, že se na mě nebudou čtenáři zlobit. Činil jsem tak ve snaze po nalezení Svatého grálu naprosté a ničím nerušené interoperability a kompatibility mezi operačními systémy dneška. V příštím dílu seriálu si budeme povídat o webových službách. Ukážeme si, jak si s Kerberem rozumí Apache, Firefox, Konqueror a Internet Explorer ;-).

       

Komentáře

[VSi]

Díky za skvělé pokračování seriálu, takové shrnutí konfigurace všech služeb jsem nenalezl ani v angličtině.

Pokud se Samba nastaví jako v článku, je možné používat současně i klasické ověřování pro klienty bez Kerbera?

Měl bych jeden dotaz. Nezkoušel někdo, jestli ksetup /mapuser * * funguje i na uživatele z NT4 domény (Samba PDC). Mám Samba PDC, což funguje bezvadně a takhle by se to dalo "bezbolestně" rozšířit o Kerberos. (Samozřejmě vím o Active Directory.)

[.]

Uf, už sem ani nedoufal, že se objeví pokračování. Po hodně dlouhé době konečně nějaký pořádný a užitečný seriál. Díky autore, máš můj obdiv. Hned to jdu zkoušet :)

[Drom]

+1 Ale vyzkousim to az za par dni :)

[Marek]

Ano, diky za vyborny clanek ... ale neco jednodussiho by nebylo?

eM

[gnome-hater]

co třeba AD od MS? :)

[xindl]

Náš administrátor shledal tento komentář závadným.

vulgární

Zobrazit komentář

[Voty]

Ten ksetup.exe, znamena to, ze i Windows XP Home by se dalo zridit SSO? To by ale nebylo vubec marne. To budu muset jeste dneska vyzkouset, asi se opet nevyspim.

[Jirka]

IMHO ne, protože Home nepřipojíš do domény.

[kralyk z abclinuxu]

v clanku by melo byt
s/KDC ce Windows/KDC ve Windows, neni liz pravda?

[Robert Krátký]

Dík, opraveno.

[Kyosuke]

Author for president! Z toho by se měl napsat manuál.

[.]

Ještě dotaz: jak je to s Vistamy? Máte nějaké zkušenosti, lze je přiohnout aby používaly kerberos?

[Palo]

Este moje skusenosti s touto bestion (windows): Vzdy si ksetup stiahnite poslednu verziu. Na niektorych strojoch sa neinstaluju fixpaky (rozne dovody) a starsie ksetup maju problemy s lustenim klucov. Zadavate spravne heslo a on ho nevie rozlusknut.

A snad uz iba jedna bezpecnostna, kluce neprenasajte po sieti. Radsej si ich kopnite na USB kluc a preneste do cieloveho pocitaca. To je vhodne pre hostile podmienky beznej pocitacovej firmy nikdy neviete kto kde nacuva.

[maker007]

Nevím ale skutečnost, že musím vytvářet lokální účty stejného jména dělá tuto metodu nepoužitelnou ve firemním prostředí. Nedokážu si představit, že budu při každém přidání uživatele obíhat všechny počítače a vytvářet lokální účty. Jestli windows neumí vytvořit ten lokální účet automaticky tak to je na nic. Zrovna tak uživatele nepochopí proč se nemůžou doklikat ke serveru v okolních počítačích.

[ZiGi]

lokany ucet sa moze vytvorit aj sam, pri prihlaseni. ak pouzivatelia nahodne pristupuju ku vsetkym pocitacom v realme, postrupne budu mat vsade lokalne ucty. skoda, ze nefunguju roaming profiles.

[Drom]

Cestovni profily jsou pro bezny uzivatele celkem nepouzitelny. Cekani na stazeni dat, kde nekolik giga delaji zabavny videa a tak, to se clovek taky prihlasi treba za dve minuty :) A ne, nepomuze, kdyz lidem reknete, ze si to maji ukladat na nejakej sitovej disk, aby se to netahalo s profilem.

[Kyosuke]

Tyhle věci nejdou zakázat? Já myslel, že i normální síťové domovské složky na SMB/CIFS se dají vytvářet.

[Marv-CZ]

To řeším jednoduše tak, že nastavím "Dokumenty" na síťový disk.

[spes]

Zajimalo by me jak zajistit, aby se lokalni ucet vytvoril sam.

[DNA]

super článek, jen ten lokalizovaný shell to kazí otazníky (i proto nepoužívám lokalizaci)...