Kurumsal Uygulamalarda Sonsuz Parola Döngüsü: Outlook ve Microsoft Edge “NTLM Blocking” Sorunu

Kurumsal Active Directory ortamlarında kullanıcıların en sık karşılaştığı problemlerden biri doğru kullanıcı adı ve parola girilmesine rağmen kimlik doğrulama ekranının sürekli tekrar etmesidir.

Özellikle Microsoft Edge üzerinden şirket içi Intranet, ERP, CRM veya benzeri web uygulamalarına erişilmeye çalışıldığında ya da Outlook açıldığında kullanıcıdan sürekli parola istenebilir.

Bazı durumlarda parola doğru girilmesine rağmen pencere kapanmaz bazı durumlarda ise kullanıcı “Access Denied”, “Unauthorized” veya “Erişim Engellendi” hatası ile karşılaşır.

Bu problem ilk bakışta kullanıcı hesabı, parola süresi, Outlook profili, tarayıcı cache’i veya Exchange erişim problemi gibi görünebilir. Ancak kök neden çoğu zaman istemci, tarayıcı, web sunucusu veya Exchange mimarisi arasındaki kimlik doğrulama yönteminin uyumsuz çalışmasıdır.

Özellikle NTLM, NTLMv2, Negotiate ve Kerberos geçişlerinde yaşanan yapılandırma eksiklikleri bu tür sonsuz parola döngülerine neden olabilir.

Problemin Genel Belirtileri

Bu sorun genellikle aşağıdaki senaryolarla kendini gösterir:

Kullanıcı Microsoft Edge üzerinden şirket içi bir web uygulamasına erişmeye çalışır. Sayfa açılmadan önce Windows kimlik bilgisi ekranı gelir. Kullanıcı domain hesabını doğru yazmasına rağmen aynı ekran tekrar tekrar gelir.

Outlook açıldığında kullanıcıdan sürekli parola istenir. Parola doğru girilse bile Outlook bağlantısı sağlıklı şekilde kurulamaz veya kısa süre sonra tekrar parola sorulur.

Bazı kullanıcılarda sorun yaşanırken bazı kullanıcılarda yaşanmaz. Bu durum genellikle farklı OU, farklı GPO, farklı Windows build, farklı Edge policy veya farklı güvenlik güncelleştirme seviyelerinden kaynaklanır.

Sunucu tarafında IIS, Exchange, reverse proxy veya load balancer kullanılıyorsa, Kerberos için gerekli SPN kayıtları eksik veya hatalı olabilir.

NTLM, Kerberos ve Negotiate İlişkisi

Windows domain ortamlarında kimlik doğrulama için uzun yıllardır NTLM ve Kerberos protokolleri kullanılmaktadır. Kerberos, domain ortamlarında daha güvenli ve modern kimlik doğrulama yöntemi olarak tercih edilir.

NTLM ise daha eski bir protokoldür ve Microsoft tarafından artık aktif geliştirme altında olmayan, kullanımı azaltılması önerilen bir kimlik doğrulama yöntemi olarak konumlandırılmıştır. Microsoft, NTLM çağrılarının doğrudan NTLM yerine “Negotiate” üzerinden yapılmasını, Negotiate’in önce Kerberos denemesini ve gerekirse NTLM’e fallback yapmasını önerir.

Buradaki kritik nokta şudur:
Kerberos’un çalışabilmesi için istemcinin bağlandığı servis adının Active Directory tarafında doğru bir SPN kaydına karşılık gelmesi gerekir. SPN, Kerberos kimlik doğrulamasında servis örneğini servis hesabıyla eşleştiren benzersiz kimliktir.

Örneğin kullanıcı şu adrese gidiyorsa:

https://erp.sirket.local

Kerberos açısından bu erişim çoğu zaman aşağıdaki SPN kaydını gerektirir:

HTTP/erp.sirket.local

Eğer bu SPN doğru servis hesabına veya doğru bilgisayar hesabına tanımlı değilse, Kerberos devreye giremez. Bu durumda istemci NTLM’e düşmeye çalışabilir. Ancak ortamda NTLM kısıtlanmışsa, NTLMv1 devre dışı bırakılmışsa, NTLM trafiği policy ile engellenmişse veya Edge/Outlook tarafında kimlik doğrulama şemaları doğru tanımlı değilse kullanıcı sonsuz parola döngüsüyle karşılaşabilir.

Kök Neden: NTLM Kısıtlaması ve Eksik Kerberos Yapılandırması

Güvenlik sıkılaştırması yapılan kurumsal ortamlarda NTLM kullanımı azaltılır veya tamamen sınırlandırılır. Bu doğru bir güvenlik yaklaşımıdır; ancak Kerberos tarafı eksiksiz hazırlanmadıysa kullanıcı deneyimi ciddi şekilde etkilenir.

