WinRM Nedir? WinRM Client&Service Mantığı ve WinRM TrustedHost Kullanımı

Merhaba,

Windows tarafında uzaktan yönetim denince PowerShell Remoting, Enter-PSSession, Invoke-Command, Ansible, SCCM/MECM, çeşitli otomasyon araçları ve daha birçok bileşenin bir noktada WinRM’e dokunduğunu görürüz. WinRM çoğu Windows yöneticisinin hayatında vardır ama yapılandırmasının nasıl çalıştığı konusunda zaman zaman gereğinden fazla sihirli bir kutu muamelesi görür.

Bir makinede:

Enter-PSSession -ComputerName SERVER01

çalışır ve “tamam, WinRM çalışıyor” deriz. Bir süre sonra başka bir ortamda aynı komut çalışmaz. Firewall’a bakılır, DNS’e bakılır, Kerberos’a bakılır, TrustedHosts ‘a bakılır, 5985 açık mı diye bakılır. Sonra konu ister istemez “WinRM neden böyle davranıyor?” noktasına gelir.

Bu yazıda WinRM’i biraz daha temelden ele alacağım ve benim gözümden sahada en çok karıştırıldığını gördüğüm konulara odaklanmaya çalıaşacağız.

Konu başlıkları :

• WinRM tam olarak nedir?
• Client ve Service ne demektir?
• Listener nedir?
• HTTP 5985 ve HTTPS 5986 arasındaki fark nedir?
• AllowUnencrypted neyi ifade eder?
• TrustedHosts gerçekten ne işe yarar?
• IPv4Filter, IPv6Filter ve Listener Address arasındaki fark nedir?
• WinRM nasıl yapılandırılır?
• HTTP ne zaman yeterlidir, HTTPS ne zaman tercih edilmelidir?
• Authentication ile encryption arasındaki fark nedir?
• WinRM’in limitleri ve üretim ortamında dikkat edilmesi gereken noktalar nelerdir?

Önce temel mimariyi oturtursak sonrasının kolay olacağını düşünütorum.

• Fakat şunu belirteyim ki, hem okurken sıkılmamanız hem de konuları daha diri tutabilmek adına yazıyı seri olarak böldüm. Yani konu başlıklarını bu yazıda bulamazsanız, yazının sonundaki linklerden WinRM ile ilgili diğer yazılara ulaşabilirsiniz.

1. WinRM nedir?

WinRM, Windows Remote Management‘in kısaltmasıdır.

Windows sistemlerini uzaktan yönetmek için kullanılan Microsoft’un WS-Management (WS-Man) tabanlı yönetim altyapısıdır.

Burada önemli bir ayrıntı var:

WinRM, PowerShell Remoting’in kendisi değildir.

PowerShell Remoting, WinRM’i kullanan yapılardan biridir.

Örneğin:

Enter-PSSession -ComputerName SERVER01

dediğimizde PowerShell arka planda WinRM/WS-Man üzerinden uzak makineyle iletişim kurar.

Benzer şekilde:

Invoke-Command -ComputerName SERVER01 -ScriptBlock {
    Get-Service
}

komutunda da WinRM devrededir.

Dolayısıyla kabaca şöyle düşünebiliriz:

WinRM’in kullanım alanı sadece PowerShell değildir. Windows yönetim araçları, otomasyon ürünleri ve çeşitli üçüncü parti çözümler de WinRM’i kullanabilir.

Bu yüzden WinRM’i “PowerShell’in uzaktan bağlantı özelliği” olarak düşünmek eksik olur.

Daha doğru tanım:

WinRM, Windows üzerinde uzaktan yönetim isteklerinin taşınmasını ve işlenmesini sağlayan yönetim altyapısıdır.

2. WinRM’de en önemli ayrım: Client ve Service

WinRM yapılandırmasına ilk defa ciddi şekilde baktığınızda karşınıza şu yapı çıkar:

winrm/config
    Client
    Service
    Winrs

Burada özellikle Client ve Service birbirine karıştırılıyor.

Aslında mantığı çok basit.

Bir bilgisayar:

• başka bilgisayara bağlanıyorsa Client
• başka bilgisayarların kendisine bağlanmasına izin veriyorsa Service

rolündedir.

Diyelim ki:

ADMIN01  --------->  SERVER01

ADMIN01 üzerinden:

Enter-PSSession SERVER01

çalıştırıyoruz.

Bu durumda:

ADMIN01 = WinRM Client
SERVER01 = WinRM Service

olur.

Ama:

SERVER01 ---------> ADMIN01

