Bu Konu Neden Önemli?
Microsoft Entra Connect, şirket içi Active Directory kimliklerini Microsoft Entra ID ile senkronize etmek için kullanılan hibrit kimlik bileşenidir.
Karar Verirken Kontrol Edilecek Noktalar
Sync kapsamındaki OU ve nesneleri kontrollü seçin.
Password Hash Sync / PTA gibi yöntemleri iş gereksinimine göre değerlendirin.
Staging server planını düşünün.
Sync hatalarını düzenli izleyin.
Mimari ve çalışma modeli
Entra Connect şirket içi AD kimliklerini bulut kimliğine bağlayan senkronizasyon tasarımıdır; AD yedeği değildir. Kaynak otoritesi, OU filtreleme, attribute eşlemesi ve eşleşen kullanıcı kimliği belirlenir. Password hash synchronization, pass-through authentication ve federation farklı oturum bağımlılıkları oluşturur.
- 1AD kaynak kapsamı
- 2Attribute ve eşleme
- 3Sync yöntemi
- 4Bulut nesnesi/oturum
Tasarım parametreleri
- Yetkili kaynak
- Hangi nitelik ve kimliğin yerelden veya buluttan yönetildiğini belirleyin; aynı alanı iki taraftan kör değiştirmenin sonucunu test edin.
- Sync ve authentication
- Parola hash sync, pass-through ve federasyon farklı giriş bağımlılıklarıdır; dizin sync ile karıştırmayın.
- Kimlik ve tenant sınırı
- Kullanıcı, misafir, yönetici ve uygulama kimliklerini ayırın. Tenant politikaları ile tek kaynağın izinleri aynı kapsam değildir.
- Veri sahipliği ve yaşam döngüsü
- Verinin sahibi, saklama süresi, silinme yolu ve geri kazanım yöntemi belirlenmelidir. Senkronizasyon ile yedeklemeyi ayırın.
- Lisans ve özellik kapsamı
- Kullanıcı rolü, cihaz, tenant ve gerekli özellik üzerinden lisans doğrulayın. Güncel paket adını geçmiş bilgiyle varsaymayın.
- Bağlantı ve maliyet
- İnternet, kimlik servisi, veri çıkışı, depolama ve işletim giderini birlikte değerlendirin. Bütçe alarmının harcamayı otomatik durdurduğunu varsaymayın.
Hesap ve uygulama örneği
Örnek pilotta sınırlı OU ve test kullanıcılarıyla başlayın. Eşleşmeyen UPN veya duplicate attribute bulgularını çözmeden büyük scope değişikliği yapmayın. Şirket içi kullanıcı silme veya OU taşımasının bulut nesnesine etkisini sentetik hesapla sınayın; accidental-deletion korumasını kontrol edin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Yerel parola değişti, bulut giriş farklı | Sync gecikmesi veya authentication yöntemi etkili olabilir. | Aktif yöntem, scope ve son başarılı sync kaydını doğrulayın. |
| Bazı kullanıcılar erişemiyor | Lisans, grup, cihaz durumu veya erişim politikası farklı olabilir. | Etkilenen ve çalışan kullanıcıların karar kayıtlarını karşılaştırın. |
| Silinen veri geri getirilemiyor | Saklama ve kurtarma kapsamı beklenenden farklı olabilir. | Nesne türü, silinme zamanı ve resmî kurtarma koşullarını doğrulayın. |
| Maliyet beklenenden yüksek | Kaynak boyutu, veri çıkışı, saklama veya taahhüt kullanımı farklı olabilir. | Kaynak ve hizmet bazında gerçekleşeni tahminle eşleştirin. |
Kabul ve doğrulama kontrolleri
- Sync sağlığını, nesne eşleşmesini ve giriş yöntemini birbirinin yerine kullanmadan doğrulayın.
- Kullanıcı, misafir ve yönetici senaryolarını ayrı test edin.
- Kayıp cihaz ve iptal edilen erişim davranışını doğrulayın.
- Bir test nesnesini silip tanımlı yöntemle geri kazanın.
- Gerekli özellik için güncel lisans kapsamını belgeleyin.
- Günlükleri kimlik ve kaynak açısından uçtan uca eşleştirin.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Replikasyonun kapsamı
Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun