Gelin biraz Immutable ID’den bahsedelim. Immutable ID’nin kelime anlamına bakarsanız “değişmez, değiştirelemez” anlamlarına geliyor. Bu makalenin konusu olan Immutable ID’yi, yazının sonunda anladığınıza ve bununla ilgili işlemleri yapabileceğinize inanıyorum.
Tanımlamalar
Öncelikle bir kaç tanımlama yapmamız gerekiyor.
| Kavram | Anlam |
| Active Directory Domain Services (ADDS) | ADDS için, yerel sunucularda kullandığımız, nesne (kullanıcı,grup,yazıcı,yönetilebilir birimler vs…) yönetimini yapan bir patron diyebiliriz. ADDS’ile entegre olmuş başka ürünleriniz olabilir ancak biz ADDS’nin ne dediği ile ilgileniyor olacağız. |
| Azure Active Directory (AAD) | AAD, yeni bir Azure veya Office 365 hesabı açtığınızda varsayılan olarak oluşturulan kimlik yönetimi servisidir. Birçok kişi Office 365’te yaptığı kullanıcı yönetimini aslında AAD üstünde yaptığını bilmiyor. Ayrı bir director hizmeti sanılıyor. Burada en azından bu kavramı öğrenmiş olalım. Yanlış anlaşılmaması gereken bir konu var. AAD ile ADDS arasında isim benzerliği dışında yapısal bir benzerlik yoktur. Yani AAD üstünde yazıcılar, yönetilebilir birimler, grup ilkeleri, operation master roles gibi özellikler yoktur. |
| AAD Connect, AADSync veya DirSync | Konumuz olan ImmutableID’nin ihtiyacımız olan noktası. AAD Connect (eski adıyla AADSync veya DirSync), hem lokalinizdeki ADDS hem de AAD ile konuşur ve bir takım sınırlar çerçevesinde birbirine eşitlemeler yapar. Örnek olarak AD üstünde bir kullanıcı oluşturduğunuzda AAD Connect bunu AAD tarafına iletir ve bu nesne AAD üstünde de oluşturulur. AAD tarafından yerel ADDS yönüne de eşitlemeler yapılır. Örnek olarak şifre resetleme, gruplar veya cihazlar. Ancak günümüz koşullarında senaryoların %95’i tek yönlü olarak çalışmaktadır. |
“Primary Key” Kavramını Anlamak
İlişkisel veritabanı ile uğraşmış olanlar bu kavrama aşinadır veya iyi biliyordur. Primary Key’ler, bir kaydın diğer kayıtlardan ayrışmasını sağlar. Örnek olarak buna bina numaralarını verebiliriz. Nasılki her bir apartmanın, binanın aynı cadde veya sokak üstünde bir numarası var ise ilişkisel veritabanlarında da her bir kaydın tekil bir anahtarı vardır.
Örnek olarak 2 adet tablomuz olsun. Bir tanesi ToplantiOdasi, diğeri de Kullanicilar.
Her iki tabloda ID ve isim kolonlarına sahip olsun.
ToplantiOdasi tablosu için kayıt örneği:
| ID | Isim |
| 1 | Güney Toplantı Odası |
| 2 | Kuzey Toplantı Odası |
Kullanicilar tablosu için kayıt örneği:
| ID | Isim |
| 1 | Ali |
| 2 | Veli |
Her iki tabloldada gördüğünüz üzere, ID kolonları her bir satıra özgü olarak verilir. Bu da satırların birbirlerinden ayrışmasını sağlar. Peki bu ID kolonunu nerde kullanacağız diye sorabilirsiniz. Buna bir örnek verelim. Rezervasyon isimli bir tablomuz olsun. Bu tabloda bir kullanıcı, bir toplantı odasını belirli saatler arasında rezerve etsin.
| KullaniciID | ToplantiOdasiID | BaslangicTarihi | BitisTarihi |
| 2 | 1 | 01.07.2020 13:00:00 | 01.07.2020 14:00:00 |
| 1 | 2 | 02.07.2020 09:30:00 | 02.07.2020 12:00:00 |
İşte tamda burada artık bize ayrıştırıcı değerler gerekir. Hangi kullanıcının hangi toplantı odasını reserve edeceğini sadece tekil olan ID’ler ile eşleştiririz. Böylece bu kaydın tekil olmasını sağlar.
Active Directory İçerisindeki Tekil ID
Active Directory içerisinde yukarıdaki gibi bir yapısı olmasa da, hiç değişmemesi gereken değerleri olan bir kaç alanı vardır. Bu alanlar her obje için geçerlidir. En bilineni ise Türkçesi ile Güvenlik Tanımlayıcısı veya İngilizce anlamı ile Security Identifiers’dır (SID). Bu değer örnek olarak şu şekildedir; S-1-5-21-98765-8547-0101-100. 16’lık sayı sisteminde türetilen tekil bir anahtardır. SID’ler Active Directory orman yapısına özgüdür ve yalnızca kullanıcı ve gruplara atanır. Kişiler ve diğer nesne türleri SID değeri almaz. SID’ler sadece, bir orman içerisindeki diğer etki alanlarına geçirildiğinde değişebilir.
Bir AD nesnesini benzersiz olarak tanımlamak için kullanılabilecek bir diğer özellik ise GUID’dir. GUID’ler, yazılım geliştirme dünyasında, teorik olarak tüm sistem ve platformlarda küresel olarak benzersiz bir değer sağlamak için çok yaygın olarak kullanılmaktadır. Yani, dünyadaki tüm ADDS ormanlarında iki nesnenin aynı GUID değerine sahip olduğu bir örnek olmamalıdır. Ancak aynı şeyi SID için söyleyemeyiz.
Bu sebeplerden ötürü objectGuid özniteliği, modern uygulamalarda AD nesnelerini benzersiz olarak tanımlamak için yaygın olarak kullanılır. ObjectGuid, belirli bir AD ormanında yaşadığı sürece kullanıcı veya grup ile kalır.
AAD Connect Dünyası
Elimizde örnek olarak bir domain olsun. Mshowto.com adı ile bir AD ormanı ve etki alanı oluşturdunuz. Güzel bir karar vererek Office 365 ve Azure üzerinde Exchange Online, Teams, Azure ATP gibi ürünleri satın aldınız. Artık kullanıcılara atamak için bekleyen lisanslarınız mevcut.
Kullanıcıları AD’den AAD’ye almak için AAD Connect yazılımını kurmamız gerekiyor. AAD Connect’i önerilen olarak orman içerisinde üzerinde rol olmayan, etki alanına bağlı bir sunucuda kurmanız önerilmektedir. Kurulum esnasında sizden nesneleri senkronize etmek için hangi özelliğe bakarak senkronize edeceğini sorar. Bu alanın adı Identifying Users’dır. Resim-1’de gördüğünüz üzere “Select how users should be identified with Azure AD” kısmında varsayılan olarak “Let Azure manage the source anchor” seçeneği işaretli geliyor. Eski yapıda bu kısım aslında ObjectGuid olarak seçiliyordu. Ancak AAD Connect 1.1.524.0 sürümü ile beraber ms-DS-ConsistencyGuid özniteliği seçilmektedir. Bu öznitelik sadece eşitleme için kullanılıyor ve lokalde kullandığınız objectGuid’in başına bir iş gelmemesini sağlıyor.
Bu öznitelik ImmutableID olarak bilinir. Öznitelik ismi bu şekilde olmasa da Microsoft’un tanımladığı özellik budur.
Resim – 1
AAD Connect ve AAD dizaynı bu şekilde yapılmıştır. Daha detaylı bilgi için:
Hangi Senaryolarda sourceAnchor Kullanılır ?
3 tane senaryo söyleyelim bunun için.
- Yeni bir eşitleme işleminde, felaket senaryolarında veya tekrar yapılandırma senaryolarında AAD Connect nesnelerin mevcuttaki ImmutableID’sini kullanarak yeni bir senkronizasyon işlemi başlatır veya senkronizasyonu kaldığı yerden devam ettirir.
- Ters bir senaryoda (AAD kullanırken), bulut tabanlı kimlik doğrulamasından eşitlenmiş bir modele geçiş yaparsanız, bu öznitelik kullanıcıların AAD ile ADDS hesaplarını eşleştirmesine yardımcı olur.
- Kimlik doğrulama işlemini federasyon yapısında kullanırsanız, bu özelliği userPrincipalName ile birlikte bir kullanıcıyı tekilleştirmek için kullanılır.
AAD Connect Kullanıcıyı Nasıl Gönderiyor ?
AAD Connect, Aşağıdaki işlemler ile kullanıcıyı AAD’ye taşır:
- AAD Connect, kullanıcının userPrincipalName özniteliğini alır.
- Kullanıcının objectGuid değerini alır ve Base64 string tipine çevirir.
objectGuid: 7754d997-1fc3-4217-9e95-de012f1586e5 ToBase64(): dU1Icfw0IGnpXAAA4BLxWA
- AAD Connect, AAD’nin veritabanından Base64 tipinde “dU1Icfw0IGnpXAAA4BLxWA” immutableID değerine sahip bir kullanıcı arar.
- Eğer bir kayıt bulunursa obje güncellenir.
- Eğer obje bulunamaz ise yeni bir obje yaratılır ve immutableID değerine bu Base64 değeri ile damgalar ve AD nesnesini AAD nesnesi ile eşleştirir.
Ortaya Çıkan Ek Senaryolar
- ImmutableID’ye dayalı bir eşleşme bulunamaz, ancak UPN özniteliği eşleşen ancak immutableID’si boş bir kullanıcı bulunursa, bu kullanıcının immutableID değeri yeni değerle damgalanır ve AD+AAD kullanıcıları eşitlenir. Bu işleme “soft match” adı verilir.
- ImmutableID’ye dayalı bir eşleşme bulunamaz, ancak UPN özniteliği eşleşen ve farklı bir immutableID’ye sahip bir kullanıcı bulunursa senkronizasyon işlemi hata verir. AAD Connect, aynı nesne olmadığı için kullanıcının UPN’ini geçersiz saymaz.
- ImmutableID’ye dayalı bir eşleşme bulunur, ancak nesne türleri farklı ise ( örneğin, AAD Connect kişisi ile eşleşen AD kullanıcısı), AAD Connect bir hata Yazar ve nesneleri senkronize etmeyi reddeder.
Problem Nedir ?
Makalenin bu aşamasına kadar AD ile AAD arasında kullanıcıların hangi mantıkla eşleştirildiğini anladık.
Bu anlayışla; bir kullanıcının bir ormandan diğer bir ormana taşınması veya etki alanı içerisinde silinip aynı upn ile tekrar oluşturulması durumunda immutableID değişeceği için UPN aynı olsa dahi Azure AAD bunu farklı bir kullanıcı olarak görecek ve eşleştirmeyecek. İşin kötüsü eski kullanıcıyı buluttan silecektir. Bu makalenin yazım amacı ise yanlışlıkla veya bir şekilde zorunluluktan silinen kullanıcıların, AAD üstündeki kullanıcı ile tekrar eşleştirilmesidir. Prolemimiz tam olarak budur. 😊
Yaklaşık 2015 yılına kadar bu sorunun bir çözümü yoktu. Bir kullanıcı eğer silindiyse veya başka bir ormana taşındıysa herşeyin yeniden oluşturulması gerekiyordu. Sonrasında ise Microsoft, Global Administrator rolündeki kişilerin immutableID özniteliğini temizlemesine ve yazmasına izin vererek bu sorunu gidermek için işlevsellik sağlamıştır. Burada çözüm için 2 yoldan bahsedebiliriz.
Not: Bu 2 yolda Azure AD Powershell bağlantısı gerektirir. Bu nedenle aşağıdaki çözümlerden herhangi birini deneyecekseniz Connect-MsolService komutu ile AAD’ye bağlandığınıza emin olun.
Çözüm – 1
Bu adımı pek tavsiye etmesemde çözümsüz kalındığı durumlarda kullanılabilir, denenebilir.
Yapacağımız işlem aslında basit. AAD kullanıcısının immutableID’sini temizleyerek AAD’nin bu kullanıcıyı daha önce hiç bir kullanıcı ile eşleştirmediğini düşünmesini sağlayacağız. Yani immutableID özniteliğini sileceğiz. Temel olarak bu işlemin sonucunda yukarıda bahsettiğim senaryolardan ( Ortaya Çıkan Ek Senaryolar ) 1. adım gerçekleşecek. Yani AAD Connect kullanıcıyı UPN ile eşleştirecek ve immutableID eşleştirmesi yapacak. Bir nevi “soft match” işlemi olacak.
Bunu aşağıdaki komutlar ile yapabilirsiniz:
# Tek bir kullanıcı için
Get-MsolUser -UserPrincipalName upn@mshowto.org | Set-MsolUser -ImmutableId $null
# Toplu olarak (txt içerisinde, her satırda bir UPN)
Get-Content users.txt | % { Get-MsolUser -UserPrincipalName $_ | Set-MsolUser -ImmutableId $null }# Bütün kullanıcılar (yapmayın arkadaşlar 😊 )
Get-MsolUser -All | Set-MsolUser -ImmutableId $null
Çözüm – 2
Benim kullandığım ve önerdiğim bir çözümdür. Bu çözümde ortamı riske atmak yerine bir nesnenin diğerine zorla eşleştirmesini sağlayacak. Bu çözümde birkaç tane daha fazla komut var. Ancak sorunsuz. 😊
- İlk adımımızı domain ortamında gerçekleştireceğiz. Bunun için:
Import-Module ActiveDirectory
- Kullanıcının objectGUID’ini alup Base64 formatına çevireceğiz.
$userUPN = "upn@mshowto.org" $guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$userUPN)").objectGuid) $immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())
- Elde ettiğimiz immutableID’yi AAD’ye yazacağız.
Get-MsolUser -UserPrincipalName $userUPN | Set-MsolUser -ImmutableId $immutableId
- Toplu bir şekilde yapacaksanız bunu eğer:
Get-Content users.txt | % { "Set-MsolUser -UserPrincipalName $_ -ImmutableId $([System.Convert]::ToBase64String((Get-AdUser -LdapFilter "(userPrincipalName=$_)")[0].objectGuid.ToByteArray())) " }Hangi çözüm yolunu seçerseniz seçin, işlemlerden sonra AAD Connect’i tekrardan çalıştırın. Kullanıcılarınız eşleşmiş olacaktır.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: azure, azure ad connect, ImmutableID,ImmutableID nedir?
