Az Azure oldaláról több fejlesztés és módosítás is történt aminek a következménye az, hogy támogatot a megoldás. Azonban fontos kiemelni ennek a bejelentésnek a margójára néhány gondolatot:

• Csak akkor támogatott, ha az összes Exchange adatbázis és adatbázis log, Azure premium storage-on van elhelyezve. Egyéb kialakításban nem támogatott a megoldás. Ez nem meglepo, teljesítmény okokból (is) szükséges ez a kitétel.

• A legjobb felho alapú Exchange szolgáltatás az Office 365. Ha az Exchange szervereid a felhoben futtatod, akkor használd helyette az Office 365-t. Jobb lesz a szolgáltatás minosége, kevesebb feladatod lesz és várhatóan olcsóbb is lesz, lásd elozo pont, a premium storage nem olcsó. Ha nem aggódsz az adataid miatt az Azure szolgáltatásban való futtatás kapcsán, akkor az Office 365 kapcsán se tedd.

• Az Exchange szerver akkor boldog, ha gyors kapcsolaton eléri a DNS szervereid és a tartományvezérloket. Az Exchange önmagában még kevés, megfelelo számú tartományvezérlot is ki kell tenned.

Ahogy a második pontban írtam, mi úgy gondoljuk, hogy a legjobb felho alapú Exchange az Office 365. Mégis akkor miért készítettük el ezt a szolgáltatást?

• Ideiglenes szerver – kellene ideiglenesen egy Exchange a környezetedbe de nincs hardware? Nyílvánvaló, hogy használjuk a Microsoft Azure szolgáltatást erre. Példa: hybrid együttélés kialakítása Office 365-el.

• Teszt / fejlesztoi környezet – szükség lenne tesztelésre, alkalmazások fejlesztésére egy környezet? Nyílvánvaló, hogy használjuk a Microsoft Azure szolgáltatást erre. Példa: hotfix / service pack kipróbálása.

• Disaster recovery szolgáltatás – az Exchange környezet on-premises fut, azonban a Microsoft Azure a Disaster Recovery adatközpont? Sebaj, az Exchange is használható a DR telephelyen. Példa: az elsodleges telephely tönkrement, aktiváljuk a Microsoft Azure-t.

Pontos leírások és útmutatások a kialakításhoz késobb lesznek elérhetoek. Jó kis kaland tesztelni, de nagyon éljük bele magunkat. Office 365-re fel.

A legegyszerubb modell az, amikor a felhasználónak a cloud szolgáltatásban egy új, mindentol független felhasználói azonosítója van és ahhoz tartozik egy jelszó. Ennek az új felhasználói objektumnak semmilyen kapcsolata nincs a felhasználó vállalati azonosítójával. Egyetlen közös az ember, aki mindkét felhasználói objektumot használja. Egyszeru ez, a felhasználó ha a cloud szolgáltatást szeretné használni, akkor a cloud azonosítóját adja meg, ha a vállalati rendszereket, akkor pedig azt adja meg. Egyszeru, de nem felhasználóbarát. A következo ábrán ez látható. Kiss Pista képzeletbeli felhasználónk a vállalatánál rendelkezik, egy AD felhasználóval és a felhoben egy másik felhasználóval. A ketto felhasználói objektum önálló életet él.

Ennek az egyszeru megoldásnak a jellemzoi:

• A felhasználói objektumok és jelszavak kezelése a felhoben és a helyi címtárban történik. Tehát új felhasználó létrehozása, meglevo törlése, tulajdonságok módosítása, jelszó változtatása stb. mindkét címtárban elvégzendo feladat. Ez pedig extra munkát igényel.

• A vállalati infrastruktúrában levo jelszóházirendek és szabályok nem érvényesülnek a felhoben létrehozott objektumokra.

• A felhasználónak több felhasználónevet és jelszót kell megjegyeznie, ami automatikusan csökkenti a felhasználói elégedettséget és a biztonságot is.

