OpenAFS – administrátorské a uživatelské identity

28. 12. 2011 | Michal Švamberg

Články - OpenAFS – administrátorské a uživatelské identity  

Tentokrát se zaměříme na vazbu AFS a Kerberos, kterou jsme zatím bez většího vysvětlení používali od prvních dílů. Vytvoříme si identitu pro vlastního administrátora, protože sdílení administrátorských účtů není vhodná praxe ani v malých organizacích.

Obsah

• Vazba na Kerberos
• Nový administrátor
• Nový uživatel
• Nastavení principalů v AFS
• Závěr

Vazba na Kerberos

Pokud chceme založit nového uživatele, musíme to udělat na dvou místech. Zavést uživatele do KDC (Key Distribution Center, v našem případě Kerbera) a nastavit mu v něm heslo. Tím je v databázi KDC vytvořeno sdílené tajemství mezi uživatelem a KDC, které je později používáno pro účely autentizace (vytváření lístků, ...).

Dále si musíme vytvořit záznam v PRDB (Protection Data Base). Vazba mezi  jednotlivými databázemi je tvořena automaticky na základě shody jména uživatele (principalu) a důvěry mezi AFS servery a KDC. Důvěru mezi nimi jsme zařídili při instalaci buňky ve druhém díle, a to příkazem asetkey, který přejal klíč z Kerberos keytabu do AFS KeyFile, ten najdete v /etc/openafs/server/KeyFile.

Zkontrolovat si to můžete příkazy (druhý příkaz vyžaduje oprávnění root):

~$ bos listkeys afssrv.foo.bar
key 2 has cksum 1976585079
Keys last changed on Tue Feb 22 17:17:19 2011.
All done.

~# klist -k /var/lib/krb5kdc/keytab.afs -e
Keytab name: WRFILE:/var/lib/krb5kdc/keytab.afs
KVNO Principal
---- --------------------------------------------------------------------------
   2 afs/foo.bar@FOO.BAR (DES cbc mode with CRC-32) 

Avšak soubor keytab.afs jsme použili pouze jako prostředek pro výměnu klíčů při instalaci. Ve skutečnosti se musíme podívat do databáze Kerbera, kde zjistíme aktuální informace o používaném klíči. Prozatím opět zneužijeme privilegia uživatele root:

~# kadmin.local -p spravce/admin -q "getprinc afs/foo.bar"
getprinc afs/foo.bar
Principal: afs/foo.bar@FOO.BAR
Expiration date: [never]
Last password change: Tue Feb 22 16:01:02 CET 2011
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Feb 22 16:01:02 CET 2011 (spravce/admin@FOO.BAR)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

Zde vidíme informace o principalu afs/foo.bar@FOO.BAR (služba AFS), jehož klíč (de facto heslo) jsme uložili do keytab.afs, abychom ho mohli do AFS naimportovat příkazem asetkey. Pro nás je důležité, že odpovídají čísla klíčů a jsou ve správném šifrování, které umí OpenAFS. AFS tak má k dispozici klíč, kterým dokáže ověřit, že token vytvořený z lístku pro službu afs/foo.bar@FOO.BAR není nějaký podvrh. Celá záležitost s protokolem Kerberos je trochu zamotanější, ale pro naše potřeby to stačí, méně náročným lze doporučit Frantu a jeho krabice, ostatním už jedině dokumentaci prokolu Kerberos.

Je doporučení, že jednou za čas byste klíč měli vyměnit. To znamená celou operaci zopakovat a výsledný /etc/openafs/server/KeyFile ručně rozkopírovat na všechny vaše servery. Důvodem je slabost šifry DES (kterou dnes lze prolomit do jednoho dne), ale jiné šifrování zatím OpenAFS nepodporuje.

Nový administrátor

Po odbočce k protokolu Kerberos si založíme jednoho administrátora, abychom jím pak mohli vytvářet uživatele. V systému se rozlišují 4 základní typy principalů: administrátoři, uživatelé, počítače (host) a služby. Je vhodné je rozlišovat, protože v databázi KDC se používají tzv. politiky (policy), kterými jednotlivé principaly lze předkonfigurovat. Vytvoříme tedy tyto politiky:

~$ su
Password:

~# kadmin.local -p kadmin/admin@FOO.BAR
Authenticating as principal kadmin/admin@FOO.BAR with password.
kadmin.local:  add_policy -minlength 8 -minclasses 3 admin
kadmin.local:  add_policy -minlength 8 -minclasses 2 -maxlife "365 days" user
kadmin.local:  add_policy -minlength 8 -minclasses 4 host
kadmin.local:  add_policy -minlength 8 -minclasses 4 service

Všechny politiky vyžadují heslo minimální délky 8 znaků a podle důležitosti musí obsahovat různé množství tříd znaků (čísla, velká písmena, malá písmena, interpunkce a ostatní znaky). Jak je vidět, na uživatele jsme nebyli tak přísní jako na administrátory s požadovanou kvalitou hesla. Ale uživatelé si každý rok musí změnit heslo příkazem kpasswd. Administrátoři si heslo nemusí měnit, defaultně je nastaven maxlife na 0, což se bere jako nekonečno. Ztráta jejich přístupu k systému by mohla být fatální a také se předpokládá nějaké povědomí o potřebě měnit hesla.

Než začneme vytvářet nový principal v Kerberu pro administrátora, je vhodné se rozmyslet, jak budete rozlišovat administrátory od uživatelů. Nejčastěji se administrátorům připojuje přídomek admin nebo root. Ale lze narazit i na jiné varianty. V obecném formátu principalu primary/instance@REALM využijeme část instance. Je vhodné mít všude sladěné uživatelské jména a tak doporučuji, abyste si administrátorskou identitu odvodili od svého běžného loginu. Takže pro uživatele lojza budeme mít principal lojza/admin@FOO.BAR. V příštím díle pak shodu loginu a principalu využijeme k automatickému vytváření lístku. Můj oblíbený login je svamberg takže si pro něj vytvořím principal (stále pracujeme v kadmin.local):

kadmin.local:  add_principal -policy admin svamberg/admin@FOO.BAR 
Enter password for principal "svamberg/admin@FOO.BAR": 
Re-enter password for principal "svamberg/admin@FOO.BAR": 
Principal "svamberg/admin@FOO.BAR" created.

kadmin.local:  quit

Nyní sice máme administrátora, ale ten nemá žádná oprávnění. Použijeme tedy hvězdičkovou notaci v souboru /etc/krb5kdc/kadm5.acl abychom všem administrátorům (*/admin) přidali všechna oprávnění (*). Pak provedeme restart admin serveru a už nebudeme uživatele root potřebavat.

~# echo "*/admin *" >> /etc/krb5kdc/kadm5.acl

~# /etc/init.d/krb5-admin-server restart
Restarting Kerberos administrative servers: kadmind

~# exit

Nový uživatel

A teď vytvořeným administrátorem si můžeme vytvořit uživatele, tentokrát už nepoužijeme program kadmin.local, který přistupuje k databázi KDC přímo. Spustíme kadmin, kterým se regulérně přihlásíme k administrátorskému rozhraní KDC serveru, kde vytvoříme běžného uživatele (v jejich principalu se nepoužívá část instance):

~$ kadmin -p svamberg/admin
Authenticating as principal svamberg/admin with password.
Password for svamberg/admin@FOO.BAR:

kadmin:  add_principal -policy user svamberg
Enter password for principal "svamberg@FOO.BAR": 
Re-enter password for principal "svamberg@FOO.BAR": 
Principal "svamberg@FOO.BAR" created.

kadmin:  quit

Program kadmin můžete použít odkudkoliv, kde budete mít svůj /etc/krb5.conf (nebo si vzpomenete na adresu admin serveru, viz man kadmin).

Nastavení principalů v AFS

Principal pro uživatele i administrátora máme vytvořen, ale nemáme žádnou návaznost na AFS. Token sice vytvoříme, ale je nám prakticky k ničemu, protože není svázaný s žádným uživatelem:

~$ kinit svamberg
Password for svamberg@FOO.BAR:

~$ aklog

