Řada informací k tomuto tématu se nachází v dokumentaci Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 3.1.

Termíny okolo autentizace

Velmi stručný a spíše lidový popis několik termínů.

• Autentizace (Authentication) - ověření, jde o potvrzení, že osoba je ta, za kterou se vydává.
• Autorizace (Authorization) - oprávnění, jde o ověření, že osoba má oprávnění provést o co se snaží.
• Účtování (Accounting) - logování, zaznamenávání aktivit uživatele.

Tři výše uvedené termíny se využívají dohromady a mluvíme o AAA metodách nebo serverech.

O více-faktorovou autentizaci (multiple-factor authentication) se jedná, pokud při ověřování využijeme více než jeden faktor. Jako faktory bereme tři kategorie: něco co znám (heslo, PIN), něco co vlastním (certifikát, čipová karta), něco co jsem (otisk prstu). Takže dvou-faktorová autentizace (two-factor authentication) je třeba čipová karta s certifikátem, kde musím použít PIN, nebo certifikát a uživatelské jméno s heslem.

Cisco ASA - AAA Server Groups

Běžné nastavení autentizace jsme si popsali v předchozích dílech. Pro většinu situací musíme vytvořit Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups a tu pak přiřazujeme k profilu v nastavení daného Connection Profile.

Autentizace

Pro autentizaci můžeme využít řadu různých metod (AAA serverů):

• Local - lokální DB uživatelů na ASA, uživatele můžeme spravovat v Configuration > Remote Access VPN > AAA/Local Users > Local Users
• RADIUS - Remote Authentication Dial In User Service, podpora Cisco ACS a ISE, RSA RADIUS, Microsoft IAS a NPS
• TACACS+ - Terminal Access Controller Access-Control System Plus
• SDI - RSA SecureID - autentizační token, který generuje krátkodobě platné heslo
• NT - NTLM Version 1 - velice stará a nedoporučovaná metoda
• Kerberos - podpora šifrování 3DES, DES, RC4
• LDAP - podpora LDAPv3 řady výrobců včetně Microsoft Active Directory, defaultně se autentizační údaje odesílají na LDAP server v čistém textu, ale je možno nastavit SASL protokol (Digest-MD5 nebo Kerberos) nebo využít LDAPS
• HTTP Form - HTTP Forms Authentication for Clientless SSL VPN

Asi nejuniverzálnější a s nejvíce možnostmi je RADIUS. Všechny služby mají určitá omezení (co se týče podporovaných algoritmů, výrobců serverů, apod.). Vše je popsáno v dokumentaci Configuring AAA Servers and the Local Database.

Autorizace

Pro autorizaci můžeme použít pouze RADIUS nebo LDAP. U serveru RADIUS jde o využití RADIUS Authorization Attributes, které se předávají na ASA. Například pomocí atributu 25 můžeme uživateli přiřadit jméno Group Policy. Seznam atributů je v článku ASA RADIUS Authorization Attributes. Při použití LDAP serveru (třeba AD DS) provedeme mapování LDAP atributů na Cisco ASA atributy (specific authorization attribute), provádí se v Configuration > Remote Access VPN > AAA/Local Users > LDAP Attribute Map. Tak můžeme třeba LDAP atribut Department mapovat na jméno Group Policy. Vytvořenou mapu ještě musíme přiřadit k určitému LDAP serveru v rámci AAA Server Groups. Více informací třeba v Supported Cisco Attributes for LDAP Authorization.

Využití certifikátů

Výjimku tvoří autentizace certifikátem, kterou ASA také podporuje. Pro tuto metodu se nevytváří žádná AAA Server Groups, ale nastavuje se přímo přepínačem Method: Certificate na Connection Profile. Abychom mohli certifikáty využít, tak musíme mít certifikační autoritu (CA). Většinou je nejjednodušší použít Microsoft CA v rámci domény. Ale pokud žádnou CA nemáme, tak můžeme provozovat přímo na ASA Configuration > Remote Access VPN > Certificate Management > Local Certificate Authority > CA Server. Popis The Local CA.

Certifikát autority (může jich být více), kterou chceme používat, musíme mít nastaven v Configuration > Access Remote VPN > Certificate Management > CA Certificates. Abychom mohli provozovat SSL VPN (což jsme popsali v předchozích dílech), tak musíme mít nastaven i Web Server certifikát pro ASA, přidáme jej v Configuration > Remote Access VPN > Certificate Management > Identity Certificates.

