Bu makalemde bozulan bir Active Directory nin Azure AD ile senkronizasyon uyumsuzluğunu nasıl recovery edeceğimizden bahsediyor olacağım
Merhaba Arkadaşlar, yeni bir makalede yine birlikteyiz. Bu makalemde diğerlerinden farklı olarak bozulmuş bir Active Directory nin kurtarılması sonrası Azure AD ye senkronizasyon sorunlarını konuşuyor olacağız.
Bazı durumlar da Microsoft 365 veya Azure üzerindeki servislerde kullandığınız cloud kullanıcı account bilgilerini local Active Directory ile eşleştirmeniz gerekebilir. Microsoft 365 üzerinde yeni oluşturduğunuz bir tenant üzerinde Azure AD Connect tool vasıtasıyla directory synchronization yapısının kurulmasını birkaç adımda basitçe tamamlayabilmekteyiz. Yeni açılan tenant’larda herhangi bir kullanıcı olmadığı için On-Premise Active Directory üzerindeki kullanıcıların Cloud’a sync olması sırasında her bir user , group ve contact için yeni obje oluşturularak local Active Directory’den attributeler sync olmaktadır.
Peki halihazırda Microsoft 365 üzerinde Exchange Online servisini kullanıyorsam ve kullanıcılarımı cloud üzerindeyse , local Active Directorydeki kullanıcıları nasıl eşleştireceğim?
Bir diğer senaryoda Microsoft 365 üzerinde kullanıcılarım olduğunu ve sadece Teams servisini kullandığımı düşünürsek On-Premise yapımda bulunan Exchange serverımı Exchange Online platformuna taşıyacağım bir senaryoda local Active Directory objelerimi Azure Active Directory’e Teams kullanıcılarına zarar vermeden hangi yöntem ile sync etmem gerekmektedir?
Azure AD Connect kurulumunu tamamlayıp senkronizasyonu başlattığımızda Azure AD sync servisi local AD den gelen her bir kullanıcıyı kontrol eder. Kullanıcı yoksa local AD de bulunan kullanıcıyı ekler, kullanıcı varsa üzerindeki değişiklikleri günceller. Bu işlemler gerçekleştirilirken 3 temel attributeden yararlanılır. Bunlar userPrincipalName, proxyAddresses ve immutableID ‘dir.
Not: userPrincipalName, proxyAddresses ve immutableID bu üç attribute çok önemli.
userPrincipalName ve proxyAddresses üzerinden yapılan eşleşme SOFT match, immutableID attribute üzerindeki bir eşleşme ise Hard match olarak bilinir.
Azure AD Connect, Azure servisi üzerinde işlem yaparken local AD üzerinden gelen bir objenin attribute değerleri ile Azure AD üzerinde bulunan objenin değerlerinin aynı olup olmadığını kontrol eder aynı olduğuu tesbit ederse obje değerlerinin local AD üzerindek objeden devralınmasını sağlar. Azure AD üzerinde Cloud managed olarak görünen obje sync sonrası Synced with Active Directory olarak işaretlenir. Burda baskın olan taraf local AD dir. Bu yüzden güncel olması gereken taraf local AD dir.
local AD de bulunan objelerinizin Azure AD ile eşleşmesi iki yöntem ile olur.
- Soft Match (SMTP)
- Hard Match (ImmutableID)
Soft Match ve Hard Match arasındaki farkı kısaca anlatmak gerekirse. Azure AD connect toolunuzu kurduğunuz sunucunun bozulduğunu düşünelim. Artık local AD ile Azure AD arasındaki sync işlemini yapamıyor olacaksınız. Bunun için yeni bir Azure AD connect uygulamasını kurup yeniden sync işlemini yapabilirsiniz. Bu işlem esnasında localde bulunan AD üzerindeki objenin Proxy Address attribute una girilen değer ile Exchange online üzerinde bulunan SMTP attributelerinin aynı olması durumunda Azure AD connect sync işlemini başarılı bir şekilde yapacaktır. Zaten eşleşme olmaması durumunda dumplicate dediğimiz bir durum oluşur. Yani Azure AD eşleşme bulamadığı zaman local AD den gelen Objeyi mükerrer olacak şekilde Azure AD üzerinde yeniden oluşturur. Buda ayrı ayrı objelerin varolmasına sebebiyet verir. Oysa bu iki obje tek bir objede birleşmiş olmalıydı. Soft Matchi varsayılan durum gibi anlayabiliriz. Yani sorunsuz bir Azure AD connect uygulamasının çalıştığı ortamda yapılan sync yani eşleşme Soft Match tir.
Matchin yani eşleştirme konusunun anlamını özetleyecek olursak şöyle düşünebiliriz. Microsoft 365 üzerinde Exchange online yapısını daha önceden cloud üzerinde satınalıp kullandığınızı yani direk olarak Microsoft 365 satınaldığınızı düşünelim. Bunun üzerinde Teams, CRM gibi uygulamaları kullanıyorsunuz ve kullanıcılarınız var. Aynı kullanıcılar localde bulunan AD nizdede var. local AD de bulunan kullanıcıların şifrelerini localden Cloud üzerinde bulunan aslında aynı olan kullanıcıyıda Cloud üzerinden resetliyorsunuz. Bu isteklerin ve iş yükünün iki katı olarak size dönüyor ve siz şöyle düşünüyorsunuz bu iki hesabıda madem aynı kişi kullanıyor neden tek bir hesap altında birleştirmeyelim diyorsunuz. İşte match işleminin tam olarak anlamı budur. Örneğing Ali Çelik kullanıcısı aynı isimde hem Cloud da var hemde local AD de var ve bunları ayrı ayrı yönetiyorsunuz. local AD de yaptığınız değişikliklerin Cloud a sync olarak taşınması işlemine match diyoruz. Bu işlem içinde Azure AD Connect uygulamasını kullanıyoruz. Bu uygulama bu matchi basit bir şekilde yapabilen bir tool. Bu tool un match işlemini yapabilmesi için localde bulunan AD objelerinin Azure AD de bulunan objelerle aynı olduğuna ikna olması gerekiyor. Bunun içinde yukarda bahsettiğimiz userPrincipalName, proxyAddresses ve immutableID atribute leri çok önemli. Azure AD connect tool u bu 3 attribute a göre match işlemine karar veriyor. Burada bir tutarsızlık görürse sync işlemi sonunda dumplicate dediğimiz mükerrer objeler oluşuyor yada hiç oluşmuyor hata veriyor.
Birinci senaryomuz şöyle olsun. Microsoft 365 üzerinde Eskiden satn almış olduğumuz bir Exchange Online yapımız olsun. Bu yapımızdada kullanıcılarımız olsun. Sonrasındada local AD de bu kullanıcıların varolduğunu ve tek biryerden kontrol etmek istediğimizi düşünelim.
Bunun için yapılması gereken adımların başında Exchange Online üzerindeki her bir kullanıcının SMTP adres bilgisinin On-Premise Active Directory yapısında bulunan ilgili kullanıcının Proxy Address attribute içerisine girilmesi gerekmektedir.
Exchange Online
On-Premise AD
Not: Exchange Online üzerinde ikincil Email adresleriniz varsa bunlarıda Active Directory tarafında küçük smtp kullanarak eklemeniz gerekmektedir. Büyük SMTP varsayılan adresi küçük smtp diğer mail adreslerin temsil eder.
Ayrıca dikkat edilmesi gereken bir hususta SYNC edilecek kullanıcı objelerinin UPN bilgisinin ‘de eşleşmesi gerekmektedir. Siz SMTP adres bilgisini aynı tutsanız ‘da kullanıcı UPN bilgisinin farklı olması durumunda farklı kullanıcı kimlikleri oluşacağı için eşleşme sağlanmayacaktır.
Attribute tanımlamaları yapıldıktan sonra AD Connect uygulaması ile sync işlemi başlatılabilir. Sync işleminden sonra match işleminin başarılı olup olmadığını anlamak adına Office 365 üzerindeki Active Users bölümünü kontrol edebilirsiniz. Azure AD tarafında kullanıcının hemen sağında “Synced with Active Directory” ifadesini görürsünüz
SMTP match ile ilgili son söz olarak sync sonrası local AD denin Azure AD ye baskın olacağı şeklindedir. Yani local AD deki özellikller, şifre, gpo vb. özellikler baskındır.
Buraya kadar anlattıklarımız aslında Azure AD Connect uygulamasının varsayılan durumuydu yani Azure AD de hizmet alırsınız mevcu localde bulunan AD objelerini Azure AD Connect sayesinde buluta sync eder bulut hizmetlerinden faydalanırsınız. Bu sync işlemi size local AD den kullanıcılarınızı çift taraflı yönetme fırsatı verir şeklindeydi.
Birazda Hard Match dediğimiz felaket durumlarında uygulanabilecek olan senaryomuza gelelim.
AD Connect uygulamasının olduğu sunucuyu veya local AD diye anlattığımız AD sunucumuzu kaybetmemiz durumunda neler yaşarız. Microsoft 365 bundan nasıl etkilenir?
ADConnect sunucusunun kapanması veya sunucuyu tamamen kaybetmemiz durumunda herhangi bir sistem kesintisi yaşanmaz. Sadece kapalı olduğu süre içerisinde local AD – Azure AD sync işlemleri yapılamaz. Yani local AD de resetlediğiniz bir şifre Azure AD ye yansımaz dolayısı ile Azure tarafı hala eski şifre ile çalışmaya devam eder. Azure AD Connectin olmaması kısa vadede olmasada orta vadede bir sıkıntıdır bu yüzden bir an önce ayağa kaldırılması gerekir. Sunucunun ayağa kalkması durumunda sync işlemleri kaldığı yerden devam edecektir. Yani herşey normale dönecektir.
Pekiya local AD yi kaybetmemiz durumunda ?
Senaryomuzdan önce local AD ve Azure AD de bir objenin asıl kimliği nedir ondan bahsedelim. local AD tarafında bir objenin ObjectGUID attribute u objenin uniq bir adresidir. Bunu Tc kimlik numarası gibi düşünebiliriz Ali ler çoktur ama aynı Tc kimliğe ait tek bir Ali vardır. Azure AD tarafında bunun adı ImmutableID şeklindedir. Azure AD Connect bu iki değer üzerinden objenin aynı olup olmadığına karar verir.
Felaket sonrasında mevcut local AD mizi kurtaramadığımızı kullanıcılarımızı yeniden oluşturduğumuzu düşünelim. Yeni oluşturulan her bir kullanıcının ObjectGUID attribute değeri eskisinden farklı olacağı için Azure AD Connect yeni oluşturulan obje ile Azure AD de bulunan objenin farklı olduğunu düşünecek sync sonrası dumplicate dediğimiz mükerrer objeler oluşacaktır. Aslında bu objeler mükerrer değil farklı farklı objelerdir. Sebebine gelince Azure AD tarafında objenin ImmutableID attribute u local AD deki objenin ObjectGUID attribute üne denk gelmiyordur. Normal bir sync esnasında local AD üzerinde bulunan kullanıcının ObjectGUID değeri Base-64 olarak sistem tarafından convert edilerek öncelikle AD Connect üzerinde tanımlı ImmutableID attributine eşlenmektedir. Bu eşleşme olmazsa sync sonrası dumplicate oluşur.
Senaryomuza dönecek olursak. Öncelikli olarak yeni bir local AD kurulup kullanıcılarımız yeniden oluşturulur. local AD üzerinden kullanıcının ObjectGUID değeri kontrol edilir.
Microsoft 365 Powershell komutlarımızı Azure AD tarafında kullanabilmemiz için Azure a bağlanmamız gerekiyor dilerseniz önce bunu yapalım.
Office 365 Exchange Online PowerShell ile bağlantı kurulur.
Import-Module MSOnline
$O365Cred = Get-Credential
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-MsolService –Credential $O365Cred
Artık Microsoft 365 Powershell komutlarını kullanabilir hale geldik.
İlk olarak ali.celik kullanıcımızın local AD tarafında bulunan ObjectGuid değerini öğrenelim.
Not: GetADUser komutu local AD tarafında kullanılan bir komuttur. Kullanıcı bilgilerini getirir. Get-MsolUser Azure AD tarafında kullanılan bir komuttur. Kullanıcı bilgilerini getirir.
Get-ADUser ali.celik -properties * | fl objectguid
Bu komut seti bize ali.celik kullanıcımızın objectguid attribute unu görmemizi sağlar. Komutu biraz geliştirip bu değerin ImmutableID karşılığını aşağıdaki şekilde bulabiliriz
$userUPN = "ali.celik@abc.com"
$guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$userUPN)").objectGuid)
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())Aynı kullanıcı için,
Get-MsolUser -UserPrincipalName ali.celik@abc.com -properties * |select ImmutableID
komutu ile Azure AD tarafındaki ImmutableID değerini görebiliriz. Senaryomuzda bu değerlerin farklı olduğunu zaten göreceksiniz. Düzgün çalışan bir sistemde bu değerler aynıdır.
Farklı olduğunu gördüğümüze göre şimdi eşitlememiz gerekiyor Bu eşitlemeyi yapmadan önce Azure AD tarafında bulunan ali.celik@abc.com objesinin ImmutableID değerini null yapmamız gerekiyor
Get-MsolUser -UserPrincipalName ali.celik@abc.com | Set-MsolUser -ImmutableId $null
Bu işlemi yaptıktan sonra komut setimizi biraz daha geliştirelim.
$userUPN = "ali.celik@abc.com"
$guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$userUPN)").objectGuid)
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())
Get-MsolUser -UserPrincipalName $userUPN | Set-MsolUser -ImmutableId $immutableIdBu komut setimizde özetle şunu söylüyoruz. local AD de bulunan ali.celik@abc.com kullanıcısının önce ObjectGUID attribute değerini bul ve bunu base64 metodunu uygulayarak ImmutableID karşılığını göster sonrasındada Azure AD de bulunana ali.celik@abc.com objesinin ImmutableID değeri ile aynı yap.
Artık ali.celik@abc.com kullanıcımız sync için hazır. Hatırlarsanız local AD mizi yeniden kurup kullanıcılarımızı oluşturmuştuk. Sonra bir kullanıcı için local AD – Azure AD tarafındaki ObjectID ve ImmutableID değerlerini eşitledik. Bu eşitlemeyi tüm kullanıcılar için yaptıktan sonra yeni bir Azure AD Connect uygulaması kurup sync işlemini başarılı bir şekilde yapabiliriz.
Durun durun hemen kızmayın o kadar kullanıcı tek tek match edilirmi demeyin tüm kullanıcıların ImmutableID lerini nasıl eşitleyeceğimizide anlatacağım.
Öncelikle
Get-MsolUser -All | Set-MsolUser -ImmutableId $null
komutu ile tüm kullanıcıların Azure AD tarafında ImmutableId leri null yapılır. Sonra aşağıdaki script i çalıştırırız.
Cls
$onPremUsers=get-aduser -filter * |select userprinc* -ExpandProperty userprincipalname
$toplaObj=@()
foreach($temp in $onPremUsers){
$userUPN =$($temp)
$guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$($userUPN))").objectGuid)
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())
Get-MsolUser -UserPrincipalName $userUPN | Set-MsolUser -ImmutableId $immutableId
$obj=[PscustomObject]@{
userUPNAddress=$temp
immutableIds=$immutableId
}
$toplaObj+=$obj
}
$toplaObj |export-csv c:\temp\adImm.csvKomut setimiz artık bir script haline geldi. Scriptimizi özetlemek gerekirse local AD de bulunan kullanıcıları bir diziye alıp tek tek ObjectGUID değerlerine ulaşıyor Basa64 metodu ile bunu ImmutableID değerlerine çevirip tüm kullanıcılar için Azure AD tarafında ImmutableID lerini eşitliyor. Sonundada eşitlediği kullanıcıların ImmutableID değerlerini bir dosyaya .csv olarak export ediyor.
Kürşat ARI / System Engineer & PowerShell Developer
PowerShell 