~$ tokens | nl
       
     1  Tokens held by the Cache Manager:
       
     2  Tokens for afs@foo.bar [Expires Apr  2 10:09]
     3     --End of list--

Na řádku 2 je jen obecný token a není v něm řečeno, kterému uživateli z AFS patří. Budeme tedy naposledy potřebovat token od afsadmin:

~$ kinit afsadmin
Password for afsadmin@FOO.BAR:

~$ aklog 

~$ tokens | nl
       
     1  Tokens held by the Cache Manager:
       
     2  User's (AFS ID 1) tokens for afs@foo.bar [Expires Apr  2 10:16]
     3     --End of list--

Zatím je toto jediný token, který máme ve skupině system:administrators, proto napřed vytvoříme identitu pro našeho nového správce v AFS a pak jej do skupiny přidáme. AFS pro  oddělení jména a funkce nepoužívá lomítko nýbrž tečku, proto si já založím uživatele svamberg.admin:

~$ pts createuser svamberg.admin
User svamberg/admin has id 2

~$ pts adduser svamberg.admin system:administrators

~$ pts members system:administrators
Members of system:administrators (id: -204) are:
  afsadmin
  svamberg.admin

Zařazení do této skupiny nám ale nedává úplně všechna oprávnění. Můžeme sice dělat některé operace, ale již v příštím díle bychom zjistili, že takto nemůžeme například založit nový volume. Proto svého administrátora přidáte na každý AFS server do souboru UserList (ten se nachází v /etc/openafs/server/). Pro tuto operaci použijeme příkaz:

~$ bos adduser afssrv.foo.bar svamberg.admin

Aktuální obsah seznamu privilegovaných uživatelů si lze vypsat příkazem:

~$ bos listuser afssrv.foo.bar
SUsers are: afsadmin svamberg.admin

Správce afsadmin ponecháme v seznamu, jeho přístup na konci tohoto článku odepřeme v Kerberosu. Jeho identitu můžeme tak snadno obnovit a použít jej v případě nějaké krize.

A teď už můžete používat svou vlastní administrátorskou identitu pro správu celého systému. Hned ji využijeme na to, abychom do Protection Data Base (PRDB) přidali i obyčejného uživatele. Výjimečně si pustíme aklog v debug režimu, kde je pěkně vidět, jak z Kerberos lístku vytvoří AFS token:

~$ kinit svamberg/admin
Password for svamberg/admin@FOO.BAR: 

~$ aklog -d
Authenticating to cell foo.bar (server afsdb.foo.bar).
Trying to authenticate to user's realm FOO.BAR.
Getting tickets: afs/foo.bar@FOO.BAR
Using Kerberos V5 ticket natively
About to resolve name svamberg.admin to id in cell foo.bar.
Id 2
Set username to AFS ID 2
Setting tokens. AFS ID 2 /  @ FOO.BAR 

~$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 2) tokens for afs@foo.bar [Expires Apr  2 10:56]
   --End of list--

Lze doporučit nějak vhodně oddělit uživatele od systémových účtů. To lze provést obdobně jako v Linuxu, kdy systémové účty mají nižší ID a běžní uživatelé začínají od čísla 1000. To lze nastavit i u účtů v AFS, posuneme čítač pro vytváření uživatelů na vyšší číslo. To samé provedeme i čítači skupin, které se počítají v záporné ose.

~$ pts listmax
Max user id is 2 and max group id is -205.

~$ pts setmax -group -1000 -user 1000

$ pts listmax
Max user id is 1000 and max group id is -1000.

Jako administrátor lze vytvořit obyčejného uživatele v PRDB:

~$ pts createuser svamberg
User svamberg has id 1001

Když už máme svou vlastní a vyzkoušenou správcovskou identitu, můžeme zakázat uživatele afsadmin. To zařídíme přes kadmin, kde zakážeme tvorbu Kerberos lístku (a potažmo tokenu) pro tento principal:

~$ kadmin -p svamberg/admin
Authenticating as principal svamberg/admin with password.
Password for svamberg/admin@FOO.BAR: 

kadmin:  modify_principal -allow_tix afsadmin
Principal "afsadmin@FOO.BAR" modified.