Když použijeme autentizaci certifikátem, tak můžeme využít možnost přiřadit Connection Profile podle nějaké položky v certifikátu. Nastavujeme v Configuration > Remote Access VPN > Advanced > Certificate to AnyConnect and Clientless SSL VPN Connection Profile Maps.

Při autentizaci certifikátem mi připadá zvláštní hlavní princip chování (i když to samozřejmě má svůj logický význam). Všechny certifikáty, které jsou vydány autoritou nastavenou na ASA a jsou platné, jsou považovány za validní a jsme pomocí nich přihlášeni. Jaké typy certifikátů ASA akceptuje je popsáno níže. Na ASA nemůžeme určovat nějaké omezení certifikátů, nebo třeba vybrat pouze přesně dané certifikáty, pomocí kterých bude povoleno přihlášení. Pokud bychom měli jednu CA a chtěli vydávat speciální typ certifikátů lidem, kteří mají povolenu VPN, tak se nám stejně přihlásí i jiní lidé, kteří mají jiný typ certifikátu od stejné autority.

Jedna možnost, jak tuto situaci obejít, je pomocí mapování certifikátů na Connection Profile a vytvořit profil, který nepovolí přihlášení. Druhá možnost je využít autorizaci na RADIUS serveru. ASA sice nepodporuje autentizaci přes RADIUS s využitím certifikátu. Ale můžeme využít autentizaci certifikátem na ASA, z něho vzít přihlašovací jméno a provést autorizaci tímto jménem na RADIUS serveru. Pak povolíme přihlášení pouze vybraným uživatelům.

Existuje i určitá možnost řízení, ale je na straně klienta. Můžeme konfigurovat jaké certifikáty AnyConnect klient nabízí pro použití. Toto nastavení se provádí pomocí profilu klienta AnyConnect Client Profile (více tuto oblast popíšeme později). Tyto nastavení lze na klientovi obejít, takže na ně nemůžeme spoléhat.

Používané typy certifikátů

Když jsme používali starší IPsec VPN a Cisco VPN Client, tak jsme mohli v IKE fázi 1 provést autentizaci certifikátem počítače. Klient v nastavení nabízel všechny certifikáty (počítačové i uživatelské), ale pokud jsme nepoužili certifikát s Enhanced Key Usage hodnotou IP security tunnel termination (1.3.6.1.5.5.7.3.6). Tak nám přihlášení nefungovalo (pokud jsme nevypli kontrolu pro daný trustpoint).

Když vytváříme SSL VPN s autentizací pomocí certifikátů, tak je chování jiné, ale také hodně záleží na použitých typech (Key Usage) certifikátů. Serverový certifikát je nejjednodušší udělat jako klasický SSL certifikát (u MS šablona Web Server). V požadavcích je, že musí mít Key Usage atribut Digital Signature a Key Encipherment a Enhanced Key Usage atribut Server Authentication (1.3.6.1.5.5.7.3.1).

Stejně tak jsou kladené obdobné nároky na klientský certifikát. Defaultně musí mít Key Usage atribut Digital Signature a Key Encipherment a Enhanced Key Usage atribut Client Authentication (1.3.6.1.5.5.7.3.2). Certifikát může být jak uživatelský (a nacházet se v Current User Certificate Store) tak počítačový (Local Machine Certificate Store). Do úložiště local machine má ale přístup pouze uživatel s administrátorským oprávněním. Otestoval jsem třeba uživatelský certifikát ze šablony SmartCard Logon a počítačový z Workstation Authentication. Akceptované certifikáty můžeme měnit pomocí nastavení AnyConnect Client Profile - Certificate Matching.

Certifikáty jsou podporovány i pro počítače Mac a Linux, ale nesmí se nacházet na SmartCard. Pokud máme certifikát uložen na čipové kartě, tak musíme při autentizaci standardně zadat PIN.

Přihlašování certifikátem probíhá tak, že se po volbě certifikátu nejprve kontroluje autorita, od které je tento certifikát vydán. Pokud je CA na ASA povolena (existuje TrustPoint), tak se kontroluje vlastní certifikát, u kterého se ověřuje Key usage a validita. V dalším kroku se hledá, jestli existuje mapování certifikátu na Connection Profile, pokud ano, tak se přiřadí tento profil.