Az elozo megoldásnak egy másik módja az, amikor a felhasználónév és a jelszó megegyezik. Az authentikáció és az authorizáció továbbra is a cloud szolgáltatásnál és szolgáltatónál történik. Az azonosításnak nincs köze, a vállalati címtárhoz, az Active Directory-hoz. Egyetlen optimalizáció a rendszerben az, hogy a végfelhasználó használhatja ugyanazt a felhasználónevet és jelszót a szolgáltatások eléréséhez. De hogyan biztosíthatjuk azt, hogy a felhasználónév és a jelszó megegyezzen ég és föld, vagyis a saját infrastruktúránkban levo AD és a felho szolgáltatás között? A felhasználónév esetében egyszeru a dolgunk, mert úgy hozzuk létre a felho szolgáltatás esetében a felhasználót, hogy az UPN neve megegyezzen a helyi címtárban levovel. Mondjuk mindkét esetben usera@contoso.hu nevet adunk a felhasználónak. A jelszó esetében viszont már nincs könnyu dolgunk adminisztrátoroknak. Ugyanis azt a felhasználók adják meg és két helyen kell nekik jelszót megadniuk. A helyi és a felho címtárban. Így aztán elérkeztünk kb. 2.5 oldal után oda, hogy ez egy közepes vállalatnál és attól nagyobb környezetekben elfogadhatatlan és valami mást kell biztosítanunk. Amit keresünk az a Szinkronizáció. Így nagybetuvel.

Szinkronizáció

A Microsoft cloud szolgáltatások mögött egy egységes Active Directory szolgáltatás áll. Ez az Azure Active Directory. A helyi címtárunkban levo felhasználói objektumokat és csoportokat az Azure AD-val (AAD) egyszeruen szinkronizálhatjuk. Ennek elonye az, hogy automatizálható és ha kialakítottuk akkor a felhasználók kezelésének a helye továbbra is maradhat a helyi címtárunk. A változások szinkronizálódni fognak az AAD-ba. Például egy új felhasználó létrehozása, egy meglevo törlése, telefonszám módosítása stb.

A jelszavak esetére két lehetoségünk van:

• Jelszó szinkronizáció – ebben az esetben a felhasználónak a jelszavát (csak a HASH-t) is szinkronizáljuk az AAD-ba. Így a felhasználó ugyanazt a felhasználónév / jelszó párost használhatja a vállalati környezetének az elérésére és a felhoszolgáltatás elérésére. Illetve a felhasználónak elég a vállalati környezetben megváltoztatnia a jelszavát, a változás szinkronizálódik az AAD-ba is.

• Federáció kialakítása – ebben az esetben a felhasználói azonosítás (authentication) a helyi környezetben muködo ADFS szerveren történik. Az atuhorizáció van csak a felhoben. Az ADFS-rol részletesebben itt írtam: http://blogs.technet.com/b/zoltanh/archive/2014/03/22/adfs-233-s-az-exchange-server-2013.aspx . Federáció használata esetén nincs szükség arra, hogy a felhasználónak a jelszava az AAD-ban elérheto legyen.

Az AAD-val történo szinkronizáció elso és legegyszerubb eszköze a DirSync (Microsoft Azure Active Directory Sync). A használata egyszeru, nem túl komplikált eszköz. Segítségével a felhasználóinkat és csoportjainkat szinkronizálhatjuk az AAD-ba. További képességei:

• Jelszó szinkronizáció – AD-ból az AAD-ba

• Exchange Hybrid deployment – az Exchange Hybrid együttmuködéshez szükséges az AAD-ból az AD-ba visszaírni. Ezt is képes a DirSync elvégezni.

A DirSync eszköznek azonban van néhány korlátja:

• Egy erdo támogatása – ha a vállalatunknál egynél több Active Directory erdo (nem tree és nem domain) van, akkor a DirSync nem használható. Nem tud több AD erdot szinkronizálni egy O365 Tenantba.

• Nincs szurési lehetoség – nincs hivatalosan támogatott mód arra, hogy szurjük, hogy kiket szinkronizál az AD-ból az AAD-be. Ha a DirSync-et beállítottuk, akkor az az AD-ban levo összes felhasználót és csoportot szinkronizálja az AAD-ba.

A fenti két korlát kezelésének a módja a FIM. A FIM és a DirSync testvérek. Mindkét eszköz a Synchronization Service-re épül, aminek elég kalandos volt az életútja. Míg a DirSync az egy elore csomagolt ’gyorskaja’, addig a FIM segítségével bármilyen étel fozheto. A DirSync nem módosítható, cserébe az ügyfélhelyzetek 80%-át lefedi. A maradék 20%-ra, pedig ott a FIM, amit hozzáérto ember képes bekonfigurálni. A FIM-hez elérheto a Forefront Identity Manager Connector for Windows Azure Active Directory. Így szinkronizálhatunk tulajdonképpen bármit az AAD-hez. Akár 60 Active Directory erdot is, ahogy erre nemrég volt is példa. A hátránya ennek a megoldásnak az, hogy nagyon drága. A szoftver maga nem, azonban a jó szinkronizáció kialakítása nem egy vagy két nap. A helyzetet tovább nehezíti az, hogy a FIM-hez érto szakemberek száma elég kevés. Szóval komplikált, hosszan elhúzódó projectek ezek általában.

