Eida.cz - Enterprise naplno v AD

Enterprise naplno v AD

28. září 2018, 20:31 Eida

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ý.

01-default.conf 334 bajtů
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 {
	...
}

...


}
FreeRADIUS - server default

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

02-eap.conf 859 bajtů
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"
	}

	...
}
FreeRADIUS - modul EAP

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
}

...
}
FreeRADIUS - server inner-tunnel

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.

04-inner-eap.conf 125 bajtů
eap inner-eap {
	default_eap_type = mschapv2
	timer_expire     = 60
	max_sessions = 2048

	mschapv2 {
		send_error = yes
	}
}
FreeRADIUS - modul inner-EAP

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ě.

05-mschap.conf 624 bajtů
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
	}
	...
}
FreeRADIUS - modul MSCHAP

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.

Eida
Tento článek přečetlo již 362 čtenářů (0 dnes).

Komentáře

Nový komentář