Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti
Geçen hafta bir müşterimizin kimlik mimarisi review’unda, tam ortasında ufak değil, bayağı can sıkıcı bir sürpriz yaşadık. Tahmin eder mısınız? Adam yıl başından beri Agent ID üstünde emek vermiş, blueprint’leri kurmuş, sponsor olarak da klasik role-assignable security group’ları atamıştı; public preview’da gayet yürüyen bu kurgu, Microsoft sessizce GA hazırlığı yaparken bir anda farklı kurallara takıldı ve bizim arkadaşın provisioning pipeline’ı bir sonraki cycle’da duvara toslamak üzereydi.
📋 İçindekiler
- Daha fazla bilgi için
Şimdi gelelim işin can alıcı noktasına.
2. Hedef grup tipini seçin
Şahsen, Burada karar aslında basit gibi dürüyor ama öyle her zaman değil — dürüst olayım, biraz hayal kırıklığı —. Her sponsor için “dynamic mi olsun, M365 mi” diye bakın. Eğer o grup aynı zamanda iletişim kanalı gibi davranacaksa M365 tarafı daha mantıklı geliyor; sadece attribution için duruyorsa dynamic security çoğu senaryoda baya iş görüyor (şaşırtıcı ama gerçek). Az önce basit dedim ama aslında küçük detaylar sonucu değiştiriyor, o yüzden kullanım amacını baştan netleştirin.
3. Yeni gruplar oluşturun, paralel çalıştırın
Doğrusu, Eski grubu hop diye silmeyin, orada acele etmeye gerek yok. Yeni dynamic ya da M365 grubunu açın, üyeleri doğrulayın, ardından agent sponsorship’i yeni gruba çevirin; ben burada bir hafta paralel takip yapmanızı öneririm (çünkü ilk gün her şey düzgün görünürken üçüncü günde tuhaf bir edge case patlayabiliyor). Evet, biraz temkinli yaklaşım ama açık konuşayım, çoğu göç işi böyle kurtuluyor.
4. Audit log’ları kontrol edin
Entra ID audit log’larında “agent sponsor” ile ilgili event’leri didik didik inceleyin (evet, doğru duydunuz). Sponsor resolution gecikmesi var mı, hata dönüyor mu, beklenmedik bir mapping mi oluşmuş; bunların hepsi burada kendini belli eder. Şey gibi düşünün: dışarıdan sessiz duran sistem bazen içeride minik minik takılıyor ve log’a bakmadan bunu yakalamak zor oluyor.
Bu konuda agent ekosistemini derinlemesine takip ediyorsanız, Teams Agent Kurulumu Artık Tek Komutla Tamam yazımı da okuyun — Agent ID ile beraber kullanılan deployment patterns’a değiniyorum.
Eksik Tarafı da Konuşalım: Bence Yetersiz Olan Şey
Bu değişiklik kağıt üstünde fena durmuyor. Hatta ilk bakışta mantıklı bile geliyor. Ama açık konuşayım — role-assignable group desteğinin GA’dan çıkarılması, hibrit RBAC ile agent governance kurmaya çalışan ekiplerin önüne gereksiz bir taş koyuyor; özellikle de sponsor lookup, yetki zinciri ve operasyonel kontrol aynı yerde dönüyorsa, iş iyice uzuyor.
Microsoft “ileride değerlendireceğiz” diyor. Evet, güzel cümle. Ama ben bu lafı kaç kez duydum, kaçı gerçekten geri geldi, doğrusu sayamadım. Asıl çözüm bence şuydu: role-assignable grupları desteklemeye devam et, sponsor lookup için ayrı bir caching katmanı ekle (yükü kullanıcıya değil kendi mimarine al), sonra performans nerede sıkışıyorsa orayı toparla. Ama Microsoft optimize etmek yerine kısıtlamayı seçti; anlaşılır, evet, ama içime tam sinmedi.
Yine de gözüm açık. Microsoft bu tarz GA anı kısıtlamaları — ki bu tartışılır — bazen 6-12 ay içinde gevşetiyor, hatta sessiz sedasız geri adım attığı da oluyor. “watch this space” dedikleri şey boşuna söylenmiyor olabilir. Peki neden? Çünkü bu tip kararlar çoğu zaman kalıcı tasarım tercihi değil, geçici yük azaltma hamlesi gibi dürüyor.
Eğer agent kimlik altyapısının başka tarafları da ilgini çekiyorsa, A2A v1 ile.NET’te Çapraz Platform Agent İletişimi yazısı agent-to-agent iletişiminin kimlik tarafını anlamak için iyi bir başlangıç noktası oluyor. Bir de Entra External ID Native Auth SSO: Tam Entegre Deneyim yazımda Entra’nın genel yönünü biraz daha açıyorum; bağlamı oturtmak isteyen için iş görüyor.
Sıkça Sorulan Sorular
Mevcut role-assignable group sponsor’larım çalışmaya devam edecek mi?
Evet, devam ediyor. Public preview döneminde atanmış sponsor ilişkileri GA sonrasında da sorunsuz işliyor. Kısıtlama sadece yeni atamalar için geçerli. Bence yine de uzun vadede yeni grup tiplerine geçmekte fayda var, hani ileride başka kısıtlamalar da gelebilir.
Bir security group’u dynamic membership group’a sonradan dönüştürebilir mıyım?
Hayır, maalesef doğrudan dönüştüremiyorsunuz. Üyelik tipi — yanı assigned mı dynamic mi — grup oluşturulduktan sonra değiştirilemiyor. Bunun yerine yeni bir dynamic group oluşturup üyeleri rule ile yeniden tanımlamanız gerekiyor. Biraz zahmetli, aslında baştan doğru tipi seçmek çok daha kolay.
Sponsor olarak bireysel kullanıcı atamak hâlâ mümkün mü?
Kısacası, i̇lginç olan şu ki, Evet, neredeyse tamamen mümkün. Bireysel user ataması GA’da hiç değişmedi. Küçük ekipler veya net sahiplik ilişkileri için gayet pratik. Ama tecrübeme göre sistem büyüdükçe grup bazlı yapıya geçmek kaçınılmaz oluyor.
Dynamic membership group için ekstra lisans gerekiyor mu?
Evet, dynamic membership Entra ID P1 lisansı istiyor. Açıkçası çoğu kurumsal Microsoft 365 E3/E5 paketinde bu zaten dahil, mesela büyük ihtimalle elinizde vardır. Sadece M365 Business Basic gibi alt paketlerdeyseniz lisans yükseltmesi gerekebilir. M365 group işe standart lisansla çalışıyor, orada sorun yok.
Sponsor değişikliği sonrası agent çalışmayı durur mu?
Aslında, Hayır, durmuyor. Sponsor sadece attribution. Governance katmanında bir şey — agent’ın runtime davranışını, token alma kabiliyetini veya API çağrılarını hiç etkilemiyor. Yanı gönül rahatlığıyla değiştirebilirsiniz, agent kesintisiz çalışmaya devam ediyor.
Kaynaklar ve İleri Okuma
Sponsor group type requirements for agent identities — Microsoft 365 Developer Blog
Microsoft Entra Agent ID Resmî Dokümantasyonu
Dynamic membership rules for groups in Microsoft Entra ID
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
GPT-5.6 Sol, Terra, Luna Copilot'ta: Hangisi Sizin İçin?9 Tem 2026GitHub Bildirim Saklama Süresi Kısalıyor: Ne Yapmalı?25 Nis 2026Sıfır Güven (Zero Trust) Gerçekten Ne Kadar İşe Yarıyor? Donan, Hayal Kırıklığı Yaratan ve Şaşırtıcı Taraflar23 Mar 2026Koddan Buluta: azd ile AI Ajanınızı Microsoft Foundry’ye Dakikalar İçinde Taşıyın23 Mar 2026
İlginizi Çekebilir
Murat Ö.
Peki bu değişiklik mevcut ortamlarda geriye dönük uyumluluk sorununa yol açmıyor mu? Özellikle role-assignable grupları sponsor olarak kullanan yerler için ciddi bir migration süreci gerekebilir gibi görünüyor.
Mehmet K.
Role-assignable grupların artık desteklenmemesi biraz can sıkıcı oldu, bizim ortamda bunları yoğun kullanıyoruz ve geçiş biraz zahmetli olacak gibi görünüyor. Dynamic membership group’lara alışmak zaman alır ama uzun vadede daha yönetilebilir olur sanırım. Bu arada şu yazınız da güzeldi: VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor — https://www.askinkilic.com.tr/vsix-icin-sdk-style-proje-destegi-build-suresi-75-azaliyor/
Yorumlar kapalı.
2 comments