Možná stojí za zmínku zapsat si sem tam pár poznámek v takových časech, které vlastně nikdy neoplývají volnými chvílemi, jak vlastně na to, jak dosáhnout už tolikrát dosažených cílů. Dnešek patří několika zamyšlením se nad kouzelným světem škálování, které má dneska vlastně k dispozici každý (pokud ovšem alespoň trochu chce), a tak nějak se celý nese v jarním duchu završené snahy, která konečně po čtyřech letech začne přinášet nějaké ovoce. Sice ne tak pěkné, jako fraktální geometrie, ale na druhou stranu o něco užitečnější.
Asi před více než čtyřmi lety jsme v budníku začali okrajově uvažovat a Active Directory, protože se tomu vlastně stejně žádná organizace, natož řízená státem, nevyhne. Tehdá byla na obloze a v cloudu velká myšlenka, totiž první Samba 4, od které bylo možné si slibovat úplně totální revoluci, schopnosti svaté krávy a vizi plnohodnotného nahrazení Windows Serveru v roli doménového řadiče. Řadič domény, aby bylo jasno, schraňuje hardwarové a softwarové prostředky sítě a organizuje je. Active Directory je LDAP vize Microsoftu, která umí zorganizovat chaos v síti a poskytovat v první řadě centralizované přihlašování a ověřování uživatelů, kteří pak mohou přistupovat na připojené počítače, které zas mají vlastnosti podle přednastavených šablonových politik a vůbec je to celé tak úžasně flexibilní, že to nebyla úplně věc, kterou by chtěl mít každý doma. Postupně se ukazuje, že opak je pravdou, protože několik zásadních výhod se najde i pro dnešní dobu.
Pravda, akcie Intelu padají kvůli nedávným a novým bugískům k zemi a svět se začíná pomalu chvět v rytmu aarch64 a RISC-V, nicméně x86_64 je pořád ještě základní konzumní platforma, kterou má doma téměř každý. A s tím, jak se vše postupně zmenšuje, zlevňuje a leniví, se už dá i na domácí úrovni používat rozumná virtualizace za rozumnou cenu. Současné ITX desky s pasivně chlazenými integrovanými procesory už nemají nejmenší problém s VT-x, a tedy cesta k levné a hodně snadno škálovatelné platformě je zcela otevřená. Přestože v budníku jsme začínali s poněkud jiným vybavením a jiným záměrem, pro střední organizaci není vyloženě překážkou naplno hučící stolní bedna, alespoň plná deska poskytne více možností rozšíření. Mít něco takového doma, to už vyžaduje trochu více představivosti - a přece, náš velitel si doma (a v bytě!) jede prostě Windows Server v obyčejné skříni. Není to moc k pochopení. Zkrátka a dobře, dneska na bare-metal není úplně ideální naplácat všechno najednou. Dneska nám tam jede vlastně už jen firewall, DNS, MTA, reverzní proxy s balancerem a KVM. S tímhle návrhem jsme začali, protože jedna pitomá aplikace prostě nemohla běžet v Mono a vyžadovala WPF, k čemuž plnohodnotně postačil obyčejný IIS v Pro verzi Win 7, kterou jsme si jako OEM napaštili na stroj virtuálně. Kvůli tomu tam právě jela ta reverzní proxy, takže síťový provoz mohl zůstat krásně filtrovaný za NATem a nebylo se čeho bát.
Myšlenka spustit si Active Directory sice přišla pozvolna, ale ve skutečnosti byla realizována velmi rychle. Doménové řadiče je ale hodně pitomé provozovat za NATem, takže nejdelší zdržení bylo asi v nekonečném odkládání, kdy nebyl čas server na několik minut odpojit a nastavit na jeho fyzickém síťovém rozhraní společný můstek. Nicméně takový den nakonec přece nastal, takže mohly vzniknout i virtuály fyzicky připojené k LAN bez ochechulí. No, AD je docela složitý komplex, který je zcela závislý na DNS, poskytuje ověřování Kerberos, jede si adresářové služby LDAP, nabízí připojeným počítačům hodiny a spoustu dalšího, včetně klasického sdílení souborů, neboť na něm poskytuje celý SYSVOL a Netlogon, ale taky se dá použít pro další běžná sdílení. Takže i když nebude realizovaný originálním MS Serverem, ale Sambou 4, je potřeba, aby byl prostě přímo na oné síti - je tedy vyloženě vhodným kandidátem pro připojení do nového můstku.
Taková nemilá ochechule na tomhle principu je ale hlavně fakt, že služba DNS je povinná prakticky pro všechno. Jinými slovy, všechny stroje v doméně s ní a s její pomocí musí komunikovat; v malých organizacích je taky AD server často primárním DNS serverem pro celou síť a tím to končí. U nás ale už primární DNS server běžel kvůli mnoha jiným důvodům a navíc by nebylo asi úplně super, kdyby jím měl být stroj virtuální s omezenými prostředky. Takže první myšlenková část příprav počítala s tím, že DNS backendem pro budoucí Sambu 4 AD bude BIND9 logicky konfigurovaný jako master pro novou AD zónu (ve skutečnosti dvě zóny), kterou pošle existujícímu primárnímu DNS, který ji bude udržovat a aktualizovat jako slave. Toliko možná úvodem, ještě se k tomu vrátím.
Pro teď ovšem nějaký praktický příklad vycházející ze skutečných událostí. Pokusme se na stávající síti, kde je server KVM s pracujícím bridgováním, rozjet novou doménu kouzelného světa Active Directory EIDA.LAN. Budou k tomu potřeba zatím dva stroje (řadič domény a jeden virtuální klient) a závěrem pak jeden bonus v podobě rozšíření o RADIUS server ověřující proti novému AD. Přehled příkladu:
LAN: 172.16.1.0/24, brána 172.16.1.100 ---------------------------------------------------------- KVM, DNS: 172.16.1.150 Linux (fyzický x86_64) Nová doména: EIDA.LAN dc.eida.lan 172.16.1.20 Debian 9 (virtuální stroj, Samba 4) radius.eida.lan 172.16.1.21 Debian 9 (virtuální stroj, FreeRADIUS 3) ap1.eida.lan 172.16.1.10 DD-WRT (fyzický Wifi AP) w7.eida.lan (DHCP) Win 7 (virtuální stroj, RSAT)
Pro úplnost se přiznám, že příklad dělám ve vmWare, ale vadit by to záměru ani výsledku nijak nemělo. Jak pro tyhle účely, tak pro provoz, pojedou nové virtuální stroje na systému Debian 9 GNU/Linux, jeden pak budou Microsoft Windows 7 s nástroji RSAT. Řadič domény nemá překvapivě téměř žádné drastické nároky a konfigurace s jedním CPU jádrem a 512 MB RAM je postačující i pro středně velkou organizaci (nicméně jsou dobrá jádra dvě), v RADIUS systému je potřeba se rozhodnout, jestli bude logovat třeba do MySQL a jaká bude jeho průměrná zátěž - hodí se mu více vláken a více paměti. Virtuální Windows jsou oříškem, ale ukázalo se, že mají spoustu výhod - například mít po ruce prostředí Windows, když je potřeba - a od toho by se měly odvíjet parametry.
-
Rozdělení VM disku - ext4 nad LVM -
Minimální konfigurace -
Juch a jede to
-
Instalace Windows - název w7 -
Definice pracovní sítě -
Instalace RSAT
Máme systémy, co dál? Instalátor Debianu hardware poznal, do Windows je možná potřeba přihodit KVM ovladače RedHat VirtIO, pak balíček RSAT (pro Windows 7 tedy KB958830) a je to vybavené. V Debianu bude potřeba udělat několik zásadních změn. V první řadě jde o to, že je nutné nějak namapovat Windows/NT vlastnosti do UNIXové struktury, a k tomu účelu slouží právě rozšířené atributy a přístupová oprávnění ACL. Odpovídající balíčky pro začátek tedy budou acl, později libacl1-dev a z důvodů pohodlí pak ještě aptitude a htop, protože proč ne. Aby bylo možné ale rozšířené atributy a ACL používat, musí být jejich podpora aktivní na úrovni souborového systému. Z tohoto důvodu proběhla konfigurace EXT4 nad LVM, která se pro tyhle účely ukázala jako nejvíce stabilní. Změna v /etc/fstab spočívá v aktivaci user_xattr a acl pro root /, tedy:
# /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/dc--vg-root / ext4 user_xattr,barrier=1,acl,errors=remount-ro 0 1 UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot ext2 defaults 0 2 /dev/mapper/dc--vg-swap_1 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Pak může a nemusí přijít reboot, ostatně bude to ve virtuálu docela rychlé a není důvod vyťukávat remount aktivního rootu. Jako další bude asi nutná vůbec příprava několika balíčků, aby se dala přeložit Samba 4 a NTPd ze zdrojových kódů, protože ty balíčkové není možné tak snadno pro zamýšlené účely používat. Sosněme tedy základ krb5-user a bind9, potom taky build-essential, python-dev, gnutls-dev, libacl1-dev, libldap2-dev, libcap-dev a libpam-dev. Tím by to vše bylo nachystané na stavbu Samby, která se dá získat z oficiálního webu v poslední verzi. Víceméně není potřeba žádná další složitá konfigurace, prostě ./configure, make, make install.
Překlad by v čistém systému neměl skončit žádnou chybou a celá instalace by měla skončit v /usr/local/samba, což by bylo velmi vhodné hodit si pro všechny systémové účty (jak obyčené, tak pro roota) do PATH, kde jsou nástroje na snazší ovládání, tedy ideálně
# echo "export PATH=\$PATH:/usr/local/samba/sbin:/usr/local/samba/bin" >> /etc/bash.bashrc # source /etc/bash.bashrc
Následuje už samotná inicializace domény, což by nemělo být už nic těžkého. Zkrátka podle návodu na oficiální Samba-wiki, v interaktivním režimu s dodržením RFC2307 pomocí samba-tool domain provision --use-rfc2307 --interactive. Říše bude EIDA LAN, doména EIDA, role serveru pochopitelně dc a jako DNS backend BIND9_DLZ, což použije lokální instalaci serveru Bind9 a bude do ní lifrovat DLZ tabulky, tj. dynamické zónové záznamy podle toho, jak budou v síti komunikovat se Sambou. V tomhle kroku se také vytvoří účet Administrator pro správu domény - musí mít silné heslo, v příkladu bude Koko1234. V tenhle okamžik proběhne vytvoření všech tabulek, SYSVOL, samotné připojení řadiče k doméně a fůra nových souborů, které bude ještě nutné připojit.
Server Role: active directory domain controller Hostname: dc NetBIOS Domain: EIDA DNS Domain: eida.lan DOMAIN SID: S-1-5-21-1523246170-3054018885-1264867384
Zmiňované soubory vznikly v /usr/local/samba/, kde jsou důležité adresáře private a bind-dns. Asi jako první na řadu přijde nakopírování nového krb5.conf z private/ do /etc/, kde bude uložená nová Kerberova říše Její Jasnosti, kde vlastně je jen název říše, vypnuté vyhledávání říše, ale zapnuté vyhledávání KDC. Tohle je mimochodem věc, která je hodně citlivá na správnou konfiguraci. Pokud se v některém z předchozích kroků jako závislost dostal do systému démon Avahi (avahi-daemon), je potřeba ho odstranit. V bind-dns je stručně popsán návod, co vlastně dělat s DNS serverem. Kdyžtak named -V ukáže aktuální verzi Bind9, ta je tady v Debianu 9 zrovna 9.10, takže všechny konfigurace platí pro 9.10, což by mělo být přednastavené v poskytnutém snippetu pro named.conf. Zbývá tedy upravit lokální konfiguraci Bind9.
// /etc/bind/named.conf.options
acl "trusted" {
172.16.1.0/24;
localhost;
localnets;
};
// DNS servery v siti
acl "server" {
172.16.1.20/32;
172.16.1.150/32;
};
options {
directory "/var/cache/bind";
// DNS keytab ze Samby
tkey-gssapi-keytab "/usr/local/samba/bind-dns/dns.keytab";
allow-query { trusted; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
allow-update { trusted; };
allow-transfer { server; };
// primarni DNS v siti
forwarders {
172.16.1.150;
};
dnssec-validation auto;
auth-nxdomain no;
listen-on { 172.16.1.20; };
};
A v neposlední řadě taky lokální /etc/resolv.conf, aby řadič dokázal vyhledávat názvy podle vlastní DNS a případně aby vůbec mohl na Internet, nicméně výpadek lokálního Bind9 by neměl rozhodně nastat, že :D.
# /etc/resolv.conf search eida.lan domain eida.lan # lokální DC nameserver 172.16.1.20 # primární DNS nameserver 172.16.1.150 # záloha nameserver 8.8.8.8
Tím by byla funkcionalita DNS na řadiči hotová, teď ještě připravit síť na jeho operaci. Jak bylo řečeno v úvodu, pokud by DC neměl být primárním serverem, musí alespoň do primárního serveru posílat změny v zóně. Zónový záznam /etc/bind/eida.zone bude vypadat přibližně nějak tahle.
// KVM /etc/bind/eida.zone
zone "eida.lan" IN {
type slave;
masters { 172.16.1.20; };
file "/etc/bind/dynamic/eida.lan";
allow-transfer { none; };
allow-query { any; };
};
zone "_msdcs.eida.lan" IN {
type slave;
masters { 172.16.1.20; };
file "/etc/bind/dynamic/_msdcs.eida.lan";
allow-transfer { none; };
allow-query { any; };
};
Ten je pak nutné zahrnout (include) do veškerého nastavení named.conf a poupravit nastavení tak, aby umožňovala transfery zón z AD od řadiče.
// KVM /etc/bind/named.conf.options
acl "trusted" {
172.16.1.0/24;
localhost;
localnets;
};
acl "ad" {
172.16.1.20/32;
172.16.1.150/32;
};
options {
directory "/var/cache/bind";
// transfery zóny
allow-query { trusted; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
allow-transfer { ad; };
// IP Googlu, ale měly by tu být DNS IP od ISP
forwarders {
8.8.8.8;
8.8.4.4;
};
dnssec-validation auto;
auth-nxdomain no;
listen-on { 172.16.1.150; };
};
Je čas přejít na samotnou Sambu. Její konfigurace je docela přímočará, nicméně pro nějaké reálné použití by to mohlo vypadat následovně. Do KVM přišel přišel fyzický disk ve smyslu raw zařízení identifikovaného pomocí UUID a jako ext4 s podporou ACL je mountovaný do /server/. Jeho smyslem je poskytnout jednak úložiště pro domovské adresáře uživatelů, ale také úložiště pro cestovní profily. Kdo kdy pracoval s Windows, nebo hůře, s Windows Serverem, určitě ví, o čem je řeč a jaké zlo to je. Popis je zase k dispozici na oficiální wiki Samby, včetně gacků pro GPO.
# /usr/local/samba/etc/smb.conf [global] netbios name = DC realm = EIDA.LAN server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate workgroup = EIDA server role = active directory domain controller idmap_ldb:use rfc2307 = yes username map = /usr/local/samba/etc/smbusers idmap config EIDA.LAN:unix_nss_info = yes idmap config EIDA.LAN : backend = tdb idmap config *:range = 70001-80000 idmap config EIDA.LAN:schema_mode = rfc2307 idmap config EIDA.LAN:range = 3000000-4000000 os level = 100 logon home = \\%N\users\%U logon path = \\%N\profile\%U acl allow execute always = yes [netlogon] path = /usr/local/samba/var/locks/sysvol/studanka.local/scripts read only = No guest ok = yes browseable = no hide files = /Network Trash Folder/Temporary Items/.AppleDouble/ valid users = %U [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No [users] comment = Domovský adresář path = /server/users csc policy = documents read only = No force create mode = 0600 force directory mode = 0700 hide files = /Profile/Network Trash Folder/Temporary Items/.AppleDouble/mbox/Maildir/ [profile] comment = Profily uživatelů path = /server/profiles read only = no writable = yes valid users = %U browseable = no force create mode = 0600 force directory mode = 0700 store dos attributes = Yes profile acls = yes csc policy = disable vfs objects = acl_xattr follow symlinks = yes hide files = /Network Trash Folder/Temporary Items/.AppleDouble/mbox/Maildir/
Teď přijde na řadu trochu testování a hlavních úprav. Po zapnutí nebo restartu Bind9 teď stačí spustit Sambu prostě příkazem samba. Pro jistotu pomůže nahlédnout do systémové žurnálu (journalctl -r), ale mělo by to běžet ok. Kontrola přihlášení Kerberos kinit Administrator y se měla zeptat na heslo k říši EIDA.LAN a po jeho zadání vystavit platný ticket. Pokud ano, je čas poladit výchozí velmi nepříjemnou politiku, která je ale zkopírovaná přímo od Microsoftu. Vlastně ke všemu je tady samba-tool, teď je důležitý jeho uzel domain passwordsettings, kde je vhodné nastavit požadavky na složitost, minimální a maximální stáří hesla (maximální stáří hesla způsobuje požadavek na jeho změnu co tři měsíce, což je nepříjemné, u Windows Serveru se to dá nastavit tak na jeden rok) a na minimální délku. To jsou věci, které je vhodné zahodit, pokud budou muset být k dispozici univerzální nebo testovací účty.
Pro správné fungování přihlášení jsou důležité správně nastavené hodiny. Hodinami se myslí NTP server, který by měl řadič démy počítačům poskytovat. Hodiny slouží hlavně k tomu, aby proces přihlášení proběhl v nějakém rozumném časovém rámci, jinak se to prostě nepovede. Další výhodou NTP serveru je jeho schopnost správně podepisovat pakety, což ale bohužel poskytovaní démoni v repozitářích Debianu neumí a je potřeba si zase sestavit vlastního ze zdrojových kódů oficiálního NTPd a konfigurovat ho s flagem --enable-ntp-signd a --enable-linuxcaps. Při jeho sestavení by zase nic nemělo skončit s chybou a nový časový démon je na světě.
# /etc/ntp.conf # hodiny v síti broadcast 172.16.1.255 # lokální hodiny server 172.16.1.150 # zfalšování strata, jinak se Windows nesynchronizují fudge 172.16.1.150 stratum 3 server 0.pool.ntp.org iburst prefer server 1.pool.ntp.org iburst prefer server 2.pool.ntp.org iburst prefer driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp # podepisování ntpsigndsocket /usr/local/samba/var/lib/ntp_signd restrict -4 default kod nomodify notrap nopeer mssntp restrict 127.0.0.1 # pouze pro DC restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery
Podepisování je dobře popsáno zase na wiki Samby. Po správném nastavení oprávnění pro ntp_signd stačí už jen nového démona spustit jako ntpd -u ntp:ntp a v systémovém logu by se mělo zobrazit něco jakože podepisování už probíhá a vše je v pořádku, tedy v adresáři ntp_signd by se měl objevit odpovídající socket.
dc ntpd[72274]: switching logging to file /var/log/ntp dc ntpd[72274]: restrict 0.0.0.0: KOD does nothing without LIMITED. dc ntpd[72274]: MS-SNTP signd operations currently block ntpd degrading service to all clients. dc ntpd[72274]: proto: precision = 0.073 usec (-24) dc ntpd[72272]: Command line: ntpd -u ntp:ntp dc ntpd[72272]: ntpd 4.2.8p11@1.3728 St dub 11 19:49:37 UTC 2018 (2): Starting
A hotovo z hlediska nastavení řadiče! Nicméně je tu ještě jedna maličkost, která není tak samozřejmá. Ručně nainstalované služby jsou spuštěné ručně a po restartu nenaběhnou samy od sebe. Samozřejmě je můžeme podle zvyklostí napsat do /etc/rc.local.
#!/bin/sh -e # ACTIVE DIRECTORY /usr/local/sbin/ntpdd -u ntp:ntp /usr/local/samba/sbin/samba exit 0
Ehm, jenže, jaksi. Debian 9 je už plně systemd a na SystemV RC skripty se tu takhle snadno nehraje, takže tuhle věc je zase možné vrátit zpátky tím, že se jednoduše vytvoří jednotka, která vrátí novému systému starý rc-přístup. Protože proč ne. Jednotka bude v /etc/systemd/system/rc-local.service a bude v ní cosi jako následující úryvek.
[Unit] Description=/etc/rc.local ConditionPathExists=/etc/rc.local [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 StandardOutput=tty RemainAfterExit=yes SysVStartPriority=99 [Install] WantedBy=multi-user.target
Novou jednotku je potřeba jaksepatří zaregistrovat - systemctl enable rc-local. A tímhle krokem to všechno končí a řadič domény je plně připravený. Aby se protřepal a nemíchal, je vhodné ho restartovat a skočit k dalšímu kroku, přidání virtuálních Windows do nové domény a první spuštění RSAT. V sedmičkách je potřeba to po instalaci tak trochu zapnout přidáním funkcí systému; potřeba bude správa uživatelů AD, správa DNS a správa zásad skupiny (GPO). V GPO přijde v první řadě nastavit synchronizace hodin, ta je opět popsaná na wiki Samby, potom případné nastavení výchozích profilů a domovských disků, což je vhodné. V tomto skromném příkladě jsou zde noví uživatelé Koko a Koko2 se stejnými hesly, přičemž první z nich je členem nové skupiny wifi.
-
Ověření fungujících DNS v LAN -
Připojení k doméně EIDA.LAN -
Ověření a připojení proběhlo úspěšně
-
Přihlášení doménovým účtem -
Nový doménový uživatel Koko -
Nová skupina wifi
A teď to nejzajímavější. Fungující doména, tedy přihlašování, domovské disky a cestovní profily, to je prima věc. Ale k čemu všemu by se to dalo ještě využít? V minulých letech jsme byli donuceni nastavit nad celým areálem budníku roaming o několika přístupových bodech pro bezdrátovou síť s tím, že bylo nutné nějakých způsobem ověřovat normální lidi od divokých kidů. Toho jsme docílili centralizací MAC tabulek na jednom místě, kterým byl RADIUS, resp. FreeRADIUS server 2. Ten se později upgradoval na verzi 3.0, ale víceméně to pořád běhalo jednoduše tak, že služba wrt-radauth, která je v DD-WRT pro tento účel dost vhodná, zkrátka posílá jako uživatelské jméno a heslo MAC adresu zařízení, které se pokouší přihlásit, i když uživatel nebo útočník zná předsdílený WPA klíč. RADIUS pak odešle nějakou odpověď na základě které se buď nestane nic, nebo je o zamítnutí přístupu informován čipset, který MAC zablokuje, případně je tam fallback, že se upraví firewall tak, aby zařízení prostě nemohlo komunikovat, i když bude na síti přihlášené. Obě varianty mají nevýhodu, že se každých pět minut ověřují znovu a znovu. Samozřejmě tím je možné docela dobře sledovat slabá místa a monitorovat, kde kdo a jak chodí, což je teď v rámci GDPR docela téma, ale hlavně je ta technická režie docela vysoká, takže to chce zkusit i jiné způsoby. No a když už je centrální evidence legitimních uživatelů, proč to nezkusit jako plnohodnotné WPA 2 Enterprise, kde uživatelským jménem a heslem budou prostě údaje s AD a RADIUS je ověří?
Snáze se to řekne, než provede. Naštěstí tady znovu získává slovo kouzelný svět škálování, protože by nedávalo smysl upravovat stávající stroje, jinak by se rozbilo dost jiných věcí. Výborná možnost proto je spustit nový RADIUS server jako další virtuální stroj, když už ten výkon máme. Pro takovýto stroj je opět vybraný systém Debian 9 GNU/Linux začínající na jednom GB operační paměti a jeho výhodou je, že bude operovat pouze s výchozími balíčky, které budou snadno dostupné v repozitářích.
Co se týče disků, není na škodu znovu použít LVM a EXT4, zase je totiž vhodné mít aktivní rozšířené atributy a ACL přímo na disku. Tento počítač bude pracovat trochu jinak, než se asi očekává - jeho základním úkolem bude připojit se k doméně jako obyčejný člen, což mu umožní sehrát roli přístupové brány k AD. Proč to nedělat přímo na řadiči nebo na KVM železe? Jednoduše proto, že se nebude zasahovat do žádné jiné konfigurace a riziko selhání jedné komponenty neohrozí druhou. Připojení je zase vhodné realizovat přímo na fyzickém můstku, NATovat zrovna RADIUS, byť na jediném portu, by byl docela nářez.
Co se tedy týče instalace balíčků, budou to acl, krb5-user, samba, freeradius a winbind. Právě poslední jmenovaný se bude starat o samotné ověřování ve směru systém-AD a tuto informaci si pak převezme RADIUS. V tomto počítači přijde několik drobných změn, třeba přidání a prohledávání domény eida.lan v /etc/resolv.conf. Tím dalším pak bude zejména chování Kerbera, trochu potuněné.
# /etc/krb5.conf
[libdefaults]
default_realm = EIDA.LAN
dns_lookup_realm = false
dns_lookup_kdc = false
[domain_realm]
.eida.lan=EIDA.LAN
eida.lan=EIDA.LAN
[realms]
EIDA.LAN = {
default_domain = eida.lan
kdc = dc.eida.lan
}
Je tam hlavně vypnuté vyhledávání a explicitně nastavený KDC server pro říši. To může pomoci v několika problémech v DNS. Další úpravou bude změna chování ověřování v /etc/nsswitch.conf, kde přijde kontrola pomocí souborů a především pomocí winbind, který tu bude sloužit jako prostředník.
# /etc/nsswitch.conf passwd: compat files winbind group: compat files winbind shadow: compat files winbind gshadow: files hosts: files dns networks: files protocols: db files winbind services: db files winbind ethers: db files rpc: db files netgroup: nis winbind
S winbind pracuje Samba. Speciálně pro svoje účely má pro něj v /var/lib/samba/ komunikační rouru pod winbindd_privileged, přičemž tento adresář musí mít oprávnění 0750. Vzhledem k tomu, že k němu budou muset přistupovat třetí služby, musí být tyto služby buď členy privilegované skupiny, nebo můžeme prostě pomocí ACL nastavit nějakému uživateli nebo skupině vlastní přístup. Konkrétní třetí službou bude FreeRADIUS, který se balíčkově zavádí uživatele freerad, tedy začarujeme pro něj přístup pro čtení.
# setfacl -m u:freerad:rx /var/lib/samba/winbindd_privileged
Posledním krokem je pak připojení tohoto počítače do domény jako obyčejného člena domény. To si žádá určitou úpravu v Sambě, která bude pracovat v režimu ADS. Zvláštní pozornost si ale zasluhuje nastavení winbind, kde je s výhodou aktivní využití výchozí domény a jako oddělovač je zvolen symbol +.
# /etc/samba/smb.conf
[global]
security = ADS
workgroup = EIDA
realm = EIDA.LAN
username map = /etc/samba/user.map
idmap config EIDA.LAN : backend = tdb
idmap config EIDA.LAN : range = 3000000-4000000
winbind separator = +
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = yes
realm = EIDA.LAN
Po tomhle je potřeba Sambu, pak už je možné připojit se v pohodě k doméně, restartovat i winbind a provést určitá ověření funkčnosti.
root@radius:/etc/samba# net ads join -U Administrator Enter Administrator's password: Using short domain name -- EIDA Joined 'RADIUS' to dns domain 'eida.lan' root@radius:/etc/samba# /etc/init.d/winbind restart [ ok ] Restarting winbind (via systemctl): winbind.service. root@radius:/etc/samba# wbinfo -u dns-dc administrator koko guest koko2 krbtgt root@radius:/etc/samba# wbinfo -g ras and ias servers cert publishers domain users dnsupdateproxy enterprise admins domain computers allowed rodc password replication group domain guests schema admins group policy creator owners domain admins wifi denied rodc password replication group enterprise read-only domain controllers read-only domain controllers dnsadmins domain controllers root@radius:/etc/samba# wbinfo -a koko%koko plaintext password authentication succeeded challenge/response password authentication failed wbcAuthenticateUserEx(EIDA+koko): error code was NT_STATUS_WRONG_PASSWORD (0xc000006a) error message was: Wrong Password Could not authenticate user koko with challenge/response
Pokud je všechno v pořádku, proběhne připojení do domény, na řadiči se zavede správně DNS záznam do zóny, winbind se podaří bez chyb restartovat a wbinfo by mělo podle nastavení v smb.conf poskytnout seznam všech uživatelů a skupin na řadiči s vynecháním domény. Ověření autentizace (wbinfo -a jméno%heslo) by mělo proběhnout správně při čistém textu a ve výchozím nastavení selhat v challege/response ověření. To v principu ničemu nevadí, protože toto ověřování nebude na zamýšlené úrovni využíváno, i když se dá třeba někde dočíst opak.
To nejsložitější, příprava konfigurace samotného RADIUS serveru, je ve skutečnosti docela hračka, když se na to jde od lesa. Záměr bude takový, že budeme chtít povolit přístup všem správně ověřeným uživatelům AD, kteří jsou členy doménové skupiny wifi. K ověření, že něco takového jde udělat překvapivě snadno, využijeme nástroj ntlm_auth, který se později stane klíčovým pro celý systém.
root@radius:/etc/samba# ntlm_auth --allow-mschapv2 --require-membership-of=EIDA+wifi --request-nt-key --domain=EIDA.LAN --username=koko --password=koko NT_STATUS_OK: Success (0x0) root@radius:/etc/samba# ntlm_auth --allow-mschapv2 --require-membership-of=EIDA+wifi --request-nt-key --domain=EIDA.LAN --username=koko2 --password=koko2 NT_STATUS_LOGON_FAILURE: Logon failure (0xc000006d)
Důležité je si uvědomit, že většina wifi AP, která bude nastavená na RADIUS, tedy WPA 2 Enterprise, posílá svoje požadavky jako pap, není tedy nutné jen pro tento konkrétní účel nastavovat (PEAP-)MS-CHAP, který je určený pro poněkud jiné účely a na Sambě AD by bylo velmi složité ho rozjet, protože RADIUS potřebuje nižší, méně bezpečnou verzi, což je tak trochu proti vlastnímu přesvědčení Microsfotu, ale co už. Pro konkrétní potřeby je potřeba upravit poskytovaný modul.
# /etc/freeradius/3.0/mods-available/ntlm_auth.conf
exec ntlm_auth {
wait = yes
program = "/usr/bin/ntlm_auth --allow-mschapv2 --require-membership-of=EIDA+wifi --request-nt-key --domain=EIDA.LAN --username=%{mschap:User-Name} --password=%{User-Password}"
}
Což samozřejmě není všechno, protože je ještě třeba nastavit požadované chování. FreeRADIUS je modulární a nabízí tzv. sites, výchozí z nich je default. V sekci authorize je potřeba navrhnout nový postup, pokud přijde dotaz, na který neumí server zatím reagovat - jinými slovy, pokud není zvolený typ autentizace, řízení se předá do ntlm_auth. V rámci autentizace je potřeba říci, jak na to má sekce authenticate reagovat. Takže tam přijde tento nový typ a ověřování bude provádět pomocí stejnojmenného modulu nastaveného výše.
# /etc/freeradius/3.0/sites-enabled/default
...
authorize {
...
if(!control:Auth-Type) {
update control {
Auth-Type = "ntlm_auth"
}
}
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type NTLM_AUTH {
ntlm_auth
}
...
}
A poslední v řadě, připravit si nějaké klienty, tedy ověřené přístupové body, přes které se budou koncová zařízení uživatelů do sítě hlásit. Tyto body používají sdílené klíče pro interní šifrovanou komunikaci s RADIUS serverem, když posílají svá data. Samozřejmě každý bod může být spravovaný zvlášť a může zůstat uložený třeba v MySQL a podle potřeby se nechat vypínat, ale dá se taky udělat univerzální kombo, kdy klienti budou mít jedno heslo a budou pracovat na jednom adresním rozsahu. To na teoretický úkor bezpečnosti neuvěřitelně urychluje práci při nasazování nových bodů a přeškálovávání celých budov, což nás, shodou okolností, v budníku co nevidět taky čeká.
# /etc/freeradius/3.0/clients.conf
# OBECNA DEFINICE AP
client 172.16.1.0/24 {
secret = krutoheslo123
shortname = clientap
}
Pokud je takto jednoduše nastaveno, je možné nahodit debugovací režim freeradius -X a z vedlejší konzole zavolat radtest a odzkoušet oba příkladové uživatele. Koko je členem skupiny wifi a přístup by mu měl být udělen, kdežto Koko2 členem není a nesmí se tedy dostat přes nástrahy RADIUS servernu.
eida@radius:~$ radtest koko koko localhost 0 testing123 Sent Access-Request Id 49 from 0.0.0.0:38625 to 127.0.0.1:1812 length 74 User-Name = "koko" User-Password = "koko" NAS-IP-Address = 172.16.1.21 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "koko" Received Access-Accept Id 49 from 127.0.0.1:1812 to 0.0.0.0:0 length 20 eida@radius:~$ radtest koko2 koko2 localhost 0 testing123 Sent Access-Request Id 215 from 0.0.0.0:56251 to 127.0.0.1:1812 length 75 User-Name = "koko2" User-Password = "koko2" NAS-IP-Address = 172.16.1.21 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "koko2" Received Access-Reject Id 215 from 127.0.0.1:1812 to 0.0.0.0:0 length 20 (0) -: Expected Access-Accept got Access-Reject
Jestli to zafunguje, je to už jenom krůček k plnohodnotnému enterprise přístupu. Jak je vidno, tak se to skutečně povedlo. Je to občas všechno možná zdánlivě složité, ale opak je pravdou. Linux je tu pro ty, kteří chtějí dělat věci jednoduše, rychle a zdarma, jen nesmí být prostě moc líní a musí si občas sáhnout až na svoje dno. Ta dřina se jednoho dne totiž vyplatí.