Internet Explorer'da Kerberos hatalarını giderme

Bu makale, Internet Explorer'da Kerberos kimlik doğrulamasını kullanacak şekilde yapılandırılmış web sitelerine eriştiğinizde çeşitli hataların nedenlerini yalıtmanıza ve düzeltmenize yardımcı olur. Olası sorunların sayısı, bunları çözmek için kullanılabilecek araç sayısı kadar fazladır.

Kerberos başarısız olduğunda sık görülen belirti

Windows Tümleşik Kimliği Doğrulanmış'ın yapılandırıldığı bir web sitesine erişmeye çalışırsınız ve Kerberos kimlik doğrulama protokolunu kullanmayı beklersiniz. Bu durumda, tarayıcınız aşağıdaki gibi sizden hemen kimlik bilgileri ister:

Geçerli bir kullanıcı adı ve parola girseniz de, yeniden istenir (toplam üç istem). Ardından, istediğiniz kaynağa erişmenize izin verilmediğini gösteren bir ekran gösterilir. Ekranda aşağıdaki hataya benzer bir HTTP 401 durum kodu görüntülenir:

Yetkilendirilmedi
HTTP Hatası 401. İstenen kaynak için kullanıcı kimlik doğrulaması gerekir.

Microsoft Internet Information Services (IIS) sunucusunda, web sitesi günlükleri aşağıdaki günlük gibi 401.2 durum koduyla biten istekler içerir:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Ya da ekranda aşağıdaki günlük gibi bir 401.1 durum kodu görüntülenir:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Kerberos'un kullanılıp kullanılmadığını belirleme

Kerberos kimlik doğrulaması hatasını giderdiğinizde, yapılandırmayı en düşük düzeyde basitleştirmenizi öneririz. Diğer bir ifadeyle, varsayılan bağlantı noktasında çalışan bir istemci, bir sunucu ve bir IIS sitesi. Ayrıca bazı temel sorun giderme adımlarını da izleyebilirsiniz. Örneğin, kullanılan kimlik doğrulama yöntemini doğrulamak için bir test sayfası kullanın. ASP.NET kullanıyorsanız, bu ASP.NET kimlik doğrulama testi sayfasını oluşturabilirsiniz.

Klasik ASP kullanıyorsanız, aşağıdaki Testkerb.asp sayfasını kullanabilirsiniz:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

Kerberos'un kullanılıp kullanılmadığını belirlemek için aşağıdaki araçları da kullanabilirsiniz:

• Fiddler
• HttpWatch
• Ağ İzleyicisi
• Tarayıcınızdaki geliştirici araçları

Bu tür izlemelerin nasıl oluşturulabileceği hakkında daha fazla bilgi için bkz. istemci tarafı izleme.

Kerberos kullanıldığında, üst bilgi Kerberos anahtarını içerdiğinden, istemci tarafından gönderilen istek büyük olur (2.000 bayttan HTTP_AUTHORIZATION fazla). Aşağıdaki istek, gelen kullanıcıların kimliğini doğrulamak için Kerberos tabanlı Windows Kimlik Doğrulaması kullanan bir sayfaya yöneliktir. GET isteğinin boyutu 4.000 bayttan fazladır.

NTLM el sıkışması kullanılırsa istek çok daha küçük olur. Aşağıdaki istemci tarafı yakalaması bir NTLM kimlik doğrulama isteği gösterir. GET isteği çok daha küçüktür (1.400 bayttan az).

Kerberos kimlik doğrulamasının başarısız olduğunu belirledikten sonra, verilen sırayla aşağıdaki öğelerin her birini denetleyin.

Kerberos kimlik doğrulamasının başarısız olup olmadığını denetleme öğeleri

Aşağıdaki bölümlerde, Kerberos kimlik doğrulamasının başarısız olup olmadığını denetlemek için kullanabileceğiniz şeyler açıklanmaktadır.

İstemci ve sunucu aynı etki alanında mı?

Kerberos anahtarı etki alanı denetleyicisi (DC) tarafından teslim edildiğinden Kerberos kullanmak için bir etki alanı gerekir. Aşağıdaki durumlarda gelişmiş senaryolar da mümkündür:

• İstemci ve sunucu aynı etki alanında değil, aynı ormanın iki etki alanında yer alır.
• İstemci ve sunucu iki farklı ormandadır.