kadmin:  quit

~$ kinit afsadmin
kinit: Clients credentials have been revoked while getting initial credentials

Stejným způsobem lze zablokovat i ostatní uživatelské principaly a tím jim odepřít přístup nejen k AFS, ale i jiným službám, které můžete mít na Kerberos navázány.

Závěr

Každý správce by měl mít svou běžnou (uživatelskou) identitu a k ní samostatnou administrátorskou. Není dobrý nápad mít jednu identitu, ke které si budete předávat heslo. Ztrácí se tím pak informace, kdo co udělal a také to spěje jen k problémům v budoucnu. KDC umožňuje drobnější dělení práv a spoustu dalších detailů, ale to už je trochu mimo téma tohoto seriálu.

Správci jsou už spokojení, ale pro uživatele jsme toho moc neudělali. Napravíme to tedy v příštím díle, kde jim vytvoříme jejich vlastní prostor a také je naučíme pracovat se skupinami.

Centrum informatizace a výpočetní techniky pro Západočeskou univerzitu v Plzni buduje a provozuje od roku 1996 prostředí Orion založené na  autentizačním systému Kerberos a distribuovaném síťovém souborovém systému AFS s více než 22 tisíci aktivních uživatelů.

Seriál OpenAFS (dílů: 11)

První díl: OpenAFS – úvod, poslední díl: OpenAFS – zálohování do volumů.
Předchozí díl: OpenAFS – prakticky o volumech a replikaci
Následující díl: OpenAFS – uživatel

Diskuse k tomuto článku

[Max]

Měl bych několik technických. Podle tohoto : Using Stanford OpenAFS for Windows to vypadá, že stačí vytvořit základní hierarchii a poté si jen win admin nainstaluje clienta a ten mu umožní nastavovat přístupová práva přímo na síťové složce pro dané uživatele / skupiny přes kontextové menu. Takže velmi podobně klikací způsob, jako má netware (příklad : How can I setup file and folder permissions or trusteeships for my NDS network share?). Je to tak?
Jinak podle těch screenshotů to vypadá, že se tam uživatel vepisuje ručně, nebo lze vybrat uživatele ze seznamu, nebo něco podobného?

V poslední řadě by mně zajímalo, zda existuje, nebo zda můžete někdo doporučit nějaké klikátko pro správu uživatelů / skupin. Prostě takové té nejběžnější části.
Díky
Zdar Max

[List]

Každý AFS strom se buduje tak, že se vytvoří základní kostra a tu pak administrátoři dále spravují a rozšiřují, většinou jde o malou skupinu lidí, která se drží nějakých pravidel. To jestli akce z kontextového menu projde nebo neprojde záleží na tom, jaké má aktuální uživatel (nebo win admin) práva, tedy token. Klient ve win umožňuje mnoho akcí provádět z kontextového menu, na ostatní lze použít i z prostředí windows příkazy 'vos', 'fs', 'bos', ...

Ohledně vpisování uživatelů vs. seznam: tak to netuším, ale zkusím vypátrat od kolegů.

Pro unix jsem několikrát uvažoval o klikátku, dokonce o tom, že jej třeba v Perlu napíšu, ale nakonec jsem se nedostal ani k jednoduchému skriptu. Takže stále používám příkazovou řádku a postupem času zjišťuji, že ani nic jiného nechci. Pokud jde o unixové uživatele, tak netuším. Většinou znají login člověka, kterému chtějí nastavit oprávnění a v dokumentaci stačí uvést jen příslušný příkaz.

List.

[List]

Tak je to tak, jak jsem si myslel, uživatele je potřeba dopsat ručně. Seznam všech uživatelů a skupin je dostupný pouze skupině system:administrators, takže běžný uživatel ani tento seznam nemůže vidět, viz man pts_listentries. Ale muže si ověřit, že daný uživatel existuje příkazem 'pts examine <username>'.

List.

[Max]

Děkuji za info, dostupný seznam čistě pro admini je samozřejmě jasná věc, obyčejný uživatel by neměl mít možnost vidět seznam uživatelů na serveru, takže ok.
Zdar Max

[ES]

Super super...