Konfigurace dvou-faktorové autentizace na Cisco ASA

Vycházíme z následujících předpokladů:

• máme externí CA a její certifikát jsme přidali mezi CA certifikáty na ASA
• od CA jsme vydali certifikát pro ASA ve formátu PKCS #12 base64-encoded a nainstalovali na ASA
• od CA jsme vydali certifikát pro klienta ve formátu PKCS #12
• na ASA máme nakonfigurovánu SSL VPN

V dalších krocích nastavíme autentizaci tak, že se nejprve provede autentizace certifikátem a hned potom je uživatel dotázán na uživatelské jméno a heslo, které se ověřuje vůči RADIUS server (a potažmo Active Directory).

Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups

Připravíme si AAA Server Group pro autentizaci. Jako protokol zvolíme RADIUS a ponecháme defaultní hodnoty. Do skupiny přidáme RADIUS server, přes inside interface zadáme adresu MS Network Policy and Access Services (NPS) serveru a ponecháme defaultní porty nebo upravíme podle nastavení serveru.

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

Zvolíme editaci profilu, který využijeme pro připojení. V sekci Authentication nastavíme Method na Both a zvolíme vytvořenou AAA Server Group. Tím se použije jak autentizace certifikátem, tak pomocí AAA. Ve většině případů (popsáno v předchozích dílech - použití RADIUS s MS-CHAPv2, jinak neprojde autentizace a dostaneme Login failed.) se ještě přepneme na Advanced - General a zaškrtneme Enable password management.

Volitelně můžeme nastavit řadu dalších parametrů. Pokud by k tomu byl důvod, tak můžeme využít dvojitou autentizaci (Double Authentication). Na profilu se přepneme na Advanced - Secondary Authentication a zde nastavíme další AAA Server Group. V tomto případě se při přihlašování klientem zobrazí dvě políčka pro jméno a heslo.

Pro větší bezpečnost můžeme nastavit, že se uživatelské jméno bere z certifikátu a napevno se použije při autentizaci (uživatel jej nemůže měnit ani jej nemusí vidět). Na profilu se přepneme na Advanced - Authentication, v dolní části volíme, jaký údaj z certifikátu se má použít jako uživatelské jméno. K tomu můžeme zatrhnout Pre-fill-username from certificate. Nastavení údaje z certifikátu, který se použije jako username, je důležité také pro identifikaci uživatele v rámci session na ASA. Takže třeba pro SmartCard Logon certifikát změníme hodnotu na UPN, abychom dostávali přihlašovací jméno uživatele a ne jeho zobrazované jméno.

Za zmínku ještě stojí jedna možnost nastavení. V situaci, kdy třeba použijeme autentizaci pouze certifikátem, ten nám nepředává žádné autorizační údaje. Tak můžeme nastavit zvlášť autorizaci vůči nějaké AAA Server Group (v úvahu přichází LDAP nebo RADIUS), i když vůči ní neprovádíme autentizaci. Nastavení se provádí v Advanced - Authorization.

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile

V nastavení profilu klienta můžeme určit parametry, podle kterých se vyhledává certifikát pro autentizaci. Samozřejmě je důležité, aby byl daný klientský profil přiřazen ke Group Policy, která se aplikuje na klienta.

V sekci Preferences (Part 1) nastavujeme Certificate Store, jestli se certifikáty na Windows hledají v uživatelském, počítačovém nebo obou úložištích. Také je zde volba Certificate Store Override, toto nastavení zajistí, že se prohledává počítačové úložiště, i když uživatel nemá administrátorská oprávnění.

V sekci Preferences (Part 2) můžeme nastavit volbu Disable Automatic Certificate Selection. Rozhoduje o tom, jestli se klientovi zobrazí seznam nalezených vhodných certifikátů, nebo se automaticky použije první z nich.

V sekci Certificate Matching můžeme omezovat (či jinak řečeno povolovat) certifikáty, které klient nabídne pro použití při autentizaci. Můžeme volit některé hodnoty Key Usage a Extended Key Usage, případně zadat libovolné OID (do Custom Extended Match Key). V části Distinguished Name můžeme nastavit filtry podle DN v Subject nebo Issuer, například že OU == IT. Pro porovnání můžeme využít i různé masky.

Chyba v Certificate Matching