Bu olası senaryolar, bu makalenin Çalışırken kullanılan iki ormanım arasında Kerberos temsili neden başarısız oluyor ? bölümünde açıklanmıştır.

IIS tümleşik kimlik doğrulaması kullanacak şekilde yapılandırılmış mı?

Internet Explorer'da tümleşik kimlik doğrulaması etkinleştirildi mi?

Kullanılan URL, kimlik bilgilerinin gönderilebileceği bir güvenlik bölgesine çözümlenebilir mi?

Aşağıdaki siteler için her zaman bu denetimi çalıştırın:

• Tarayıcının Yerel Intranet bölgesiyle eşleşen siteler.
• Güvenilen Siteler bölgesindeki siteler.

Tarayıcınızın siteyi dahil etmeye karar aldığı bölgeyi de kontrol edebilirsiniz. Bunu yapmak için Internet Explorer'ın Dosya menüsünü açın ve özellikler'i seçin. Özellikler penceresi, tarayıcının göz attığınız siteyi dahil etmeye karar aldığı bölgeyi görüntüler.

Sitenin dahil olduğu bölgenin Otomatik oturum açmaya izin verip vermeyeceğini de kontrol edebilirsiniz. Bunu yapmak için Internet Explorer'ın Internet seçenekleri menüsünü açın ve Güvenlik sekmesini seçin. İstediğiniz bölgeyi seçtikten sonra, ayarları görüntülemek için Özel düzey düğmesini seçin ve Otomatik oturum açma'nın seçili olduğundan emin olun. (Bu özellik genellikle Intranet ve Güvenilen Siteler bölgeleri için varsayılan olarak açıktır).

IIS sunucusu WWW-Authenticate: Negotiate üst bilgisini gönderecek şekilde yapılandırılmış mı?

IIS bu üst bilgiyi göndermezse, NTAuthenticationProviders yapılandırma özelliği aracılığıyla Negotiate üst bilgisini ayarlamak için IIS Yöneticisi konsolunu kullanın. Daha fazla bilgi için bkz. Windows Kimlik Doğrulama Sağlayıcıları <sağlayıcıları>. Konsola IIS yöneticisindeki Windows Kimlik Doğrulaması ayrıntılarının Sağlayıcılar ayarı aracılığıyla erişebilirsiniz.

İstemci ve sunucu aynı bilgisayarda yüklü mü?

Varsayılan olarak, Kerberos bu yapılandırmada etkin değildir. Bu davranışı değiştirmek için kayıt defteri anahtarını ayarlamanız DisableLoopBackCheck gerekir. Daha fazla bilgi için bkz. KB 926642.

İstemci Kerberos bileti alabilir mi?

İstemci bilgisayarın belirli bir hizmet asıl adı için Kerberos anahtarı alabildiğini doğrulamak için Kerberos Listesi (KLIST) aracını kullanabilirsiniz. Bu örnekte, hizmet asıl adı (SPN) http/web-server'dır.

Kerberos anahtar isteği başarısız olduğunda Kerberos kimlik doğrulaması kullanılmaz. İstenen SPN DC tarafından bilinmediğinden NTLM geri dönüşü oluşabilir. DC'ye ulaşılamıyorsa NTLM geri dönüşü gerçekleşmez.

SPN bildirmek için aşağıdaki makaleye bakın:

Internet Information Services'te barındırılan Web uygulamalarını yapılandırırken SPN'leri kullanma.

Web sunucusu varsayılandan başka bir bağlantı noktası kullanıyor mu (80)

Varsayılan olarak, Internet Explorer SPN'de Kerberos bileti istemek için kullanılan bağlantı noktası numarası bilgilerini içermez. Farklı bağlantı noktaları ve kimlikler altında birden çok site barındırmak için IIS kullanıyorsanız sorun olabilir. Bu yapılandırmada, Tüm SPN'ler Active Directory'de doğru şekilde bildirilmiş olsa bile Kerberos kimlik doğrulaması yalnızca belirli sitelerde çalışabilir. Bu sorunu düzeltmek için kayıt defteri değerini ayarlamanız FEATURE_INCLUDE_PORT_IN_SPN_KB908209 gerekir. (Anahtarı bildirme hakkında bilgi için Internet Explorer özellik anahtarları bölümüne bakın.) Bu ayar, Internet Explorer'ı Kerberos anahtarını istemek için kullanılan SPN'ye bağlantı noktası numarasını eklemeye zorlar.

