Az RD Gateway elég régóta létező komponens, segítségével megoldható a belső hálózaton található gépek RDP elérése, biztonságosan (TCP 443-as porton keresztül)

A pandémiás helyzet miatt sok cégnek kapóra jöhet ez a megoldás. Jön az igény: a céges PC-met el kellene érnem az otthoni gépemről, mintha azon dolgoznék. Lehetőleg biztosítva az identitásellenőrzést is, azaz a név/jelszó pároson kívül legyen többfaktoros hitelesítés is.

Lássuk, hogyan lehet ezt egy meglévő RD Gateway és Azure MFA-val megoldani! (Az RD Gateway telepítés-konfigurálás lépéseket a cikk nem tartalmazza)

Előfeltételek:

• Azure MFA licensz a felhasználónak, Authenticator konfigurálva push notification módra
• Földi Active Directory integrációja az Azure AD-val (dirsync)
• Remote Desktop Gateway konfigurálva és elérhető az internet felől (pl. tsgw.corp.com címen)
• Földi Network Policy and Access szerepkör telepítve

Azure AD tenant ID beszerzése

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview linken kiolvashatjuk a tenant id-t. Ezt mentsük el a későbbi használat miatt.

Azure NPS Extension telepítése

Az NPS szerverre telepíteni kell az Azure MFA extensiont. Vigyázat! A telepítés után minden authentikációs kérést az Azure felé fog küldeni, ezért feltétlenül fontos, hogy külön NPS szervert használjunk. Ellenkező esetben a wifihez/vpn-hez használt NPS-t működésképtelenné teheti.

Töltsük le az extensiont és teleptsük fel:

https://www.microsoft.com/en-us/download/details.aspx?id=54688

Telepítés után konfiguráció következik. Admin powershellből navigáljunk a “c:\Program Files\Microsoft\AzureMfa\Config” folderbe és indítsuk el az .\AzureMfaNpsExtnConfigSetup.ps1 scriptet.

Majd a felugró ablakban jelentkezzünk be Global Adminként

A script bekéri majd a Tenant ID-t, ezt másoljuk be és nyomjunk Entert:

Connection authorization policy beállítása központi használatra

Remote Desktop connection authorization policies (RD CAPs) szükségesek az RD Gateway-hez kapcsolódáshoz. Alapértelmezetten ezek a policy lokálisan vannak tárolva, de ez esetben át kell állítani központi RD CAP Store-ra.

Nyissuk meg az RD Gateway szerveren a Remote Desktop Gateway Managert. Jobb klikk a szerver nevén, Properties, RD CAP Store és a Central Server running NPS résznél vegyük fel a kívánt NPS nevét vagy IP-jét

Adjunk meg egy erős, hosszú shared secretet és mentsük el a későbbi használathoz.

RADIUS Timeout átállítása

A RADIUS timeout értékét át kell állítani az alapértelmezettről, hogy a felhasználónak legyen ideje a kétfaktoros hitelesítést végrehajtani.

Ehhez az RD Gateway szerveren indítsuk el a Network Policy Server konzolt, majd menjünk a Radius Clients/Remote Radius Server részre. Nyissuk meg a TS Gateway Server Groupot. Itt megjelenik az általunk beállított radius szerver, kattintsunk az Edit…-re. A Load Balancing tabon látunk két értéket:

Number of seconds without response before request is considered dropped

Number of seconds between requests when server is identified as unavailable

Ezek értékét állítsuk át 60-ra

Connection Request Policy ellenőrzése

Az RD Gateway-en nyissuk meg a Network Policy Server konzolt, keressük meg a Policies / Connection Request Policies részt. Kattintsunk duplán a TS GATEWAY AUTHORIZATION POLICY-re, majd Settings és végül Authentication. Győződjünk meg róla, hogy a kérések biztosan a távoli NPS szerverre mennek:

NPS konfiguráció

Az NPS szerveren, ahol telepítettük az MFA Extsensiont, nyissuk meg az NPS konzolt, és adjunk hozzá RADIUS klienst:

A new radius client ablakban adjuk meg az RD Gateway nevét és IP/DNS nevét, illetve írjuk be a korábban elmentett Shared Secretet:

Network Policy konfiguráció

Az NPS szerveren indítsuk el az NPS konzolt, nyissuk ki a Policies ágat és válasszuk a Network Policies részt. Kattintsunk jobb klikkel a “Connections to other access servers” policyre és válasszuk a “Duplicate policy” opciót:

Nevezzük át a policyt, kapcsoljuk be a “Policy enabled” részt és válasszuk a “Grant access opciót:

