Enterprise naplno v AD
Konečně je chvíle klidu, podzimu, kočičího předení a pohodlí. To přímo vybízí k dodělání druhé části pekelně vypečené integrace kouzelného světa Active Directory v běžném životě. Protože kdo to minule četl, jistě bez ochechulí odtušil, že spuštění Samby v roli AD DC a napojení RADIUSu je jenom prvním krokem v celém spektru neomezených možností, které ani zdaleka nejsou naplno enterprise. Je třeba navázat dalšími kroky — konfigurací šifrovaného EAP pro RADIUS, aby to vůbec mohlo jet WPA 2 Enterprise, a taky připojení linuxových strojů do domény, včetně funkčního SSH přístupu a sudo.
Buďme jako doma. Podniková wifi je věc, která lidi obyčejně provází v plně enterprise prostředí, ať už jím je bitevní domov, malé společenství, kupa lidí, nebo budka podobná třeba velitelství, která má dokonce ještě ke všemu přístup do megaglobální hierarchie eduroam. Překvapivě na tom není vlastně nic těžkého a stačí si jen od autorit zajistit certifikáty a vše může jet ještě dnes. Ale bez předbíhání, ať nechybí základní konfigurace — co se vlastně správně děje při plném enterprise ověřování údajů vzduchem? RADIUS jako takový musí každému připojenému NAS nejprve zprostředkovat šifrovaný komunikační kanál pro autorizaci, který se otevírá v běžné konfiguraci jako defaultní server na portu 1812 a který následně bude použitý pro řízení provozu, a také sám pro sebe musí zajistit tunýlek, kde proběhne autentizace uživatele AD, což většinou probíhá skrze EAP. Na tom není víceméně nic složitého, základ bude zhruba všude stejný.
server default { listen { type = auth ipaddr = * port = 1812 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } authorize { filter_username preprocess suffix eap { ok = return updated = return } expiration logintime ... } authenticate { eap } post-auth { ... } ... }
Konfigurace EAP modulu je už o něco zábavnější, protože v sobě zahrnuje už nějaké to důležité šifrování. A když je řeč o šifrování, v případě TLS nebo TTLS bude potřeba mít k dispozici hotové… certifikáty! Yay. Samozřejmě FreeRADIUS na tohle myslí a v adresáři certs
v konfiguraci má zaváděcí skript, co tohle všechno zařídí sám, ale v závislosti na verzi je potřeba si dát pozor na výsledné názvy souborů. No a v případě, že je k dispozici nějaká vyšší moc (tj. stávající podniková CA), bude s klidem možné si serverový certifikát nechat podepsat od ní a vytvořit si už jen nějakou tu omáčku pro výměnu klíčů, tj. DH. No ale při zjednodušení, kdy nebudou použité certifikáty klientské, je to opravdu všechno. Následující nastavení využije vygenerovaný certifikát a metodou MSCHAPv2 bude odesílat už skutečné autentizační informace do serveru běžně nazývaného inner-tunnel.
eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no max_sessions = ${max_requests} tls-config tls-common { private_key_password = *** certificate_file = ${certdir}/server.pem private_key_file = ${certdir}/server.key ca_file = ${cadir}/ca.pem dh_file = ${certdir}/dh ca_path = ${cadir} cipher_list = "DEFAULT" ecdh_curve = "prime256v1" cache { enable = yes max_entries = 255 } ocsp { enable = yes override_cert_url = no use_nonce = yes } } tls { tls = tls-common } ttls { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" } peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" } ... }
V tunýlku, což je speciální server, který by měl běžet jen na lokálu, pak proběhne samotná komunikace se sambou už ne pomocí jména a hesla, ale pomocí vyšší NTLM magie ve smyslu challenge-response. O tom ale samotný tunýlek nemluví a zásadní je pro něj jen nastavení komunikace na localhostu.
server inner-tunnel { listen { ipaddr = 127.0.0.1 port = 18120 type = auth } authorize { filter_username mschap suffix update control { &Proxy-To-Realm := LOCAL } inner-eap { ok = return } expiration logintime pap mschap } authenticate { inner-eap mschap pap Auth-Type MS-CHAP { mschap } mschap } session { radutmp } ... }
Aby to nebylo tak jednoduché, konfigurace se pak rozpadá na flow vnitřního EAP, který neříká nic jiného, než že ověřování bude zajišťovat modul MSCHAPv2.
eap inner-eap { default_eap_type = mschapv2 timer_expire = 60 max_sessions = 2048 mschapv2 { send_error = yes } }
A v něm už bude figurovat minule zmíněný program ntlm_auth
, jen ale s tím rozdílem, že už komunikace neprobíhá v plaintextu, ale v hashi, takže začnou hrát roli proměnné Challenge
NT-Response
, zapsané přibližně sáledovně.
mschap { use_mppe = yes require_encryption = yes require_strong = yes ntlm_auth = "/usr/local/samba/bin/ntlm_auth --require-membership-of=DOMENA+radius --allow-mschapv2 --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=DOMENA --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}" pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 retry_delay = 30 lifetime = 86400 cleanup_interval = 300 idle_timeout = 600 } ... }
To je víceméně všechno pro plnohodnotné enterprise nastavení. K ověření funkčnosti mohou posloužit nástroje eapol_test
, které ale nejsou běžnou součástí distribuce FreeRADIUS, ale lze je získat ze zdrojových balíčků.
Daleko zajímavější je pak druhá část podnikového problému, samotné připojení linuxových strojů do domény. To není asi úplně typická konfigurace, ale je nesmírně zajímavá, protože umožní ušetřit spoustu práce a spoustu nastavování různých přístupů. Obecně by se dalo říct, že v praxi budou typy konfigurací dvě, totiž RHEL a jeho Fedory a CentOSy a pak Debian, takže různé Bububu a deriváty, jako třeba elementaryOS.
U RHELů je to dost přímočaré, neboť disponují přímo v základu nástrojem realm
, takže stačí začarovat realm join --user=velitel domena.lan
a po zadání hesla je vymalováno. K nastavení řady dalších věcí, jako jsou domovské adresáře a idčka, pak slouží démon sssd
s konfigurací v sssd.conf
. Tohle platí celosystémově, čili po začarování id domenovy_uzivatel
by měly být zobrazeny i všechny AD skupiny. To je důležité pro definice SSH přístupů, je-li třeba je omezit, nebo zkrátka pro globální sudo
— získání roota přes sudo
znamená naplnit pravidla uložená v sudoers
, tj. pro CentOS 7 někde v cestě /etc/sudoers.d/sudoers
. Skupiny se označují znamínkem %
a v závislosti na kvalifikovaných jménech je pak možné zapsat napříkald řádek %DOMENA\\Domain\ Admins ALL=(ALL) ALL
pro rootovský přístup všem doménovým správcům.
Debian a Bububu v základu tak jednoduché a podnikově přítulné nástroje nemají, takže se to dělá hezky starou cestou. V první řadě je potřeba nastavit správně hostname i s celou doménou a v optimálním případě nechat hodiny synchronizovat NTP s DC. Pro samotné připojení je pak samozřejmě potřeba Samba, Kerberos a věci pro PAM. Teoreticky tedy postačí balíky samba krb5-config krb5-user winbind libpam-winbind a libnss-winbind. Vysoce moderní distra krátce po instalaci většinou odpálí ncurses rozhraní pro textovou konfiguraci Kerbera, kde se specifikuje doména. Když ne, tak zkrátka se vším všudy v /etc/krb5.conf, jak bylo minule už řečeno. Stejně tak následuje nastavení Samby v režimu member a winbindového PAM, což lze pak ověřit začarováním getent passwd
, co by mělo vypsat uživatele z AD. A pak už, snad, možná, doufejme, si můžeme užívat enterprise naplno v barvách podzimu.