Bir kullanıcı birçok gruba ait olduğunda Kerberos kimlik doğrulamasıyla ilgili sorunlar

Bu makale, bir kullanıcı birçok gruba ait olduğunda Kerberos kimlik doğrulaması hatası sorunlarını çözmenize yardımcı olur.

Şunlar için geçerlidir: Windows 10 - tüm sürümler, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Özgün KB numarası: 327825

Belirtiler

Çok sayıda güvenlik grubuna ait olan bir kullanıcının kimlik doğrulaması sorunları vardır. Kimlik doğrulaması yaparken, kullanıcı HTTP 400 - Hatalı İstek (İstek Üst Bilgisi çok uzun) gibi bir ileti görebilir. Kullanıcının kaynaklara erişim sorunları da vardır ve kullanıcının grup ilkesi ayarları doğru güncelleştirilmeyebilir.

Hatanın bağlamı hakkında daha fazla bilgi için bkz . HTTP isteklerine http 400 Hatalı İstek (İstek Üst Bilgisi çok uzun) yanıtları.

Not

Benzer koşullarda, Windows NTLM kimlik doğrulaması beklendiği gibi çalışır. Windows davranışını analiz etmediğiniz sürece Kerberos kimlik doğrulama sorununu göremeyebilirsiniz. Ancak, bu tür senaryolarda Windows grup ilkesi ayarlarını güncelleştiremeyebilir.

Bu davranış, şu anda desteklenen Windows sürümlerinden herhangi birinde oluşur. Şu anda desteklenen Windows sürümleri hakkında bilgi için bkz. Windows yaşam döngüsü bilgi sayfası.

Neden

Kerberos'un kullanıcıyı temsil etmek için derlediği bilet, kullanıcının tüm grup üyeliklerini içerecek kadar büyük olmadığından kullanıcı kimlik doğrulaması yapamıyor.

Kimlik Doğrulama Hizmeti Değişimi'nin bir parçası olarak, Windows yetkilendirme amacıyla kullanıcıyı temsil eden bir belirteç oluşturur. Bu belirteç (yetkilendirme bağlamı olarak da adlandırılır) kullanıcının güvenlik tanımlayıcılarını (SID) ve kullanıcının ait olduğu tüm grupların SID'lerini içerir. Ayrıca, kullanıcı hesabının sIDHistory özniteliğinde depolanan tüm SID'leri de içerir. Kerberos bu belirteci Kerberos Ticket-Getting Anahtarındaki (TGT) Privilege Attribute Certificate (PAC) veri yapısında depolar. kerberos, Windows Server 2012 başlayarak belirteci Kerberos anahtarındaki Active Directory Talep bilgileri (Dinamik Access Control) veri yapısında da depolar. Kullanıcı çok sayıda grubun üyesiyse ve kullanıcı veya kullanılmakta olan cihaz için çok fazla talep varsa, bu alanlar bilette çok fazla alan kaplayabilir.

Belirtecin sabit bir en büyük boyutu (MaxTokenSize) vardır. Uzak yordam çağrısı (RPC) ve HTTP gibi aktarım protokolleri, kimlik doğrulama işlemleri için arabellek ayırdığında değere güvenir MaxTokenSize . MaxTokenSize belirteci oluşturan Windows sürümüne bağlı olarak aşağıdaki varsayılan değere sahiptir:

  • Windows Server 2008 R2 ve önceki sürümleri ile Windows 7 ve önceki sürümleri: 12.000 bayt
  • Windows Server 2012 ve sonraki sürümleri ile Windows 8 ve sonraki sürümleri: 48.000 bayt

Genel olarak, kullanıcı 120'den fazla evrensel gruba aitse, varsayılan MaxTokenSize değer bilgileri barındıracak kadar büyük bir arabellek oluşturmaz. Kullanıcı kimlik doğrulaması yapamaz ve yetersiz bellek iletisi alabilir. Ayrıca, Windows kullanıcı için grup ilkesi ayarlarını uygulayamayabilir.

Not

Diğer faktörler de en fazla grup sayısını etkiler. Örneğin, genel ve etki alanı yerel gruplarının SID'leri daha küçük alan gereksinimlerine sahiptir. Windows Server 2012 ve sonraki sürümler Kerberos anahtarına talep bilgileri ekler ve ayrıca kaynak SID'lerini sıkıştırır. Her iki özellik de alan gereksinimlerini değiştirir.

Çözüm

