Microsoft Entra sertifika tabanlı kimlik doğrulaması teknik ayrıntılı bilgi

Bu makalede, Microsoft Entra sertifika tabanlı kimlik doğrulamasının (CBA) nasıl çalıştığı açıklanır ve Microsoft Entra CBA yapılandırmalarıyla ilgili teknik ayrıntılara yer verilmiştir.

Microsoft Entra sertifika tabanlı kimlik doğrulaması nasıl çalışır?

Aşağıdaki görüntüde, bir kullanıcı Microsoft Entra CBA'nın etkinleştirildiği bir kiracıdaki bir uygulamada oturum açmaya çalıştığında ne olacağı açıklanmaktadır.

Şimdi her adımı inceleyeceğiz:

1. Kullanıcı, MyApps portalı gibi bir uygulamaya erişmeye çalışır.

2. Kullanıcı henüz oturum açmadıysa, kullanıcı konumundaki https://login.microsoftonline.com/Microsoft Entra ID Kullanıcı Oturum Açma sayfasına yönlendirilir.

3. Kullanıcı kullanıcı adını Microsoft Entra oturum açma sayfasına girer ve ardından İleri'yi seçer. Microsoft Entra Id, kiracı adını kullanarak giriş bölgesi bulma işlemini gerçekleştirir ve kullanıcı adı kiracıdaki kullanıcıyı aramak için kullanılır.

   

4. Microsoft Entra Id, kiracı için CBA'nın etkinleştirilip etkinleştirilmediğini denetler. CBA etkinse, kullanıcı parola sayfasında Sertifika veya akıllı kart kullan bağlantısını görür. Kullanıcı oturum açma bağlantısını görmüyorsa kiracıda CBA'nın etkinleştirildiğinden emin olun. Daha fazla bilgi için bkz. Nasıl yaparım? Microsoft Entra CBA'yı etkinleştirme?

   Not

   Kiracıda CBA etkinse, tüm kullanıcılar parola sayfasında Sertifika veya akıllı kart kullan bağlantısını görür. Ancak yalnızca CBA kapsamındaki kullanıcılar, Kimlik sağlayıcısı (IdP) olarak Microsoft Entra Id kullanan bir uygulamada başarıyla kimlik doğrulaması yapabilir.

   

   Telefon oturumu açma veya Güvenlik anahtarları gibi diğer kimlik doğrulama yöntemlerini etkinleştirdiyseniz, kullanıcılar farklı bir oturum açma ekranı görebilir.

   

5. Kullanıcı sertifika tabanlı kimlik doğrulamasını seçtikten sonra istemci, genel Microsoft Entra Id olan certauth uç noktasına https://certauth.login.microsoftonline.com yönlendirilir. Azure Kamu için certauth uç noktası şeklindedirhttps://certauth.login.microsoftonline.us.

   Uç nokta TLS karşılıklı kimlik doğrulaması gerçekleştirir ve TLS el sıkışmasının bir parçası olarak istemci sertifikasını istemektedir. Oturum açma günlüğünde bu istek için bir girdi görüntülenir.

   Not

   Ağ yöneticisi, müşterinin bulut ortamı için Kullanıcı oturum açma sayfasına ve certauth uç noktasına *.certauth.login.microsoftonline.com erişim izni vermelidir. İstemci sertifika isteğinin TLS el sıkışmasının bir parçası olarak başarılı olduğundan emin olmak için certauth uç noktasında TLS incelemesini devre dışı bırakın.

   TLS inceleme devre dışı bırakmanızın, veren ipuçları içeren yeni URL için de çalıştığından emin olun. B2B kullanıcıları için değişebileceğinden url'yi tenantId ile sabit kodlamayın. TlS denetimi devre dışı bırakma için hem eski hem de yeni URL'nin çalışmasına izin vermek için normal bir ifade kullanın. Örneğin, ara sunucuya bağlı olarak veya *certauth.login.microsoftonline.comkullanın*.certauth.login.microsoftonline.com. Azure Kamu içinde veya *certauth.login.microsoftonline.uskullanın*.certauth.login.microsoftonline.us.

   Erişime izin verilmediği sürece, veren ipuçlarını etkinleştirirseniz sertifika tabanlı kimlik doğrulaması başarısız olur.

6. Microsoft Entra Id bir istemci sertifikası istemektedir. Kullanıcı istemci sertifikasını seçer ve Tamam'ı seçer.

   

7. Microsoft Entra Id, sertifikanın iptal edilmemiş ve geçerli olduğundan emin olmak için sertifika iptal listesini doğrular. Microsoft Entra Id, sertifika alanı değerini kullanıcı özniteliği değeriyle eşlemek için kiracıda yapılandırılan kullanıcı adı bağlamasını kullanarak kullanıcıyı tanımlar.

8. Çok faktörlü kimlik doğrulaması gerektiren bir Koşullu Erişim ilkesine sahip benzersiz bir kullanıcı bulunursa ve sertifika kimlik doğrulaması bağlama kuralı MFA'yı karşılarsa, Microsoft Entra Id kullanıcıyı hemen oturum açar. MFA gerekliyse ancak sertifika yalnızca tek bir faktörü karşılarsa, parolasız oturum açma veya FIDO2 zaten kayıtlıysa ikinci bir faktör olarak sunulur.

9. Microsoft Entra Id, oturum açma işleminin başarılı olduğunu belirtmek için bir birincil yenileme belirteci göndererek oturum açma işlemini tamamlar.

10. Kullanıcı oturum açma işlemi başarılı olursa, kullanıcı uygulamaya erişebilir.

Veren ipuçlarını anlama (Önizleme)

Veren ipuçları, TLS el sıkışmasının bir parçası olarak Güvenilir CA Göstergesini geri gönderir. Güvenilen CA listesi, Kiracı tarafından Entra güven deposunda karşıya yüklenen Sertifika Yetkilileri'ne (CA) tabi olacak şekilde ayarlanır. Tarayıcı istemcisi veya yerel uygulama istemcisi, sertifika seçicide gösterilen sertifikaları filtrelemek için sunucu tarafından geri gönderilen ipuçlarını kullanır. İstemci yalnızca güven deposundaki CA'lar tarafından verilen kimlik doğrulama sertifikalarını gösterir.

Veren ipuçlarını etkinleştirme

Etkinleştirmek için Veren İpuçları onay kutusuna tıklayın. Kimlik Doğrulama İlkesi Yöneticileri, TLS incelemesi etkinleştirilmiş ara sunucusunun doğru güncelleştirildiğinden emin olduktan sonra Kabul ediyorum'a tıklamalı ve kaydetmelidir.

Not

Kuruluşunuzda TLS denetimine sahip güvenlik duvarları veya proxy'ler varsa, altında [*.]certauth.login.microsoftonline.comherhangi bir adı eşleştirebilen certauth uç noktasının TLS denetimini kullanımdaki ara sunucuya göre özelleştirilmiş olarak devre dışı bırakıldığını kabul edin.

Not

Sertifika yetkilisi URL'si, veren ipuçları etkinleştirildikten sonra bir biçimde t{tenantId}.certauth.login.microsoftonline.com olacaktır.

CA güven deposu güncelleştirme yayma

Veren ipuçlarını etkinleştirdikten ve CA'ları güven durumundan ekledikten, güncelleştirdikten veya sildikten sonra, veren ipuçlarının istemciye geri yayılması 10 dakikaya kadar gecikebilir. Kullanıcılar ipuçları yayılana kadar yeni CA'lar tarafından verilen sertifikalarla kimlik doğrulaması yapamaz.

