RDP'deki NLA Hataları: Nedenler, Çözümler ve En İyi Uygulamalar

Giriş

Ağ Düzeyi Kimlik Doğrulaması (NLA), Tam oturum oluşturulmadan önce kimlik doğrulaması yapılmamış kullanıcıları durdurarak Uzak Masaüstü Protokolü için temel bir güvenlik kontrolüdür. Ancak NLA başarısız olduğunda, BT ekipleri engellenen oturum açma işlemleri, belirsiz hata mesajları ve kritik sunuculara ulaşamayan hayal kırıklığına uğramış son kullanıcılarla karşılaşır. Bu kılavuz, NLA'nın ne olduğunu, bu hataların neden meydana geldiğini ve RDP güvenlik duruşunuzu zayıflatmadan NLA sorunlarını sistematik olarak nasıl gidereceğinizi ve çözeceğinizi açıklar.

RDP'de NLA Nedir?

Ağ Düzeyi Kimlik Doğrulama, Windows Vista ve Windows Server 2008 ile tanıtılan bir RDP güvenlik geliştirmesidir. Tam uzak masaüstü oturumu oluşturmak ve ardından kimlik bilgilerini istemek yerine, NLA kullanıcıların önce kimlik doğrulaması yapmasını gerektirir. Sadece başarılı bir kimlik doğrulamasından sonra RDP yığını grafiksel oturumu oluşturur.

NLA, kullanıcı kimlik bilgilerini hedef sisteme güvenli bir şekilde iletmek için CredSSP'ye (Kimlik Bilgisi Güvenlik Destek Sağlayıcısı) dayanır. Alan katılımlı ortamlarda, CredSSP, oturum açılmadan önce hesabı doğrulamak için Active Directory ile iletişim kurar. Bağımsız veya iş grubu ana bilgisayarlarında, CredSSP, uzaktan oturum açma için yapılandırılmış yerel hesapları doğrular.

NLA'nın ana faydaları şunlardır:

• Açık RDP uç noktalarındaki kaba kuvvet ve hizmet reddi saldırıları için pencereyi azaltma
• Etkinleştirme tek oturum açma alan kullanıcıları için (SSO), kullanıcı deneyimini iyileştirme
• Oturum oluşturulmadan önce kimlik doğrulama yaparak performansı artırma

Ancak, NLA işletim sistemi sürümlerine, yamanlara duyarlıdır, TLS konfigürasyon ve alan sağlığı. Bu ön koşullardan herhangi biri başarısız olduğunda, NLA geçerli bağlantıları tamamen engelleyebilir.

RDP'deki NLA Hatalarının Yaygın Belirtileri Nelerdir?

NLA ile ilgili sorunlar genellikle altta yatan nedenden bağımsız olarak benzer mesajlarla ortaya çıkar. Aşağıdaki durumlarla karşılaşıyorsanız muhtemelen bir NLA sorunu yaşıyorsunuz:

• Uzak bilgisayar Ağ Düzeyi Kimlik Doğrulaması (NLA) gerektiriyor, ancak bilgisayarınız bunu desteklemiyor.
• “Bir kimlik doğrulama hatası oluştu. İstenen işlev desteklenmiyor.”
• “CredSSP şifreleme oracle düzeltme hatası.”
• Kimlik bilgileriniz çalışmadı.
• Başlangıç RDP el sıkışması sırasında veya kimlik bilgileri girildikten hemen sonra zaman aşımı veya ani bağlantı kesilmeleri

Bu belirtiler hem alan katılımlı hem de bağımsız ana bilgisayarları etkileyebilir. Pratikte, genellikle uyumsuz güvenlik politikaları, engellenmiş alan denetleyici erişimi veya her iki tarafta da eski RDP bileşenleri ile ilişkilidir.

RDP'deki NLA Hatalarının Nedenleri Nelerdir?

Ortak kök nedenleri anlamak, sorunları hızlı bir şekilde çözmenize ve NLA'yı kalıcı olarak devre dışı bırakmak gibi riskli geçici çözümlerden kaçınmanıza yardımcı olur.

• İstemci veya Sunucu OS Uyumsuzluğu
• Alan Denetleyici Ulaşılamıyor
• CredSSP Yamanı Uyuşmazlığı
• TLS veya RDP Şifreleme Yanlış Yapılandırması
• Grup İlkesi veya Kayıt Çatışmaları
• Bozulmuş Kullanıcı Profilleri veya Kimlik Bilgileri
• Çalışma Grubu ve Alan Dışı Senaryolar

