Certificate-Based Authentication ile Intune ve Conditional Access Entegrasyonu

Mert Ozsoy7 gün önce

0 75 7 dakika okuma süresi

Bir SCEP veya PKCS profiliyle cihazlara sertifika dağıttıktan sonra bu sertifikaların çoğu zaman tek bir amacı oluyor: Wi-Fi veya VPN tarafında 802.1X kimlik doğrulaması. Ama aynı sertifika, Microsoft Entra ID’nin native Certificate-Based Authentication (CBA) özelliğiyle birleştiğinde çok daha farklı bir işe yarayabiliyor; kullanıcı parolasını hiç girmeden, doğrudan sertifikayla Entra ID’de oturum açabiliyor ve bu oturum açma, doğru yapılandırıldığında Conditional Access’in MFA şartını da karşılayabiliyor.

Buradaki asıl karışıklık şu: Intune’un bir sertifika dağıtması ile o sertifikanın Entra ID’de gerçekten CBA için kullanılabilir olması aynı şey değil. İkisi ayrı sistemler, ayrı yapılandırma katmanları. Bu yazıda Intune’un SCEP/PKCS ile dağıttığı sertifikaların Entra CBA tarafında nasıl tanınıp değerlendirildiğini, CA trust store kurulumundan authentication binding ve username binding policy’lerine, oradan da Conditional Access’e nasıl bağlandığını anlatıyorum. SCEP ile PKCS’nin kendi iç mimarisine bu yazıda girmiyorum, o konuyu ayrı bir yazıda zaten işledim.

CBA Aslında Ne Yapıyor, Intune’un Rolü Ne?

Microsoft Entra CBA, kullanıcının parola yerine bir X.509 sertifikayla doğrudan Entra ID’ye kimlik doğrulaması yapmasını sağlayan bir özellik. AD FS gibi bir federasyon katmanına ihtiyaç duymuyor, tamamen bulut tarafında çalışıyor ve tenant’ta herhangi bir ücretli lisans gerektirmeden kullanılabiliyor. Kullanıcı sign-in ekranında “sertifika ile oturum aç” seçeneğini gördüğünde, cihazdaki sertifika deposundan uygun sertifikayı seçiyor, Entra ID bu sertifikayı kendi trust store’undaki CA zincirine karşı doğruluyor ve eşleşme başarılıysa kullanıcıyı içeri alıyor.

Intune’un buradaki rolü tek bir şey: sertifikayı cihazın veya kullanıcının yerel sertifika deposuna, doğru özelliklerle yerleştirmek. SCEP certificate profile veya PKCS certificate profile bu işi yapıyor, trusted certificate profile ile de CA zincirinin cihaza güvenilir olarak tanıtılmasını sağlıyor. Ama Intune’un cihaza bir sertifika göndermiş olması, o sertifikanın Entra ID tarafında CBA için kabul edileceği anlamına gelmiyor. Entra ID kendi tarafında CA’ya güvenmiyorsa, CBA authentication method hiç açılmamışsa veya sertifikadaki alanlar kullanıcı objesiyle eşleşmiyorsa, sertifika cihazda dursa da oturum açmada işe yaramıyor.

Intune sertifika sağlama ile Microsoft Entra ID CBA yapılandırması arasındaki sorumluluk sınırı

Sertifikanın Intune Tarafında Taşıması Gereken Özellikler

CBA için kullanılacak sertifikanın Entra ID tarafından kabul edilebilmesi için birkaç şartı taşıması gerekiyor, bu şartlar SCEP veya PKCS profilinde ayarlanıyor.

Extended Key Usage (EKU) alanında Client Authentication (1.3.6.1.5.5.7.3.2) bulunmalı. Bu, zaten Wi-Fi/VPN 802.1X için kullanılan sertifikalarda genelde hazır oluyor, ayrı bir EKU eklemeye gerek kalmıyor çoğu ortamda. Subject Alternative Name (SAN) tarafında ise varsayılan CBA eşleştirmesi kullanıcının UPN’sini Principal Name alanından okuyor; bu yüzden SCEP profilindeki Subject Alternative Name ayarında UPN değerinin ({{UserPrincipalName}}) Principal Name tipiyle eklenmiş olması gerekiyor. Bu ayar zaten çoğu kurumsal SCEP profilinde mevcut, çünkü aynı alan Wi-Fi/VPN kimlik doğrulaması için de kullanılıyor.