Kimlik Doğrulama İlkesi Yöneticileri, yayma işlemini başlatmak için veren ipuçlarını etkinleştirdikten sonra bir sertifikayla oturum açmalıdır. CA güven deposu güncelleştirmeleri yayılırken kullanıcılar aşağıdaki hata iletisini görür.

Sertifika tabanlı kimlik doğrulaması MFA özelliği

Microsoft Entra CBA, çok faktörlü kimlik doğrulaması (MFA) özelliğine sahiptir. Microsoft Entra CBA, kiracı yapılandırmasına bağlı olarak tek faktörlü (SF) veya çok faktörlü (MF) olabilir. CBA'nın etkinleştirilmesi, kullanıcının MFA'yı tamamlayabilmesini sağlar. Bir kullanıcının MFA'yı tamamlamak için daha fazla yapılandırmaya ve kullanıcı CBA kapsamındayken diğer kimlik doğrulama yöntemlerini kaydetmek için kanıta ihtiyacı olabilir.

CBA özellikli kullanıcının yalnızca Tek Faktörlü (SF) sertifikası varsa ve MFA'yı tamamlaması gerekiyorsa:

1. Parola ve SF sertifikası kullanın.
2. Geçici Erişim Geçişi oluşturun.
3. Kimlik Doğrulama İlkesi Yöneticisi bir telefon numarası ekler ve kullanıcı hesabı için sesli/kısa mesaj kimlik doğrulamasına izin verir.

CBA özellikli kullanıcıya henüz bir sertifika verilmediyse ve MFA'yı tamamlaması gerekiyorsa:

1. Geçici Erişim Geçişi oluşturun.
2. Kimlik Doğrulama İlkesi Yöneticisi bir telefon numarası ekler ve kullanıcı hesabı için sesli/kısa mesaj kimlik doğrulamasına izin verir.

CBA özellikli kullanıcı akıllı kart desteği olmadan mobil cihazda olduğu gibi bir MF sertifikası kullanamıyorsa ve MFA'yı tamamlaması gerekiyorsa:

1. Geçici Erişim Geçişi oluşturun.
2. Kullanıcının başka bir MFA yöntemi kaydetmesi gerekir (kullanıcı MF sertifikasını kullanabildiğinde).
3. Parola ve MF sertifikası kullanın (kullanıcı MF sertifikasını kullanabildiğinde).
4. Kimlik Doğrulama İlkesi Yöneticisi bir telefon numarası ekler ve kullanıcı hesabı için sesli/kısa mesaj kimlik doğrulamasına izin verir.

Tek faktörlü sertifika tabanlı kimlik doğrulaması ile MFA

Microsoft Entra CBA, tek faktörlü sertifikalarla MFA gereksinimlerini karşılamak için ikinci bir faktör olarak kullanılabilir. Desteklenen birleşimlerden bazıları şunlardır:

1. CBA (ilk faktör) ve geçiş anahtarları (ikinci faktör)
2. CBA (ilk faktör) ve parolasız telefon oturumu açma (ikinci faktör)
3. CBA (ilk faktör) ve FIDO2 güvenlik anahtarları (ikinci faktör)

Kullanıcıların, Microsoft Entra CBA ile oturum açmak için MFA almak ve parolasız oturum açma veya FIDO2'yi önceden kaydetmek için başka bir yolu olmalıdır.

Önemli

Bir kullanıcı, CBA yöntemi ayarlarına dahil edildiğinde MFA özellikli olarak kabul edilir. Başka bir deyişle, kullanıcı diğer kullanılabilir yöntemleri kaydetmek için kimlik doğrulamasının bir parçası olarak yazım denetlemeyi kullanamaz. Geçerli sertifikası olmayan kullanıcıların CBA yöntemi ayarlarına dahil edilmediğinden emin olun. Kimlik doğrulamasının nasıl çalıştığı hakkında daha fazla bilgi için bkz . Microsoft Entra çok faktörlü kimlik doğrulaması.

CBA ile parolasız telefon oturumu açma (PSI) ayarlama adımları

Parolasız oturum açmanın çalışması için kullanıcıların mobil uygulamaları aracılığıyla eski bildirimi devre dışı bırakması gerekir.

1. Microsoft Entra yönetim merkezinde en azından Kimlik Doğrulama İlkesi Yöneticisi olarak oturum açın.

2. Parolasız telefon oturum açma kimlik doğrulamasını etkinleştirme adımlarını izleyin.

   Önemli

   Önceki yapılandırmada Parolasız seçeneğini belirttiğinizden emin olun. PSI için eklenen grupların Kimlik Doğrulama modunu Parolasız olarak değiştirmeniz gerekir. Herhangi birini seçerseniz, CBA ve PSI çalışmaz.

3. Koruma>Çok Faktörlü kimlik doğrulaması>Ek bulut tabanlı çok faktörlü kimlik doğrulama ayarları'nı seçin.

   

4. Doğrulama seçenekleri'nin altında Mobil uygulama aracılığıyla bildirim seçeneğinin işaretini kaldırın ve Kaydet'i seçin.

   

Tek faktörlü sertifikalar ve parolasız oturum açma kullanan MFA kimlik doğrulama akışı

Tek faktörlü sertifikası olan ve parolasız oturum açma için yapılandırılmış bir kullanıcı örneğine göz atalım.

1. Kullanıcı asıl adınızı (UPN) girin ve İleri'yi seçin.

   

2. Sertifikayla oturum aç'ı seçin.

   

   Telefon oturumu açma veya FIDO2 güvenlik anahtarları gibi diğer kimlik doğrulama yöntemlerini etkinleştirdiyseniz, kullanıcılar farklı bir oturum açma ekranı görebilir.

   

3. İstemci sertifikası seçicisinde doğru kullanıcı sertifikasını seçin ve Tamam'ı seçin.

   

4. Sertifika tek faktörlü kimlik doğrulama gücü olacak şekilde yapılandırıldığından, kullanıcının MFA gereksinimlerini karşılamak için ikinci bir faktöre ihtiyacı vardır. Kullanıcı kullanılabilir ikinci faktörleri görür ve bu durumda parolasız oturum açma olur. Microsoft Authenticator uygulamamda bir isteği onayla'yı seçin.

   

5. Telefonunuzda bir bildirim alırsınız. Oturum açmayı onayla? seçeneğini belirleyin.

6. Tarayıcıda veya uygulama ekranında gördüğünüz numarayı Microsoft Authenticator'a girin.

   

7. Evet'i seçtiğinizde kullanıcı kimlik doğrulaması yapabilir ve oturum açabilir.

İkinci faktör olarak Sertifika tabanlı kimlik doğrulaması ile MFA (Önizleme)

CBA, MFA almak için Parola (ilk faktör) ve CBA (ikinci faktör) gibi ikinci bir faktör olarak kullanılabilir.

Not

iOS'ta, sertifika tabanlı kimlik doğrulamasına sahip kullanıcılar sertifika tabanlı kimlik doğrulamasını iki kez kullanma seçeneğine tıklamaları gereken bir "çift istem" görür. iOS'ta, Microsoft Authenticator Uygulaması'na sahip kullanıcılar ayrıca CBA'yı zorunlu kılacak bir Kimlik Doğrulama Gücü ilkesi varsa veya ikinci faktör veya adım adım kimlik doğrulaması olarak CBA kullanıyorlarsa CBA ile kimlik doğrulaması yapmak için saatlik oturum açma istemi görür.