İstemci veya Sunucu OS Uyumsuzluğu

Eski Windows sürümleri veya üçüncü taraf RDP istemcileri NLA veya modern CredSSP davranışını tam olarak desteklemeyebilir. Örneğin, eski Windows XP veya erken Vista sürümleri belirli güncellemeler olmadan NLA zorunlu sunuculara bağlanamaz. Desteklenen sistemlerde bile, eski RDP istemci ikili dosyaları, işletim sisteminin nominal olarak desteklemesine rağmen "bilgisayarınız NLA'yı desteklemiyor" hatalarına neden olabilir.

Alan Denetleyici Ulaşılamıyor

Bir alan katılımlı ortamda, NLA, kimlik bilgilerini doğrulamak ve makinenin güvenli kanalını sürdürmek için bir alan denetleyicisine ulaşmaya bağlıdır. Eğer alan denetleyicisi çevrimdışıysa, bir [ tarafından engellenmişse] güvenlik duvarı veya bir güven sorunuyla karşılaşıldığında, NLA kimlik doğrulaması, sunucu kendisi çalışıyor olsa bile başarısız olabilir. Genellikle alan denetleyici bağlantısı veya genel "kimlik doğrulama hatası oluştu" mesajlarını belirten hatalar göreceksiniz.

CredSSP Yamanı Uyuşmazlığı

2018 "Şifreleme Oracle Düzeltmeleri" güncellemeleri ile birlikte, CredSSP kimlik bilgilerini koruma konusunda daha katı hale geldi. Eğer bir istemci güncellemeye sahipse ancak sunucu sahip değilse (veya tam tersi), iki uç nokta güvenli bir yapılandırma üzerinde anlaşamayabilir. Bu uyumsuzluk "CredSSP şifreleme oracle düzeltmesi" hataları üretebilir ve her iki taraf yamanana kadar NLA oturum açmalarını engelleyebilir.

TLS veya RDP Şifreleme Yanlış Yapılandırması

NLA, kimlik bilgisi değişimini korumak için Taşıma Katmanı Güvenliği (TLS) kullanır. TLS 1.0/1.1 devre dışı bırakılırsa ve TLS 1.2 doğru bir şekilde etkinleştirilmezse veya zayıf şifreleme setleri zorunlu kılınırsa, istemci ve sunucu arasındaki el sıkışma, NLA tamamlanmadan önce başarısız olabilir. Özel güvenlik güçlendirmesi, FIPS modu veya yanlış yapılandırılmış sertifikalar, standart NLA olmadan RDP'nin bazı koşullar altında çalışmaya devam etmesine rağmen NLA'yı bozabilir.

Grup İlkesi veya Kayıt Çatışmaları