Internet Explorer beklenen SPN'yi kullanıyor mu?

Bir web sitesine diğer ad (CNAME) kullanılarak erişiliyorsa, Internet Explorer ilk olarak dns çözümlemesini kullanarak diğer adı bir bilgisayar adına (ANAME) çözümler. Bilgisayar adı daha sonra SPN'yi oluşturmak ve bir Kerberos bileti istemek için kullanılır. Internet Explorer adres çubuğuna http://MYWEBSITEgirilen URL olsa bile, MYWEBSITE bir MYSERVER (ANAME) diğer adıysa Internet Explorer HTTP/MYSERVER için bir SPN ister. Kayıt defteri anahtarını kullanarak FEATURE_USE_CNAME_FOR_SPN_KB911149 bu davranışı değiştirebilirsiniz. (Anahtarı bildirme hakkında bilgi için bkz . Internet Explorer özellik anahtarları .)

Ağ İzleyicisi izlemesi, aşağıdaki örnekte olduğu gibi Kerberos anahtarıyla ilişkili SPN'yi denetlemek için iyi bir yöntemdir:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

Uygulama havuzu kimliği SPN ile ilişkilendirilmiş hesapla eşleşmiyor mu?

Bir Kerberos bileti Internet Explorer'dan IIS sunucusuna gönderildiğinde, anahtar özel anahtar kullanılarak şifrelenir. Özel anahtar, SPN ile ilişkili kullanıcı hesabı için kullanılan parolanın karmasıdır. Bu nedenle yalnızca bu hesap altında çalışan bir uygulama biletin kodunu çözebilir.

Aşağıdaki yordam Kerberos kimlik doğrulama algoritmasının bir özetidir:

1. Internet Explorer, adres çubuğuna girilen URL'yi kullanarak bir SPN belirler.

