TR / EN

Web Konsolunda Açılan Windows Oturumu RDP ile Neden Açılmaz?

Aynı kullanıcı adı ve parola bir ekranda çalışıp diğerinde reddedildiğinde insan doğal olarak parolanın doğru olduğunu düşünür. Bu çıkarım kısmen doğrudur fakat yeterli değildir. Sanallaştırma platformunun web konsolu fiziksel klavye ve ekranın uzaktan karşılığı gibi davranırken RDP, ağ üzerinden gelen ayrı bir protokol, oturum türü, kimlik sağlayıcı ve kullanıcı hakkı zincirinden geçer. Başarı ölçtüğümüz yollar aynı değildir.

Çok lokasyonlu bir kurumda 20 Temmuz 2026 tarihinde yaşanan olayda Windows sunucu konsoldan yönetilebiliyor, doğrudan RDP denemesi ise daha oturum açılmadan kesiliyordu. Rastgele politika gevşetmek yerine bağlantıyı ağ erişimi, RDP dinleyicisi, NLA ön kimlik doğrulaması, hesap çözümleme ve oturum açma hakkı katmanlarına böldük. Bu ayrım, hem kök nedeni bulmayı hem de güvenlik seviyesini düşürmeden müdahale etmeyi sağladı.

Sorunun ortaya çıkışı

Bakım ekibi web tabanlı hipervizör konsolundan sunucuya yerel bir hesapla girebiliyordu. Aynı görünen bilgiler RDP istemcisinde kullanıldığında genel bir kimlik doğrulama hatası alınıyordu. Sunucu yeniden başlatılmış, RDP daha önce kullanılmış ve ağ adresi değişmemişti. İş kritik olduğu için hızlı erişim gerekiyordu; ancak NLA kapatmak veya herkesi yönetici yapmak kabul edilebilir bir kısayol değildi.

Önce RDP istemcisinin gerçekten doğru sunucuya ulaştığını doğruladık. İsim çözümleme yerine onaylı yönetim kaydı, sertifika bilgisi ve hedef sistem kimliği karşılaştırıldı. TCP bağlantısının kurulabilmesi yalnızca dinleyiciye ulaşmayı kanıtladı; kimliğin kabul edildiğini göstermedi. Konsol açık olduğu için sunucu içinden servis, politika ve olay günlüklerini güvenli biçimde inceleme avantajımız vardı.

İlk belirtiler ve yanlış varsayımlar

“Parola konsolda çalışıyor, RDP de kabul etmeli” varsayımı hesap adının nasıl çözümlendiğini atlıyordu. Kısa kullanıcı adı istemci tarafında kayıtlı etki alanı, hedef bilgisayar veya Microsoft hesabı bağlamında yorumlanabilir. Yerel hesap için HEDEFkullanici biçimi ile domain hesabı için DOMAINkullanici aynı kimliği göstermez. Görünen profil klasörü de hesabın kesin oturum açma adı değildir.

İkinci yanlış yaklaşım güvenlik duvarını tamamen kapatıp denemekti. Bağlantı NLA aşamasına geliyorsa port yolu büyük ölçüde çalışıyordur; hata kaydı daha değerli kanıt sunar. Benzer şekilde NLA’yı devre dışı bırakmak eski istemci uyumsuzluğunu ayırabilir ama kalıcı çözüm değildir. Önce istemci saati, kayıtlı kimlik bilgisi ve kullanıcı adı bağlamı gibi düşük riskli olasılıkları eledik.

Teknik analiz

Sunucuda Remote Desktop Services durumu, RDP-Tcp dinleyicisi ve ilgili Windows Firewall profil kuralları kontrol edildi. Ardından Security ve TerminalServices günlüklarında deneme anına karşılık gelen kayıtlar incelendi. Başarısız oturum türü, hesap adı, durum ve alt durum kodları; yanlış parola, bilinmeyen kullanıcı, izin verilmeyen oturum veya NLA uyuşmazlığını birbirinden ayırdı. Günlük verisi dışarı paylaşılmadan olay kaydında maskelendi.