Trusted certificate profili de burada devreye giriyor ama iki farklı amaçla. Cihaz tarafında, sertifikanın geçerli bir CA’dan geldiğini doğrulamak için Windows’un kendi Trusted Root Certification Authorities deposuna root CA’nın kurulu olması gerekiyor; bunu Intune zaten trusted certificate profile ile sağlıyor. Entra ID tarafında ise ayrı bir adım var: aynı CA zincirinin Entra ID’nin kendi trust store’una da yüklenmesi gerekiyor. Bu iki adım birbirinden bağımsız, biri cihazı diğeri Entra ID’yi ilgilendiriyor.

Windows’ta CBA için istemci tarafında özel bir ayar gerekmiyor. Sertifika Personal depoda, doğru EKU ve SAN ile duruyorsa ve Entra ID tarafı yapılandırılmışsa, kullanıcı tarayıcıda veya Office uygulamalarında sertifika seçeneğini otomatik olarak görüyor.

Entra Tarafında CA Trust Store Kurulumu

Entra ID’nin CBA için CA’lara güvenmesi, cihazın CA’ya güvenmesinden tamamen ayrı bir yapılandırma. Microsoft artık PKI-based trust store’u öneriyor; bu yapı CA’ları bir PKI container objesi altında topluyor, klasik düz listeye göre daha yüksek limitlere sahip (250 CA’ya kadar, CA başına 8 KB) ve issuer hints gibi yeni özellikleri destekliyor.

PKI container oluşturmak ve CA yüklemek Entra ID admin center > Identity Secure Score > Public key infrastructure ekranından yapılıyor, bunun için Privileged Authentication Administrator rolü yeterli. Root CA’yı, ardından zincirdeki tüm intermediate CA’ları tek tek veya bir .p7b dosyası olarak toplu yükleyebilirsiniz. Her CA için Certificate Revocation List URL alanını da girmeniz gerekiyor; bu URL internet üzerinden erişilebilir olmalı.

CRL URL’sini boş bırakırsanız Entra ID hiçbir revocation kontrolü yapmıyor; iptal edilmiş bir sertifika bile kabul edilebiliyor. Bu ayarı atlamak kurulumu hızlandırır ama üretimde ciddi bir açık bırakır, CRL’nin gerçekten internetten erişilebilir olduğunu test etmeden CBA’i devreye almamak gerekiyor.

Sertifikanın certification path’inde root’a kadar her CA’nın Entra ID trust store’unda bulunması şart; zincirde eksik bir intermediate CA varsa CBA doğrulaması başarısız oluyor. Sertifikanın Certification Path sekmesinden zinciri kontrol edip her adımın Entra ID’ye yüklendiğinden emin olmak, kurulumdan sonra karşılaşılan “sertifika seçeneği geliyor ama oturum açmıyor” tipi sorunların en sık nedenini baştan ortadan kaldırıyor.

CBA’i Tenant İçin Etkinleştirme

CA trust store hazır olduktan sonra CBA’in kendisini açmak gerekiyor. Bu adım Entra ID > Authentication methods > Certificate-based authentication altında, en az Authentication Policy Administrator rolüyle yapılıyor. Burada Enable seçilip hangi kullanıcı veya grubun CBA kullanabileceği belirleniyor.

CBA’i All users için açmamanızı öneririm. Bir kullanıcı CBA kapsamına girdiği anda, geçerli bir sertifikası olmadan başka bir MFA yöntemi kaydedemez hale geliyor; identity proof olarak CBA’i tamamlamak zorunda kalıyor. Sertifikası henüz dağıtılmamış bir kullanıcı bu durumda kendini kilitlenmiş bulabiliyor. Sadece sertifikası gerçekten dağıtılmış kullanıcıları kapsayan bir grubu hedeflemek, bu tip destek taleplerini baştan önlüyor.

CBA açıldıktan sonra tüm tenant kullanıcıları sign-in ekranında sertifika seçeneğini görebiliyor, ama sadece hedef gruba dahil olan kullanıcılar sertifikayla gerçekten oturum açabiliyor. Ayrıca ağ tarafında *.certauth.login.microsoftonline.com uç noktasına erişimin açık olması ve bu uç noktada TLS inceleme (TLS inspection) yapan bir proxy varsa bunun kapatılması gerekiyor; TLS handshake sırasında istemci sertifikası isteği araya giren bir inceleme cihazı yüzünden bozulabiliyor.