Kattintsunk át a “Constraints” fülre és pipáljuk be az “Allow clients to connect without negotiating an authentication” method opciót:

Mentsük el a policyt, majd győződjünk meg róla, hogy engedélyezve van és a lista elején áll:

Csatlakozás RDP klienssel

Miután végeztünk minden konfigurációs beállítással, teszteljünk. Indítsuk el az RDP klienst és csatlakozzunk egy belső géphez a szokásos beállításokkal:

Ha mindent jól csináltunk, a telefonon meg kell jelennie az Authenticatior üzenetnek, ahol a belépést jóváhagyhatjuk:

Hibakeresés, logok ellenőrzése

Probléma esetén segítségül hívhatjuk az eventlogot. Az RD Gateway szerveren nyissuk meg az Event Viewert és navigáljunk el Network Policy and Access Services custom nézethez:

Összefoglalás: az RD Gateway kényelmes és hasznos megoldás, amit az Azure MFA Extensionnal biztonságosabbá is tehetünk.

Bizonyára nagyon sokan ismerik a Kerberos authentikációt, on-premise környezetben főleg. Szeretjük is, mert biztonságos és működik vele a single sin-on (SSO). Ha a felhasználónk már authentikálta magát, akkor a további erőforrások eléréséhez nem kell újra megtennie, a háttérben intéződik.

Emlékeztetőül, a klasszikus Kerberos-hitelesítés így történik:

Így ha egy active directory userrel vagyunk belépve és megpróbáljuk elérni a pl. a belső sharepointot (pl. https://sharepoint.company.com), akkor a háttérben megtörténik a hitelesítés és a felhaszáló eléri az erőforrást (természetesen vannak előkövetelmények, SPN legyen beállítva). Ha nincs SPN definiálva, akkor Kerberos helyett NTLM hitelesítéssel próbálkozik (ez is SSO még, de jóval nagyobb terhelés a kiszolgálónak a challenge/response folyamat miatt), ha az NTLM sem sikerül, akkor felugrik a jelszóbekérő ablak. Természetesen mindez függ, hogy a Sharepointnál milyen hitelesítést állítottunk be:

Tehát van működő Kerberos és SSO. Viszont, ahogy láttuk, a működéshez kell a Ticket Granting Service, azaz a domain controller. Ha ez kiszolgáló nem elérhető hálózati szinten, a Kerberos nem működik.

Mi lehet a megoldás, ha távolról, céges hálózat nélkül szeretnénk elérni a belső alkalmazásokat, SSO-val? A régi megoldás a VPN kapcsolat, de az nehézkes, komplexé tehet az infrastruktúrát.

A modern megoldás, ha Azure AD Application Proxyt használunk, melynek segítségével a belső webalkalmazásokat elérhetjük SSO-val, az Azure AD segítségével.

Nézzük, hogyan lehet egy belső alkalmazást publikálni:

Előfetétel: az AAD App Proxyhoz Azure AD P1 vagy P2 licensz szükséges.

Azure AD Connect megléte, felhasználók szinkronizálása az AzureAD-ba.

Működése:

A felhasználó szeretné elérni a belső alkalmazást, először az Azure AD-hoz fordul. Az AAD továbbítja őt az Application Proxy Service-hez, ami kommunikál az előzőleg a földi környezetbe telepített Application Proxy Connectorral. Itt megtörténik az authentikáció és a felhasználó megkapja a hozzáférést.

1. lépés

Application Proxy Connectorok telepítése: két on-premise kiszolgálóra telepíteni kell a Connector agentet. A két agent a redundancia miatt szükséges. Amennyiben Kerberost akarunk használni, a két szervernek ugyanannak a domainnek tagja kell legyen, mint ahol a belső erőforrás található. A telepítés menete itt olvasható:

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application

Amennyiben a Connectorok telepítve vannak, lehet őket csoportokba rendezni:

A csoportba rendezés lehetővé teszi hogy különböző applikációkhoz külön Connector Agenteket rendeljünk.

2. lépés

Enterprise Application létrehozása: itt hozzuk létre az AzureAD-ban a publikálni kívánt alkalmazást.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/

Válasszuk a New Applicationt, majd a következő oldalon az “On-premies application” lehetőséget:

A Basic Settings résznél töltsük ki az Internal és External URL részeket. Ennél a példánál split-dns van, tehát a külső és belső névtér megegyezik. Így az internal és external url egyaránt https://sharepoint.istvanffy.eu lett. A pre-authentication legyen “Azure Active Directory”, a Connector Groupot pedig állítsuk be, ha szükséges (tesztkörnyezetben maradhat Default-on)

Az Additional Settings résznél hagyjuk az alapbeállításokon:

Az így elkészült alkalmazásnál a Properties résznél kapcsoljuk ki az “User assignment required” opciót.

Ha ezt nem tesszük, akkor csak azok a felhasználók férnének hozzá az alkalmazáshoz, akiket a Users and Groups résznél engedélyezünk. Ez hasznos lehet, ha szeretnénk csoportszinten megszabni, kik érhetik el az alkalmazást. Egyéb esetekben (ha mindenkinek szeretnénk elérhetővé tenni) ki kell kapcsolni.

3. lépés

Single Sign-on beállítása: a létrehozott alkalmazásnál navigáljunk el a Single Sing-on részhez és az alábbi beállításokat találjuk

Mivel mi a Kerberost szeretnénk megvalósítani, válasszuk a Windows Integrated Authentication opciót.

Itt meg kell adnunk az on-premise környezetben beállított SPN értékét (lásd később)

Vigyázzunk a formátumra, SPN esetén http/sharepoint.istvanffy.eu formában kell megadni. A Delegated Login Identity értékét hagyjuk az User Principal Name formában, így a felhasználó az UPN-jével tud authentikálni.

4. lépés

SPN ellenőrzése: jó esetben már beállításra került a földi környezetben a szükséges SPN. Ezt leellenőrizhetjük egy domaines gépen futtatott setspn -Q http/sharepoint.istvanffy.eu lekérdezéssel.

Amennyiben mégsem létezne az SPN, az alábbi hibát kapjuk:

Ez esetben kézzel kell hozzárendelnünk az SPN-t, a következő paranccsal: setspn -S http/sharepoint.istvanffy.eu <sharepoint szerver neve>

5. lépés

Kerberos delegálás beállítása: a következő lépésben lehetővé tesszük a Connector Agentek számára, hogy a Kerberos-delegálást használják.

Az Active Directory Users and Computers konzolban keressük meg a Connector Agent számítógép objektumát, majd menjünk a Delegation fülre, válasszuk ki a “Trust this computer…” és “Use any authentication protocol” részt

Az Add gombbal keressük ki a sharepoint szerver computer accountját (vagy service userét, ha ahhoz van az SPN hozzárendelve), és válasszuk ki a kívánt service-t (esetünkben a http/sharepoint.istvanffy.eu)

A fenti beállítást ne felejtsük el minden Connector Agent computernél hozzáadni, különben Kerberos-hibákat kaphatunk.

6. lépés

DNS beállítása: ahhoz, hogy az applikáció elérhető legyen az Azure AD-n keresztül, a DNS-t be kell állítani. Esetünkben definiálnunk kell, hogy a sharepoint.istvanffy.eu mutasson az Azure-re. Ezt CNAME-rekord létrehozással tudjuk megtenni, erre az Enterprise Application figyelmeztet is:

7. lépés

3rd party tanúsítvány feltöltése: ahhoz, hogy az applikációt a saját domainnevünkkel tudjuk elérni, szükséges egy harmadik féltől származó tanúsítvány feltöltése az Azure-be. Ezt a tanúsítványt fogja a hitelesítéshez használni és így biztosan nem kapunk böngésző-figyelmeztetéseket

A tanúsítványt pfx formátumban kell feltölteni és megadni a hozzá tartozó jelszót:

Amennyiben később több alkalmazást is publikálánk, a tanúsítványt nem szükséges minden alkalommal feltölteni, elég egyszer.

8. lépés

Tesztelés: ezek után az active directory felhasználóval belépve a gépre (VPN és céges hálózat nélkül) elnavigálunk a publikált alkalmazás linkjére (jelen cikk példájában https://sharepoint.istvanffy.eu) akkor azt tapasztaljuk, hogy a sharepoint rögtön “beengedett”, azaz nem kért authentikációt, sikerült a Kerberos-hitelesítés.

Amennyiben más gépről hívjuk meg a linket, az AzureAD fogja kérni a hitelesítést:

A céges accountot és jelszót megadva szintén megtörténik a hitelesítés.

Hibakeresés:

A leggyakoribb probléma, hogy a Kerberos-delegáció nincs jól beállítva, ez esetben az alábbi hibát kapjuk (incorrect Kerberos constrained delegation configuration)

Ez esetben duplán ellenőrizzük le az SPN és delegációs beállításokat.

Szintén tud segíteni a Connector Agenteken eventlog:

Applications and Services Logs > Microsoft > AadApplicationProxy > Connector > Admin

A teljes hibakeresési link: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-back-end-kerberos-constrained-delegation-how-to

Összefoglalva: megoldható a belső alkalmazások elérése külső hálózatból, a biztonságos és SSO-t nyújtó Kerberos-hitelesítéssel is.