Sık görülen kök nedenler şunlardır:

Web sunucusu veya uygulama sunucusu için SPN kaydı eksiktir.

Exchange ortamında Outlook, Autodiscover veya MAPI endpoint’leri için Kerberos yapılandırması eksiktir.

Load balancer arkasındaki Exchange veya IIS sunucularında ortak isim üzerinden erişim vardır fakat bu ortak isim için SPN doğru yapılandırılmamıştır.

Edge tarafında Integrated Windows Authentication için gerekli kurumsal URL izin listesi tanımlı değildir.

Windows istemcilerde LMCompatibilityLevel, eski NTLM davranışlarıyla çakışacak şekilde yapılandırılmıştır.

Security Baseline veya GPO ile NTLM kısıtlanmıştır, ancak uygulama hâlâ NTLM bağımlıdır.

Bu nedenle bu problem yalnızca “kullanıcı parolasını sıfırlayarak” veya “Outlook profilini yeniden oluşturarak” kalıcı olarak çözülmez. Asıl çözüm, kimlik doğrulama zincirinin doğru tasarlanmasıdır.

İstemci Tarafında Geçici Çözüm: LMCompatibilityLevel Ayarı

İstemci tarafında yapılabilecek ilk kontrollerden biri LAN Manager authentication level ayarıdır. Microsoft dokümantasyonuna göre LMCompatibilityLevel değeri 5 yapıldığında istemciler NTLMv2 kullanır; Domain Controller tarafında ise LM ve NTLM yanıtları reddedilir, yalnızca NTLMv2 kabul edilir.

Bu ayar eski LM ve NTLMv1 davranışlarını engelleyerek daha güvenli NTLMv2 kullanımını zorlar. Ancak bu ayar her ortamda doğrudan uygulanmamalıdır. Eski sistemler, eski NAS cihazları, eski uygulamalar veya NTLMv1 bağımlı servisler varsa erişim problemleri oluşabilir.

Yönetici olarak PowerShell veya Komut İstemi açılarak aşağıdaki komut çalıştırılabilir:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LMCompatibilityLevel /t REG_DWORD /d 5 /f

Bu ayar sonrasında istemcinin yeniden başlatılması önerilir.

GPO üzerinden uygulamak için yol:

Computer Configuration
 └─ Windows Settings
    └─ Security Settings
       └─ Local Policies
          └─ Security Options
             └─ Network security: LAN Manager authentication level

Önerilen değer:

Send NTLMv2 response only. Refuse LM & NTLM

Bu adım tek başına Kerberos problemini çözmez. Sadece istemcinin eski NTLM protokollerine düşmesini engeller ve NTLMv2 kullanımını garanti altına alır.

Microsoft Edge İçin Kurumsal Adresleri Integrated Authentication Listesine Eklemek

Microsoft Edge tarafında Integrated Windows Authentication’ın hangi sunucular için kullanılacağını policy ile belirlemek mümkündür. Microsoft Edge dokümantasyonunda bunun için AuthServerAllowlist policy’si kullanılır.

Bu policy, Edge’in entegre kimlik doğrulamayı hangi sunucu veya domain listesi için etkinleştireceğini belirler; virgülle ayrılmış sunucu adları ve wildcard kullanımı desteklenir.

Ayrıca Edge’de hangi HTTP authentication şemalarının kullanılacağını belirlemek için AuthSchemes policy’si kullanılır. Bu policy basic, digest, ntlm ve negotiate değerlerini destekler. Değerler virgülle ayrılır ve case-sensitive çalışır.

Registry üzerinden örnek yapılandırma aşağıdaki gibi uygulanabilir:

$Path = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"

if (-not (Test-Path $Path)) {
    New-Item -Path $Path -Force
}

New-ItemProperty -Path $Path `
    -Name "AuthSchemes" `
    -Value "ntlm,negotiate" `
    -PropertyType String `
    -Force

New-ItemProperty -Path $Path `
    -Name "AuthServerAllowlist" `
    -Value "*.sirket.local,intranet.sirket.local,erp.sirket.local,mail.sirket.local,autodiscover.sirket.local" `
    -PropertyType String `
    -Force

Bu örnekte *.sirket.local ifadesi şirket içi domain yapısını temsil eder. Kendi ortamınıza göre aşağıdaki gibi değerler kullanılabilir:

*.contoso.local
*.contoso.com
intranet.contoso.com
erp.contoso.com
mail.contoso.com
autodiscover.contoso.com

Policy’nin uygulanıp uygulanmadığını kontrol etmek için Edge adres çubuğuna aşağıdaki adres yazılabilir:

edge://policy

Burada AuthSchemes ve AuthServerAllowlist değerlerinin görünüyor olması gerekir.

GPO ile Edge Authentication Policy Tanımlama

Registry yerine merkezi yönetim için GPO kullanılması daha doğru bir yöntemdir. Bunun için Microsoft Edge ADMX şablonlarının domain ortamına yüklenmiş olması gerekir.

GPO yolu genel olarak şu şekildedir:

Computer Configuration
 └─ Administrative Templates
    └─ Microsoft Edge
       └─ HTTP authentication

Burada aşağıdaki policy’ler yapılandırılabilir:

Supported authentication schemes
Configure list of allowed authentication servers

Örnek değerler:

Supported authentication schemes:
ntlm,negotiate

Configure list of allowed authentication servers:
*.sirket.local,intranet.sirket.local,erp.sirket.local,mail.sirket.local,autodiscover.sirket.local

GPO uygulandıktan sonra istemci üzerinde aşağıdaki komutlarla policy yenilenebilir:

gpupdate /force

Ardından Edge policy ekranı kontrol edilmelidir:

edge://policy

Kalıcı Çözüm: Sunucu Tarafında Kerberos ve SPN Yapılandırması

İstemci tarafında yapılan registry veya GPO ayarları operasyonel kesintiyi azaltmak için kullanılabilir. Ancak kalıcı ve doğru çözüm, sunucu tarafında Kerberos yapılandırmasının tamamlanmasıdır.

Öncelikle ilgili servis için SPN kaydı kontrol edilmelidir:

setspn -Q HTTP/erp.sirket.local

Eğer kayıt yoksa ve web uygulaması bir domain servis hesabı altında çalışıyorsa, SPN ilgili servis hesabına eklenmelidir:

setspn -S HTTP/erp.sirket.local DOMAIN\svc-erp
setspn -S HTTP/intranet.sirket.local DOMAIN\svc-erp

Eğer IIS uygulaması Network Service, Local System veya ApplicationPoolIdentity gibi bilgisayar hesabı üzerinden çalışıyorsa SPN bilgisayar hesabında olabilir:

setspn -S HTTP/erp.sirket.local DOMAIN\WEB01$

Burada en önemli nokta SPN’in doğru hesaba eklenmesidir. Aynı SPN’in birden fazla hesapta bulunması Kerberos hatalarına neden olur. Bu nedenle önce mutlaka sorgulama yapılmalıdır:

setspn -Q HTTP/erp.sirket.local

Tüm duplicate SPN kontrolleri için:

setspn -X

Microsoft’un setspn aracı, Active Directory servis hesaplarının SPN kayıtlarını okumak, eklemek, silmek ve kontrol etmek için kullanılan standart komut satırı aracıdır.

Exchange ve Outlook Tarafında Kerberos Kontrolü

Problem Outlook tarafında yaşanıyorsa Exchange mimarisi ayrıca incelenmelidir. Özellikle load balancer arkasında çalışan Exchange Client Access servislerinde Kerberos kullanımı için ASA credential ve ilgili HTTP SPN kayıtları doğru yapılandırılmalıdır.

Microsoft, load-balanced Exchange Client Access servislerinde Kerberos kullanılabilmesi için kullanılan FQDN’lere ait HTTP SPN kayıtlarının ASA credential ile ilişkilendirilmesi gerektiğini belirtir. Örnek olarak mail.domain.com ve autodiscover.domain.com gibi isimler için HTTP SPN kayıtları gereklidir.

Exchange tarafında kontrol edilebilecek örnek komutlar:

Get-MapiVirtualDirectory | Select Identity,IISAuthenticationMethods
Get-OwaVirtualDirectory | Select Identity,InternalUrl,ExternalUrl,WindowsAuthentication
Get-EcpVirtualDirectory | Select Identity,InternalUrl,ExternalUrl,WindowsAuthentication
Get-WebServicesVirtualDirectory | Select Identity,InternalUrl,ExternalUrl
Get-ClientAccessService | Select Name,AutoDiscoverServiceInternalUri

MAPI over HTTP için Negotiate desteği kontrol edilmelidir:

Get-MapiVirtualDirectory | Format-List Identity,IISAuthenticationMethods

Gerekli görülürse, ortam tasarımına göre Negotiate authentication method olarak eklenebilir. Ancak Exchange tarafında yapılacak bu değişiklikler mutlaka mevcut mimari, load balancer, certificate, namespace ve ASA credential yapısı değerlendirilerek uygulanmalıdır.

Sorun Giderme İçin Faydalı Kontrol Komutları

İstemci üzerinde Kerberos ticket durumunu görmek için:

klist

Ticket cache temizlemek için:

klist purge

Belirli bir HTTP servisi için Kerberos ticket alınabiliyor mu kontrol etmek için:

klist get HTTP/erp.sirket.local

Domain Controller erişimini kontrol etmek için:

nltest /dsgetdc:sirket.local

GPO’nun istemciye uygulanıp uygulanmadığını görmek için:

gpresult /h C:\Temp\gpo-report.html

Edge policy kontrolü için:

edge://policy

SPN kontrolü için:

setspn -Q HTTP/erp.sirket.local
setspn -Q HTTP/mail.sirket.local
setspn -Q HTTP/autodiscover.sirket.local
setspn -X

Uygulama Öncesi Dikkat Edilmesi Gerekenler

Bu tarz kimlik doğrulama problemleri production ortamlarında doğrudan geniş kapsamlı değişikliklerle çözülmemelidir. Öncelikle küçük bir test OU oluşturulmalı ve yalnızca birkaç test istemcisine GPO uygulanmalıdır.

Önerilen uygulama sırası şu şekildedir:

Önce problemli URL ve servisler netleştirilmelidir.

Ardından ilgili servislerin hangi hesap altında çalıştığı belirlenmelidir.

SPN kayıtları kontrol edilmeli, eksik veya duplicate kayıtlar düzeltilmelidir.

Edge tarafında AuthServerAllowlist ve gerekirse AuthSchemes policy’leri test OU üzerinde denenmelidir.

LMCompatibilityLevel değişikliği eski uygulama bağımlılıkları kontrol edilerek uygulanmalıdır.

Outlook problemi varsa Exchange namespace, virtual directory, authentication method ve ASA credential yapısı ayrıca analiz edilmelidir.

Örnek Toplu İstemci Workaround Scripti

Aşağıdaki örnek script, istemci tarafında NTLMv2 seviyesini ayarlar ve Microsoft Edge için belirlenen kurumsal adresleri Integrated Authentication listesine ekler.

# Yönetici olarak çalıştırılmalıdır.

Write-Host "NTLMv2 ve Microsoft Edge Integrated Authentication ayarları uygulanıyor..." -ForegroundColor Cyan

# 1. LMCompatibilityLevel değerini NTLMv2 güvenli seviyeye çek
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LMCompatibilityLevel /t REG_DWORD /d 5 /f

# 2. Microsoft Edge policy registry path
$EdgePolicyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"

if (-not (Test-Path $EdgePolicyPath)) {
    New-Item -Path $EdgePolicyPath -Force | Out-Null
}

# 3. Edge authentication schemes
New-ItemProperty -Path $EdgePolicyPath `
    -Name "AuthSchemes" `
    -Value "ntlm,negotiate" `
    -PropertyType String `
    -Force | Out-Null

# 4. Kurumsal URL allowlist
New-ItemProperty -Path $EdgePolicyPath `
    -Name "AuthServerAllowlist" `
    -Value "*.sirket.local,intranet.sirket.local,erp.sirket.local,mail.sirket.local,autodiscover.sirket.local" `
    -PropertyType String `
    -Force | Out-Null

Write-Host "Ayarlar uygulandı. GPO/policy kontrolü için edge://policy adresini kontrol edebilirsiniz." -ForegroundColor Green
Write-Host "Bazı ayarların aktif olması için istemcinin yeniden başlatılması önerilir." -ForegroundColor Yellow

Bu scriptte yer alan domain ve sunucu adları örnek olarak verilmiştir. Kendi ortamınıza göre mutlaka değiştirilmelidir.

Outlook veya Microsoft Edge üzerinde sürekli parola sorulması her zaman kullanıcı hesabı veya parola problemi anlamına gelmez. Kurumsal Active Directory ortamlarında bu sorun çoğu zaman NTLM, NTLMv2, Negotiate ve Kerberos arasındaki geçişlerin doğru yapılandırılmamasından kaynaklanır.

İstemci tarafında LMCompatibilityLevel, Edge AuthSchemes ve AuthServerAllowlist ayarları kısa vadede operasyonel kesintiyi azaltabilir. Ancak kalıcı ve sağlıklı çözüm, sunucu tarafında Kerberos mimarisinin doğru kurulması, SPN kayıtlarının eksiksiz tanımlanması ve Exchange/IIS/load balancer mimarisinin buna uygun yapılandırılmasıdır.

Bu nedenle en doğru yaklaşım, istemci tarafında kontrollü workaround uygularken eş zamanlı olarak sunucu tarafında Kerberos/SPN analizinin yapılmasıdır. Böylece hem kullanıcıların parola döngüsü problemi giderilir hem de ortam daha güvenli ve sürdürülebilir bir kimlik doğrulama mimarisine taşınmış olur.