Yerel Güvenlik İlkesi veya uygulanan GPO içinde “Allow log on through Remote Desktop Services” ve “Deny log on through Remote Desktop Services” haklarını birlikte değerlendirdik. Remote Desktop Users grubu üyeliği tek başına yeterli olmayabilir; deny hakkı önceliklidir. Domain güveni, saat farkı ve kullanıcı kilitlenmesi de kontrol edildi. Ağ tarafında yalnızca izinli yönetim segmentinden hedef porta erişim ölçüldü.

# Yerel konsolda, salt okunur PowerShell kontrolleri
Get-Service -Name TermService
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 3389
Get-LocalGroupMember -Group 'Remote Desktop Users'

Uygulanan çözüm veya önerilen mimari

Vakadaki hesap yereldi ancak istemci eski domain bağlamını kullanıyordu. Kimlik bilgisi kasasındaki hedefe bağlı eski kayıt kaldırıldı ve kullanıcı adı açıkça hedef bilgisayar bağlamıyla girildi. Hesap, ayrıcalıklı yönetici grubuna eklenmeden Remote Desktop Users grubuna dahil edildi; GPO ile gelen deny hakkı olmadığı doğrulandı. Başarılı oturumdan sonra başarısız denemelerin kilitlenme sayacı ve olay kaydı gözden geçirildi.

Kalıcı mimaride RDP yalnızca yönetim ağı veya kimlik tabanlı özel ağ üzerinden erişilebilir tutuldu. Yönetici ve standart uzaktan erişim rolleri ayrıldı, NLA açık bırakıldı ve MFA sağlayan yönetim geçidi değerlendirildi. Hesap açma süreci grup tabanlı hale getirildi; kişiye özel firewall istisnası veya yerel yönetici üyeliği yerine merkezi, süreli ve denetlenebilir yetkilendirme kullanıldı.

Alternatifler ve karar gerekçesi

NLA’yı kapatmak bağlantıyı geçici olarak mümkün kılabilirdi, fakat kimlik doğrulama öncesi daha fazla oturum kaynağı tüketir ve saldırı yüzeyini büyütürdü. Sorun eski istemciden kaynaklanmıyorsa hiçbir kök nedeni de çözmezdi. Hesabı Administrators grubuna almak yetki sorununu maskeleyebilirdi; görev için gereksiz ayrıcalık oluşturacağı için bu seçenek reddedildi.

Web konsolunu sürekli yönetim kanalı olarak kullanmak ağdaki RDP sorununu atlatır, ancak konsol platformundaki güçlü ayrıcalıkları günlük operasyona taşır. RD Gateway, VPN veya overlay ağ seçenekleri kurum ölçeğine göre değerlendirildi. Mevcut kontrollü yönetim ağı ve az sayıdaki yetkili kullanıcı için grup tabanlı RDP yeterliydi; internetten doğrudan yayın ise hiçbir senaryoda seçilmedi.

Güvenlik ve operasyonel riskler

Tekrarlanan denemeler hesabı kilitleyebilir ve hizmet hesabıyla ortak kimlik kullanılıyorsa uygulamayı da etkileyebilir. Bu yüzden deneme sayısı sınırlandı, her değişiklikten sonra tek kontrollü giriş yapıldı. Güvenlik günlükları kullanıcı adı, kaynak adresi ve domain bilgisi içerebildiği için destek kaydına ham halde konmadı. Konsol erişimi de acil durum yetkisi olarak denetlendi.

RDP’nin tüm ağ profillerinde açılması veya geniş kaynak aralığına izin verilmesi operasyonu kolaylaştırırken kalıcı risk üretir. Erişim kaynağı sınırlandırılmalı, hesap yaşam döngüsü izlenmeli, güçlü parola ve MFA politikaları uygulanmalıdır. Sertifika uyarısını görmezden gelmek yanlış hedefe kimlik bilgisi gönderme riski taşır. İzleme, başarısız giriş artışı ile beklenmeyen grup üyeliği değişikliklerini birlikte takip etmelidir.