Ez a blogot viszont az ihlette, hogy már nincs szükség többé a FIM-re a komplex szinkronizációs esetekben sem. A napokban jelent meg az AAD Sync Beta2-es verziója. Az eszköz nagyon hamar végleges verziójában is elérheto lesz. Hamarabb mint gondolnád. Az AAD Sync leváltja a DirSync eszközt. A FIM Connector ugyan megmarad egyelore, azonban nem az a preferált út. Új deployment során az AAD Sync-et javasoljuk használni mert ötvözi a DirSync és a FIM Connector minden elonyét. Többek között támogatja a több AD erdo használatát, támogatja a tulajdonságok szurését, az Exchange Hybrid együttélést, valamint az összes O365 szolgáltatást.

Az eszköz telepítheto és támogatott:

• Windows Server 2008 / 2008 R2 / 2012 / 2012 R2 OS-en

• Tartományvezérlon, tagkiszolgálón, munkacsoportban

• SQL Server 2008 / 2008 R2 / 2012-el vagy helyben telepített SQL Express-el (default). Az SQL szerver lehet local, vagy távoli.

Az eszköz használata és telepítése egyszeru:

• Telepítsük elofeltételként a .NET 3.5-t a kiszolgálóra. Ez a Beta2 elofeltétele. A végleges verzióban erre nem lesz szükség.

• Töltsük le a telepítokészletet

  

• Indítsuk el a telepítokészletet. A telepítés elevációt igényel

  

• A telepítokészlet minden szükséges elofeltételt telepíti. A grafikus telepíto nem ad lehetoséget arra, hogy távoli SQL szerverhez vagy az AAD Sync szerverre telepített SQL szerverhez csatlakozzon. A grafikus telepíto, automatikusan telepíti az SQL Express-t a gépre és annak használatára konfigurálja magát. Ha távoli SQL, vagy helyben telepített SQL szerverhez szeretnénk az eszközt konfigurálni, akkor a grafikus telepítés helyett válasszuk a parancssori verziót.

• A telepítokészlet minden szükséges elofeltételt telepít

  

• A sikeres telepítés után meg kell adnunk az AAD global admin joggal rendelkezo felhasználónkat. Ennek a nevében fog csatlakozni a Tenant-hoz az eszköz.

• Következo lépésként adhatjuk hozzá az AD erdoket forrásként az eszközhöz. Meg kell adni az erdo nevét és a felhasználónevet és jelszót amivel csatlakozni tud az AD erdohöz az eszköz. A felhasználónevet NETBIOSDOMAINNAME\UserName formátumban adjuk meg.

  

• Az ADD forest gomb megnyomása után a kezelt erdok között a frissen hozzáadott erdo megjelenik. Ha több erdonk van, akkor itt a többit is hozzáadhatjuk.

• A legkomplikáltabb konfigurációs oldal a rendszerben ez. Ha több AD erdonk van forrásként akkor akár az is elofordulhat, hogy ugyanaz a felhasználó egynél több erdoben is szerepel. Az viszont nem lenne szerencsés, ha minden erdobol a felhasználónak az egyetlen felhasználói azonosítóját szinkronizálnánk az AAD-be. Ennek kiküszöbölésére meghatározhatjuk azt, hogy ha több eronk van, akkor a felhasználók: a, csak egy erdoben vannak; b, milyen tulajdonság egyezosége alapján tudja eldonteni az AAD Sync, hogy ugyanarról a felhasználóról van szó.

  

• Hogy tovább komplikáljuk ezt a konfigurációs ablakot, itt kapott szerepet az is, hogy az AAD-ban levo objektummal való egyezoség milyen attributum alapján kerüljön eldöntésre. Az alapértelmezett beállítás itt az objectGUID ami az esetek túlnyomó többségében tökéletesen megfelelo beállítás.

• Engedélyezhetjük az Exchange hybrid szinkronizációt csak úgy mint korábban, valamint lehetoség nyílik az AAD alkalmazás és tulajdonság szurésre. Ezt kiválasztva lehetoségünk nyílik az egyes AD tulajdonságok szinkronizálásának engedélyezésére / tiltására. Ezt azonban akkor és csak akkor tegyük, ha arra külön igényünk van. Nem gondoljuk, hogy az esetek túlnyomó többségében erre szükség volna. A szükséges és elégséges tulajdonsághalmazt szinkronizáljuk.

