Opravy a úpravy fungování domény jsou poměrně zdlouhavé a jen těžko se dá za dva dny dohnat, co za uplynulé roky. Ale rád bych dál rozváděl návrh architektury tak, aby se nakonec všechno zefektivnilo, možná přehnaně, kde by nakonec byl hlavním DNS serverem Knot, aby měl i Kalužák radost z toho, jak moc se dá nad Debianem kutit enterprise.
Dnešní páteční myšlenka se týká dynamické aktualizace zóny na základě připojení zařízení do DHCP. V MS AD to takhle funguje – kdykoliv se připojí zařízení k síti a dostane od DHCP adresu, server aktualizuje zónový záznam a počítač je dostupný přes DNS. Tohle samozřejmě v implementaci Samba4 v kombinaci v ISC-DHCP-Serverem také funguje, ale bude potřeba udělat pár drobných změn – oficiální ukázka totiž počítá s návrhem jednoho síťového superserveru, který je DCčkem, DNSkem i DHCPkem dohromady. Idea z minula bude jiná, rozšířená podle obrázku.
Oficiální návod s tím ale nepočítá, cestou bude několik záchytných bodů, zvlášť pokud by se mělo dodržet, že řadiče pojedou na Debian stable a zbytek bude vždy aktuální testing. Princip je přitom poměrně jednoduchý a snadno uchopitelný – kdykoliv do sítě přijde zařízení a vyžádá si adresu z DHCP, nebo kdykoliv DHCP propustí držené zapůjčení adresy, je vykonána nějaká akce. Tou akcí je jednoduchý skriptík s funkcionalitami přidat/odebrat záznam. Aby to bylo možné, je potřeba doménové řadiče kontaktovat jako uživatel s oprávněním editace DNS a vše by mělo probíhat automaticky, pokudmožno bez hesla. To lze zařídit také poměrně přímočaře, stačí vytvořit uživatelský účet, zde všude pojmenovaný jako dhcpduser, se členstvím v implicitní skupině DnsAdmins, přičemž je nastaveno, že jeho údaje jsou náhodné a nikdy nevyprší. Následně je získán jeho keytab pro Kerberos a další ověřování je už zajištěno pouze skrze něj.
Toliko tedy teorie. V praxi ale DHCP server bude na jiném počítači a nebude se přímo připojovat na Sambu, ač by měl být jejím doménovým členem (member server, security ADS a odpovídající realm). Je potřeba tedy zajistit, aby měl spojení na Kerberos a odpovídající konfiguraci. Ve výchozím stavu, tedy bez nějaké volby, se tu nabízí MIT implementace Kerberos, která má také nějaká svá specifika.
# DHCP server /etc/krb5.conf
[libdefaults]
default_realm = DOMENA.LAN
dns_lookup_realm = false
dns_lookup_kdc = true
[realms]
DOMENA.LAN = {
kdc = dc1.domena.lan
kdc = dc2.domena.lan
admin_server = dc1.domena.lan
default_domain = domena.lan
} Pokud se povede kinit a vše funguje, a to včetně zobrazení účtu dhcpduser přes wbinfo -u, bude možné vyzískat odpovídající keytab. Ten ale jaksi nepůjde získat přímo pomocí samba-tool – z DC především kvůli tomu, že nebude souhlasit verze a novější Kerberos, který bude na testing, s tím nebude spolupracovat; pomocí samba-tool z DHCP serveru se to nemusí povést kvůli chybějícím balíkům, resp. Python si bude stěžovat z podobného důvodu. Manuální postup není nikde v oficiálních ukázkách uveden, ale výsledku lze dosáhnout vzdáleně pomocí ktutil, jen vědět, jaké klíče to keytabu zapsat. Po chvíli pátrání se zdá, že Samba vyexportuje dvojici klíčů (kvno 2 a 3) se třemi různými variantami šifrování. Protože výsledný keytab bude mít ale jen omezené použití, lze to celé zjednodušit následujícím postupem. Nutno taky dodat, že tam padne požadavek na konkrétní heslo, které tedy nemůže být náhodné a je potřeba ho znát, tj. vytvořit ho manuálně.
# ktutil ktutil: add_entry -password -p dhcpduser@DOMENA.LAN -k 2 -f ktutil: add_entry -password -p dhcpduser@DOMENA.LAN -k 3 -f ktutil: wkt /etc/dhcp/dhcpduser.keytab ktutil: quit # file /etc/dhcp/dhcpduser.keytab dhcpduser.keytab: Kerberos Keytab file, realm=DOMENA.LAN, principal=dhcpduser/, type=91432, date=Tue Aug 17 16:02:08 1993, kvno=23 # chmod 0400 /etc/dhcp/dhcpduser.keytab
Tím by měl být zajištěný keytab, pomocí kterého se skript připojí na Kerberos, získá nebo obnoví tiket, díky kterému se můžu přihlásit k Sambě a pomocí samba-tool nástroje pak bude provádět samotné úpravy DNS. Tady je další záchytný bod, jelikož skript specifikuje proměnnou Server pomocí aktuálního hostname, což ale nedává pro výše zmíněnou architekturu smysl a je potřeba se dotazovat přímo na řadič domény. Řadiče domény jsou zde použity dva, oba se stejnými schopnostmi, teoreticky nic nebrání tomu, aby byly postupně další přidávány, nebo třeba některé odebírány. Proto implicitně existují A a AAAA záznamy na adresy řadičů pro název celé domény (domena.lan) a je možné požadavek směřovat přímo tam.
Další zajímavá schopnost skriptu je zavést MAC adresu počítače do odpovídajícího LDAP objektu. To může být užitečné, ale pokud se počítač nenachází v doméně, nebude nalezen ve stromu objektů, nebude tedy možné mu hardwarovou adresu přiřadit. Tento fakt je reflektován návratovým kódem 68, z tabulky systémových hlášek tedy EX_NOHOST. To je sice správné, ale prakticky pak skript skončí s chybou, což nemusí být vždy úplně přehledné. Měním tedy 68 na 0 a doufám, že mě za to nikdo nesežere.
# /usr/local/bin/dhcp-dyndns.sh 114c141 < Server=$(hostname -d) --- > Server=$(hostname -s) 374,375c401 < exit 0 < #68 --- > exit 68 428d453 <
Poslední kapitola nastavení je AppArmor. To je skvělá věc, pokud je potřeba zabránit napadení procesu a jeho následnému útoku. Bohužel administrativa při lokálních úpravách je pak poměrně detektivní prací, protože skriptem použité nástroje spouští celou kaskádu různých volání po přístupech, které je třeba uspokojit. Opět lze jen poznamenat, že ukázka na oficiální Samba wiki není postavena pro čistý Debian testing, nuže lokální úpravy pro používání by měly nejspíše zahrnovat následující řádky – které je tedy třeba povolit ještě v hlavním konfiguračním souboru pro DHCPd.
# AppArmor local/usr.sbin.dhcpd
/tmp/dhcp-dyndns.cc{,.*} rkw,
/usr/local/bin/dhcp-dyndns.sh rix,
/usr/local/lib/python*/dist-packages/ r,
/usr/bin/ r,
/usr/bin/date rix,
/usr/bin/gawk rix,
/usr/bin/grep rix,
/usr/bin/hostname rix,
/usr/bin/kinit w,
/usr/bin/kinit.mit rix,
/usr/bin/klist.mit rix,
/usr/bin/ldbmodify rix,
/usr/bin/ldbsearch rix,
/usr/bin/logger rix,
/usr/bin/samba-tool rix,
/usr/bin/tr rix,
/usr/bin/wbinfo rix,
/usr/sbin/samba rix,
/dev/tty wr,
/dev/urandom w,
/proc/** r,
/run/samba/winbindd/pipe wr, Tím je tedy dílo dokonáno, všechno funguje a nemusíme se o to zas na chvíli starat. Co bude příští kapitola, že by 802.1X? No, možná. Hezky jedno po druhém. Důležité je, že díky dynamickým záznamům a následným zónovým transferům všechno moc hezky navazuje a pokud nejsou v logu žádná chybová hlášení, je zřejmě čas na croissant. Nebo na čokorolku. Podle potřeby.