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.