• A Configure parancs segítségével elindíthatjuk a Sync service konfigurálását. A megadott adatok alapján a varázsló a Sync service-ben létrehozza a szükséges Management Agent-eket és azokat helyesen bekonfigurálja.

• A sikeres konfigurálás után, elindíthatjuk a szinkronizáció azonnal:

  

• A szinkronizáció az AD erdok számától és az azokban levo objektumok számától függ. A szinkronizáció egyes lépéseirol információt kapunk a parancssori eszköztol.

• Az eszköz a %SystemDrive%\Temp könyvtárba naplózza a telepítés lépéseit.

• Az eszköz 3 óránként szinkronizál automatikusan! Jelenleg ennek módosítása nem támogatott.

Látható tehát, hogy az AAD Sync egy egyszeru eszköz, aminek a segítségével két korábbi eszköz képességeit egyesíthetjük egyszeruen. Érdemes elkezdeni az ismerkedést vele.

Amikor elkészítesz egy Edge Sync-et, akkor egy temp crendential kerül létrehozásra. Ez 1440 percig (1 nap) érvényes. Az Exchange az Edge Sync létrehozásakor és késobb is rendszeresen változtatja a credenital jelszavát. Active Directory telephelyenként van egy credential. Azonos AD telephelyen levo Exchange szerverek azonos credential-t használnak az EDGE szerverekhez való csatlakozáshoz. A Credenital Manager-en keresztül történik ennek a credential-nek a módosítása az Edge szerveren / szervereken. Azonban eddig ismeretlen ok miatt az Exchange Server 2013 alapú Edge szervereken a Credential Manager szolgáltatás indítási módja, Manual. Ezért a service nem indul el, ezért aztán az Exchange nem képes a credential-t módosítani. Így aztán 1 nap után a temp credential lejár és a szinkronizáció szétesik.

A megoldás a következo:

1. Állítsd át a Credential Manager szolgáltatás indítási típusát Manual-ról Automatic-ra
2. Indítsd el a szolgáltatást
3. Az Edge szerveren a New-EdgeSubscription segítségével készíts egy új Subscription fájlt
4. Az Exchange szervereden fejezd be az Edge sync létrehozását -- New-EdgeSubscription http://technet.microsoft.com/en-us/library/bb123800(v=exchg.150).aspx

Ha használsz Exchange Server 2013 alapú Edge szervert, akkor célszeru ellenorizned a Credential Manager szolgáltatásod állapotát.

Mindenki életében legalább egyszer eljön az a pillanat Exchange Server kapcsolódási hiba keresése során, hogy az Outlook kapcsolódási állapotát kell vizsgálja. A saját munkánk könnyítésére úgy kb. 10 évvel ezelott egy nagyon hasznos funkció került be az Outlook kliensbe. Ez pedig a Connection Status ablak. Az ablak elocsalogatása „egyszeru”. A billentyuzet bal oldali CTRL gombját nyomva tartva, az értesítési területen az Outlook ikonon az egér jobb gombjával kell kattintani, majd a megjeleno helyi menüben megtaláljuk a „Connection Status…” menüpontot. Aham, logikus és misem egyszerubb ennél. Sicc. :)

Lendüljünk tova azon, hogy miként érheto az el. A lényeg, hogy megvan. Ha elindult, akkor egy ablakot fogunk látni, amiben sok sor, és még több oszlop látható. Valami ilyesmi:

E sorok írásakor éppen repülon ülök az öreg kontinens felett és nincs WIFI, ezért nincs kapcsolatom. Ha erre eddig nem jöttem volna rá, akkor a Connection Status rávezet szépen, némi asszociáció után.

Hajlamosak vagyunk azt gondolni, hogy az itt látható információk tökéletesen egyértelmuek. Bevallom én is ebbe a hibába estem, sokunkkal együtt. Azonban Richard rávezetett, hogy tévedtem, ezért köszönet neki. A felvetésére elkezdtem végiggondolni, hogy vajon minden sor és oszlop értheto és egyértelmu? Voltak olyan oszlopok amiket csak hosszas kutakodás után sikerült csak megértenem. Szóval értem, hogy ez frusztráló lehet másoknak is. Ezért próbálok segíteni és az oszlopokhoz és a sorokhoz némi magyarázattal szolgálni.

