Seamless SSO – AZUREADSSOACC

Egyszer volt, hol nem volt, telepítésre került az Azure AD connect és a sok kijelölhető opció közül bepipálásra került az “Enable single sign-on” lehetőség, mert ezzel tuti jó lesz a felhasználói élmény 🙂

Aztán böngésszük az on-premise AD-t (Private cloud AD – csak, hogy maradjunk a hivatalos megnevezéseknél) és találunk egy computer accountot, ami valahogy, valamikor létrejött, aminek a neve “AZUREADSSOACC”. Bizonyám ez összefügg azzal az opcióval amit kipipáltunk. De ez miért jött létre? Mire kell? Hogyan működik? Na ezt nézzük meg.

Az nem kérdés, hogy szeretnénk növelni a felhasználói élményt úgy, hogy a biztonság ne sérüljön, tehát a felhasználó által a private cloud-ban megszokott szolgáltatások elérése, ugyanúgy működjön a felhőben is, tehát ne kelljen újból és újból megadni a felhasználói-jelszó párost. Igen, a kerberosról beszélek.

Bizony, ezért jött létre ez a computer account, ami nem más mint az Azure AD “megszemélyesítése”. De hogyan működik? Vizsgáljuk meg.

  1. Felhasználó be szeretne jelentkezni egy felhős web app-ba.
  2. Az App átírányítja az Azure AD-hoz.
  3. Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
  4. A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
  5. A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
  6. Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
  7. A felhasználó böngészője elküldi a titkosított kerberos ticketet.
  8. Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
  9. Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
  10. Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.

Remélem hasznos volt! 🙂

Üdv.:
NLB

Administrative units (AU) – Azure AD

Egy ideje elérhető egy új funkció az Azure AD-ban, ami “Administrative units” névre hallgat. Igaz még “csak” preview fázisban. Az Azure portálon az Azure AD-n belül itt található:

De mire jó ez? Egyszerű. Logikai egységeket tudunk létrehozni, amelyekben jelenleg még “csak” felhasználókat és csoportokat tudunk definiálni, a vállalatunk felépítése alapján, például földrajzi szempontból. Az “+Add” gombra kattintva tudjuk az egységeket létrehozni egy név megadásával, valamint egy leírást is hozzá tudunk adni.

Miután létrehoztuk és megnyitjuk az AU-t, akkor az alábbi lehetőségek közül választhatunk.

A Manage rész alatt a következő lehetőségek jelennek meg:

  • Properties (Alap tulajdonságokat tudunk módosítani, mint például a “Displayname”)
  • Users (Hozzá tudjuk adni azon felhasználókat, akik a szervezeti egységekhez tartoznak)
  • Groups (Hozzá tudjuk adni azon csoportokat, akik a szervezeti egységekhez tartoznak)
  • Roles and administrators
    Na elérkeztünk a lényeghez. Különböző adminisztratív jogosultságokat tudunk adni az adott AU-hoz. Jelenleg ezek a szerepkörök állnak rendelkezésre.

Nyissuk meg az egyik szerepkört, például a “User administrator”-t. Ezután a “+Add assignments” lehetőségre kattintva hozzá tudjuk adni azon adminisztrátorokat, akiknek ilyen jogot szeretnénk adni erre az AU-ra.

Héééé, na de várjuk csak. Ezek ugyanazok a role-ok, amik directory szinten is megtalálhatóak! Hogyha itt valakit hozzáadok, akkor az egész directory-n ilyen joga lesz!? Neeem! Miért nem? Ezért:

Bizonyám a scope kizárólag erre az AU erőforrásra szól. Sőt! Nézzük meg, hogy ez hogy látszik az Azure AD\Roles and administrators oldalról.

Megnyitom a “User administrator” szerepkört. Bizonyám itt is szépen látszódik a hatókör. Sőt! innen vissza sem tudom vonni az adminisztrátortól a szerepkört!

Remélem hasznos volt!

üdv.:
NLB