Bu sorunu çözmek için, istemci bilgisayarlar da dahil olmak üzere Kerberos kimlik doğrulama işlemine katılan her bilgisayarda kayıt defterini güncelleştirin. Özellikle kullanıcılarınızın birden çok etki alanı veya ormanda oturum açması gerekiyorsa, tüm Windows tabanlı sistemlerinizi güncelleştirmenizi öneririz.

Önemli

Kayıt defterini hatalı olarak değiştirirseniz önemli sorunlar oluşabilir. Değiştirmeden önce, sorun oluşması durumunda geri yükleme için kayıt defterini yedekleyin.

Bu bilgisayarların her birinde kayıt defteri girdisini MaxTokenSize daha büyük bir değere ayarlayın. Bu girdiyi alt anahtarda HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters bulabilirsiniz. Bu değişikliği yaptıktan sonra bilgisayarların yeniden başlatılması gerekir.

için yeni bir değer belirleme hakkında daha fazla bilgi için MaxTokenSizebu makalenin En büyük belirteç boyutunu hesaplama bölümüne bakın.

Örneğin, SQL Server istemcisini kullanan bir web uygulaması kullanan bir kullanıcıyı düşünün. Kimlik doğrulama işleminin bir parçası olarak, SQL Server istemcisi kullanıcının belirtecini bir arka uç SQL Server veritabanına geçirir. Bu durumda, aşağıdaki bilgisayarların her birinde kayıt defteri girdisini yapılandırmanız MaxTokenSize gerekir:

  • Internet Explorer çalıştıran istemci bilgisayar
  • IIS çalıştıran web sunucusu
  • SQL Server istemci bilgisayarı
  • SQL Server veritabanı bilgisayarı

Windows Server 2012 (ve sonraki sürümlerde), belirteç boyutu belirli bir eşiği geçerse Windows bir olayı (Olay Kimliği 31) günlüğe kaydedebilir. Bu davranışı etkinleştirmek için, büyük Kerberos anahtarları için Bilgisayar Yapılandırması\Yönetim Şablonları\Sistem\KDC\Uyarı grup ilkesi ayarını yapılandırmanız gerekir.

En büyük belirteç boyutunu hesaplama

Windows'un belirli bir kullanıcı için oluşturduğu belirtecin boyutunu hesaplamak için aşağıdaki formülü kullanın. Bu hesaplama, öğesini değiştirmeniz MaxTokenSizegerekip gerekmediğini belirlemenize yardımcı olur.

TokenSize = 1200 + 40d + 8s

Windows Server 2012 (ve sonraki sürümler) için bu formül bileşenlerini aşağıdaki gibi tanımlar:

  • 1200. Kerberos anahtarının tahmini ek yük değeri. Bu değer, DNS etki alanı adının uzunluğu ve istemci adının uzunluğu gibi faktörlere bağlı olarak değişebilir.
  • d. Aşağıdaki değerlerin toplamı:
    • Kullanıcının hesap etki alanı dışındaki evrensel gruplardaki üyeliklerin sayısı.
    • Hesabın sIDHistory özniteliğinde depolanan SID sayısı. Bu değer grup üyeliklerini ve kullanıcı SID'lerini sayar.
  • s. Aşağıdaki değerlerin toplamı:
    • Kullanıcının hesap etki alanı içindeki evrensel gruplardaki üyeliklerin sayısı.
    • Etki alanı yerel gruplarındaki üyeliklerin sayısı.
    • Genel gruplardaki üyelik sayısı.

Windows Server 2008 R2 ve önceki sürümler aynı formülü kullanır. Ancak bu sürümler, etki alanı yerel grup üyeliklerinin sayısını s değeri yerine d değerinin parçası olarak kabul eder.