2. SPN, Windows güvenliğinden (Yerel Güvenlik Yetkilisi Alt Sistem Hizmeti (LSASS) işleminden sorumlu olan sistem bileşenine bir Güvenlik Destek Sağlayıcısı Arabirimi (SSPI) API'si (InitializeSecurityContext) aracılığıyla geçirilir. Bu aşamada, Internet Explorer kodunun Kerberos anahtarını oluşturmak için herhangi bir kod uygulamadığını görebilirsiniz. Internet Explorer yalnızca SSPI API'lerini çağırır.

3. LSASS, DC'ye Kerberos bileti istemek için geçirilen SPN'yi kullanır. DC isteğe hizmet verebilirse (bilinen SPN), bir Kerberos bileti oluşturur. Ardından, SPN ile ilişkilendirilmiş hesabın kullanıcı hesabı parolasının karmasından oluşturulan bir anahtar kullanarak anahtarı şifreler. LSASS daha sonra bileti istemciye gönderir. Internet Explorer söz konusu olduğunda, bilet opak bir blobdur.

4. Internet Explorer, üst bilgide Authorization: Negotiate LSASS tarafından sağlanan Kerberos anahtarını kapsüller ve ardından bileti IIS sunucusuna gönderir.

5. IIS, isteği işler ve belirtilen konak üst bilgisini kullanarak doğru uygulama havuzuna yönlendirir.

6. Uygulama havuzu, SSPI/LSASS API'lerini kullanarak ve şu koşulları izleyerek anahtarın şifresini çözmeyi dener:

   • Anahtarın şifresi çözülebiliyorsa Kerberos kimlik doğrulaması başarılı olur. Biletle ilişkili tüm hizmetler (kimliğe bürünme, bilet izin veriyorsa temsilci seçme vb.) kullanılabilir.

   • Anahtarın şifresi çözülemezse Kerberos hatası (KRB_AP_ERR_MODIFIED) döndürülür. Bu hata, anahtarın aktarım sırasında bir şekilde değiştirildiğini gösteren genel bir hatadır. Bu nedenle biletin şifresi çözülemez. Bu hata, Windows olay günlüklerine de kaydedilir.

SpN'yi açıkça bildirmezseniz, Kerberos kimlik doğrulaması yalnızca aşağıdaki uygulama havuzu kimliklerinden biri altında çalışır:

• Ağ Hizmeti
• ApplicationPoolIdentity
• LOCALSYSTEM veya LOCALSERVICE gibi başka bir sistem hesabı

Ancak bu kimlikler bir güvenlik riski olduğundan önerilmez. Bu durumda Kerberos anahtarı, etki alanına bir bilgisayar (bu durumda IIS'nin çalıştığı sunucu) eklendiğinde Active Directory'de oluşturulan varsayılan SPN kullanılarak oluşturulur. Bu varsayılan SPN, bilgisayar hesabıyla ilişkilendirilir. IIS altında, bilgisayar hesabı Ağ Hizmeti veya ApplicationPoolIdentity ile eşler.

Uygulama havuzunuzun listelenen kimlikler dışında bir kimlik kullanması gerekiyorsa SPN bildirin ( SETSPN kullanarak). Ardından uygulama havuzu kimliğiniz için kullanılan hesapla ilişkilendirin. Yaygın bir hata, farklı hesapları olan benzer SPN'ler oluşturmaktır. Örneğin:

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite UserAppPool2

Http/mywebsite SPN için Kerberos anahtarının UserAppPool1 veya UserAppPool2 parolası kullanılarak şifrelenip şifrelenmediğini bilmenin belirleyici bir yolu olmadığından bu yapılandırma çalışmaz. Bu yapılandırma genellikle KRB_AP_ERR_MODIFIED hatalar oluşturur. Bu hatalı yinelenen SPN senaryosunda olup olmadığınızı belirlemek için aşağıdaki makalede belgelenen araçları kullanın:

AD 2012 R2 ve AD 2016'da neden yine yinelenen SPN'leriniz olabilir?

Windows Server 2008'den itibaren, hedef hesabınız için yeni bir SPN bildirirken komutunu kullanarak setspn –X yinelenen SPN'lerin algılanmasına olanak tanıyan Windows için SETSPN'nin güncelleştirilmiş bir sürümünü de kullanabilirsiniz. Daha fazla bilgi için bkz . Setspn.

Ayrıca aşağıdaki makaleleri gözden geçirmenizi öneririz:

• Kerberos Kimlik Doğrulaması sorunları – Hizmet Asıl Adı (SPN) sorunları - Bölüm 1

• Kerberos Kimlik Doğrulaması sorunları – Hizmet Asıl Adı (SPN) sorunları - Bölüm 2

• Kerberos Kimlik Doğrulaması sorunları – Hizmet Asıl Adı (SPN) sorunları - Bölüm 3

Kerberos kimlik doğrulaması IIS 6'da çalışsa bile IIS 7 ve sonraki sürümlerde başarısız oluyor mu?

Çekirdek modu kimlik doğrulaması, IIS 7'de kullanıma sunulan bir özelliktir. Aşağıdaki avantajları sağlar:

• Çekirdek modundan kullanıcıya mod geçişleri artık yapılmadığından performans artırılır.
• Kerberos anahtarı kod çözme işlemi, uygulama havuzu kimliği kullanılarak değil makine hesabı kullanılarak yapılır. Bu değişiklik, SPN'leri bildirmek zorunda kalmadan farklı kimlikler altında çalışan birden çok uygulama havuzuna sahip olmanıza olanak tanır.

Kerberos kimlik doğrulaması çalışsa da temsilci seçme neden başarısız oluyor?

Bu senaryoda, aşağıdaki öğeleri denetleyin:

• URL için kullanılan Internet Explorer Bölgesi. Kerberos temsilcisine yalnızca Intranet ve Güvenilen Siteler bölgeleri için izin verilir. (Başka bir deyişle, Internet Explorer initializeSecurityContext çağırdığında bayrağı yalnızca belirlenen bölge Intranet veya Güvenilen Siteler olduğunda ayarlarISC_REQ_DELEGATE.)

• Sitenizi barındıran IIS uygulama havuzu için kullanıcı hesabının Active Directory'de Temsilci seçme için güvenilen bayrağı ayarlanmış olmalıdır.

Temsilci seçme işlemi yine başarısız olursa IIS için Kerberos Configuration Manager kullanmayı göz önünde bulundurun. Bu araç, Kerberos kimlik doğrulaması ve hedef hesaplardaki ilişkili SPN'ler için IIS yapılandırmalarını tanılamanıza ve düzeltmenize olanak tanır. Daha fazla bilgi için bkz. README.md. Aracı buradan indirebilirsiniz.

Kerberos kimlik doğrulaması kullanırken neden kötü performans alıyorum?

Kerberos, Windows Server 2008 SP2 ve Windows Server 2008 R2 gibi Eski Windows Server sürümlerinde istek tabanlı bir kimlik doğrulama protokolüdür. Bu, istemcinin sunucuya yapılan her istekle Kerberos anahtarını (oldukça büyük bir blob olabilir) göndermesi gerektiği anlamına gelir. NTLM kullanan kimlik doğrulama yöntemlerine aykırıdır. Varsayılan olarak, NTLM oturum tabanlıdır. Bu, tarayıcının sunucuya TCP bağlantısını açtığında yalnızca bir isteğin kimliğini doğrulanacağı anlamına gelir. Aynı TCP bağlantısındaki sonraki her istek, isteğin kabul edilmesi için artık kimlik doğrulaması gerektirmez. IIS'nin daha yeni sürümlerinde, Windows 2012 R2'den itibaren Kerberos da oturum tabanlıdır. Yalnızca yeni bir TCP bağlantısındaki ilk isteğin kimliği sunucu tarafından doğrulanmalıdır. Sonraki isteklerin Kerberos bileti içermesi gerekmez.

IIS 7 ve sonraki sürümler altında çalıştırıyorsanız authPersistNonNTLM özelliğini kullanarak bu davranışı değiştirebilirsiniz. Özelliği true olarak ayarlanırsa Kerberos oturum tabanlı hale gelir. Aksi takdirde istek tabanlı olur. Her seferinde sunucuya gönderilecek daha büyük miktarda veri içermemiz gerektiğinden daha kötü performansa sahip olacaktır. Daha fazla bilgi için bkz. İstek tabanlı ve Oturum Tabanlı Kerberos Kimlik Doğrulaması (veya AuthPersistNonNTLM parametresi).

Kerberos temsilcisi neden iki ormanım arasında başarısız oluyor?

Aşağıdaki senaryoyu inceleyin:

• Uygulamanızın kullanıcıları A ormanı içindeki bir etki alanında bulunur.
• Uygulamanız B ormanı içindeki bir etki alanında bulunuyor.
• Ormanlar arasında bir güven ilişkin var.

Bu senaryoda, Kerberos temsilcisi daha önce çalışıyor olsa ve ormanlarda veya etki alanlarında herhangi bir değişiklik yapmamış olsanız bile çalışmayı durdurabilir. Kerberos kimlik doğrulaması bu senaryoda hala çalışır. Yalnızca temsilci seçme başarısız olur.

Bu sorun, Mart 2019 ve Temmuz 2019'da Microsoft tarafından yayımlanan Windows Server güvenlik güncelleştirmeleri nedeniyle oluşabilir. Bu güncelleştirmeler, tüm yeni ve mevcut güvenler için orman sınırları arasında kısıtlanmamış Kerberos temsilini (bir uygulamadan bir arka uç hizmetine Kerberos belirteci devretme özelliği) devre dışı bırakılmıştır. Daha fazla bilgi için bkz. Windows Server'da gelen güvenler arasında TGT temsiline Güncelleştirmeler.

Internet Explorer özellik anahtarları

Bu anahtarlar, tarayıcının bazı özelliklerini açıp kapatan kayıt defteri anahtarlarıdır. Anahtarlar aşağıdaki kayıt defteri konumlarında bulunur:

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – kullanıcı düzeyinde tanımlanmışsa
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - makine düzeyinde tanımlanmışsa

Özelliği açmak mı yoksa kapatmak mı istediğinize bağlı olarak özellik anahtarları bu konumlardan birinde oluşturulmalıdır:

• bilgisayardaki tüm kullanıcılar için
• yalnızca belirli bir hesap için

Bu anahtarlar ilgili yol altında oluşturulmalıdır. Anahtarın içinde, adlı iexplorer.exe bir DWORD değeri bildirilmelidir. Özelliğin istenen ayarına bağlı olarak her anahtarın varsayılan değeri true veya false olmalıdır. Varsayılan olarak, hem özellik anahtarlarının FEATURE_INCLUDE_PORT_IN_SPN_KB908209FEATURE_USE_CNAME_FOR_SPN_KB911149hem de değerinin değeri false'tur. Eksiksizlik için, özellik anahtarını Kerberos anahtarına bağlantı noktası numaraları içerecek şekilde true değerine dönüştürerek kayıt defterinin örnek dışarı aktarma işlemi aşağıda verilmiştir:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Daha fazla bilgi

Windows Tümleşik Kimlik Doğrulaması için tanılama sayfaları sorunlarını giderme