3. Azure AD sxemi.

Bildiyimiz kimi, obyektlərin yaradılması üçün əsas olan,  Active Directory sxemidir. Əlbəttə ki, hər kəs ən azı bir dəfə Exchange, SFB və ya SCCM quraşdırmazdan əvvəl AD sxemini genişləndirirdi. Bəs Azure AD-də sxem ilə bağlı vəziyyət necədir?

Sxem var… lakin bizim öyrəşdiyimiz kimi deyil.

Azure AD-də standart klasslar mövcüddur, ancaq demək olar ki, sənədlərin hamısında onlar – Resurs Tipi olaraq göstərilib. Bu resurs tiplərinin bəzilərini genişləndirmək mümkündür.

Aşağıda genişlənən resursların siyahısı ilə tanış ola bilərsiniz:

• Contact – Əlaqə məlumatları.
• Device – Avadanlıqlar. Əvvəllər bu resurs tipini yalnız PC olaraq qəbul edirdik, lakin indi bunlara əməliyyat sistemləri də daxildir. Həmçinin mobil əməliyyat sistemləri də bu resurs tipinə aid edilir.
• Event – təqvim və qrup təqvimində hadisə.
• Post – Conversation resursundakı əlavə element
• ThreadGroup – Azure Active Directory qrupu (hər hansı bir növü).
• Message – mailFolder-da mesaj.
• Organization – Tenant obyekti.
• Azure AD User – Cloud istifadəçisi

Qeyd etmək lazımdır ki, siz burada öz klasınızı yarada bilməzsiniz. Bütün sxem dəyişiklikləri sadəcə olaraq mövcüd resurslara “extension attributes” əlavə etməklə icra olunur.

4. İtirdiyimiz funksionallıq.

Daha əvvəl qeyd etdiyimiz kimi AD DS və Azure AD arasında fərqlər onlar üçün ümumi olan cəhətlərdən daha çoxdur. Bu isə onların bir-birindən əhəmiyyətli dərəcədə fərqləndiyini göstərir. Ən əhəmiyyətli fərqlərdən biri kataloqun direct strukturudur, yəni Azure AD-də OU birləşmələri yoxdur və heç vaxt olması nəzərdə tutulmayıb.

Bundan əlavə, Azure AD Group Policy dəstəkləmir, çünki klass olaraq sxemdə mövcüd deyil.

Eləcə də, Azure AD Kerberos autentifikasiyası metodundan artıq istifadə etmir, bunun əvəzinə SAML, WS-Federasiya, OpenID Connect və əlbəttə ki, Federated Services istifadə edir.

Sual – “nə üçün belə bir kataloq lazımdır?”

Cavab çox sadədir. Azure AD “AD DS”-in əvəzedicisi kimi qəbul edilməməlidir. O, bunun üçün  yaradılmamışdır. Azure AD əsasən HTTP və ya HTTPS vasitəsilə əldə olunan Cloud-based İnternet xidmətləri üçün “identity solution” sayılır.

Digər məqsədlər üçün isə aşağıdakı variantlar vardır:

1. Local AD DS istifadə etmək;
2. Local AD DS istifadə etmək və Azure AD ilə sinxronlaşdırmaq;
3. Local AD DS istifadə etmək, trust üçün cloudda VM yaradaraq Azure AD ilə sinxronlaşdırmaq (İkinci seçimdən çox fərqlənmir)
4. Azure Active Directory Domain Services istifadə etmək.

Əsas yadda saxlamaq lazımdır ki, “AD DS-dən Azure AD-a keçirik” ssenarisi real deyil. Bu, müxtəlif istifadə ssenariləri olan iki məhsula gedib çıxarır. Biri cloud-la inteqrasiya olunmur, digəri On-Premise üçün tətbiq edilə bilməz.

5. Azure AD Connect. Sinxronizasiya.

Hər hansı bir şirkət Azure və ya Office365 komplektindən istifadə etməyə başlayan kimi, servislərə yetki əldə edə bilməsi üçün avtomatik olaraq onun üçün cloudda Azure AD nümunəsi yaradılır. Təbii ki, istifadəçinin on-premise və cloud accountlarının eyni zamanda  tam sərbəst formada mövcüd olması düzgün deyil. Buna görə də, “yerlə göyün dostluq etməsi“ hər hansı bir şəkildə yerli kataloqun cloudla sinxronlaşması ilə başlanır.

Nadir hallarda bu sinxronizasiya AD DS-dən Azure AD-yə birtərəfli olur. Sinxronizasiya prosesi “Microsoft”un təqdim etdiyi və pulsuz olan ayrıca bir proqram tərəfindən həyata keçirilir. Bu köməkçi proqrama bir çox dəyişikliklər edilib və Microsoft Forefront Identity Manager (FIM) məhsulunun bir hissəsi olub. Hazırda isə bu, Azure AD Connect adlandırılır.

FIM məhsulu olduqca mürəkkəbdir və bu səbəbdən bir “wizard”-un olması vacib idi. Microsoft əməkdaşları “Azure AD Connect” üzərində işləyərkən, hər şeyi mümkün qədər sadələşdirilməli olmağını anlayırdılar. Azure AD Connect qurmaq həqiqətən çətin deyil, lakin bunun necə işlədiyini anlamaq üçün sənədlərin oxunması lazımdır.

Davamı var…