ADFS és az Exchange Server 2013

Ahhoz, hogy az ADFS és az Exchange Server 2013 kombinációjáról beszéljünk, eloször tisztáznunk kell az ADFS szerepét. Exchange blog lévén, feltételezem, hogy az Exchange az ismert. :)

Mi hát az ADFS?

Mélyen él az emlékeimben az amikor 2003-ban eloször láttam és hallottam az ADFS-rol. Egy belso bizalmas konferenciánk volt. Ahol Bill Gates mondott egy érdekes beszédet. Ebben a beszédben rengeteg jövobeli szolgáltatás, termék jelen volt. Nem mellesleg említés szinten volt egy olyan példa is, hogy A vállalatnál muködo SharePoint Portál szolgáltatásait B vállalat felhasználói tudják használni úgy, hogy: a két vállalat között nincs hagyományos trust kapcsolat, a két vállalat között csak HTTPS kommunikáció lehetséges és B vállalat felhasználója SSO (single-sign-on) segítségével éri el a szolgáltatást. Ez utóbbi az igazán fontos. Tehát B vállalat felhasználója, reggel beér a céghez. Bekapcsolja a gépét, belép a B vállalat Active Directory címtárába, majd elindítja a böngészojét és A vállalat SharePoint portálját böngészi úgy, hogy nem kellett újra azonosítania magát. Nem mellesleg nincs az A vállalat címtárában sem felhasználói azonosítója. Felhasználónk csak a B vállalat címtárában szerepel.

Ez a beszéd és ez a példa annyira megragadta a figyelmemet és elindította a képzeletemet, hogy utána sokáig nem tudtam ettol szabadulni. Fogalmam sincs, hogy pontosan hogyan muködik és mi az a csoda ami ezt megvalósítja. De az biztos, hogy a hét további részében, amikor a hotelbe visszaértem, akkor csak ezen merengtem, hogy vajon, hogy fog ez muködni. Biztos voltam benne, hogy nekem ezt meg kell értenem és foglalkoznom kell vele, mert annyira egyedi és Bill is beszél róla. Majd késobb megérkezett a Windows Server 2003 R2 beta verziója benne az ADFS komponenssel és azonnal lecsaptam rá. Validálni szerettem volna, hogy amirol Bill beszélt az muködik-e. És tényleg. Muködik. Azóta eltelt több mint 10 év és jól látjuk, hogy az ADFS alapú azonosítás és authorizáció napjaink fontos épitoköve. No nem azért mert olyan sok az A és B vállalat kapcsolata ami ezt kikénszeríti. Nem. Sajnos még ma is botladoznak, bukdácsolnak az ügyfelek a saját maguk által kötött békjókban, ha cross-org elérést kell biztosítani a szolgáltatásokhoz. Az IT, IT szemmel nézi és a legegyszerubb megközelítést alkalmazza: vegyünk fel az AD-ba új júzert. Az IT biztonság berzenkedik, ezért csinálnak egy új forestet, amit aztán trustolnak össze-vissza. Ááá. Az IT szempontjából is rossz és a végfelhasználók szempontjából is az. Majd idorol-idore aztán újrakezdik az egészet. Szóval nem, az ADFS használatát nem a vállalatok közti kommunikáció egyszerüsítésére kezdte el a világ használni. Helyette az alapja lett a felhoszolgáltatásoknak. Hiszen helyettesítsük be az A és B vállalatokat. A vállalat a Microsoft és a nálunk levo Exchange, Sharepoint stb. szolgáltatásokat biztosítjuk a felhasználók millióinak. B vállalat pedig a Te céged. Hogy fogják a Te céged felhasználói az általunk biztosított szolgáltatásokat elérni úgy, hogy nem mi csináljuk az azonosítókezelést (jelszó, jelszólejárat stb.)?

Egyszeru a válasz az elozo kérdésre. Hát erre való az ADFS. Nem kell Windows NT alapú trustot kiépíteni, nincs RPC forgalom csak HTTPS és van SSO. Minden szép, minden jó.