Nem ígérem, hogy teljesköru lesz a leírásom. Ennek az az oka, hogy az oszlopok Outlook kliens verziónként és Windows verziónként eltérhet. Ahogy az oszlopok értékei is eltérhetnek egy-egy esetben és néhány helyzetben nem is értelmezhetoek. Nem vállalkozom arra, hogy az összes Outlook verzió + összes Windows verzió + összes létezo Exchange kapcsolódási verziót leírjam, mert ez egyszeruen túl sok.

Abban viszont biztos vagyok, hogy a legtöbb korunk helyzetét a magyarázatom lefedi. Úgy mint Outlook 2007+ és Exchange Server 2010+ kapcsolódás. A tisztán RPC és már nem támogatott Exchange Server 2003 (de szerettem) környezeteket nem célom lefedni információval.

A blog idoállóságával kapcsolatban van némi fenntartásom. Bármikor, ha a valós élet úgy hozza, akkor bármilyen értesítés nélkül átfogjuk alakítani ennek az ablaknak az oszlopait vagy a megjelenített adatokat. A cél itt az, hogy a leggyakoribb hibák könnyu kezelésére, kiszurésére használjuk ezt az eszközt, aminek a legnagyobb felhasználói a Microsoft terméktámogatási szakemberek. Amolyan melléktermékként profitál belole mindenki más is.

Mielott rákanyarodnék az információkra, elotte még egy gondolat. Képzeljünk el egy hatalmas szerszámosládát. Benne rengeteg szerszámmal. Ha belenézünk, akkor tudjuk az összes eszközrol azt, hogy mire való? Ha kiveszünk egy eszközt, akkor annak az összes funkciójával maradéktalanul tisztában vagyunk? Ha az összes funkcióját ismerjük, akkor használjuk az összeset? Ha használjuk az összeset, akkor mindegyik funkcióhoz tartozóan ismerjük a fizikai, kémiai törvényeket, hogy miként muködik? Jó eséllyel találunk ebben a példában olyan kombinációkat, ahol a válasz végig: nem. Sot ha jobban belegondolok, akkor ez van többségben. Nos, az Outlook Connection Status ablakban levo összes információ egy-egy eszköz. Gondoljatok erre így. Az ablak maga pedig a szerszámosláda. A jó munkás ember, rendre dobálja bele az újabb és újabb szerszámokat. Néha ki is vesz belole, de csak néha. Szükség van úgy általában az összesre? Nem. Mindegyik mögött értjük a valós muködést? Nem. Kell, hogy értsük a fizikai törvényeket ahhoz, hogy egy csavart becsavarjunk? Nem okvetlenül. Biztosan jobban tudunk az információ birtokában csavarozni? Nem okvetlenül. Szóval gondoljatok ezekre az információkra is valahogy így.

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: http://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: http://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.

Az, hogy ma írok, azt jelenti, hogy az éjszakám rövid volt. Exchange Server 2013 SP1-et terítettünk egy nagy környezetben. Minden jól ment, néhány apróságot leszámítva és azt, hogy hajnalig dolgoztunk. Reggel, azonban megérkezett az elso probléma:

• Néhány felhasználó nem éri el az OWA-t és a következo hibaüzenetet kapja:
• 

Csak, hogy a keresok, helyesen indexeljék, kiemelem, tehát a hiba: "X-OWA-Error: Microsoft.Exchange.Security.Authentication.TokenMungingException"

A hibát az okozza, ha olyan felhasználóval próbálunk belépni, aminek a recipientTypeDetails értéke RoomMailbox vagy LinkedMailbox. Itt egy példa a RoomMailbox-ra, lekérdezheto a get-mailbox <alias> |fl *type* paranccsal (is):

A terveink szerint a RoomMailbox típusú postaládával nem lehet bejelentkezni OWA-n keresztül. Ezt el kell fogadnunk és általában nem is itt szokott probléma lenni. Inkább a LinkedMailbox esetén merül fel pár kérdés. Ezeket igyekszem logikusan leírni:

• Mi az a LinkedMailbox? - egy Exchange Organizáció, egy Active Directory erdohöz van rendelve. Több erdohöz nem tudod az Exchange Organizációt rendelni (apró érdekesség, hogy annó, az Exchange 5.0 / 5.5 idejében egy Exchange Organizáció több NT 4.0 tartományhoz is "kapcsolódhatott", kommentben jöhet a tipp, hogy miért). Ebbol az következik, hogy a postaládákat amiket egy Exchange organizációban hozunk létre, azt csak egy Active Directory erdoben levo Active Directory felhasználóhoz rendelhetjük hozzá. De mi van azokkal az ügyfelekkel akiknek több Active Directory erdojük van? Nekik kötelezoen több Exchange Organizáció kell? A válasz az, hogy nem. Erre való a LinkedMailbox. Az Exchange Organizáció AD erdojében létrehozunk egy felhasználót ami tiltott állapotban van. A postaládát ehhez a tiltott felhasználóhoz rendeljük hozzá. Majd a másik AD erdo felhasználóját, hozzá linkeljük ehhez a postaládához. Ezzel azt érjük el, hogy egy olyan erdoben levo felhasználónak adunk postaládát, ahol valójában nincs Exchange Organizáció. Természetesen a két Active Directory erdo között trust kapcsolat kell vagy ha az erdok több tartományból állnak, akkor elég a két tartomány között trust kapcsolat.
• Honnan tudom, hogy egy postaláda LinkedMailbox? -- onnan, hogy van egy olyan tulajdonsága minden postaládának, hogy isLinkedMailbox. Ennek értéke lehet, true vagy false. Ha true, akkor az linked mailbox. Ha false, akkor nem.
• Honnan tudom, hogy egy LinkedMailbox-hoz ki van hozzárendelve? - van egy olyan tulajdonsága minden postaládának, hogy linkedMasterAccount. Ennek az értéke, a másik erdoben levo felhasználó SID-je.
  
• Mi nem LinkedMailbox? - az helytelen LinkedMailbox, ha az isLinkedMailbox értéke true és a linkedMasterAccount értéke nem egy másik AD forest felhasználójára mutat. Az ilyen linkedMailbox beállítását helytelennek tekintjük.
  

A LinkedMailbox legfontosabb beállításait egyszeruen lekérdezhetjük:

Tehát mi nem muködik az SP1 esetén?

• RecipientTypeDetails = RoomMailbox, akkor nem lehet bejelentkezni OWA-n
• RecipientTypeDetails = LinkedMailbox és a LinkedMasterAccount értéke nem egy másik AD forest felhasználójának SID-jére mutat (pl.: SELF, vagy a postaláda account-ja), akkor nem lehet bejelentkezni OWA-n
  

Azonban ha a felhasználó rendesen beállított LinkedMailbox, akkor az OWA bejelentkezés muködik helyesen.

Adódik a kérdés, hogy a helytelenül beállított LinkedMailbox-al mit lehet valójában csinálni? Konvertálni kell hagyományos UserMailbox-ra a következo módszer segítségével: http://technet.microsoft.com/en-us/library/bb201694(v=exchg.141).aspx. A parancs amit használhatunk:

• Set-User -Identity zoltanh@fabrikam.hu -LinkedMasterAccount $null

Ezzel kiütjük a LinkedMasterAccount értékét és a felhasználó RecipientTypeDetails értéke UserMailbox -ra változik. Ezután a felhasználó használhatja az OWA-t.

Az, hogy miért van a rendszerben helytelenül beállított LinkedMailbox, helyes kérdés lehet. Általában ezek nagyon régi környezetek maradékai. Az adott környezet amiben ez a hiba elojött, legalább Exchange 5.0 óta létezik és az a néhány tucat felhasználó és postaláda már az eredeti rendszer óta muködik. Egy új környezetben ilyen állapot nem várható.

Azt tanácsolom, hogy ha a fenti hibát tapasztaljátok, akkor érdemes a fenti logikai fonálon elindulva a hibakeresést elvégezni, a következo kérdések megválaszolásával:

• RoomMailbox az adott postaláda? - ha igen, akkor nincs további teendo mert ez az elvárt muködés.
• LinkedMailbox az adott postaláda? - ha igen, akkor a LinkedMasterAccount egy másik forest felhasználójára mutat? Ha nem, akkor konvertáljuk a felhasználót.

Most, hogy megjelent az SP1, annak telepítése után engedélyezzük. A frissített, MAPIHTTP képes eszközeink profitálni fognak belole. Röviden áttekintjük most azt, hogy mit is kaptunk az SP1-el, mi az alapértelmezett beállítás, valamint azt, hogy hogyan tudjuk engedélyezni a szolgáltatást gyorsan és egyszeruen.

Mit kaptunk az SP1-el?