şeklinde bir bağlantı kurulursa bu kez roller tersine döner.

Dolayısıyla “bu makine WinRM client mı server mı?” sorusunun cevabı aslında kullanım yönüne bağlıdır.

Aynı Windows makinesi hem Client hem Service olabilir.

3. Client neyi kontrol ediyor?

Şöyle bir yapı düşünelim:

ADMIN01 üzerindeki:

winrm/config/client

ayarları, ADMIN01’in uzak sisteme bağlantı kurarken nasıl davranacağını belirler.

Örneğin:

Client
    NetworkDelayms
    URLPrefix
    AllowUnencrypted
    Auth
    DefaultPorts
    TrustedHosts

Buradaki ayarlar “Ben başka bir bilgisayara bağlanırken ne yapacağım?” sorusuyla ilgilidir.

Örneğin:

Enter-PSSession -ComputerName SERVER01

çalıştırıldığında, komutu çalıştırdığını makine için Client tarafındaki ayarlar devreye girer.

4. Service neyi kontrol ediyor?

Yine aynı akış ve görselde yönü ters çevirelim:

SERVER01’in:

winrm/config/service

ayarları ise SERVER01’e gelen WinRM bağlantılarının nasıl karşılanacağını belirler.

Örneğin:

Service
    MaxConnections
    AllowUnencrypted
    Auth
    IPv4Filter
    IPv6Filter
    AllowRemoteAccess

gibi ayarlar Service tarafındadır.

Dolayısıyla şöyle düşünmek işleri çok kolaylaştırıyor:

Client = Ben başkasına bağlanıyorum.
Service = Başkası bana bağlanıyor.

Bu ayrımı oturtunca WinRM konfigürasyonunun geri kalanı çok daha anlaşılır hale geliyor.

5. Client ve Service authentication neden ayrı?

Örneğin Client tarafında:

Client
    Auth
        Kerberos = true
        Negotiate = true
        Basic = false

Service tarafında ise:

Service
    Auth
        Kerberos = true
        Negotiate = true
        Basic = false

görebiliriz.

Bunlar aynı ayarın iki farklı kopyası değildir.

Client:

Ben hangi authentication yöntemlerini kullanabilirim?

diye bakar.

Service:

Bana gelen bağlantılarda hangi authentication yöntemlerini kabul edebilirim?

diye bakar. Dolayısıyla bir authentication yönteminin kullanılabilmesi için iki tarafın da buna uygun yapılandırılmış olması gerekir.

Örneğin:

Client
    Auth
        Basic = true

Service
    Auth
        Basic = false

durumunda bağlantı Basic authentication ile kurulamaz.

Tersi de aynı şekilde geçerlidir.

6. TrustedHosts konusu

WinRM tarafında en çok yanlış anlaşılan ayarlardan biri de TrustedHosts.

Örneğin:

Client
    TrustedHosts = SERVER01

gördüğümüzde bunun:

“SERVER01 benim bilgisayarıma bağlanabilir.”

anlamına geldiği sanılabiliyor. Fakat cevap aslında, Hayır.

TrustedHosts Client tarafında bulunur.

Yani anlamıı kabaca:

“Ben Client olarak hangi uzak bilgisayarları trusted host olarak değerlendireceğim?”

şeklindedir.

Örneğin:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVER01"

komutunu ADMIN01 üzerinde çalıştırdığımızda ADMIN01’in Client yapılandırmasını değiştiriyoruz. Bu ayar özellikle Kerberos’un kullanılamadığı workgroup ortamları veya IP adresiyle bağlantı gibi senaryolarda karşımıza çıkar. Ancak burada yılların Windows yöneticilerinden gelen klasik bir tavsiyeyi hatırlatmakta fayda var:

TrustedHosts = * yazıp geçmek, sorunu çözmenin en hızlı yollarından biridir. Aynı zamanda çoğu zaman sorunu çözmekten çok üzerini örter.

Özellikle domain ortamında sırf bir bağlantı problemi çıktı diye TrustedHosts=* yapmak iyi bir yaklaşım değildir.

Önce DNS, SPN, Kerberos, authentication ve firewall tarafını anlamak gerekir.

•  Microsoft’un dokümantasyonuna göre TrustedHosts listesindeki bilgisayarlar normal mutual authentication mekanizmasıyla doğrulanmaz ve istemci credential bilgilerinin bu bilgisayarlara gönderilmesi söz konusu olabilir. Bu nedenle listenin mümkün olduğunca dar tutulması önerilir. Link : https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management