Çıkarılan Dersler

Kontrol Listesi

Windows masaüstünde görülen ad, profil klasörü ve whoami çıktısı aynı kullanıcıyı anlatıyor gibi görünse de farklı ad alanlarından gelir. Özellikle yerel hesap sonradan Microsoft hesabına bağlandığında bu fark RDP istemcisinde belirginleşir. Kullanıcı cihazın başında PIN ile rahatça oturum açarken uzaktan bağlantıda aynı PIN reddedilir; kısa profil adıyla yapılan deneme de başka bir yerel hesaba yönlenebilir.

21 Temmuz 2026 tarihli bir destek çalışmasında çözüm, parolayı tekrar tekrar sıfırlamak değil kimliğin hangi sağlayıcı tarafından doğrulandığını belirlemekti. RDP için kullanıcı adını `MicrosoftAccounthesap` bağlamında vermek, çevrim içi hesabın gerçek parolasını kullanmak ve istemcideki eski kayıtları temizlemek gerekiyordu. Bu basit görünen ayrıntının arkasında Windows Hello, yerel kimlik bilgisi ve ağ kimlik doğrulamasının farklı güven sınırları bulunuyor.

Sorunun ortaya çıkışı

Uzak çalışan bir kullanıcı Windows 11 bilgisayarına kimlik tabanlı özel ağ üzerinden erişebiliyor, RDP oturumu açarken kimlik bilgisi hatası alıyordu. Fiziksel cihazda PIN kabul ediliyor, hesap ayarlarında Microsoft hesabına bağlı bir e-posta görünüyordu. whoami ise kısa ve daha eski bir yerel ad döndürüyordu. Üç farklı gösterim destek ekibinin hangi değeri kullanacağı konusunda belirsizlik yarattı.

Ağ yolu ve RDP servisi sağlıklıydı; hata NLA kimlik doğrulama aşamasındaydı. Kullanıcı gizli bilgisini destek görevlisine iletmeden, ekranda gördüğü hesap türünü tarif etti. Amaç yeni bir yönetici hesabı açmak veya mevcut hesabı dönüştürmek değildi. Önce var olan kimliğin doğru sözdizimi ve geçerli parola türüyle kullanılabilir olup olmadığını kontrollü biçimde sınadık.

İlk belirtiler ve yanlış varsayımlar

En belirgin yanlış varsayım PIN’in parola olduğuydu. Windows Hello PIN’i cihazdaki güvenli donanım ve kullanıcı profiliyle ilişkilidir; uzaktaki RDP kimlik doğrulamasında hesaba ait ağ parolası yerine geçmez. PIN’in kısa olması zayıf bir ağ parolası olduğu anlamına da gelmez, çünkü cihaz dışına taşınan ortak bir sır değildir. RDP istemcisinin beklediği bilgi farklıdır.

Profil klasörü adını kullanıcı adı kabul etmek de yanıltıcıydı. Windows ilk kurulum sırasında klasörü kısaltabilir ve hesap sonradan değişse bile klasör adı aynı kalabilir. whoami çıktısı güvenlik sorumlusunun yerel temsilini gösterir; Microsoft hesabına giriş biçimini tek başına açıklamaz. Ayrıca istemci, daha önce kaydettiği `PCADIkullanici` bilgisini yeni girişin üzerine sessizce uygulayabilir.

Teknik analiz

Hesaplar bölümünde oturumun yerel mi, Microsoft hesabı mı olduğu doğrulandı. `whoami /user` ile SID kaydedildi; yalnızca görünen ad değişikliklerinin ayrı hesap oluşturup oluşturmadığı bu sabit kimlik üzerinden değerlendirildi. Yerel Users ve Remote Desktop Users üyelikleri kontrol edildi. Olay günlüğünde gelen hesap adının hangi paket tarafından nasıl çözümlendiği, gerçek adres veya kişisel hesap bilgisi dışarı aktarılmadan incelendi.