Az azonosítási kérdések esetén mindig van egy dilemma. Ha adott Alice és Bob és Bob arra kíváncsi, hogy Alice valóban az akinek mondja magát, akkor kell egy harmadik fél, akiben Alice és Bob is kölcsönösen megbízik. A harmadik, egyben megbízható fél jelenléte az authentikációs folyamatban azt biztosítja, hogy egyszerubben meggyozodhetünk arról, hogy Alice, valóban Alice. Ugyanis a harmadik fél látja el az azonosítási feladatot és a folyamat végén ad "valamit" Alice-nek, amit Alice nem tud elolvasni, csak Bob. Alice ezt a "valamit" átadja Bob-nak, aki eltudja olvasni azt.

Az Active Directory esetében ha ezt lebontjuk a résztvevok szintjéra akkor:

• Az egyik résztvevo fél egy felhasználó
• A másik résztvevo fél egy szolgáltatás mondjuk egy Web szerver
• A harmadik fél, akiben a szolgáltatás és a felhasználó is megbízik, a tartományvezérlo

A felhasználó ha szeretné elérni a Web szervert, akkor nem a Web szerver azonosítja ot. A felhasználót azonosítja a tartományvezérlo, majd a tartományvezérlo kiállít egy Kerberos jegyet (ez a valami), amivel a felhasználó nem tud semmit sem csinálni, csak átküldeni a Web szervernek. A Web szerver képes ezt a Kerberos jegyet elolvasni és abból megtudja állapítani, hogy a felhasználó elérheti-e a szolgáltatást vagy sem.

Honnan tudja a Web szerver azt, hogy a felhasználó elérheti-e a szolgáltatást? Hát onnan, hogy a Kerberos jegyben a felhasználó SID-jei és a csoporttagsága alapján megkapott SID-ek vannak. A Web szervert ezeket a SID-eket az adott elérni kívánt eroforrás hozzáférési listáján szereplo SID-ek listájával összehasonlítja. Ebbol már talán értheto, hogy miként muködik. A folyamatot itt leegyszerüsítettem, nem beszélek most az Access Token generálásról.

A lényeg tehát a Kerberos esetében az, hogy a Kerberos jegyben ott vannak a SID-ek, amikbol aztán az eroforrás kiszolgáló képes eldönteni azt, hogy a felhasználónak van-e jogosultsága vagy sem. Az a folyamat, amikor az eroforrás kiszolgáló eldönti azt, hogy van-e joga az adott felhasználónak azt Authorization (Authz) folyamatnak hívjuk.

Az ADFS alapú azonosítás esetében a harmadik fél az ADFS kiszolgáló. Az ADFS kiszolgálóban bízik meg mindenki. Azonban két vállalat esetében nem egy, hanem legalább két ADFS rendszerrol beszélhetünk. Ugyanis A és B vállalatnak is van egy-egy ADFS rendszere. A vállalat a saját ADFS szerverében bízik meg és B vállalat is csak a saját ADFS szerverében bízik meg. Azonban a két ADFS rendszert kölcsönösen megbízhatóvá tehetjük. Ezzel a lépéssel az biztosítható, hogy A vállalat ADFS szervere által kiadott ADFS tokent, B vállalat ADFS szervere elfogadja.

Mielott a teljes folyamatot áttekintjük, elotte bontsuk ki egy kicsit az ADFS tokent "a valamit". Talán még emlékeztek rá, a Kerberos jegyben vagy tokenben SID-ek szerepelnek (leegyszerüsítve a képet). Az ADFS tokenben azonban elsosorban nem SID-ek vannak. Úgynevezett claim-ek szerepelnek az ADFS tokenben. Claim lehet a felhasználó bármilyen tulajdonsága. Például a telefonszámát, email címét, nevét, beosztását, fonökét stb. betehetjük 1-1 claim-be. Az ADFS tokenben aztán ezek a claim-ek szerepelnek. Természetesen a felhasználó SID-je, vagy csoporttagsága is lehet egy claim, így aztán a Kerberos jegyben szerepelo információ is beteheto az ADFS tokenbe. A claim-ek használata rengeteg elonyt jelent, példák:

• Nem kell mindenhez csoportot használni
• Egyszerubb hozzáférési szabályok fogalmazhatóak meg. Pl.: ha a beosztása X akkor hozzáférhet; ha a fonöke Y és a beosztás X akkor hozzáférhet stb.
• A SID-ek csak egy AD erdoben értelmezhetoek, a claim információk viszont különbözo rendszerekben is értelmezhetoek

Képzeljük el a következo architektúrát:

Ha a vállat B kliense szeretné elérni a vállalat A web szerverét és van ADFS, akkor a folyamat a következo:

• B vállalat felhasználója megnyitja a böngészojében a Web alkalmazást
• A vállalatnál levo Web szerver tudja, hogy azonosítás kell az eléréséhez, azt is tudja, hogy ADFS azonosítás kell és azt is tudja, hogy B vállalatnál van ADFS szerver és annak mi a neve. Ezért aztán, egy HTTP redirect üzenettel válaszol B vállalat felhasználójának és átirányítja a B vállalat ADFS szerveréhez.
• B vállalat ADFS szervere, Active Directory alapú azonosítással azonosítja a felhasználót. Ezt megtudja tenni egyszeruen, hiszen tartományi tag az ADFS szerver. Ez az azonosítás lehet Kerberos vagy ADFS ürlap alapú, vagy Basic azonosítás. A lényeg, hogy ezen a ponton megtörténik az azonosítása a felhasználónak.
• B vállalat ADFS szerveréhez amikor a klienst átirányítja A vállalat web szervere, akkor az átirányításkor az is szerepel az üzenetben, hogy egyébként a felhasználó milyen alkalmazást akart elérni. Tehát amikor B vállalat ADFS szerveréhez megy a kliens, akkor azt is elmondja, hogy milyen alkalmazást akart megnyitni. Ez azért fontos, mert a B vállalat ADFS szervere, nem fog ADFS tokent minden kérésre kiállítani. Csak azoknak az alkalmazásoknak az eléréshez ad ki tokent, amit ismer. Ez azért is fontos, mert minden alkalmazásnak más és más claim-re lehet szüksége. Tehát tudnia kell azt, hogy milyen alkalmazáshoz állítja ki a tokent, mert a tokenbe azokat és csak azokat a claim-eket kell betenni, ami az alkalmazáshoz okvetlen fontos. Ezen a ponton az ADFS kiállítja a tokent és visszaküldi a kliensnek.
• A kliens a tokent elküldi a .... na minek is? A Web szervernek? Nem. A vállalat ADFS szerverének küldi el, ami képes arra, hogy azt elolvassa. Elolvassa, kibontja és ez a token alapján kiállít egy új tokent amit visszaküld a kliensnek. Ennek két fobb oka van. Az egyik ok az, hogy az A vállalat eroforrásai például a Web szerver, csak a saját ADFS szerverében bízik meg és a többi kapcsolódó vállalat ADFS architektúrájában nem bízik. A bizalmi kapcsolat az ADFS rendszerek szintjén van. A másik ok pedig az, hogy ez a folyamat lehetoséget teremt arra, hogy A vállalat az ADFS tokenben levo claim-eket manipulálja. Képzeljük el azt, hogy B vállalatnál levo AD-ben az atuhorization folyamathoz szükséges információt X tulajdonságban tároljuk. A claim neve X lesz. Viszont az A vállalatnál az X nevu claim már foglalt. Mi ilyenkor a teendo? Hát az A vállalat ADFS-e képes arra, hogy az X claim-et "átnevezze" Y claim-re, amit a web szerver már érteni fog. Summa: ebben a lépésben az A vállalat ADFS-e kiállítja az új ADFS tokent és azt átküldi a kliensnek.
• A kliens az új ADFS tokent átküldi a web szervernek, ami megbízik abban, hiszen a saját ADFS rendszere adta ki. Kibontja és a claim-ek alapján elvégzi az Authorization folyamatot.

