ADFS (4) – Základní nastavení ADFS


1 Úvod

V minulém díle jsme nainstalovali ADFS servery ve scénáři 1x ADFS BE a 1x WAP proxy. V tomto díle se budeme věnovat základnímu nastavení ADFS po instalaci.

2 Teoretický základ

Kapitola shrnuje základy, které je potřeba zvážit před samotnou konfigurací ADFS v prostředí zákazníka.

Cílem základní konfigurace ADFS serverů, je

· Zabezpečení serverů proti hackerským útokům

· Nastavení serverů z pohledu administrátora tak, aby byl schopen kontrolovat a řešit případné chyby

· Nastavení ADFS serverů z pohledu klienta tak, aby nedocházelo chybám při připojování starších zařízení

2.1 Zabezpečení serverů

Zabezpečení serverů je zde zmíněno pouze pro úplnost. Velmi zkráceně je zájmem každého administrátora, mít ve spravovaném prostředí co nejlépe zabezpečené servery. Administrátor by tedy měl zvážit implementaci

· Antiviru

· Nastavení firewallu

· Security hardeningu (povolení pouze bezpečných šifrovacích protokolů a šifer, kontrola bezpečnostních děr)

· Automatických nebo řízených instalací aktualizací (například Microsoft SCCM)

· Zálohování

2.2 Nastavení pro administrátory

Počet připojených klientů ADFS ovlivňuje nejen množství ADFS serverů, které je potřeba nasadit do prostředí zákazníka, ale také nutnost změnit velikosti ukládaných Event logů. Podle definované maximální velikosti souborů event. Logů a způsobu jejich přepisu určujeme, kolik událostí je možné do souborů uložit. Každý administrátor by měl tedy zvážit, jak velkou velikost Event logů potřebuje ukládat. Do velkých společností je také možné zvážit produkty třetích stran, které se starají o Event log managment. Například SIEM.

V případě potřeby lze na ADFS zapnout diagnostické logování a výsledky poté vyhodnotit. Diagnostické logování zapínáme pouze v případě, kdy se vyskytne problém. Po vyřešení problému lze diagnostické logování vypnout. Diagnostickému logování se budeme věnovat v dalším díle seriálu o ADFS.

2.3 Server Name Indication

Server Name Indication je rozšíření protokolu TLS SSL, které umožňuje klientovi přidat hlavičku „hostname“, ke kterému se připojuje, do Client SSL HELLO zprávy. Server potom využívá SNI hlavičky k tomu, aby byl použit správný certifikát pro klienta. Hlavní výhoda SNI je použití více certifikátů pro jednu IP adresu a port. Pokud Client SSL HELLO neobsahuje SNI hlavičku, není server schopen rozlišit, který certifikát použít a provede RST spojení. Pro starší klienty je tedy potřeba zajistit možnost se autentizovat i přes to, že nepodporují SNI. Problémy s nepodporovaným SNI mohou nastat i při použití některých load balancerů (například kontrolní sondy neumí poslat Client SSL HELLO s rozšířením SNI). V další kapitole bude ADFS nastaveno tak, aby podporovalo i zařízení bez SNI.

https://blogs.msdn.microsoft.com/kaushal/2012/09/04/server-name-indication-sni-with-iis-8-windows-server-2012/

2.4 Nastavení z pohledu klienta

Klientské nastavení řeší kompatibilitu zařízení, které se připojují k ADFS (SNI), SSO z interní sítě bez zadávání hesla (IWA) a další. V tomto díle seriálu bude popsáno nastavení podpory NON-SNI a povolení IWA jako primární metody autentizace interních klientů.

3 Základní nastavení ADFS

V této kapitole bude popsáno, jaká nastavení je potřeba projít po instalaci ADFS. Úplný soupis požadavků pro technologii ADFS je k přečtení zde.

3.1 Nastavení parametrů ADFS

Nastavením parametrů ADFS, se ADFS přizpůsobuje lokálním potřebám spravovaného prostředí. K nastavení se používá dvojice PowerShell příkazů Get-ADFSProperties pro výpis konfigurace ADFS a Set-ADFSProperties k zápisu nové konfigurace. Pokud je ADFS farma konfigurovaná s WID, je potřeba změnu nastavení ADFS provádět na primárním serveru farmy. V opačném případě lze změnu provádět na kterémkoliv serveru.

Příkazem Set-ADFSProperties obvykle budou administrátoři chtít měnit délku platnosti Token Signing a Token Decrypting certifikátů, nastavení délky trustů pro ADFS Proxy a automatické obnovy Token Signing a Token Decrypting certifikátů.

I přes možnost tyto parametry měnit bude ADFS pracovat, i když parametry změněny nebudou. Detailní popis příkazu Set-ADFSProperties je zde.

3.2 Nastavení Group Policy pro servisní účty

Předpokládejme, že ADFS je nainstalované do prostředí zákazníka. ADFS pracuje až do druhého restartu serveru, kdy už služba ADFS nenaběhne. Velmi pravděpodobně se tak stalo proto, že servisní účet, pod kterým ADFS běží, již nemá právo „Log on as a service“. V případě implementace Windows Internal Database je potřeba nastavit GPO i pro servisní účet WID databáze.

Nastavení pro WID je popsáno zde. Právo „Log on as a service“ pro servisní účet lze řešit nalinkováním patřičné GPO na organizační jednotku, ve které jsou umístěny ADFS servery.

3.3 Konfigurace Server Name Indication