RDP istemcisinde üç bağlamın karıştırılmaması gerekir: yerel hesap için `BILGISAYARkullanici` veya `.kullanici`, domain için `DOMAINkullanici`, Microsoft hesabı için `MicrosoftAccounthesap_adresi`. Buradaki hesap adresi gerçek yayında gösterilmemeli ve ekran görüntüsünde maskelenmelidir. Entra katılımlı kurumsal cihazların sözdizimi ve politikası farklı olabileceğinden Microsoft kişisel hesabı ile aynı vaka sayılmamalıdır.

:: Kimlik türünü anlamaya yardımcı, değişiklik yapmayan komutlar
whoami
whoami /user
whoami /groups
net localgroup "Remote Desktop Users"

Uygulanan çözüm veya önerilen mimari

İstemcide hedef bilgisayara bağlı eski kimlik kaydı Windows Credential Manager üzerinden kaldırıldı. Kullanıcı adı alanına açıkça `[email protected]` biçiminde dokümantasyon hesabı model alınarak gerçek hesap kullanıcı tarafından girildi; PIN yerine Microsoft hesabı parolası kullanıldı. Kullanıcı parolayı destek ekibiyle paylaşmadı. Bağlantı başarılı olduktan sonra sunucudaki SID ile açılan oturumun beklenen profile ait olduğu doğrulandı.

Kurumsal kullanım için kişisel Microsoft hesaplarıyla sürekli yönetim erişimi önermiyoruz. Yönetilen cihazlarda merkezi kimlik, MFA, koşullu erişim ve hesap yaşam döngüsü sağlayan kurumsal model tercih edilmeli. Ev veya sınırlı senaryoda kişisel hesap kullanılacaksa ayrı bir standart erişim hesabı, kısıtlı RDP grubu ve özel ağ yolu düşünülebilir. Her durumda internetten doğrudan RDP yayını yapılmamalıdır.

Alternatifler ve karar gerekçesi

Yeni yerel hesap açmak sorunu hızlıca aşabilirdi. Ancak fazladan hesabın parolası, üyelikleri ve kapanış süreci yönetilmediğinde uzun vadeli risk doğurur. Mevcut Microsoft hesabının doğru biçimle çalıştığını doğrulamak en küçük değişiklikti. Hesabı yerel hesaba çevirmek de profil ve uygulama davranışını etkileyebileceğinden yalnızca RDP problemi için uygun görülmedi.

Kaydedilmiş kimlik bilgilerini tamamen kapatmak bazı yüksek güvenlikli ortamlarda doğru politika olabilir; bu vakada yalnızca hatalı hedef kaydı temizlendi. Remote Desktop yerine uzaktan yardım aracı kullanmak kullanıcı destek senaryosunda avantaj sağlayabilir, ancak sürekli yönetim oturumunun yerini her zaman tutmaz. Karar, erişim amacı, denetlenebilirlik ve kurumun kimlik standardına göre verilmelidir.

Güvenlik ve operasyonel riskler

Kişisel e-posta adresi bir kimlik verisidir; destek kaydı, ekran görüntüsü ve komut çıktısında açık bırakılmamalıdır. Parola hiçbir zaman sohbet veya uzak destek notuna yazılmamalı, kullanıcı tarafından güvenilir istemciye girilmelidir. Tekrarlı yanlış denemeler hesap kilidi ve şüpheli giriş uyarıları üretebilir. Hedef sertifikası doğrulanmadan kimlik bilgisi gönderilmemelidir.