Při testování jsem narazil na zásadní chybu. Když jsem v pravidle DN použil znak s diakritikou. Profil se uložil do souboru jmeno-profilu.xml, ale následně již nešel otevřít v ASDM. Když jsem tento xml soubor zkusil otevřít v Internet Exploreru, tak psal chybu právě na českém znaku. Ale co je větší problém, když si tento profil stáhnul klient, tak hned při startu hlásil chybu. Jediné řešení bylo smazat soubor na disku c:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\jmeno-profilu.xml.

Aplikace AnyConnect Client Profile

Pomocí profilu klienta můžeme nastavit a omezit řadu funkcí, které mají bezpečnostní dopad. Takže je důležité vědět, jak a kdy se profil aplikuje. Client Profile se přiřazuje pomocí Group Policy, v politice Advanced - AnyConnect Client - Client Profiles to Download. Politika se aplikuje až po přihlášení klienta, takže když uděláme nějakou změnu, tak teprve poté, co se klient úspěšně přihlásí, stáhne si nové nastavení a to začne být aktivní až pro další přihlášení.

Když nasazujeme klienta pomocí webu (přihlášení do Clientless VPN), tak se při instalaci klienta rovnou nainstaluje aktuální profil (údaje zná, protože již jsme do VPN přihlášeni). Takže již první přihlášení je relativně bezpečné.

Nevýhoda je, že profil je vlastně XML soubor, který se uloží na disk u klienta. A když člověk ví, kde se soubor nachází, tak ho může smazat nebo editovat a nastavit libovolné hodnoty. Takže se všechna nastavení v profilu nemohou brát jako bezpečná. Kde se profil ukládá je uvedeno v Locations to Deploy the AnyConnect Profiles.

Kontrola

Pro ověřování a hledání problémů můžeme použít všechny běžné možnosti. Prohlížet logy o průběhu přihlašování Monitoring > Logging > Real-Time Log Viewer, využít debug, prohlížet informace o aktuálních VPN spojeních Monitoring > VPN > VPN Statistics > Sessions, kde v Details vidíme řadu informací včetně způsobu autentizace.

Například v Sessions, a na dalších místech, se zobrazuje uživatelské jméno. Tam se bere údaj, kterým se uživatel autentizoval. V případě, že se přihlašujeme certifikátem, tak se použije nastavený atribut z certifikátu. Pokud se nenalezne, tak se uvádí jméno <Unknown>.

Troubleshooting - debug

Nasazoval jsem tento způsob autentizace na ASA 9.1(5)21 a nechtěla mi fungovat autentizace certifikátem počítače. Přitom uživatelský certifikát od stejné autority fungoval. Na klientovi ani na ASA se nelogovala jiná informace, než

No valid certificates available for authentication
Certificate validation failure

Nevím, co nakonec pomohlo, provedl jsem upgrade na poslední verzi ASA 9.1(7)12. Také jsem odinstaloval AnyConnect klienta a smazal jeho profil a všechna data (to v některých diskusích doporučují). Pak najednou autentizace fungovala (původně jsem ale zkoušel i z jiného PC, kde jsem nemazal profil).

Předtím jsem se snažil získat nějakou informaci, kde je chyba. Inspiroval jsem se článkem ASA AnyConnect Double Authentication with Certificate Validation, Mapping, and Pre-Fill Configuration Guide. Zde je popsán i debug, kdy se připojíme na CLI ASA pomocí SSH (nebo telnet či console) a zapneme ladění odpovídajících oblastí:

ASA#debug aaa authentication 
ASA#debug aaa authorization
ASA#debug webvpn 255
ASA#debug crypto ca 255

V článku jsou také ukázky výstupu ladících zpráv. Dost záhada mi připadá, kdy se ladící informace zobrazují, protože občas se krásně vypisovaly do SSH okna, občas pouze něco a kolikrát vůbec nic. Očividně má tento problém řada lidí, protože se to řeší v mnoha diskusích, ale nic mi nepomohlo. Někde se uvádí, že je potřeba se připojit přes konzoli nebo si zapnout logování do naší session.

ASA#terminal monitor

Hodit se může výpis zapnutého ladění nebo vypnutí všech ladících výstupů.

ASA#show debug 
ASA#undebug all

Další možnost je zobrazení informací o logování a jejich nastavení.

ASA#show logging
ASA(config)#logging monitor debugging