Pokud je potřeba podporovat NON-SNI klienty v ADFS (Problém popsán zde), je potřeba nastavit fallback certifikát pro případ, že klienti nebudou schopni poslat SNI hlavičku. Na serverech s ADFS se tedy přidává nový SSL binding 0.0.0.0:443 pro ADFS Application ID a Certificate thumbprint, použitý pro ADFS. Zda je nastaven fallback certifikát se zjišťuje přes příkaz netsh.

netsh http show sslcert

Výstupem je seznam jmen a IP adres s certifikáty pro daný server (všimněte si, že chybí binding 0.0.0.0:443 s patřičným certifikátem. Nebude tedy fungovat podpora NON-SNI zařízení. Tento obrázek ukazuje stav pro ADFS backend.

a1

Zajímavější je obrázek pro WAP proxy, kde je vidět, že SNI umožňuje, provozovat více služeb na jednom serveru a jedné IP adrese. V případě ukázky je použit * certifikát. V obrázku jsou vyznačeny různé Application ID, pro ADFS a WAP proxy. Application ID pro ADFS je vždy stejné {5d89a20c-beab-4389-9447-324788eb944a}, Pro WAP Proxy potom. {f955c070-e044-456c-ac00-e9e4275b3f04}

a2

Fallback certifikát přidáváme opět příkazem netsh.

Pro ADFS backendy:

netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={5d89a20c-beab-4389-9447-324788eb944a}

 

Pro WAP proxy:

netshhttp add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={f955c070-e044-456c-ac00-e9e4275b3f04}

Výsledkem je fallback certifikát pro default listener 0.0.0.0:443 a funkční autentizace NON-SNI zařízení.

a3

Pokud nastavení provedete špatně, záznam lze odstranit pomocí netsh

netsh http

delete sslcert ipport=0.0.0.0:443

Podrobný popis problematiky zde.

3.4 Kontrola záznamu pro Kerberos autentizaci

Správné nastavení Kerberos autentizace v ADFS je jedním z předpokladů, že bude správně pracovat Windows Integrated Autentizace. Při instalaci ADFS se vytvoří SPN záznam pro Kerberos, který je navázaný na DNS load balancované jméno, pod kterým běží ADFS. Dotaz, zda existuje SPN záznam a je navázaný na správný servisní účet. Dotaz se provádí příkazem setspn.

Setspn –q host/<dns_lb_jméno ADFS_služby>

 

Výsledkem je nalezený SPN záznam na jméno služby.

a4

Není-li SPN správně nastavený, lze nastavit opět přes příkaz setspn

Setspn –a host/<dns_lb_jméno ADFS_služby> <jméno_servisního_účtu_pro _ADFS>

 

3.5 Integrated Windows Authentication jako primární metoda autentizace, SSO pro interní klienty

Integrated Windows Autentizace umožňuje uživateli z vnitřní sítě autentizaci bez zadávání uživatelského jména a hesla použitím tokenu z Windows. Aby toto nastavení fungovalo správně je potřeba ověřit, zda v ADFS je nastavena default autentizační metoda Windows Integrated Authentication a je potřeba nastavit zóny IE tak, aby load balancované jméno ADFS serveru bylo v zóně Intranet, aby v IE byla povolena IWA v neposlední řadě také správně nastavené SPN pro Kerberos (viz předchozí kapitola).

3.5.1 Nastavení primární autentizační metody pro interní klienty

Nastavení ADFS ověříme příkazem Get-AdfsGlobalAuthenticationPolicy. Výsledkem je výpis primárních autentizačních metod pro externí a interní klienty. Je-li ve výpisu WindowsAuthentication, jako primární autentizační metoda pro interní klienty, je možné přejít na nastavení zón pro IE. V opačném případě je potřeba nastavit IWA pomocí příkazu Set-AdfsGlobalAuthenticationPolicy.

a5

3.5.2 Nastavení podporovaných klientů pro IWA

Seznam podporovaných IWA klientů lze editovat příkazem Set-ADFSProperties. Výpis aktuálně podporovaných IWA klientů je možné získat přes Get-ADFSProperties. $FormatEnumerationLimit = -1 zajišťuje vypsání neomezeně dlouhého textu do konzoly.

$FormatEnumerationLimit = -1Get-AdfsProperties | select *wia* | fl

 

Výsledkem je seznam podporovaných klientů. Seznam lze upravovat, přičemž je nutné se k seznamu chovat, jako k poli string objektů (oddělovat elementy čárkou a názvy vkládat do uvozovek)

a6

3.5.3 Nastavení local intranet zóny

Jestliže není load balancované jméno v Local Intranet zóně IE, při pokusu o autentizaci přes ADFS, je potřeba pro přihlášení zadat uživatelské jméno a heslo. V opačném případě bude uživatel rovnou vystaven token a uživatel bude přihlášen na ADFS.

a7

S IWA vypadá výsledek bez zadání uživatelského jména a hesla dle obrázku.

a8

 

Provedením nastavení z tohoto článku je ADFS připravená do produkce a pro propojení s Office 365.

V příštím díle si budeme pokračovat v nastavování ADFS, kde se zaměříme na debug logging, omezení autentizace ADFS pouze na některé uživatele a další.

- Zbyněk Saloň, KPCS CZ

Mohlo by vás také zajímat:

Basic Overview of ADFS & Azure Identity

Comments (1)

  1. Pavlik Jiri says:

    Well Done, hezký článek Zbyňku

Skip to main content