Microsoft hesabı parolasının yakın zamanda değişmesi, cihazın çevrim dışı önbelleği ile ağ doğrulaması arasında geçici fark yaratabilir. Kurtarma yöntemleri güncel tutulmalı, yerel acil durum hesabı varsa kasada ve denetimli olmalıdır. RDP erişimi yalnızca izinli cihaz ve ağlarla sınırlandırılmalı; kullanıcı Remote Desktop Users grubundan ayrıldığında erişimin gerçekten kalktığı periyodik olarak test edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir bilgisayara uzaktan erişme ihtiyacı çoğu zaman “modemde port açalım” önerisiyle başlar. Sabit genel IP yoksa dinamik DNS eklenir, ardından RDP servisi doğrudan internetin taramasına ve parola denemelerine maruz kalır. Çalışan bir bağlantı elde edilir ama kimlerin, hangi cihazdan ve hangi koşulla bağlanabileceği yeterince yönetilmez. Erişim kolaylığı güvenlik borcuna dönüşür.

21 Temmuz 2026 tarihinde değerlendirdiğimiz vakada hedef, uzaktaki Windows iş istasyonuna iki yetkili cihazdan erişmekti. Tailscale ile cihazları kimlik tabanlı şifreli bir overlay ağa aldık; yönlendiricide inbound port açmadık. Yine de ürünü kurup “güvenli” etiketi vermekle yetinmedik. Tailnet üyeliği, ACL, Windows Firewall, RDP kullanıcı hakkı, MFA ve cihaz kaybı süreçlerini tek mimarinin parçaları olarak ele aldık.

Sorunun ortaya çıkışı

Uzak lokasyondaki iş istasyonu taşıyıcı NAT arkasındaydı ve sabit genel IP hizmeti yoktu. Kullanıcının seyahat sırasında kurumsal dizüstünden masaüstüne bağlanması gerekiyordu. Geleneksel port yönlendirme teknik olarak her bağlantıda mümkün değildi; mümkün olsa bile RDP’yi doğrudan yayınlamak kurumun güvenlik standardına aykırıydı. Tam ağ VPN’i ise tek cihazlık ihtiyaç için gereğinden geniş erişim sağlıyordu.

Tasarım hedeflerini baştan yazdık: internetten dinleyen RDP olmamalı, yalnızca tanımlı kullanıcı ve cihazlar bağlanabilmeli, erişim geri alınabilmeli, istemci ile hedef arasındaki trafik şifrelenmeli ve olay kaydı tutulmalıydı. Ayrıca merkezi servis kesintisi, cihaz kaybı ve kullanıcının kurumdan ayrılması halinde bağlantının nasıl sonlandırılacağı tanımlanmalıydı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, Tailscale kurulu iki cihazın otomatik olarak yalnızca birbirine güvenli erişeceğiydi. Varsayılan paylaşım davranışı ve ACL modeli incelenmeden tailnet üyeliği geniş bir iç erişim alanı yaratabilir. Şifreli tünel trafiğin gizliliğini sağlar; hedef Windows hesabının gereğinden fazla yetkili olmasını veya RDP servisindeki kötü yapılandırmayı düzeltmez.

İkinci varsayım, Windows Firewall kuralını tamamen açmanın gerekli olduğuydu. Tailscale arayüzü için uygun profil ve kaynak kapsamı tanımlanabilir; tüm fiziksel ağlardan RDP kabul etmek gerekmez. Tailscale IP’sini internete yönlendirilebilir genel adres sanmak da hatalıdır. Bu adres overlay içinde anlamlıdır ve istemcinin tailnet kimliği olmadan doğrudan erişilemez.

Teknik analiz

Önce her iki cihazın yönetim panelinde beklenen kullanıcıya, işletim sistemine ve cihaz kimliğine bağlı olduğunu doğruladık. Tailscale durumunda doğrudan eş bağlantı mı yoksa relay mi kullanıldığı gözlendi; relay performans farkı yaratabilir ancak uçtan uca şifrelemeyi kaldırmaz. Hedefin Tailscale adı ve overlay adresiyle erişimi, normal LAN adresinden ayrı test edildi.

