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.

Microsoft Entra sertifika tabanlı kimlik doğrulamasının nasıl çalıştığıyla ilgili adımları gösteren çizim.

Ş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.

    MyApps portalında oturum açma işleminin ekran görüntüsü.

  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.

    Sertifika veya akıllı kart kullan seçeneğinin ekran görüntüsü.

    Telefon oturum 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.

    FIDO2 de etkinse Oturum açma işleminin ekran görüntüsü.

  5. Kullanıcı sertifika tabanlı kimlik doğrulamasını seçtikten sonra, istemci genel Entra Kimliği için olan https://certauth.login.microsoftonline.com certauth uç noktasına 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 işlemleri 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, yaklaşan Güvenilen CA ipuçları özelliğini 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.

    Not

    Güvenilen CA ipuçları desteklenmez, bu nedenle sertifika listesinin kapsamı daha fazla olamaz. Gelecekte bu işlevselliği eklemeyi araştırıyoruz.

    Sertifika seçicinin ekran görüntüsü.

  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.

Sertifika tabanlı kimlik doğrulaması MFA özelliklidir

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önetici istrator 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önetici istrator 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önetici istrator 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 (Önizleme)

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 parolasız telefon oturumu açma (ikinci faktör olarak parolasız oturum açma)
  2. CBA (ilk faktör) ve FIDO2 güvenlik anahtarları (ikinci faktör)
  3. Parola (ilk faktör) ve CBA (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önetici istratörü 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.

    Çok faktörlü kimlik doğrulama ayarlarını yapılandırma ekran görüntüsü.

  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.

    Mobil uygulama aracılığıyla bildirimin nasıl kaldırılacağını gösteren ekran görüntüsü.

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.

    Kullanıcı asıl adı girme ekran görüntüsü.

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

    Sertifikayla oturum açma ekran görüntüsü.

    Telefon oturum 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.

    Sertifikayla oturum açmanın alternatif yolunun ekran görüntüsü.

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

    Sertifika seçme ekran görüntüsü.

  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.

    İkinci faktör isteğinin ekran görüntüsü.

  5. Telefonunuzda bir bildirim alırsınız. Oturum açmayı onayla? seçeneğini belirleyin. Onay isteğinin ekran görüntüsü.

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

    Sayı eşleşmesinin ekran görüntüsü.

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

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. Yönetici, varsayılan değeri tek faktörden çok faktörlüye 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

Bir yönetici 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 ilkesi Yönetici istratörü 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

Entra kiracı yöneticisinin hem Veren hem de İlke OID'sini kullanarak bir 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 Oturum Açma

Workplace Join, Entra ID ve Hybrid Entra ID cihaz katılım senaryolarıyla cihaz kaydı etkilenmez. Veren VEYA İlke OID kullanan CBA kimlik doğrulama ilkesi kuralları etkilenmez. Azaltmak için yöneticilerin şunları yapması gerekir:

  • 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>123456789abcdef certificateUserIds yüksek benzite
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds yüksek benzite
IssuerAndSerialNumber (önizleme) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
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 bir Kimlik Doğrulama İlkesi Yönetici istrator, düşük benşimlilik veya yüksek benşimli kullanıcı adı bağlama eşlemesi kullanılarak bir 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 kiracı yöneticisi tarafından yapılan tüm kullanıcı adı bağlamalarının kurulumunun 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, bir yöneticinin birden çok 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önetici istrator ş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 tek bir sertifikanın birden çok hesaba eşlemesine izin vermek istemiyorsanız, Kimlik Doğrulama İlkesi Yönetici istrator 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önetici istratörü 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önetici istrator 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 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>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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ü aramak için certificateUserIds alanına işaret edecek şekilde ayarlandıysa (örneğin, bu örnekte Issuer+SerialNumber) 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ş, Veren + 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>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Bu örnekte ilk değer X509Certificate1 değerini, ikinci değer ise X509Certificate2 değerini temsil eder. Bu değerlerin daha sonra Azure AD'deki certificateUserIds alanına eşitlenmesi gerekir.

Birden çok Entra kullanıcı hesabı olan 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ı Entra Id hesaplarında kimlik doğrulaması yapmak için aynı kimlik bilgilerini kullanmak çok güvenli bir yapılandırma değildir ve birden çok 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 (örneğin, değerler hesap başına benzersiz kaldığı sürece kiracı yöneticisi 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ş yüksek benzeşim bağlamaları (güçlü kimlik doğrulaması) bağlamaları kullanıyorsa Issuer + SerialNumber ve SKI gibi görünü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>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

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. Kiracı yöneticisi sertifikayı kullanacak her kullanıcı hesabıyla benzersiz değerleri eşleyebilse de, Tüm değerleri Entra ID'deki her hesaba doldurmanın yaygın uygulaması bunu zor hale getirir. Bunun yerine, Azure AD Bağlan hesap başına istenen değerleri Entra Id'de hesaba doldurulmuş benzersiz değerlere göre filtrelemelidir. Benzersizlik kuralı tek bir dizin/kiracı sınırı içinde geçerlidir (örneğin, değerler hesap başına benzersiz kaldığı sürece kiracı yöneticisi sertifikayı başka bir dizinde/kiracıda kullanmak üzere eşleyebilir). Ayrıca, kuruluşun kullanıcılara tek bir Entra ID kiracısına katkıda bulunan birden çok AD ormanı olabilir. Bu durumda Azure AD Bağlan, bu AD ormanlarının her birine filtreyi uygulayarak bulut hesabına yalnızca istenen benzersiz değeri doldurmayı hedefleyecektir.

AD'deki altSecurityIdentities alanını istenen sertifikayı tanımlayan değerlerle doldurun ve bu kullanıcı hesabı türü için istenen sertifika değerini ekleyin (örn. ayrıntı, yönetici, geliştirici vb.). AD'de, eşitlemeye kullanıcının hangi kullanıcı hesabı türünü değerlendireceğini (örneğin, msDS-cloudExtensionAttribute1) 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>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Orman 1 - Hesap2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Orman 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Bu değerlerin daha sonra 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 Azure AD connect'i yapılandırma
  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 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 değerini dolduran önceki veya sonraki kuralların yoksayılmasını ve Entra Id içinde sonucun 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. 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, yöneticinin 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.

Yönetici, 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'nin etkileşimli oturum açma ve önbellekte başarıyla indirilmesi için crl boyutu üst sınırı genel 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 Entra ID'de 45 MB ve Azure ABD Kamu bulutlarında 150 MB).

Önemli

Yönetici 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.

      CRL'de iptal edilen kullanıcı sertifikasının ekran görüntüsü.

    • 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'nın güvenliğinin aşılması durumunda yöneticinin güvenliği aşılmış güvenilen vereni Microsoft Entra kiracı yapılandırmasından kaldırması gerekir.

Ö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:

    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 yönetici, 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:

Kullanıcı sertifikasının ekran görüntüsü.

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.

Tek faktörlü kimlik doğrulamasının gerekli olduğunu gösteren Kimlik doğrulama ilkesi yapılandırmasının ekran görüntüsü.

  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.

    Oturum açma günlüklerindeki tek faktörlü kimlik doğrulama girişinin ekran görüntüsü.

    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.

    Oturum açma günlüklerindeki etkinlik ayrıntılarının ekran görüntüsü.

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

    Oturum açma günlüklerindeki çok faktörlü ek ayrıntıların ekran görüntüsü.

    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.

    Oturum açma günlüklerindeki yenileme belirteci girişinin ekran görüntüsü.

Ç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.

Çok faktörlü kimlik doğrulamasının gerekli olduğunu gösteren Kimlik doğrulama ilkesi yapılandırmasının ekran görüntüsü.

  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.

    Oturum açma günlüklerindeki çeşitli girişlerin ekran görüntüsü.

    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.

    Oturum açma günlüklerindeki ikinci faktörlü oturum açma ayrıntılarının ekran görüntüsü.

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

    Oturum açma günlüklerindeki kesintiye uğramış deneme ayrıntılarının ekran görüntüsü.

    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:

Sertifika doğrulama hatasının ekran görüntüsü.

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.

Yöneticiye 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.

Hata ayrıntılarının ekran görüntüsü.

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.

Yeni bir oturum açma girişiminin ekran görüntüsü.

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