0x0000FFFF (64K) değerine sahipsenizMaxTokenSize, yaklaşık 1600 d sınıfı SID veya yaklaşık 8000 s sınıfı SID'yi arabelleğe alabilirsiniz. Bununla birlikte, için güvenli bir şekilde kullanabileceğiniz MaxTokenSizedeğeri aşağıdakiler de dahil olmak üzere başka bir dizi faktör etkiler:

  • Temsilci hesapları için güvenilir kullanırsanız, her SID için iki kat fazla alan gerekir.

  • Birden çok güvene sahipseniz, GÜVEN'leri SID'leri filtrelemek için yapılandırın. Bu yapılandırma Kerberos anahtar boyutunun etkisini azaltır.

  • Windows Server 2012 veya sonraki bir sürümü kullanıyorsanız, aşağıdaki faktörler SID alanı gereksinimlerini de etkiler:

    • PAC'teki SID'leri sıkıştırmak için yeni bir şema vardır. Daha fazla bilgi için bkz. KDC Kaynak SID Sıkıştırması. Bu özellik, biletteki SID'ler için gereken boyutu azaltır.
    • Dinamik Access Control, anahtara Active Directory talepleri ekler ve boyut gereksinimlerini artırır. Ancak, talepleri Windows Server 2012 dosya sunucularıyla dağıttığınızda, dosya erişimini denetleyen çok sayıda grubu aşamaya almayı bekleyebilirsiniz. Bu azaltma, bilette gereken boyutu da azaltabilir. Daha fazla bilgi için bkz. Dinamik Access Control: Senaryoya Genel Bakış.
  • Kerberos'u kısıtlanmamış temsil kullanacak şekilde yapılandırdıysanız, geçerli bir tahmin MaxTokenSizeelde etmek için formüldeki değeri iki katına TokenSize çıkarmış olmanız gerekir.

    Önemli

    2019'da Microsoft, Kerberos için kısıtlanmamış temsilin varsayılan yapılandırmasını devre dışı olarak değiştiren güncelleştirmeleri Windows'a gönderdi. Daha fazla bilgi için bkz. Windows Server'da gelen güvenler arasında TGT temsiline Güncelleştirmeler.

    Kaynak SID sıkıştırması yaygın olarak kullanıldığından ve kısıtlanmamış temsil kullanım dışı bırakıldığından, MaxTokenSize 48000 veya daha büyük bir değerin tüm senaryolar için yeterli hale gelmesi gerekir.

MaxTokenSize'i etkileyen bilinen sorunlar

MaxTokenSize Çoğu uygulama için 48.000 baytlık bir değer yeterli olmalıdır. Bu, Windows Server 2012 ve sonraki sürümlerde varsayılan değerdir. Ancak daha büyük bir değer kullanmaya karar verirseniz bu bölümdeki bilinen sorunları gözden geçirin.

  • LSA erişim belirteci için 1.010 grup SID'si boyut sınırı

    Bu sorun, çok fazla grup üyeliği olan bir kullanıcının kimlik doğrulaması yapamamalarına benzer, ancak sorunu yöneten hesaplamalar ve koşullar farklıdır. Örneğin, kullanıcı Kerberos kimlik doğrulamasını veya Windows NTLM kimlik doğrulamasını kullanırken bu sorunla karşılaşabilir. Daha fazla bilgi için bkz. Windows Server tabanlı bir bilgisayarda 1.010'dan fazla grubun üyesi olan bir kullanıcı hesabında günlüğe kaydetme işlemi başarısız olabilir.

  • 48.000'den büyük MaxTokenSize değerlerini kullanırken bilinen sorun

    Hizmet reddi saldırı vektörünün etkisini azaltmak için Internet Information Server (IIS), 64 KB'lık sınırlı bir HTTP isteği arabellek boyutu kullanır. BIR HTTP isteğinin parçası olan bir Kerberos anahtarı Base64 (6 bit 8 bit olarak genişletilmiş) olarak kodlanır. Bu nedenle, Kerberos anahtarı özgün boyutunun yüzde 133'ünü kullanıyor. Bu nedenle, IIS'de arabellek boyutu üst sınırı 64 KB olduğunda Kerberos anahtarı 48.000 bayt kullanabilir.

    Kayıt defteri girdisini MaxTokenSize 48000 bayttan büyük bir değere ayarlarsanız ve arabellek alanı SID'ler için kullanılırsa IIS hatası oluşabilir. Ancak, kayıt defteri girdisini MaxTokenSize 48.000 bayt olarak ayarlarsanız ve ALANı SID'ler ve talepler için kullanırsanız, kerberos hatası oluşur.

    IIS arabellek boyutları hakkında daha fazla bilgi için bkz. Windows 2000'de IIS'nin bir istemciden kabul yaptığı HTTP iletiminin üst bilgi boyutunu sınırlama.

  • 65.535'ten büyük MaxTokenSize değerlerini kullanırken bilinen sorunlar

    Bu makalenin önceki sürümlerinde için MaxTokenSizeen fazla 100.000 bayt değerleri açıklandı. Ancak, 100.000 bayt veya daha büyük olduğunda MaxTokenSize SMS Yöneticisi sürümlerinin sorun yaşadığını bulduk.

    Ayrıca, IPSEC IKE protokollerinin bir güvenlik BLOB'unun 66.536 bayttan büyük olmasına izin vermediğini ve daha büyük bir değere ayarlandığında da başarısız MaxTokenSize olacağını belirledik.