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 MaxTokenSize
bu 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 MaxTokenSize
gerekip 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 MaxTokenSize
değ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
MaxTokenSize
elde etmek için formüldeki değeri iki katınaTokenSize
çı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 girdisiniMaxTokenSize
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
MaxTokenSize
en fazla 100.000 bayt değerleri açıklandı. Ancak, 100.000 bayt veya daha büyük olduğundaMaxTokenSize
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.
Geri Bildirim
https://aka.ms/ContentUserFeedback.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz.Gönderin ve geri bildirimi görüntüleyin