Authentication Binding Policy: Single-Factor mı, MFA mı?

Sertifikayla oturum açmak tek başına MFA anlamına gelmiyor. Bu ayrımı yapan katman authentication binding policy. Tenant varsayılanı single-factor authentication; yani bir kullanıcı CBA ile oturum açtığında, aksi belirtilmedikçe bu sadece tek faktörlü bir kimlik doğrulama sayılıyor, Conditional Access’teki bir “Require multifactor authentication” grant’ini tek başına karşılamıyor.

Bu davranışı Entra ID > Authentication methods > Policies > Certificate-based authentication > Configure altından değiştirebilirsiniz. Tenant varsayılanını doğrudan MFA’ya çekebilir ya da sertifika issuer’ı veya certificate policy OID’sine göre özel kurallar tanımlayabilirsiniz. Örneğin sadece belirli bir CA’dan çıkan ve belirli bir policy OID taşıyan sertifikaları MFA sayıp geri kalanını single-factor bırakmak mümkün. Birden fazla kural çakıştığında öncelik sırası şöyle işliyor: issuer + policy OID kombinasyonu, sadece policy OID’den önce geliyor; policy OID kuralı da sadece issuer kuralından önce değerlendiriliyor.

Burada gözden kaçan bir nokta var: binding policy’nin MFA demesi, sertifikanın gerçekten ikinci bir faktör sağladığı anlamına gelmiyor. Microsoft’un kendi dokümantasyonu da bunu açıkça belirtiyor, bir sertifikanın gerçek anlamda MFA sayılabilmesi için private key’e erişimin bir PIN veya biyometrikle korunması gerekiyor. Intune’un SCEP profiliyle TPM’e, PIN olmadan yerleştirdiği bir cihaz sertifikası, binding policy MFA dese bile pratikte sadece “cihazda bir şey var” seviyesinde kalıyor; gerçek ikinci faktör (PIN, biyometrik) olmadan bu, güvenlik açısından tek faktörden çok da güçlü sayılmıyor. Bu ayrımı Conditional Access tarafında MFA gücüne (authentication strength) dayanan politikalar tasarlarken göz önünde bulundurmak gerekiyor.

Username Binding Policy: Low Affinity ve High Affinity

CBA’in bir sertifikayı hangi kullanıcıya ait olarak kabul edeceğini belirleyen katman username binding policy. Varsayılan davranış, sertifikanın SAN alanındaki Principal Name’i kullanıcı objesinin userPrincipalName attribute’una eşlemek. Intune’un SCEP profiliyle UPN’i SAN’a Principal Name olarak ekleyen bir kurulum, ekstra bir ayar yapmadan bu varsayılan eşleşmeyle çalışıyor.

Ama bu eşleşme türü low affinity sayılıyor, çünkü UPN gibi değerler teoride yeniden kullanılabilir; bir kullanıcının UPN’i değişebilir veya bir hesap silinip aynı UPN başka bir hesaba verilebilir. Daha yüksek güvenceli bir eşleşme isteniyorsa high affinity binding kullanılıyor: SubjectKeyIdentifier (SKI), SHA1PublicKey veya IssuerAndSerialNumber gibi, sertifikaya özgü ve tekrar kullanılamayan alanlar. Bu alanların hepsi kullanıcı objesindeki certificateUserIds attribute’una yazılıyor.

Burada Intune’un elini kolunu bağlayan bir nokta var: SCEP veya PKCS profili sertifikanın içine ne yazılacağını belirliyor ama kullanıcı objesindeki certificateUserIds değerini Intune doldurmuyor. Bu, tamamen Entra ID tarafında, ayrı bir adım. High affinity binding kullanmak istiyorsanız, dağıtılan her sertifikanın SKI veya seri numarası değerini alıp ilgili kullanıcının certificateUserIds attribute’una elle veya Graph üzerinden yazmanız gerekiyor. Bu işlem için bulut-only kullanıcılarda en az Privileged Authentication Administrator rolü gerekiyor.

Connect-MgGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All"

$userObjectId = "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
$user = Get-MgUser -UserId $userObjectId -Property AuthorizationInfo

$user.AuthorizationInfo.CertificateUserIds = @("X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR")
Update-MgUser -UserId $userObjectId -AuthorizationInfo $user.AuthorizationInfo