Az SP1 szerver oldali telepítésével létrejött egy Organization szintu új beállítási lehetoség. Ez az új Organization szintu tulajdonság a MapiHttpEnabled (true / false). Alapértelmezésben ennek értéke false, tehát ki van kapcsolva a MAPIHTTP szolgáltatás. Az Organization szintu beállítás mellett 1-1 új Virtual direcotry-t is kaptunk az IIS-ben, a back-end és a default web site alatt. Természetesen a MAPIHTTP esetében is követjük a proxy logikát és az új architektúrát, csak úgy mint az összes többi protokoll és alkalmazás esetében. Ezért hát a két virtual directory.

Tehát alapértelmezett beállítások esetén a MAPIHTTP nem muködik. Ezen a ponton még minden kliens RPC/HTTP protokoll segítségével kapcsolódik az Exchange szerverhez, ahogy az az én környezetemben is látható:

Engedélyezzük

A szolgáltatás engedélyezése viszonylag egyszeru feladat. Az Organization szintu beállítás értékét false-ról, true-ra kell állítanunk, amit a következo parancs segítségével egyszeruen elvégezhetünk: Set-OrganizationConfig -MapiHTTPEnabled $true

Ha a parancs sikeresen lefutott, akkor készen is vagyunk. De csak részben. Ezen a ponton a MAPIHTTP képes kliensek az AutoDiscover válaszban visszakapják a MAPIHTTP beállításokat. Ezt egyszeruen ellenorizhetjük a Test E-mail AutoConfiguration futtatásával:

A többi beállítás mellett, a kliens megkapja a MAPIHTTP elérési utat. Abból is rögtön kettot, egyet a postaláda eléréséhez (MailStore) és egyet a címjegyzék eléréséhez (Address book), ami az NSPI végpont. A fenti Autodiscover válaszban jól látszik az, hogy a szerver neve az Exchange kiszolgálóm belso FQDN címe és a külso, Internetre publikált nevét nem tartalmazza a válasz. Ennek az oka az, hogy mint bármelyik másik virtual directory, a MAPI virtual directory is rendelkezik egy externalURL és egy internalURL tulajdonsággal. Az externalURL alapértelmezésben nincs kitöltve:

A Set-MAPIVirtualDirectory cmdlet segítségével megadhatjuk a külso elérési nevet. Jelenleg a parancs futtatásakor meg kell adni az IISAuthenticationMethod értékét is:

Ha most újra futtatod a Test E-mail AutoConfiguration-t akkor azt várhatod, hogy ott lesz a külso és a belso elérési pont is. Azonban nem ez fog történni ez szinte biztos. Azért nem, mert az AutoDiscover alkalmazásnak szerver oldalon van egy gyorsítótára (cache), amibe az Exchange beállításokat letárolja. Így ha valamilyen értéket módosítasz, akkor arra az AutoDiscover nem fog azonnal reagálni és még a régi beállítások alapján fog válaszolni. A cache törlésének a legegyszerubb módja az, ha újraindítod az MSExchangeAutoDiscoverAppPool -t (ne rémülj meg, ha leállítod, utána 1-2 mp-ig hiába is nyomod a Start gombot, csak hibát kapsz, hogy nem tud elindulni. Várj nyugodtan pár mp-et. Természetesen ezido alatt a szervered az AutoDiscover kéréseket nem szolgálja ki):

Ha az újraindítás megtörtént, akkor a Test E-mail AutoConfiguration segítségével a teszteléskor azt fogod látni, hogy a külso és belso elérési pontokat egyaránt válaszként visszaküldi az AutoDiscover:

Hurrá, ezzel már majdnem készen is vagyunk. Már csak egy pont van, amire gondolni kell. Az pedig a külso kapcsolódás esetén a tuzfal. Általában korlátozott az, hogy milyen elérési utra érkezo kéréseket engedünk be az Exchange kiszolgálóhoz. A MAPIHTTP protokoll esetében a tuzfalon az RPC over HTTP publikációs szabályunkat ki kell egészíteni úgy, hogy a /mapi virtual directory-t is engedélyezzük. TMG esetében egyszeruen adjuk hozzá a /mapi/* elérési utat a PATH-hoz:

Ezzel az új protokollt sikeresen engedélyeztük, azt konfiguráltuk. Ha átgondoljuk, akkor a következoket tettük:

1. Engedélyeztük Organization szinten a protokollt
2. Beállítottuk a külso elérési pontot a MAPI virtuális directory-n, valamint az azonosítást
3. Engedélyeztük a tuzfalon a külso hozzáférést

Az 1-es és 2-es lépéseket azonban nem jó sorrendben hajtottuk végre. :) Nagyobb tétben mernék fogadni, hogy az ügyfelek is ebben a sorrendben fogják elvégezni. De mi ezzel a baj? Nagy baj nincs de nem szép. Ha Org szinten engedélyezzük a protkolt úgy, hogy még nem állítottuk be a szükséges külso és belso URL értékeket és azonosítási módszereket, akkor könnyen elofordulhat az az eset, hogy az Outlook kliensek már megkapják a nem végleges beállításokat és az alapján próbálnak meg csatlakozni a szerverhez. Ez nem fog mindig és minden helyzetben problémát okozni, de lássuk be, hogy akár okozhat is kapcsolódási problémát. Ezért aztán a helyes sorrend az, hogy elobb beállítjuk a külso és belso URL értékeket, az azonosítási módszert és csak utána engedélyezzük Org szinten a protkoll használatát. Halmozottan igaz ez akkor, ha egynél több szerverünk van.

Mi fog történni az engedélyezés után?

Outlook 2013 SP1 esetén az Outlook szólni fog, hogy indítsuk újra az Outlook-t mert olyan változtatást végzett a Rendszergazda, hogy csak na. :)

Ezt a kliens akkor fogja feldobni, ha már megkapta az AutoDiscover-tol az új beállításokat. Rendszeres idoközönként (alapértelmezésben 2 óra) az Outlook kliens érdeklodik, hogy van-e új konfiguráció. Ha van, akkor azt alkalmazza. Nos, ha megkapja a MAPIHTTP beállításokat és azt alkalmazza, akkor szól, hogy indítsuk újra. Tudom-tudom, már megígértük, hogy többet nem lesz ilyen...

Az újraindítást követoen néhány apróság tunhet fel:

• A szerver neve megváltozott és látható, hogy a /mapi/ elérési útra mennek a kérésék. A használt protokoll pedig HTTP.
• 
• Ha az Outlook profil beállításait közelebbrol megnézzük, akkor észrevehetjük azt, hogy az egész Outlook Anywhere beállítási panel eltunt. Ne is keressük többé. Viszlát. :)
  
• 
  

Az Outlook 2013 SP1 elotti kliensek a szolgáltatás engedélyezésébol nem tapasztalnak semmit. Ennek az az oka, hogy az Autodiscover kliens jelzi azt a szerver felé, hogy érti a MAPIHTTP-t. Az AutoDiscover szerver oldali komponens ezt értelmezi és csak a MAPIHTTP képes klienseknek adja vissza az AutoDiscover válaszban a MAPIHTTP beállításokat. Így aztán azok a kliensek amik nem értik ezt a protkollt, nem is kérik ezt a beállítást. Tehát nincs hatással a nem kompatibilis kliensekre a beállítás. Hosszú együttélési idore kell berendezkednünk de az új idoszámítás ezzel elindul.

• Service Pack 1 for Microsoft Office 2013 (KB2817430) 32-Bit Edition -- http://www.microsoft.com/en-us/download/details.aspx?id=42017
• Service Pack 1 for Microsoft Office 2013 (KB2817430) 64-Bit Edition -- http://www.microsoft.com/en-us/download/details.aspx?id=42006

• Exchange Server 2013 SP1 -- http://www.microsoft.com/en-us/download/details.aspx?id=41994
• Exchange Server 2013 SP1 UM language pack -- http://www.microsoft.com/en-us/download/details.aspx?id=41997

A legfontosabb újdonságok a csomagban:

• Visszatért az Edge szerver szerepkör
• SMIME kontroll az OWA-ban
• Új DLP funkció, bovebb információ itt olvasható -- http://blogs.technet.com/b/exchange/archive/2014/02/25/data-loss-prevention-in-exchange-just-got-better.aspx
• MAPIHTTP funkció, bovebb információ itt olvasható -- http://blogs.technet.com/b/zoltanh/archive/2014/01/30/mapihttp.aspx
• ADFS alapú azonosítás támogatása
• ECP-n command logging – segítségével a végrehajtott muveletek powershell parancsait láthatod
• Windows Server 2012 R2 támogatás

Hivatalos bejelentés késobb érkezik.

A frissítés menete csak úgy mint korábban, a setup /m:upgrade paranccsal végezheto el. Ahogy az összes CU, úgy természetesen az SP1 is bovíti a Schema-t.