A folyamat jó komplikáltnak tunik. És úgy tunik, hogy lassú is. A gyakorlatban azonban ha megértjük és alaposan átgondoljuk a fentieket, akkor elég nyilvánvaló a folyamat. A gyakorlatban pedig mindez nagyon gyors. Nem lassítja az elérési folyamatot a legkevésbé sem. Ami még feltuno lehet és következik a fentiekbol:

• Az eroforrás kiszolgálónak, esetünkben a web szervernek, ismernie kell az ADFS azonosítási módszert. Hiszen már az elején tudnia kell, hogy az ADFS-hez át kell irányítani a felhasználót, valamint a folyamat végén az ADFS token formátumat ismernie kell.
• A kliensnek értenie kell a HTTP redirectet és támogatnia kell az egész folyamatot. A gyakorlatban megkülönböztetünk Active és Passzív klienst és a folyamat más az egyes klienstípusoknál. Ennek a részleteibe most nem megyek bele.

Az ADFS témában írt szerintem egyik legjobb könyv amit a kezdéshez bátran ajánlok az itt érheto el ingyen: https://www.microsoft.com/en-us/download/details.aspx?id=28362 Az ADFS alapos ismertetését nem vállalom blog formában, csak személyes oktatásban. Ezért ezen a ponton elégedjünk meg a koncepció szintu megértéssel és a bovebb információkért javaslom a könyv elolvasását.

Miért érdekes ez az Exchange esetében?

Az Exchange Server temékünk eddig nem támogatta az ADFS alapú azonosítást. Igen így-úgy nem támogatott módon bekapcsolható az ADFS alapú azonosítás, de azok nem muködnek megfeleloen, nem teszteltük oket alaposan és ezért nem is támogatott megoldások. Kiváló példa erre az, hogy ami ment Exchange 2010 SP1 esetében az már SP2 és SP3 esetében nem muködik. Az Exchange Server 2013 SP1 esetében azonban ez változott. Ettol a verziótól kezdodoen az ADFS alapú azonosítás használható, támogatott. Tehát a hagyományos NTLM vagy Kerberos vagy urlap alapú azonosítás mellett lehetoségünk van arra, hogy ADFS alapú azonosítást használjunk. Ennek elonyei a következok lehetnek:

• Több AD forest esetén trust nélkül is tudunk SSO-t biztosítani
• Az Authorization során a csoporttagság helyett, gazdagabb információkat használhatunk a hozzéférés eldöntéséhez

Jelenleg csak az Exchange Server 2013 SP1 esetében támogatott az ADFS azonosítás használata.

Hogyan kezdjek hozzá egy tesztkörnyezetben?

Kezdésnek a következo elérési úton található dokumentációnkat javaslom: https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx

A legfontosabb információk és tudnivalók:

• három claim-et kell használni: user SID, group SID és UPN
• csak az OWA és csak az ECP elérésnél támogatott és használható az ADFS azonosítás
• ha ADFS azonosítást használunk, akkor minden más azonosítást ki kell kapcsolni, tehát az ADFS azonosítással együtt nem mehet Integrált, Basic vagy urlap alapú azonosítás
• az ADFS azonosítást per szerver, per virtual directory szinten kell beállítani a set-owavirtualdirectory parancs segítségével
• Orgnaizációs szinten be kell állítani azt, hogy mi az ADFS szerver elérési útja (innen tudja az Exchange, hogy hova kell átirányítani) és meg kell adni azt, hogy mi az ADFS token signing tanúsítvány.

Comments

• Anonymous
  August 02, 2014
  A felhő alapú szolgáltatások kapcsán fontos azt megterveznünk, hogy