Bu adım ölçekte manuel yapılabilecek bir şey değil; sertifika üretim sürecine (SCEP renewal dahil) entegre bir otomasyonla beslenmesi gerekiyor, aksi halde sertifika yenilendiğinde SKI değişiyor ve kullanıcı objesindeki eski değer artık eşleşmiyor. Bu yüzden çoğu kurulum, ek otomasyon maliyeti gerektirmeyen low affinity (UPN tabanlı) binding ile başlıyor, high affinity’yi sadece gerçekten yüksek güvence gereken kullanıcı gruplarında (örneğin ayrıcalıklı hesaplar) devreye alıyor.

Birden fazla binding kuralı tanımlarsanız CBA’in genel güvenlik seviyesi, tanımlı bindingler içindeki en düşük affinity’ye iniyor; çünkü Entra ID her binding’i sırayla deniyor ve ilk eşleşeni kabul ediyor. Gerçek anlamda yüksek güvence istiyorsanız sadece high affinity binding tanımlamak, low affinity’yi hiç tanımlamamak gerekiyor.

Conditional Access ile Bağlantı

CBA ile başarılı bir oturum açma sonunda kullanıcıya bir primary refresh token (PRT) veriliyor; bu token’ın içinde, authentication binding policy’nin sonucuna göre bir MFA claim’i olabilir veya olmayabilir. Conditional Access tarafında Require multifactor authentication grant’i olan bir policy varsa, bu claim’in varlığına bakılıyor.

Sertifika MFA claim’i taşıyorsa kullanıcı hiçbir ek adım görmeden içeri giriyor. Taşımıyorsa ve kullanıcı başka bir MFA yöntemi (FIDO2, passwordless telefon girişi gibi) için zaten kayıtlıysa, Entra ID bu yöntemi ikinci faktör olarak sunuyor. Hiçbir alternatif yöntem kayıtlı değilse kullanıcı MFA’yı tamamlayamıyor ve erişim engelleniyor. Bu davranış, “sertifika var ama Conditional Access hâlâ MFA istiyor” tipi şikayetlerin büyük kısmının kaynağı; sorun genelde Conditional Access tarafında değil, authentication binding policy’nin o sertifikayı single-factor sayıyor olmasında çıkıyor.

Conditional Access policy’nin CBA’i gerçekten MFA olarak kabul edip etmediğini incelemek için Conditional Access ile Intune compliance entegrasyonunu anlattığım yazıdaki report-only test yaklaşımı burada da aynen geçerli; policy’yi report-only modda çalıştırıp sonuçları sign-in log’larından doğrulamak, üretime almadan önce sürprizleri önlüyor.

Doğrulama: Sign-in Loglarında CBA

Bir kullanıcının CBA ile gerçekten nasıl oturum açtığını doğrulamanın en güvenilir yolu Entra ID > Monitoring & health > Sign-in logs. İlgili oturumu açtığınızda Authentication Details sekmesinde kullanılan yöntemin sertifika olduğunu, hangi binding kuralının eşleştiğini ve sonucun single-factor mü yoksa MFA mı sayıldığını görebilirsiniz.

Aynı ekranda Additional Details altında Is Legacy Store Used alanı da var; bu değer 0 ise Entra ID sertifikayı yeni PKI-based trust store üzerinden doğrulamış demektir, 1 ise klasik trust store devreye girmiştir. İki store’u aynı anda kullanan ortamlarda bu alan, hangi CA kaydının gerçekten devrede olduğunu netleştiriyor.

CA yapılandırmasının doğruluğunu kontrol etmek için Microsoft’un yayınladığı Test-MsIdCBATrustStoreConfiguration PowerShell cmdlet’i (MSIdentityTools modülü içinde) de işe yarıyor; trust chain’i ve CRL erişimini otomatik olarak doğrulayıp yaygın yapılandırma hatalarını raporluyor.

Intune’un dağıttığı bir sertifikayla CBA kurarken asıl karışıklık, iki farklı sistemi tek bir yapılandırma gibi düşünmekten kaynaklanıyor. Intune sertifikayı doğru EKU ve SAN ile cihaza yerleştirdiğinde işi bitiyor; sertifikanın Entra ID’de gerçekten passwordless ve MFA-satisfying bir oturum açma sağlaması, CA trust store’un, authentication binding’in ve username binding’in ayrı ayrı doğru kurulmuş olmasına bağlı. Bu üç katmandan hangisi eksikse sorun orada aranmalı; sertifikanın cihazda görünmesi, CBA’in çalıştığı anlamına gelmiyor.