Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is.Sok újdonsággal bővültek az Azure autentikációs szolgáltatásai is, így egy több részes blogbejegyzés sorozatban mutatjuk be az újdonságokat:
Az előző bejegyzések:
- Windows Azure újdonságok – Identitás-kezelés a felhőben I.
- Windows Azure újdonságok – Identitás-kezelés a felhőben II.
- Windows Azure újdonságok – Identitás-kezelés a felhőben III.
- Windows Azure újdonságok – Identitás-kezelésa felhőben IV.
Hagyományos Windows Server AD telepítése IaaS virtuális gépekre
Ahogy a 8. ábrán láthatod, létre kell hozni egy virtuális hálózatot az Azure IaaS gépeink fölött és telepítenünk kell a felhőben lévő VM-einkre a Domain Controller-eket (DC). Az így létrehozott virtuális hálózatot biztonságos VPN kapcsolat segítségével tudjuk összekapcsolni a földi adatközpontunkkal. A VPN-nel összekapcsolt földi és Azure-os gépeket egységbe foglaló hálózatban a DC-k különböző módokon kapcsolódhatnak egymáshoz:
- lehetnek ugyanannak az AD domain-nek
- létrehozhatsz külön domain-eket a saját adatközpontodban és a felhőben, melyek egy közös erdőhöz (forest) tartoznak
- létrehozhatsz külön erdőket a felhőben és az adatközpontban, amiket később összekapcsolsz (cross-forest trust megoldásokkal vagy akár ADFS-sel)
8.ábra
Bármelyik lehetőséget is választjuk, a lehető legjobb teljesítmény elérése érdekében a hálózat üzemeltetőjének gondoskodnia kell arról, hogy a telephelyről indított autentikációs kérések először a helyben futó AD-hoz jussanak el és itt legyenek kiszolgálva – majd csak akkor forduljunk a felhőhöz, ha a telephelyen futó AD nem elérhető.
A hagyományos AD-k felhőbe telepítése többek közt az alábbi problémákra lehet jó megoldás:
- Meglévő hibrid vállalati infrastruktúra esetében teljesítmény-okok miatt hasznos lehet, ha a felhőben futó VM-eiken is üzemeltetünk domain controller-t. Például egy felhőbe telepített SharePoint farm tipikusan olyan rendszer, ami gyakran intéz kéréseket az AD felé. Ezért sokat tud profitálni abból, ha az AD-t közvetlen a felhőből éri el és nem kell minden kérésével a földi adatközpont AD-jéhez fordulnia.
- Egy, a világ minden táján sok irodát működtető vállalat esetében előfordulhat, hogy kisebb, eldugottabb irodáiban nem gazdaságos helyben saját DC-t üzemeltetnie. Ilyen esetekben gyorsabb lehet egy, az egy nagyobb régióban elszórtan működő irodához földrajzilag közelebb eső Azure adatközpontban futtatni egy Active Directory-t, mint ha minden AD-hez intézett kérés a távoli saját fő adatközpont felé kellene továbbítani
- Adatközpontjaink hibatűrő képességét növelhetjük. A meghibásodásokra felkészülve a felhőben is tarthatunk fenn VM-eket, amiken az adatközpontban bekövetkező hiba esetén azonnal üzembeléptethető AD installáció van.
Ahogy a fenti három használati esetből is láthatod, a virtuális hálózatok kialakításával és konfigurálásával ez a megoldás a saját meglévő infrastruktúránk kiterjesztését valósítja meg. Így elsősorban üzemeltetők számára érdekes. Részletesebben ezért itt nem is foglalkozunk ezzel a témával. A következő URL-en olvashatsz a témáról bővebben:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx
Windows Azure Active Directory
A directory alapú rendszerek sokéves múlttal bíró, bevált megoldásokat jelentenek a nagyvállalati felhasználókezelésre. Ezért hasznos lenne, ha a felhőalkalmazásokból is hasonló hatékonysággal tudnánk használni őket, mint pl. a belső intranetről. A könyvben és az előző bekezdésekben olvashattál róla, hogy milyen kihívásokkal kell szembesülnünk, ha a hagyományos, telephelyünkön futó Windows Server AD-t szeretnénk rábírni a felhővel való együttműködésre. Láthattál erre megoldásokat is, mint az AD userek federálása az ADFS komponens segítségével, ill. az előző bekezdésben olvashattál a teljes Windows Server AD felhőbe költöztetéséről. Nagy vonalakban megismerhetted ezeknek az eljárásoknak a hiányosságait is, láthattad, milyen gyakorlati problémákra nem kínálnak megoldást.
Ha megnézzük, hogy mik a leggyakoribb funkciók, amiket egy enterprise felhőalkalmazás használni szeretne egy Active Directory-ból, akkor a kirajzolódó minta egészen egyszerű lesz. Két elkülönőlü használati esetet fogunk látni:
- Felhasználók autentikációja (Single Sign On élménnyel)
- Felhasználó-menedzsment, lekérdezések indítása az AD felé
A fenti két feladat megoldására jött létre a Windows Azure Active Directory (WAAD) szolgáltatás. Nevében szerepel az “Active Directory” kifejezés, és a legtöbb hagyományos AD-ből már ismert fogalom változatlanul él a WAAD-ban. Ugyanakkor fontos megérteni, hogy a WAAD maga is egy felhőszolgáltatás. Kialakításában az elsődleges szempont az volt, hogy az Azure egyszerűen provizionálható, PaaS-jellegű identitás-kezelési megoldást tudjon nyújtani a felhőalkalmazásaink számára. A két fő célja az autentikáció és a user-menedzsment megvalósítása. A hangsúly tehát a funkciókon van, a WAAD nem egy infrastruktúra-szolgáltatás. Látni fogod, hogy hasonlóan a Windows Server AD-hez felhasználókat tudsz felvenni, csoportokat alakíthatsz ki köztük stb. De fontos szem előtt tartani, hogy a WAAD nem egy felhőben üzemeltetett Domain Controller. Ennek eredményeként nincs lehetőséged arra, hogy egy fizikai PC-t csatlakoztass egy WAAD domain-hez. Ha “machine fleet management” megoldásra van szükséged, akkor a WAAD nem a számodra megfelelő megoldás – ebben az esetben a hagyományos Windows Server AD-t kell választanod.
Ezeket az újdonságokat Te is kipróbálhatod! Regisztrálj az ingyenes, 90 napos Azure előfizetésre!