Grup Politika Nesneleri (GPO'lar) ve yerel güvenlik politikaları, RDP, CredSSP ve şifrelemenin nasıl davrandığını kontrol eder. Çelişkili veya aşırı katı politikalar, istemcilerin desteklemediği veya istemcilerinizin kullanamayacağı FIPS uyumlu algoritmalar gerektiren senaryolarda NLA'yı zorlayabilir. SCHANNEL veya CredSSP için kayıt defteri geçersiz kılmaları benzer tutarsızlıklar yaratabilir ve "istenen işlev desteklenmiyor" ve diğer genel hatalara yol açabilir.

Bozulmuş Kullanıcı Profilleri veya Kimlik Bilgileri

Bazen, sorun tek bir kullanıcıya veya makineye özgü olabilir. Bozulmuş önbellekli kimlik bilgileri, yanlış hizalanmış Güvenlik Tanımlayıcısı (SID) veya bozulmuş bir Default.rdp dosyası NLA kimlik doğrulaması ile etkileşime girebilir. Bu durumlarda, başka bir kullanıcının aynı cihazdan giriş yapabildiğini veya aynı kullanıcının farklı bir istemciden giriş yapabildiğini, ancak her ikisinin birden giriş yapamadığını görebilirsiniz.

Çalışma Grubu ve Alan Dışı Senaryolar

NLA, kullanıcı kimliklerinin genellikle Active Directory aracılığıyla güçlü bir şekilde doğrulanabileceği bir ortamı varsayar. Çalışma grubu sistemlerinde, yerel hesapların dikkatlice yapılandırılması ve Remote Desktop üzerinden oturum açma iznine sahip olması gerekir. NLA zorunlu kılındığında ancak bir etki alanı denetleyicisi mevcut değilse veya yerel hesap ayarları yanlışsa, sunucu erişilebilir görünse bile NLA ile ilgili hatalar görme olasılığınız yüksektir.

RDP'deki NLA Hataları Nasıl Düzeltilir?

Aşağıdaki adımları, en az müdahaleden en fazla müdahaleye doğru sırasıyla kullanın. Bu yaklaşım, mümkün olduğunca güvenliği korurken erişimi geri kazanmaya yardımcı olur.

• Müşteri ve Sunucuda NLA Desteğini Onaylayın
• Etki Alanı Denetleyicisine Bağlantıyı Doğrulayın (Varsa)
• CredSSP Yaman Düzeylerini ve Politikalarını Hizala
• Gerekli TLS Protokollerini Etkinleştir ve Doğrula
• Grup Politikasını Gözden Geçirin ve Ayarlayın
• NLA'yı Geçici Olarak Devre Dışı Bırakın ve Erişimi Geri Kazanın
• RDP İstemcisini ve Ağ Yapılandırmasını Sıfırla

Müşteri ve Sunucuda NLA Desteğini Onaylayın

Öncelikle, her iki uç noktanın da NLA'yı desteklediğinden emin olun.

• Çalıştır winver hem istemci hem de sunucuda Windows Vista / Windows Server 2008 veya daha yenisi olduklarını doğrulamak için.
• En son Uzak Masaüstü istemci güncellemelerinin yüklü olduğundan emin olun (Windows Update veya Windows dışı platformlardaki Microsoft Uzak Masaüstü uygulaması aracılığıyla).
• Eğer üçüncü taraf RDP istemcileri kullanıyorsanız, NLA desteğinin açıkça belgelenmiş ve istemcinin ayarlarında etkinleştirildiğinden emin olun.

Eğer her iki taraf da NLA'yı desteklemiyorsa, o bileşeni yükseltmeyi veya değiştirmeyi planlayın, böylece güvenliği küresel olarak zayıflatmamış olursunuz.

Etki Alanı Denetleyicisine Bağlantıyı Doğrulayın (Varsa)

Alan katılımlı makinelerde, RDP ayarlarını değiştirmeden önce alan bağlantısını doğrulayın.

• Test temel ağ erişilebilirliğini etki alanı denetleyicilerine (örneğin, ping dc01.yourdomain.com ).
• Kullanım nltest /dsgetdc:yourdomain.com müşterinin bir etki alanı denetleyicisini bulabileceğini onaylamak için.
• PowerShell'de çalıştırın Test-BilgisayarGüvenliBağlantı makinenin alan adına güvenli kanalını kontrol etmek için.

Güvenli kanal bozulursa, bunu şu şekilde onarın:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Onarımdan sonra, istenirse makineyi yeniden başlatın, ardından NLA'yı tekrar test edin. Alan erişimini ara sıra engelleyebilecek DNS yanlış yapılandırmalarını, güvenlik duvarı kurallarını veya VPN sorunlarını giderin.

CredSSP Yaman Düzeylerini ve Politikalarını Hizala

Sonra, hem istemcinin hem de sunucunun mevcut güvenlik güncellemelerine sahip olduğunu, özellikle CredSSP ile ilgili olanlara dikkat edin.

• Her iki uç noktada da tüm önemli ve güvenlik güncellemelerini yükleyin.
• Grup İlkesi'nin "Şifreleme Oracle Düzeltmesi"ni yapılandırmak için kullanılıp kullanılmadığını kontrol edin:
  Bilgisayar Yapılandırması → Yönetim Şablonları → Sistem → Kimlik Bilgisi Delegasyonu .

Geçici bir test ortamında, bir katı ayarın hataya neden olduğunu doğrulamak için politikayı daha izin verici bir değere ayarlayabilirsiniz. Üretimde, uzun vadeli çözüm, politikayı kalıcı olarak gevşetmek yerine tüm sistemleri tutarlı bir yamanma seviyesine getirmek olmalıdır.

Gerekli TLS Protokollerini Etkinleştir ve Doğrula

TLS 1.2'nin desteklendiğinden ve etkinleştirildiğinden emin olun, çünkü birçok ortam artık daha eski TLS sürümlerini devre dışı bırakmaktadır.

Windows Server'da, kayıt defterinde SCHANNEL ayarlarını kontrol edin:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

TLS 1.2 istemci desteği için, şunları onaylayın:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

"Enabled"=dword:00000001

Sunucu tarafında TLS 1.2 anahtarlarını ayarlamanız gerekebilir ve ardından sunucuyu veya en azından Uzak Masaüstü Hizmetlerini yeniden başlatmalısınız. Ayrıca, RDP sertifikasının geçerli, güvenilir olduğunu ve eski imzaları kullanmadığını doğrulayın.

Grup Politikasını Gözden Geçirin ve Ayarlayın

Grup İlkesi genellikle NLA uygulaması ve RDP güvenlik yapılandırmasının tanımlandığı yerdir.

Açık gpedit.msc veya eşdeğer GPMC nesnesine gidin:

Bilgisayar Yapılandırması → Windows Ayarları → Güvenlik Ayarları → Yerel İlkeler → Güvenlik Seçenekleri

Özellikle kontrol edin:

• “Uzaktan bağlantılar için Ağ Düzeyi Kimlik Doğrulaması kullanarak kullanıcı kimlik doğrulaması gerektir.”
• FIPS uyumlu algoritmaları zorunlu kılan veya şifreleme türlerini kısıtlayan herhangi bir politika

NLA uygulamasının müşterilerinizin kaldırabileceği şekilde eşleştiğinden emin olun. Erişimi geri yüklemek için bir politikayı gevşetirseniz, değişikliği belgeleyin ve zayıf ayarları sonsuza dek bırakmak yerine temel müşteri sorunlarını düzeltmek için zaman ayarlayın.

NLA'yı Geçici Olarak Devre Dışı Bırakın ve Erişimi Geri Kazanın

Kritik bir sunucuya tüm uzaktan erişiminizi kaybettiyseniz, NLA'yı geçici olarak kapatmak gerekli bir son çare olabilir.

Yapabilirsiniz:

• Ağ ile Güvenli Mod'a önyükleme yapın ve Uzak Masaüstü ayarlarını ayarlayın, ya da
• Kurtarma medyası kullanarak önyükleme yapın, sistem hivesini yükleyin ve kayıt defterindeki RDP-Tcp anahtarını düzenleyin.

Ayarlar:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

"UserAuthentication"=dword:00000000

Bu, RDP dinleyicisi için NLA'yı devre dışı bırakır. Erişimi yeniden kazandığınızda, kök nedeni (alan bağlantısı, yamalar, TLS veya politikalar) düzeltin, ardından değeri 1 olarak geri yükleyerek NLA'yı yeniden etkinleştirin. NLA'nın uzun vadede devre dışı bırakılması, brute-force ve istismar girişimlerine maruz kalmayı önemli ölçüde artırır.

RDP İstemcisini ve Ağ Yapılandırmasını Sıfırla

Eğer NLA sorunları belirli bir istemci cihazına özgü görünüyorsa, sunucu politikasını değiştirmeden önce yerel bir sıfırlama yapın.

• Silin. Default.rdp dosyada %userprofile%\Belgeler önbellek ayarlarını temizlemek için.
• Windows Credential Manager'daki kaydedilmiş kimlik bilgilerini kaldırın ve yeniden ekleyin.
• TCP 3389'un (veya özel RDP portunuzun) yerel güvenlik duvarları ve ara ağ cihazları üzerinden izin verildiğini onaylayın.
• Aynı ağdaki başka bir istemciden test yaparak sorunun istemciye özgü mü yoksa daha genel mi olduğunu belirleyin.

Bu basit hijyen adımı genellikle bozulmuş önbellekli kimlik bilgileri veya RDP istemcisindeki yanlış uygulanan görüntü ve güvenlik seçenekleri ile ilgili sorunları çözer.

Gelecekte NLA Hatalarını Önlemek İçin En İyi Uygulamalar Nelerdir?

Hızlı bir şekilde çözüm sağlandıktan sonra, NLA'nın hem güvenli hem de güvenilir kalmasını sağlamak için ortamınızı güçlendirin.

• İşletim Sistemlerini ve RDP İstemcilerini Güncel Tutun
• Alan ve Kimlik Sağlığını İzleme
• GPO aracılığıyla RDP ve NLA Politikalarını Standartlaştırın
• Olay Günlüğü ve Güvenlik İzleme'yi Etkinleştir
• RDP'yi Güvenli Giriş Noktalarının Arkasında İzole Edin

İşletim Sistemlerini ve RDP İstemcilerini Güncel Tutun

Sunucular ve uç noktalar için standart bir yamanma döngüsü sürdürün. Desteklenen Windows sürümleri üzerinde uyum sağlayın ve eski, yamanmamış istemcileri üretimde bırakmaktan kaçının. Tutarlı güncelleme temel çizgileri, genellikle NLA'yı bozan CredSSP ve TLS uyumsuzluklarını azaltır.

Alan ve Kimlik Sağlığını İzleme

Alan katılımlı sistemler için, etki alanı denetleyici sağlığını RDP yığınınızın bir parçası olarak değerlendirin. [Kullanım araçları gibi] dcdiag , repadmin ve etki alanı denetleyicisi olay günlükleri, çoğaltma veya DNS sorunlarını erken yakalamak için. Ara sıra meydana gelen etki alanı hataları, kullanıcılar diğer semptomları fark etmeden çok önce RDP ve NLA sorunları olarak ortaya çıkabilir.

GPO aracılığıyla RDP ve NLA Politikalarını Standartlaştırın

Tanımlayın RDP şifreleme, NLA uygulaması ve CredSSP politikalarını merkezi olarak. Bunları, üretim sunucuları ile test laboratuvarları gibi cihaz rolleri temelinde OU veya güvenlik grubuna göre uygulayın. Standartlaştırma, yapılandırma kaymasını azaltır ve sorunlar ortaya çıktığında sorun gidermeyi çok daha hızlı hale getirir.

Olay Günlüğü ve Güvenlik İzleme'yi Etkinleştir

RDP sunucularında Olay Görüntüleyici'yi izleyin, özellikle:

• Windows Günlükleri → Güvenlik
• Windows Günlükleri → Sistem
• Uygulamalar ve Hizmetler Günlükleri → Microsoft → Windows → Terminal Hizmetleri

Tekrar eden başarısız oturum açma girişimlerini, TLS el sıkışma hatalarını veya CredSSP hatalarını mümkünse SIEM'inizle ilişkilendirin. Bu izleme, yapılandırma sorunları ile aktif saldırılar arasında ayrım yapmaya yardımcı olur.

RDP'yi Güvenli Giriş Noktalarının Arkasında İzole Edin

NLA ile bile, RDP'yi doğrudan internete açmak yüksek risk taşır. RDP'yi güvenli bir geçit, VPN veya ZTNA tarzı bir proxy'nin arkasına yerleştirin. Mümkünse MFA ekleyin. TSplus Advanced Security gibi araçlar, kullanıcıların nerede, ne zaman ve nasıl bağlandığını daha da kısıtlayarak, NLA ile ilgili olayların sunucuya ulaşma olasılığını azaltabilir.

TSplus Advanced Security ile RDP Güvenliğini Güçlendirin

NLA, RDP risk denkleminin sadece bir kısmını çözer. TSplus Gelişmiş Güvenlik Windows sunucularınızın ve uzaktan masaüstlerinizin etrafında, tam kapsamlı VDI yığınlarının karmaşıklığı olmadan ek savunma katmanları ekler. Dinamik brute-force koruması, IP ve ülke bazlı kısıtlamalar, çalışma saatleri politikaları ve uygulama düzeyinde erişim kuralları gibi özellikler, meşru kullanıcıların verimli kalırken saldırganların dışarıda kalmasına yardımcı olur.

RDP'ye güvenen ancak daha güçlü, daha basit güvenlik kontrolleri isteyen kuruluşlar için, NLA'yı ile eşleştirmek TSplus Gelişmiş Güvenlik uzaktan erişimi güçlendirmek ve olay yanıtı iş yükünü azaltmak için pratik bir yol sunar.

Sonuç

RDP'deki NLA hataları sinir bozucudur, özellikle de çevrede belirgin değişiklikler olmadan ortaya çıktıklarında. Gerçekte, neredeyse her zaman OS sürümlerinde, alan bağlantısında, CredSSP yamanmasında, TLS yapılandırmasında veya güvenlik politikalarında belirli sorunlara işaret ederler. Yapılandırılmış bir kontrol listesi üzerinden çalışarak, riskli kalıcı çözümlere başvurmadan güvenli erişimi geri kazanabilirsiniz.

NLA'yı isteğe bağlı bir özellik yerine temel bir güvenlik kontrolü olarak değerlendirin. Bunu etkin, doğrulanmış ve genel uzaktan erişim duruşunuzun bir parçası olarak izlenir durumda tutun. Bunu devre dışı bırakmanız gerektiğinde, etki alanını sınırlayın, temel sorunu çözün ve NLA'yı mümkün olan en kısa sürede tekrar etkinleştirin.