Kimlik doğrulama bağlama ilkesini anlama

Kimlik doğrulama bağlama ilkesi, kimlik doğrulamasının gücünü tek faktörlü veya çok faktörlü olarak belirlemeye yardımcı olur. Kimlik Doğrulama İlkesi Yöneticileri, tek faktörlü olan varsayılan değeri çok faktörlü olarak değiştirebilir veya sertifikadaki veren konu veya ilke OID veya Veren ve İlke OID alanlarını kullanarak özel ilke yapılandırmaları ayarlayabilir.

Sertifika güçlü yönleri

Kimlik Doğrulama İlkesi Yöneticileri sertifikaların tek faktörlü mü yoksa çok faktörlü mü olduğunu belirleyebilir. Daha fazla bilgi için NIST Kimlik Doğrulama Güvencesi Düzeylerini NIST 800-63B SP 800-63B, Dijital Kimlik Yönergeleri: Kimlik Doğrulaması ve Yaşam Döngüsü Mgmt'yi temel alan Microsoft Entra kimlik doğrulama yöntemleriyle eşleyen belgelere bakın.

Çok faktörlü sertifika kimlik doğrulaması

Bir kullanıcının çok faktörlü sertifikası olduğunda, yalnızca sertifikalarla çok faktörlü kimlik doğrulaması gerçekleştirebilir. Ancak, Kimlik Doğrulama İlkesi Yöneticisi sertifikaların çok faktörlü olarak kabul edilecek bir PIN veya biyometrik ile korunduğundan emin olmalıdır.

Microsoft Entra ID birden çok kimlik doğrulama ilkesi bağlama kuralını nasıl çözümler?

Birden çok özel kimlik doğrulama bağlama ilkesi kuralı, veren + ilke OID'sini veya yalnızca İlke OID'sini veya yalnızca vereni kullanma gibi farklı sertifika alanlarıyla oluşturulabilir. Aşağıda, özel kurallar çakıştığında kimlik doğrulama koruma düzeyini belirlemek için kullanılan adımlar yer almaktadır. Bunlar aşağıdaki gibidir:

1. Veren + ilke OID kuralları, İlke OID kurallarına göre önceliklidir. İlke OID kuralları, sertifika veren kurallardan önceliklidir.
2. İlk olarak veren + ilke OID kuralları değerlendirilir. Veren CA1 ve MFA ile ilke OID 1.2.3.4.5 ile özel bir kuralınız varsa, yalnızca A sertifikası hem veren değerini karşılar hem de ilke OID'ye MFA verilir.
3. Ardından, ilke OID'lerini kullanan özel kurallar değerlendirilir. İlke OID 1.2.3.4.5 içeren bir sertifikanız ve bu sertifikayı temel alan türetilmiş B kimlik bilgisine sahip bir ilke OID 1.2.3.4.5.6 ilkeniz varsa ve özel kural MFA ile 1.2.3.4.5 değerine sahip İlke OID olarak tanımlanıyorsa, yalnızca A sertifikası MFA'yı karşılar ve B kimlik bilgisi yalnızca tek faktörlü kimlik doğrulamasını karşılar. Kullanıcı oturum açma sırasında türetilmiş kimlik bilgilerini kullandıysa ve MFA'ya sahip olacak şekilde yapılandırıldıysa, başarılı kimlik doğrulaması için kullanıcıdan ikinci bir faktör istenir.
4. Birden çok ilke OID'i (örneğin, bir sertifikanın tek faktörlü kimlik doğrulamasına ve diğer bağlamaların MFA'ya bağlandığı iki ilke OID'sine sahip olması gibi) arasında bir çakışma varsa, sertifikayı tek faktörlü kimlik doğrulaması olarak ele alır.
5. Ardından, veren CA kullanan özel kurallar değerlendirilir.
6. Sertifikada hem ilke OID'sinin hem de Veren kurallarının eşleşmesi varsa, önce ilke OID her zaman denetlenir ve hiçbir ilke kuralı bulunmazsa veren bağlamaları denetlenir. İlke OID'sinin güçlü kimlik doğrulama bağlama önceliği verenden daha yüksektir.
7. Bir CA MFA'ya bağlanırsa, CA'nın çıkarmış olduğu tüm kullanıcı sertifikaları MFA olarak niteler. Aynı mantık tek faktörlü kimlik doğrulaması için de geçerlidir.
8. Bir ilke OID'i MFA'ya bağlanırsa, bu ilke OID'sini OID'lerden biri olarak içeren tüm kullanıcı sertifikaları (Bir kullanıcı sertifikası birden çok ilke OID'sine sahip olabilir) MFA olarak nitelenebilir.
9. Bir sertifikayı veren yalnızca bir geçerli güçlü kimlik doğrulama bağlamasına sahip olabilir (yani, bir sertifika hem tek faktörlü hem de MFA'ya bağlanamaz).

Önemli

Microsoft Entra Kimlik Doğrulama İlkesi Yöneticisi'nin hem Veren hem de İlke OID'sini kullanarak CBA kimlik doğrulama ilkesi kuralı yapılandırmasının aşağıdakiler gibi bazı cihaz kayıt senaryolarını etkilediği bilinen bir sorun vardır:

• İş İçin Windows Hello kaydı
• Fido2 Güvenlik Anahtarı kaydı
• Windows Parolasız Telefon Oturumu Açma

Workplace Join, Microsoft Entra Id ve Hybrid Microsoft Entra cihaz katılımı senaryolarıyla cihaz kaydı etkilenmez. Veren VEYA İlke OID kullanan CBA kimlik doğrulama ilkesi kuralları etkilenmez. Azaltmak için Kimlik Doğrulama İlkesi Yöneticileri şunları yapmalıdır:

• Sertifika tabanlı kimlik doğrulama ilkesi kurallarını şu anda hem Veren hem de İlke OID seçeneklerini kullanarak düzenleyin ve Veren veya OID gereksinimini kaldırın ve kaydedin. VEYA
• Şu anda hem Veren hem de İlke OID kullanan kimlik doğrulama ilkesi kuralını kaldırın ve yalnızca vereni veya ilke OID'sini kullanarak kurallar oluşturun

Sorunu çözmek için çalışıyoruz.

Kullanıcı adı bağlama ilkesini anlama

Kullanıcı adı bağlama ilkesi, kullanıcının sertifikasını doğrulamaya yardımcı olur. Varsayılan olarak, sertifikadaki Konu Diğer Adı (SAN) Asıl Adı, kullanıcıyı belirlemek için kullanıcı nesnesinin UserPrincipalName özniteliğine eşlenir.

Sertifika bağlamalarıyla daha yüksek güvenlik elde edin

Sertifika bağlamaları için desteklenen yedi yöntem vardır. Genel olarak, eşleme türleri Konu Anahtarı Tanımlayıcıları veya SHA1 Ortak Anahtarı gibi yeniden kullanamamanıza neden olan tanımlayıcıları temel alırsa yüksek benzite olarak kabul edilir. Bu tanımlayıcılar, ilgili kullanıcının kimliğini doğrulamak için yalnızca tek bir sertifikanın kullanılabileceğini belirten daha yüksek bir güvence sağlar.

Kullanıcı adlarına ve e-posta adreslerine dayalı eşleme türleri düşük benzeşim olarak kabul edilir. Microsoft Entra ID, yeniden kullanılabilir tanımlayıcılara göre düşük benşim olarak kabul edilen üç eşleme uygular. Diğerleri yüksek benşim bağlaması olarak kabul edilir. Daha fazla bilgi için bkz . certificateUserIds.

Sertifika eşleme alanı	certificateUserIds içindeki değer örnekleri	Kullanıcı nesnesi öznitelikleri	Tür
AsılAd	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	düşük benzite
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	düşük benzite
IssuerAndSubject (önizleme)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	düşük benzite
Konu (önizleme)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	düşük benzite
KAYAK	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	yüksek benzite
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	yüksek benzite
IssuerAndSerialNumber (önizleme)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Seri numarası için doğru değeri almak için şu komutu çalıştırın ve CertificateUserIds içinde gösterilen değeri depolayın: Söz dizimi: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Örnek: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	yüksek benzite

Kiracı düzeyinde benşim bağlaması tanımlama ve özel kurallarla geçersiz kılma (Önizleme)

Bu özellik ile Kimlik Doğrulama İlkesi Yöneticisi, düşük benşimlilik veya yüksek benşimli kullanıcı adı bağlama eşlemesi kullanılarak kullanıcının kimliğinin doğrulanıp doğrulanamadıyacağını yapılandırabilir. Kiracı için tüm kullanıcılar için geçerli olan Gerekli benşim bağlaması ayarlayabilirsiniz. Ayrıca, Veren ve İlke OID veya İlke OID'sini ya da Veren'i temel alan özel kurallar oluşturarak kiracı genelindeki varsayılan değeri geçersiz kılabilirsiniz.

Microsoft Entra Id birden çok kullanıcı adı ilkesi bağlama kuralını nasıl çözümler?

En yüksek öncelik (en düşük sayı) bağlamasını kullanın.

1. Kullanıcı adını veya Kullanıcı Asıl Adı'nı kullanarak kullanıcı nesnesini arayın.
2. 'priority' özniteliği tarafından sıralanmış CBA kimlik doğrulama yöntemi yapılandırmasında Kimlik Doğrulama İlkesi Yöneticisi tarafından yapılan tüm kullanıcı adı bağlamalarının listesini alın. Bugün öncelik kavramı Portal UX'te kullanıma sunulmaz. Graph size her bağlama için öncelik özniteliğini döndürür ve bunlar değerlendirme sürecinde kullanılır.
3. Kiracıda yüksek benşim bağlaması etkinleştirilmişse veya sertifika değeri, yüksek bensemme bağlaması gerektiren özel bir kuralla eşleşiyorsa, listeden tüm düşük benans bağlamalarını kaldırın.
4. Başarılı bir kimlik doğrulaması gerçekleşene kadar listedeki her bağlamayı değerlendirin.
5. Yapılandırılan bağlamanın X.509 sertifika alanı sunulan sertifikadaysa, Microsoft Entra Kimliği sertifika alanındaki değeri kullanıcı nesnesi öznitelik değeriyle eşleştirir.
   1. Eşleşme bulunursa, kullanıcı kimlik doğrulaması başarılı olur.
   2. Eşleşme bulunamazsa sonraki öncelik bağlamasına geçin.
6. X.509 sertifika alanı sunulan sertifikada değilse, sonraki öncelik bağlamasına geçin.
7. Yapılandırılan tüm kullanıcı adı bağlamalarını, bunlardan biri eşleşmeyle sonuçlanana ve kullanıcı kimlik doğrulaması başarılı olana kadar doğrulayın.
8. Yapılandırılmış kullanıcı adı bağlamalarının hiçbirinde eşleşme bulunmazsa, kullanıcı kimlik doğrulaması başarısız olur.

Microsoft Entra yapılandırmasını birden çok kullanıcı adı bağlamasıyla güvenli hale getirme

Sertifikaları Microsoft Entra kullanıcı hesaplarına bağlamak için kullanılabilen Microsoft Entra kullanıcı nesnesi özniteliklerinin (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) her biri, sertifikanın yalnızca tek bir Microsoft Entra kullanıcı hesabıyla eşleştiğinden emin olmak için benzersiz bir kısıtlamaya sahiptir. Ancak Microsoft Entra CBA, kimlik doğrulama ilkesi yöneticisinin birden çok Microsoft Entra kullanıcı hesabı yapılandırmasına bir sertifika eklemesine olanak tanıyan kullanıcı adı bağlama ilkesinde birden çok bağlama yöntemini destekler.

Önemli

Birden çok bağlama yapılandırıyorsanız, CBA kullanıcının kimliğini doğrulamak için her bağlamayı doğruladığı için Microsoft Entra CBA kimlik doğrulaması yalnızca en düşük benşim bağlamanız kadar güvenlidir. Tek bir sertifikanın birden çok Microsoft Entra hesabıyla eşleştiği senaryoları önlemek için Kimlik Doğrulama İlkesi Yöneticisi şunları yapabilir:

• Kullanıcı adı bağlama ilkesinde tek bir bağlama yöntemi yapılandırın.
• Kiracının yapılandırılmış birden çok bağlama yöntemi varsa ve bir sertifikanın birden çok hesaba eşlemesini istemiyorsanız, Kimlik Doğrulama İlkesi Yöneticisi ilkede yapılandırılan tüm izin verilebilen yöntemlerin aynı Microsoft Entra hesabıyla eşlenmiş olduğundan emin olmalıdır. Tüm kullanıcı hesaplarının tüm bağlamalarla eşleşen değerleri olmalıdır.
• Kiracının yapılandırılmış birden çok bağlama yöntemi varsa, Kimlik Doğrulama İlkesi Yöneticisi birden fazla düşük benşim bağlaması olmadığından emin olmalıdır.

Örneğin, PrincipalName üzerinde UPN ve SubjectKeyIdentifier (SKI) ile certificateUserIds arasında eşlenmiş iki kullanıcı adı bağlamanız olduğunu varsayalım. Sertifikanın yalnızca tek bir hesap için kullanılmasını istiyorsanız, Kimlik Doğrulama İlkesi Yöneticisi hesabın sertifikada bulunan UPN'ye sahip olduğundan emin olmalı ve aynı hesabın certificateUserId özniteliğinde SKI eşlemesini uygulamalıdır.

Bir Microsoft Entra kullanıcı hesabıyla birden çok sertifika desteği (M:1)

Bir kuruluşun tek bir kimlik için birden çok sertifika aldığı senaryolar vardır. En yaygın olarak bu, bir mobil cihaz için türetilmiş bir kimlik bilgisi olabileceği gibi, yubikey gibi ikincil bir akıllı kart veya x509 kimlik bilgisi sahibi özellikli bir cihaz için de olabilir.

Yalnızca bulut hesapları Yalnızca bulut hesapları için, certificateUserIds alanını (Kullanıcı Portalı'ndaki Yetkilendirme bilgileri) her sertifikayı tanımlayan benzersiz değerlerle doldurarak birden çok sertifikayı (en fazla 5) eşleyebilirsiniz. Kuruluş, Issuer + SerialNumber gibi yüksek benzeşim bağlamaları kullanıyorsa, CertificateUserIds içindeki değerler aşağıdaki gibi görünebilir:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Bu örnekte ilk değer X509Certificate1 değerini, ikinci değer ise X509Certificate2 değerini temsil eder. Kullanıcı, oturum açma sırasında sertifikayı sunabilir ve CBA Kullanıcı Adı Bağlaması, belirli bağlama türünü (bu örnekte Issuer+SerialNumber) aramak için certificateUserIds alanına işaret edecek şekilde ayarlandıysa, kullanıcı başarıyla oturum açar.

Karma Eşitlenmiş hesaplar Eşitlenmiş hesaplar için AD'deki altSecurityIdentities alanını her sertifikayı tanımlayan değerleri doldurarak birden çok sertifikayı eşleyebilirsiniz. Kuruluş, Issuer + SerialNumber gibi yüksek benzeşim (güçlü kimlik doğrulaması) bağlamaları kullanıyorsa, bu aşağıdaki gibi görünebilir:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Bu örnekte ilk değer X509Certificate1 değerini, ikinci değer ise X509Certificate2 değerini temsil eder. Bu değerlerin daha sonra Microsoft Entra Id içindeki certificateUserIds alanına eşitlenmesi gerekir.

Birden çok Microsoft Entra kullanıcı hesabına sahip bir sertifika desteği (1:M)

Bir kuruluşun, kullanıcının birden çok kimlikte kimlik doğrulaması yapmak için aynı sertifikayı kullanmasına ihtiyaç duyduğu senaryolar vardır. Bu genellikle yönetim hesaplarına yöneliktir. Geliştirici hesapları veya geçici görev hesapları için de olabilir. Geleneksel AD'de, sertifika değerlerini doldurmak için altSecurityIdentities alanı kullanılır ve oturum açma sırasında AD'yi oturum açmayı denetlemek üzere istenen hesaba yönlendirmek için bir İpucu kullanılır. Microsoft Entra CBA ile bu farklıdır ve İpucu yoktur. Bunun yerine, Home Realm Discovery sertifika değerlerini denetlemek için istenen hesabı tanımlar. Diğer önemli fark, Microsoft Entra CBA'nın certificateUserIds alanında benzersizliği zorlamasıdır. Bu, iki hesabın aynı sertifika değerlerini dolduramayacağı anlamına gelir.

Önemli

Farklı Microsoft Entra hesaplarında kimlik doğrulaması yapmak için aynı kimlik bilgilerini kullanmak çok güvenli bir yapılandırma değildir ve birden çok Microsoft Entra kullanıcı hesabı için bir sertifikaya izin verilmemesi önerilir.

Yalnızca bulut hesapları Yalnızca bulut hesapları için birden çok kullanıcı adı bağlaması oluşturmanız ve sertifikayı kullanacak her kullanıcı hesabıyla benzersiz değerleri eşlemeniz gerekir. Her hesabın kimliği farklı bir kullanıcı adı bağlaması kullanılarak doğrulanır. Bu, tek bir dizin/kiracı sınırı içinde geçerlidir (yani, Kimlik Doğrulama İlkesi Yöneticileri, değerler de hesap başına benzersiz kaldığı sürece sertifikayı başka bir dizinde/kiracıda kullanmak üzere eşleyebilir).

certificateUserIds alanını (Kullanıcı Portalı'ndaki Yetkilendirme bilgileri) istenen sertifikayı tanımlayan benzersiz bir değerle doldurun. Kuruluş, Issuer + SerialNumber ve SKI gibi yüksek benzeşim bağlamaları (güçlü kimlik doğrulaması) bağlamaları kullanıyorsa, bu aşağıdaki gibi görünebilir:

Kullanıcı adı bağlamaları:

• Veren + Seri Numarası -> CertificateUserIds
• SKI -> CertificateUserIds

Kullanıcı hesabı CertificateUserIds değerleri:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Artık iki kullanıcı da oturum açarken aynı sertifikayı sunduğunda, hesabı bu sertifikadaki benzersiz bir değerle eşleştiğinden kullanıcı başarıyla oturum açar. Bir hesabın kimliği Issuer+SerialNumber ve diğeri SKI bağlaması kullanılarak doğrulanır.

Not

Bu şekilde kullanılabilecek hesap sayısı, kiracıda yapılandırılan kullanıcı adı bağlamalarının sayısıyla sınırlıdır. Kuruluş yalnızca Yüksek Benans bağlamaları kullanıyorsa desteklenen hesap sayısı 3 ile sınırlandırılır. Kuruluş düşük benşim bağlamalarını da kullanıyorsa, bu sayı 7 hesap (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject) artar.

Karma Eşitlenmiş hesaplar Eşitlenmiş hesaplar için yaklaşım farklı olacaktır. Kimlik Doğrulama İlkesi Yöneticileri sertifikayı kullanacak her kullanıcı hesabıyla benzersiz değerleri eşleyebilirken, Tüm değerleri Microsoft Entra ID'deki her hesaba doldurmanın yaygın uygulaması bunu zor hale getirir. Bunun yerine, Microsoft Entra Connect hesap başına istenen değerleri Microsoft Entra Id'de hesaba doldurulan benzersiz değerlere göre filtrelemelidir. Benzersizlik kuralı tek bir dizin/kiracı sınırı içinde geçerlidir (yani, Kimlik Doğrulama İlkesi Yöneticileri, değerler de hesap başına benzersiz kaldığı sürece sertifikayı başka bir dizinde/kiracıda kullanmak üzere eşleyebilir). Ayrıca, kuruluşun tek bir Microsoft Entra kiracısına kullanıcılara katkıda bulunan birden çok AD ormanı olabilir. Bu durumda Microsoft Entra Connect, bu AD ormanlarının her birine filtreyi uygulayarak bulut hesabına yalnızca istenen benzersiz değeri doldurma hedefine sahip olur.

AD'deki altSecurityIdentities alanını istenen sertifikayı tanımlayan değerlerle doldurun ve bu kullanıcı hesabı türü (ayrıntı, yönetici, geliştirici vb.) için istenen sertifika değerini ekleyin. AD'de, eşitlemeye kullanıcının değerlendirdiği kullanıcı hesabı türünü (msDS-cloudExtensionAttribute1 gibi) belirten bir anahtar özniteliği seçin. Bu özniteliği ayrıntı, yönetici veya geliştirici gibi istediğiniz kullanıcı türü değeriyle doldurun. Bu kullanıcının birincil hesabıysa, değer boş/null bırakılabilir.

Hesaplar aşağıdaki gibi görünebilir:

Orman 1 - Hesap1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Orman 1 - Hesap2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Orman 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Bu değerlerin daha sonra Microsoft Entra Id içindeki certificateUserIds alanına eşitlenmesi gerekir.

certificateUserIds ile eşitleme adımları

1. Metaverse'e alternatifSecurityIds alanını eklemek için Microsoft Entra Connect'i yapılandırın
2. Her AD Ormanı için, yüksek önceliğe sahip yeni bir özel gelen kuralı yapılandırın (düşük sayı 100'in altında). Kaynak olarak altSecurityIdentities alanıyla bir İfade dönüşümü ekleyin. Hedef ifade, seçtiğiniz ve doldurduğunuz Anahtar Özniteliğinin yanı sıra tanımladığınız Kullanıcı Türlerine eşlemeyi kullanır.
3. Örneğin:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

Yukarıdaki örnekte, altSecurityIdentities ve msDS-cloudExtensionAttribute1is anahtar özniteliği ilk olarak doldurulup doldurulmadığını görmek için denetlenmektedir. Aksi takdirde, altSecurityId varlıkları dolduruldu mu diye kontrol edilir. Boşsa NULL olarak ayarlarız. Aksi takdirde hesap varsayılan büyük/küçük harfe girer ve bu örnekte yalnızca Issuer+SerialNumber eşlemesine göre filtreleyeceğiz. Anahtar özniteliği doldurulursa, değerin tanımlı kullanıcı türlerimizden birine eşit olup olmadığını görmek için denetlenirse. Bu örnekte bu değer detailee ise altSecurityId varlıklarından SHA1PublicKey değerine filtre uygulanır. Değer geliştirici ise altSecurityId varlıklarından SubjectKeyIssuer değerine filtre uygulanır. Belirli bir türde birden çok sertifika değeri olabilir. Örneğin, birden çok PrincipalName değeri veya birden çok SKI veya SHA1-PUKEY değeri. Filtre tüm değerleri alır ve yalnızca bulduğu ilk değerle değil Microsoft Entra Id ile eşitlenir.

1. Denetim özniteliği boşsa boş bir değerin nasıl gönderildiğini gösteren ikinci bir örnek aşağıda verilmiştir.

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

altSecurityId varlıklarındaki değer, denetim özniteliğindeki arama değerlerinden herhangi biriyle eşleşmiyorsa, bir AuthoritativeNull geçirilir. Bu, alternativeSecurityId'yi dolduran önceki veya sonraki kuralların yoksayılmasını ve Sonucun Microsoft Entra Kimliği'nde boş olmasını sağlar.

1. Düşük öncelikli yeni bir özel giden kuralı yapılandırın (160'ın üzerinde yüksek sayı – listenin alt kısmı).
2. Kaynak olarak alternativeSecurityIds alanı ve hedef olarak certificateUserIds alanıyla bir doğrudan dönüşüm ekleyin.
3. Microsoft Entra Id içindeki verilerin popülasyonunu tamamlamak için bir eşitleme döngüsü çalıştırın.

Her kiracıdaki CBA'nın, sertifikayla eşlediğiniz alan türleri için certificateUserIds alanına işaret eden Kullanıcı Adı Bağlamaları ile yapılandırıldığından emin olun. Artık bu kullanıcılardan herhangi biri sertifikayı oturum açma sırasında sunabilir ve sertifikadaki benzersiz değer certificateUserIds alanında doğrulandıktan sonra, bu kullanıcı başarıyla oturum açar.

Sertifika iptal işlemini anlama

Sertifika iptal işlemi, Kimlik Doğrulama İlkesi Yöneticilerinin daha önce verilmiş bir sertifikanın gelecekte kimlik doğrulaması için kullanılmasını iptal etmesine olanak tanır. Sertifika iptali, kullanıcının önceden verilmiş belirteçlerini iptal etmez. İptali yapılandırma konusunda belirteçleri el ile iptal etmek için adımları izleyin.

Microsoft Entra Id, kullanıcının kimlik doğrulaması sırasında sertifikaların iptal edilip iptal edilmediğini denetlemek için sertifika yetkilisinden müşterilerin sertifika iptal listesini (CRL) indirir ve önbelleğe alır.

Kimlik Doğrulama İlkesi Yöneticileri, Microsoft Entra kiracısında güvenilen verenlerin kurulum işlemi sırasında CRL dağıtım noktasını yapılandırabilir. Her güvenilen verenin, İnternet'e yönelik bir URL kullanılarak başvurulabilen bir CRL'si olmalıdır.

Önemli

Microsoft Entra Id için CRL'nin etkileşimli oturum açma ve önbellekte başarıyla indirilmesi için en büyük boyut, genel Microsoft Entra Id'de 20 MB ve Azure ABD Kamu bulutlarında 45 MB'tır ve CRL'yi indirmek için gereken süre 10 saniyeyi geçmemelidir. Microsoft Entra Kimliği CRL'yi indiremezse, ilgili CA tarafından verilen sertifikaları kullanan sertifika tabanlı kimlik doğrulamaları başarısız olur. CRL dosyalarını boyut sınırları içinde tutmak için en iyi uygulama olarak, sertifika yaşam sürelerini makul sınırlar içinde tutun ve süresi dolan sertifikaları temizleyin. Daha fazla bilgi için bkz . CRL boyutu sınırı var mı?.

Bir kullanıcı sertifikayla etkileşimli oturum açma işlemi gerçekleştirdiğinde ve CRL bulut için etkileşimli sınırı aştığında, ilk oturum açma işlemi aşağıdaki hatayla başarısız olur:

"{uri} öğesinden indirilen Sertifika İptal Listesi (CRL), Microsoft Entra Kimliği'ndeki CRL'ler için izin verilen en büyük boyutu ({size} bayt) aştı. Birkaç dakika içinde yeniden deneyin. Sorun devam ederse kiracı yöneticilerinize başvurun."

Hatadan sonra, Microsoft Entra Id hizmet tarafı sınırlarına tabi olarak CRL'yi indirmeye çalışır (genel Microsoft Entra Kimliği'nde 45 MB ve Azure ABD Kamu bulutlarında 150 MB).

Önemli

Kimlik Doğrulama İlkesi Yöneticisi CRL'nin yapılandırmasını atlarsa, Microsoft Entra Id kullanıcının sertifika tabanlı kimlik doğrulaması sırasında herhangi bir CRL denetimi gerçekleştirmez. Bu, ilk sorun giderme için yararlı olabilir, ancak üretim kullanımı için göz önünde bulundurulmamalıdır.

Şu andan itibaren, performans ve güvenilirlik nedeniyle Çevrimiçi Sertifika Durum Protokolü'ne (OCSP) destek vermiyoruz. Microsoft Entra ID, OCSP için istemci tarayıcısı tarafından yapılan her bağlantıda CRL'yi indirmek yerine ilk oturum açmada bir kez indirilir ve önbelleğe alınır, böylece CRL doğrulamasının performansı ve güvenilirliği iyileştirilir. Ayrıca, aramanın her seferinde çok daha hızlı olması için önbelleği dizine ekleriz. Müşterilerin sertifika iptali için CRL'leri yayımlaması gerekir.

Aşağıdaki adımlar CRL denetiminin tipik bir akışıdır:

1. Microsoft Entra Id, ilgili güvenilen veren veya sertifika yetkilisi sertifikasına sahip herhangi bir kullanıcının ilk oturum açma durumunda CRL'yi indirmeye çalışır.
2. Microsoft Entra ID, CRL'yi sonraki kullanımlar için önbelleğe alır ve yeniden kullanabilir. CRL belgesinde Sonraki güncelleştirme tarihini ve varsa Sonraki CRL Yayımlama tarihini (Windows Server CA'ları tarafından kullanılır) kabul eder.
3. Kullanıcı sertifikası tabanlı kimlik doğrulaması aşağıdaki durumlarda başarısız olur:

   • Güvenilir veren için bir CRL yapılandırıldı ve Microsoft Entra ID kullanılabilirlik, boyut veya gecikme kısıtlamaları nedeniyle CRL'yi indiremiyor.

   • Kullanıcının sertifikası CRL'de iptal edilmiş olarak listelenir.

     

   • Microsoft Entra Id, önbelleğe alınan CRL belgesinin süresi dolduysa dağıtım noktasından yeni bir CRL indirmeye çalışır.

Not

Microsoft Entra Id, sertifika veren CA'nın CRL'sini ve PKI güven zincirindeki diğer CA'ları kök CA'ya kadar denetler. PKI zincirinde CRL doğrulaması için yaprak istemci sertifikasından en fazla 10 CA sınırımız vardır. Sınırlama, kötü bir aktörün daha büyük CRL boyutuna sahip çok sayıda CA'ya sahip bir PKI zinciri yükleyerek hizmeti düşürmemesini sağlamaktır. Kiracının PKI zincirinin 5'ten fazla CA'sı varsa ve CA güvenliğinin aşılması durumunda, Kimlik Doğrulama İlkesi Yöneticileri güvenliği aşılmış güvenilen vereni Microsoft Entra kiracı yapılandırmasından kaldırmalıdır.

Önemli

CRL önbelleğe alma ve yayımlama döngülerinin doğası gereği, sertifika iptali durumunda, etkilenen kullanıcının Microsoft Entra ID'deki tüm oturumlarını da iptal etmek kesinlikle önerilir.

Şu andan itibaren CRL'nin indirilmesini el ile zorlamanın veya yeniden denemenin bir yolu yoktur.

İptali yapılandırma

Bir istemci sertifikasını iptal etmek için Microsoft Entra ID, sertifika yetkilisi bilgilerinin bir parçası olarak karşıya yüklenen URL'lerden sertifika iptal listesini (CRL) getirir ve önbelleğe alır. CRL'deki son yayımlama zaman damgası (Geçerlilik Tarihi özelliği), CRL'nin hala geçerli olduğundan emin olmak için kullanılır. CRL'ye, listenin bir parçası olan sertifikalara erişimi iptal etmek için düzenli aralıklarla başvurulur.

Daha hızlı bir iptal gerekiyorsa (örneğin, bir kullanıcı bir cihazı kaybederse), kullanıcının yetkilendirme belirteci geçersiz kılınabilir. Yetkilendirme belirtecini geçersiz hale getirmek için, Windows PowerShell kullanarak bu kullanıcının StsRefreshTokenValidFrom alanını ayarlayın. Erişimini iptal etmek istediğiniz her kullanıcı için StsRefreshTokenValidFrom alanını güncelleştirmeniz gerekir.

İptal işleminin devam etmesini sağlamak için CRL'nin Geçerlilik Tarihini StsRefreshTokenValidFrom tarafından ayarlanan değerden sonraki bir tarihe ayarlamanız ve söz konusu sertifikanın CRL'de olduğundan emin olmanız gerekir.

Not

Azure AD ve MSOnline PowerShell modülleri 30 Mart 2024 itibarıyla kullanım dışı bırakılmıştır. Daha fazla bilgi edinmek için kullanımdan kaldırma güncelleştirmesini okuyun. Bu tarihten sonra bu modüllere yönelik destek, Microsoft Graph PowerShell SDK'sına geçiş yardımı ve güvenlik düzeltmeleriyle sınırlıdır. Kullanım dışı bırakılan modüller Mart 30 2025'e kadar çalışmaya devam edecektir.

Microsoft Entra ID (eski adıyla Azure AD) ile etkileşime geçmek için Microsoft Graph PowerShell'e geçiş yapmanızı öneririz. Sık sorulan geçiş soruları için Bkz. Geçiş hakkında SSS. Not: MSOnline'ın 1.0.x sürümleri 30 Haziran 2024'den sonra kesintiye neden olabilir.

Aşağıdaki adımlarda, StsRefreshTokenValidFrom alanını ayarlayarak yetkilendirme belirtecini güncelleştirme ve geçersiz kılma işlemi özetlenmiştir.

1. PowerShell'e bağlanın:

   Connect-MgGraph
   

2. Bir kullanıcı için geçerli StsRefreshTokensValidFrom değerini alın:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Geçerli zaman damgasına eşit kullanıcı için yeni bir StsRefreshTokensValidFrom değeri yapılandırın:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

Ayarladığınız tarih gelecekte olmalıdır. Tarih gelecekte değilse, StsRefreshTokensValidFrom özelliği ayarlanmaz. Tarih gelecekteyse, StsRefreshTokensValidFrom geçerli saate ayarlanır (Set-MsolUser komutu tarafından belirtilen tarih değil).

CBA, Koşullu Erişim kimlik doğrulama gücü ilkesiyle nasıl çalışır?

Müşteriler, CBA'nın bir kaynağa erişmek için kullanılacağını belirtmek için bir Koşullu Erişim kimlik doğrulaması gücü ilkesi oluşturabilir.

Yerleşik Kimlik Avına dayanıklı MFA kimlik doğrulama gücünü kullanabilirsiniz. Bu ilke yalnızca CBA, FIDO2 güvenlik anahtarları ve İş İçin Windows Hello gibi kimlik avına dayanıklı kimlik doğrulama yöntemlerine izin verir.

Ayrıca, yalnızca CBA'nın hassas kaynaklara erişmesine izin vermek için özel bir kimlik doğrulama gücü oluşturabilirsiniz. CBA'ya tek faktörlü, çok faktörlü veya her ikisi olarak izin vekleyebilirsiniz. Daha fazla bilgi için bkz . Koşullu Erişim kimlik doğrulaması gücü.

Gelişmiş seçeneklerle CBA kimlik doğrulama gücü

CBA Kimlik Doğrulama yöntemleri ilkesinde, Kimlik Doğrulama İlkesi Yöneticisi CBA yönteminde kimlik doğrulama bağlama ilkesini kullanarak sertifikanın gücünü belirleyebilir. Artık kullanıcılar belirli hassas kaynaklara erişmek için CBA gerçekleştirdiğinde veren ve ilke OID'lerine göre belirli bir sertifikanın kullanılmasını gerektirecek özel bir kimlik doğrulama gücü oluşturduğunuzda Gelişmiş seçenekleri yapılandırabilirsiniz. Bu özellik, kaynaklara erişebilecek sertifikaları ve kullanıcıları belirlemek için daha hassas bir yapılandırma sağlar. Daha fazla bilgi için bkz . Koşullu Erişim kimlik doğrulaması gücü için gelişmiş seçenekler.

Oturum açma günlüklerini anlama

Oturum açma günlükleri, oturum açma işlemleri ve kaynaklarınızın kullanıcılarınız tarafından nasıl kullanıldığı hakkında bilgi sağlar. Oturum açma günlükleri hakkında daha fazla bilgi için bkz . Microsoft Entra Id'de oturum açma günlükleri.

Biri sertifikanın tek faktörlü kimlik doğrulamasını, diğeri de sertifikanın MFA'yı karşıladığı iki senaryoyu inceleyelim.

Test senaryoları için, MFA gerektiren Koşullu Erişim ilkesine sahip bir kullanıcı seçin. SAN Asıl Adı'nı UserPrincipalName ile eşleyerek kullanıcı bağlama ilkesini yapılandırın.

Kullanıcı sertifikası şu ekran görüntüsü gibi yapılandırılmalıdır:

Oturum açma günlüklerindeki dinamik değişkenlerle ilgili oturum açma sorunlarını giderme

Oturum açma günlükleri kullanıcının oturum açma sorunlarının hatalarını ayıklamak için tüm bilgileri sağlasa da, belirli değerlerin gerekli olduğu zamanlar vardır ve oturum açma günlükleri dinamik değişkenleri desteklemediğinden oturum açma günlüklerinde eksik bilgiler olur. Örneğin: Oturum açma günlüğündeki hata nedeni "Sertifika İptal Listesi (CRL) imza doğrulaması başarısız oldu. Beklenen Konu Anahtarı Tanımlayıcısı {expectedSKI} CRL Yetkili Anahtarı {crlAK} ile eşleşmiyor. Lütfen kiracı yöneticinizden CRL yapılandırmasını denetlemesini isteyin." burada {expectedSKI} ve {crlAKI} doğru değerlerle doldurulmuyor.

Kullanıcılar CBA ile oturum açma işlemi başarısız olduğunda lütfen hata sayfasındaki 'Diğer Ayrıntılar' bağlantısından günlük ayrıntılarını kopyalayın. Daha ayrıntılı bilgi için CBA hata sayfasını anlama bölümüne bakın

Tek faktörlü kimlik doğrulamasını test edin

İlk test senaryosunda, Veren konu kuralının tek faktörlü kimlik doğrulamasını karşıladığı kimlik doğrulama ilkesini yapılandırın.

1. CBA kullanarak Microsoft Entra yönetim merkezinde test kullanıcısı olarak oturum açın. Kimlik doğrulama ilkesi, Veren konu kuralının tek faktörlü kimlik doğrulamasını karşıladığı yerde ayarlanır.

2. Oturum açma günlüklerini arayın ve seçin.

   Şimdi Oturum açma günlüklerinde bulabileceğiniz girdilerden bazılarına daha yakından bakalım.

   İlk girdi, kullanıcıdan X.509 sertifikasını istemektedir. Kesintiye Uğradı durumu, Microsoft Entra Id'nin kiracıda CBA'nın etkinleştirildiğini doğrulayıp kimlik doğrulaması için bir sertifika istendiğini gösterir.

   

   Etkinlik Ayrıntıları bunun, kullanıcının sertifika seçtiği beklenen oturum açma akışının yalnızca bir parçası olduğunu gösterir.

   

   Ek Ayrıntılar, sertifika bilgilerini gösterir.

   

   Bu ek girişler kimlik doğrulamasının tamamlandığını, tarayıcıya bir birincil yenileme belirteci gönderildiğini ve kullanıcıya kaynağa erişim verildiğini gösterir.

   

Çok faktörlü kimlik doğrulamasını test edin

Sonraki test senaryosunda, policyOID kuralının çok faktörlü kimlik doğrulamasını karşıladığı kimlik doğrulama ilkesini yapılandırın.

1. CBA kullanarak Microsoft Entra yönetim merkezinde oturum açın. İlke çok faktörlü kimlik doğrulamasını karşılamak üzere ayarlandığından, kullanıcı oturum açma işlemi ikinci bir faktör olmadan başarılı oluyor.

2. Oturum açmalar'ı arayın ve seçin.

   Oturum açma günlüklerinde Kesintiye Uğramış duruma sahip bir giriş de dahil olmak üzere çeşitli girişler görürsünüz.

   

   Etkinlik Ayrıntıları bunun, kullanıcının sertifika seçtiği beklenen oturum açma akışının yalnızca bir parçası olduğunu gösterir.

   

   Kesintiye Uğradı durumundaki girdi, Ek Ayrıntılar sekmesinde daha fazla tanılama bilgisi içerir.

   

   Aşağıdaki tabloda her alanın açıklaması yer alır.

   Alan	Açıklama
   Kullanıcı sertifikası konu adı	Sertifikadaki konu adı alanına başvurur.
   Kullanıcı sertifikası bağlama	Sertifika: Asıl Ad; Kullanıcı Özniteliği: userPrincipalName; Derece: 1 Bu, hangi SAN PrincipalName sertifika alanının userPrincipalName kullanıcı özniteliğine eşlendiği ve öncelik 1 olduğunu gösterir.
   Kullanıcı sertifikası kimlik doğrulama düzeyi	multiFactorAuthentication
   Kullanıcı sertifikası kimlik doğrulama düzeyi türü	PolicyId Bu, kimlik doğrulama gücünü belirlemek için kullanılan ilke OID'sini gösterir.
   Kullanıcı sertifikası kimlik doğrulama düzeyi tanımlayıcısı	1.2.3.4 Bu, sertifikadan tanımlayıcı ilkesi OID değerini gösterir.

Sertifika tabanlı kimlik doğrulaması hata sayfasını anlama

Sertifika tabanlı kimlik doğrulaması, sertifikanın geçersiz olması veya kullanıcının yanlış sertifikayı seçmesi veya süresi dolmuş bir sertifika ya da Sertifika İptal Listesi (CRL) sorunu nedeniyle başarısız olabilir. Sertifika doğrulaması başarısız olduğunda kullanıcı şu hatayı görür:

CBA bir tarayıcıda başarısız olursa, hatanın nedeni sertifika seçiciyi iptal etmeniz olsa bile, CBA'yı yeniden denemek için tarayıcı oturumunu kapatmanız ve yeni bir oturum açmanız gerekir. Tarayıcılar sertifikayı önbelleğe alacağından yeni bir oturum gereklidir. CBA yeniden denendiğinde, tarayıcı TLS sınaması sırasında önbelleğe alınmış sertifikayı gönderir ve bu da oturum açma hatasına ve doğrulama hatasına neden olur.

Kimlik Doğrulama İlkesi Yöneticisine gönderilebilen günlük bilgilerini almak için Diğer ayrıntılar'ı seçin. Bu bilgiler oturum açma günlüklerinden daha fazla bilgi alabilir.

Kullanıcının oturum açabilecek diğer yöntemlerini denemek için Diğer oturum açma yolları'nı seçin.

Not

CBA'yı tarayıcıda yeniden denerseniz, tarayıcı önbelleğe alma sorunu nedeniyle başarısız olur. Kullanıcıların yeni bir tarayıcı oturumu açması ve yeniden oturum açması gerekir.

MostRecentlyUsed (MRU) yöntemlerinde sertifika tabanlı kimlik doğrulaması

Bir kullanıcı CBA kullanarak başarıyla kimlik doğrulaması yaptıktan sonra, kullanıcının MostRecentlyUsed (MRU) kimlik doğrulama yöntemi CBA olarak ayarlanır. Bir dahaki sefere, kullanıcı UPN'sini girip İleri'yi seçtiğinde, kullanıcı doğrudan CBA yöntemine alınır ve Sertifikayı veya akıllı kartı kullan'ı seçmesi gerekmez.

MRU yöntemini sıfırlamak için kullanıcının sertifika seçiciyi iptal etmesi, Oturum açmanın diğer yolları'nı seçmesi ve kullanıcının kullanabileceği başka bir yöntem seçip başarıyla kimlik doğrulaması yapması gerekir.

Dış kimlik desteği

Dış kimlik, Microsoft Entra CBA ile kaynak kiracısı için çok faktörlü kimlik doğrulaması gerçekleştiremez. Bunun yerine, kullanıcının ev kiracısında CBA kullanarak MFA gerçekleştirmesini sağlayın ve kaynak kiracının ev kiracısından MFA'ya güvenmesi için kiracılar arası ayarları ayarlayın.

Microsoft Entra kiracılarından Güven çok faktörlü kimlik doğrulamasını etkinleştirme hakkında daha fazla bilgi için bkz. B2B işbirliği kiracılar arası erişimi yapılandırma.

Sonraki adımlar

• Microsoft Entra CBA'ya genel bakış
• Microsoft Entra CBA'yi yapılandırma
• iOS cihazlarda Microsoft Entra CBA
• Android cihazlarda Microsoft Entra CBA
• Microsoft Entra CBA kullanarak Windows akıllı kart oturumu açma
• Sertifika kullanıcı kimlikleri
• Federasyon kullanıcılarını geçirme
• SSS
• Microsoft Entra CBA sorunlarını giderme