Windows tarafında RDP servisinin etkinliği, NLA, izinli kullanıcı grubu ve firewall kural kapsamı incelendi. ACL değerlendirmesi kaynak kullanıcı/cihaz etiketi, hedef cihaz etiketi ve yalnızca gerekli RDP servisi üzerinden yapıldı. DNS adı kullanılıyorsa MagicDNS kolaylık sağladı, fakat isim çözümleme başarısı erişim yetkisiyle karıştırılmadı. Kayıtlarda gerçek cihaz adları yayın içeriğine alınmadı.

# Durum ve bağlantı tanısı; örnek adres dokümantasyon içindir
tailscale status
tailscale ping hedef-cihaz
Test-NetConnection -ComputerName 192.0.2.25 -Port 3389

Uygulanan çözüm veya önerilen mimari

Kimlik sağlayıcıda MFA zorunlu tutuldu ve iki cihaz onaylı tailnet’e kaydedildi. Hedef iş istasyonu ile yönetim dizüstüne rol etiketleri verildi; ACL yalnızca yönetim rolünden hedef RDP servisine erişime izin verdi. Windows Firewall kuralı Tailscale arayüzü ve gerekli kaynak kapsamıyla sınırlandı. RDP kullanıcısı yerel yönetici yapılmadan ilgili gruba eklendi ve NLA açık bırakıldı.

Yönlendiricide port yönlendirme bulunmadığı dışarıdan doğrulandı. Cihaz onay süresi, anahtar yenileme politikası ve kullanılmayan cihazların otomatik kaldırılması işletim prosedürüne eklendi. Kullanıcı ayrılışı halinde kimlik sağlayıcı oturumu, tailnet üyeliği ve Windows hesabı aynı kapanış kaydında ele alındı. Böylece erişim yalnızca teknik tünel değil, yönetilen bir yaşam döngüsü haline geldi.

Alternatifler ve karar gerekçesi

Kurumsal VPN, çok sayıda servis ve kullanıcı için merkezi politika avantajı sağlayabilirdi; tek hedefli bu vakada daha geniş ağ erişimi ve ek altyapı gerektiriyordu. RD Gateway, RDP’ye özel güçlü bir aracı katmandır ve büyük Windows ortamlarında iyi seçenektir. Mevcut ölçekte kimlik tabanlı overlay, daha küçük değişiklikle gereksinimi karşıladı.

Port yönlendirme ve IP allowlist seçeneği sabit kaynak adresi olmayan kullanıcıda sürdürülebilir değildi; ayrıca internet üzerinde servis bırakıyordu. Uzaktan destek ürünleri kullanıcı onaylı kısa oturumlar için değerlidir, fakat sürekli çalışma ortamına erişim ihtiyacı farklıydı. Tailscale seçimi koşulsuz ürün tercihi değil; kapsam, yönetim kapasitesi ve mevcut kimlik sağlayıcıyla uyum sonucuydu.

Güvenlik ve operasyonel riskler

Kimlik sağlayıcı hesabı ele geçirilirse tailnet erişimi de risk altına girer; MFA ve cihaz onayı bu nedenle zorunludur. ACL’de geniş yıldız kuralları şifreli ama aşırı yetkili bir ağ oluşturabilir. Kişisel cihazların kaydı, disk şifreleme ve ekran kilidi standardı yoksa veri sızıntısı doğurur. Cihaz etiketlerini kimin değiştirebildiği ayrı yönetici rolüyle sınırlandırılmalıdır.

Hedef cihaz uykuya geçerse veya Tailscale servisi başlamazsa erişim kesilebilir; bu durum güvenlik ihlaliyle karıştırılmamalıdır. Relay kullanımı gecikmeyi artırabilir. Acil durumda erişim için onaylı alternatif kanal ve yerel destek süreci belgelenmelidir. Tailscale güncellemeleri, Windows yamaları, RDP günlükları ve yönetim panelindeki cihaz envanteri periyodik olarak gözden geçirilmelidir.

Çıkarılan Dersler

Kontrol Listesi