Windows Server’da RADIUS Sunucusu Kurulumu ve Kablosuz Ağ Kimlik Doğrulama

Yazar:komut.io ekibi Windows Server Ağ Yönetimi
0 Yorum

Kurumsal ağlarda kimlik doğrulama meselesini ciddiye almaya başlamadan önce, ben de bir zamanlar “WPA2-PSK yeter, ne gerek var bunlara” diye düşünürdüm. Sonra 150 kullanıcılı bir ofiste birisi ayrılınca tüm kablosuz ağın şifresini değiştirmek zorunda kaldım ve o gün NPS ile RADIUS’u hayatımın merkezine aldım. Bu yazıda Windows Server üzerinde RADIUS sunucusu kurarak kurumsal kablosuz ağ kimlik doğrulamasını nasıl yapılandıracağınızı, gerçek senaryolardan öğrendiklerimi de katarak anlatacağım.

RADIUS Nedir ve Neden Lazım?

RADIUS (Remote Authentication Dial-In User Service), ağa erişim taleplerini merkezi olarak yöneten bir AAA protokolüdür. Authentication (kimlik doğrulama), Authorization (yetkilendirme) ve Accounting (kayıt tutma) üçlüsünü tek noktadan yönetmenizi sağlar.

Kurumsal ortamda bunun pratik karşılığı şudur: Her kullanıcı kendi Active Directory kimlik bilgileriyle kablosuz ağa bağlanır. Birisi işten ayrıldığında AD hesabını devre dışı bırakmanız yeterlidir, o kişi bir daha ağa giremez. Bölüm bazlı VLAN ataması yapabilirsiniz, muhasebe farklı ağda, yazılım farklı ağda olabilir. Kim ne zaman bağlandı, ne kadar süre kaldı, tam kayıt tutulur.

Windows Server tarafında bu işlevi Network Policy Server (NPS) rolü üstlenir. NPS, Microsoft’un RADIUS implementasyonudur ve Active Directory ile doğal entegrasyonu sayesinde kurumsal ortamlarda oldukça güçlü bir çözüm sunar.

Ön Hazırlık ve Gereksinimler

Kuruluma geçmeden önce ortamınızın hazır olduğundan emin olmanız gerekiyor.

Gerekli bileşenler:

  • Windows Server 2019 veya 2022 (Domain Controller ya da member server olabilir)
  • Active Directory Domain Services kurulu ve çalışır durumda
  • 802.1X destekleyen kablosuz erişim noktaları (AP’ler)
  • NPS sunucusu için geçerli bir sertifika (EAP-TLS veya PEAP için)

Ağ mimarisi açısından öneriler:

  • NPS sunucusunu ayrı bir member server üzerine kurmak en sağlıklı yaklaşımdır, Domain Controller üzerine doğrudan kurmak da çalışır ama production ortamda rol ayrımı her zaman iyidir
  • AP’ler ile NPS sunucusu arasında UDP 1812 (authentication) ve UDP 1813 (accounting) portlarına izin verilmesi gerekir
  • Firewall kurallarını baştan netleştirin, sonradan port sorunuyla uğraşmak can sıkıcıdır

NPS Rolünün Kurulumu

PowerShell üzerinden kurulum hem daha hızlı hem de tekrarlanabilir olduğu için bunu tercih ediyorum.

# NPS rolünü ve yönetim araçlarını kur
Install-WindowsFeature NPAS -IncludeManagementTools

# Kurulumu doğrula
Get-WindowsFeature NPAS | Select-Object Name, InstallState, DisplayName

Kurulum tamamlandıktan sonra NPS’i Active Directory’e kaydetmeniz gerekiyor. Bu adımı atlayanların sonradan “neden kullanıcılar doğrulanamıyor” diye saatler harcadığını gördüm.

# NPS'i AD'ye kaydet (Bu komut elevated PowerShell'de çalıştırılmalı)
netsh nps add registeredserver domain=yourdomain.local server=NPSSRV01

# Alternatif olarak NPS konsolundan da yapılabilir, ama PowerShell tercihim
Register-NpsServer -Domain "yourdomain.local"

GUI üzerinden yapmak isteyenler için: Server Manager > Tools > Network Policy Server yolunu izleyin, konsol açıldıktan sonra sol panelde “NPS (Local)” üzerine sağ tıklayıp “Register server in Active Directory” seçeneğini kullanın.

Sertifika Altyapısının Hazırlanması

PEAP-MSCHAPv2 kullanacaksanız NPS sunucusunda bir sunucu sertifikası olması şarttır. İki yolunuz var: internal CA’dan sertifika almak ya da public bir CA’dan sertifika almak. Kurumsal ortamda internal CA tercih edilir.

AD CS (Active Directory Certificate Services) kuruluysa aşağıdaki PowerShell komutuyla sertifika talebini otomatikleştirebilirsiniz:

# Mevcut sertifikaları listele
Get-ChildItem -Path Cert:LocalMachineMy | 
    Where-Object {$_.EnhancedKeyUsageList -match "Server Authentication"} |
    Select-Object Subject, NotAfter, Thumbprint

# NPS için sertifika talebi oluştur
$certReq = @{
    DnsName = "npssrv01.yourdomain.local"
    CertStoreLocation = "Cert:LocalMachineMy"
    KeyAlgorithm = "RSA"
    KeyLength = 2048
    HashAlgorithm = "SHA256"
    KeyUsage = "KeyEncipherment", "DigitalSignature"
    TextExtension = @("2.5.29.37={text}1.3.6.1.5.5.7.3.1")
}

Sertifika alındıktan sonra NPS konsolunda EAP yapılandırması sırasında bu sertifikayı seçmeniz yeterli. Sertifikanın CN değerinin ya da SAN’ının NPS sunucusunun FQDN’iyle eşleştiğinden emin olun, istemci cihazlar buna bakıyor.

RADIUS İstemcilerinin (AP’ler) Tanımlanması

NPS, gelen RADIUS isteklerini yalnızca tanımlı istemcilerden kabul eder. Her AP’yi veya AP controller’ınızı RADIUS istemcisi olarak eklemeniz gerekir.

# Tek bir AP eklemek için
New-NpsRadiusClient -Address "192.168.10.50" `
    -Name "AP-Kati3-Sag" `
    -SharedSecret "Gizli$ifre2024!" `
    -VendorName "Cisco"

# Birden fazla AP'yi döngüyle eklemek
$apList = @(
    @{IP="192.168.10.51"; Name="AP-Kati1-Sol"},
    @{IP="192.168.10.52"; Name="AP-Kati1-Sag"},
    @{IP="192.168.10.53"; Name="AP-Kati2-Merkez"}
)

foreach ($ap in $apList) {
    New-NpsRadiusClient -Address $ap.IP `
        -Name $ap.Name `
        -SharedSecret "Gizli$ifre2024!" `
        -VendorName "Standard"
    Write-Host "$($ap.Name) eklendi: $($ap.IP)"
}

Shared Secret hakkında önemli bir not: Her AP için farklı shared secret kullanmak güvenlik açısından daha doğrudur. Pratikte yönetimi kolaylaştırmak için tek bir shared secret kullananlar da var ama en azından bu değerin karmaşık ve uzun olmasına dikkat edin. 12 karakterin altındaki shared secret’lar güvenlik açısından yetersiz kalır.

Eğer AP controller kullanıyorsanız (Cisco WLC, Aruba, Unifi Controller gibi) yalnızca controller’ın IP adresini eklemeniz yeterlidir, tek tek AP eklemek gerekmez.

Ağ İlkelerinin (Network Policy) Yapılandırılması

NPS’in asıl gücü burada yatıyor. Ağ ilkeleri, hangi kullanıcıların hangi koşullarda ağa erişebileceğini belirler.

Senaryo olarak şunu ele alalım: “Yalnızca ‘Domain Users’ grubundan olan kullanıcılar kablosuz ağa bağlanabilsin, misafirler bağlanabilsin ama farklı VLAN’a düşsün.”

# Önce mevcut politikaları listeleyelim
Get-NpsNetworkPolicy | Select-Object Name, PolicySource, ProcessingOrder, Enabled

# Kurumsal kullanıcılar için temel politika oluşturma
# (Bu işlem genellikle GUI'den daha rahat yapılır, ama scripting için)
$policyName = "Kurumsal-Kablosuz-Erisim"

# NPS policy XML ile de yönetilebilir, export/import oldukça kullanışlı
netsh nps export filename="C:NPS-Backupnps-config.xml" exportPSK=YES

GUI üzerinden politika oluştururken adımları şöyle özetleyebilirim:

NPS konsolunda “Policies > Network Policies” altına sağ tıklayın, “New” deyin. Policy name olarak anlamlı bir isim girin (AP-Kurumsal-Wifi gibi). Conditions ekranında şu koşulları ekleyin:

Koşullar (Conditions):

  • Windows Groups: Domain Users (ya da özel bir güvenlik grubu)
  • NAS Port Type: Wireless – IEEE 802.11 (bu önemli, sadece wifi üzerinden gelen istekleri karşılasın)
  • Client IPv4 Address: AP’lerinizin subnet’ini girebilirsiniz (opsiyonel ama önerilen)

Constraints sekmesinde:

  • Authentication Methods: PEAP seçin, EAP türü olarak Microsoft: Secured Password (EAP-MSCHAP v2) ekleyin
  • “Less secure authentication methods” bölümündeki tüm seçeneklerin işaretini kaldırın

Settings sekmesinde RADIUS Attributes:

VLAN atama için vendor-specific attribute eklemeniz gerekiyor. Standard RADIUS attribute’ları ile VLAN atama:

Tunnel-Type = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (includes all 802 media plus Ethernet canonical format)  
Tunnel-Pvt-Group-ID = 10  (VLAN ID numarası)

Bu üç attribute birlikte çalışır ve AP’ye “bu kullanıcıyı VLAN 10’a koy” der.

Accounting ve Loglama Yapılandırması

Kimin ne zaman bağlandığını tutmak hem güvenlik hem de troubleshooting açısından kritik. NPS bu logları varsayılan olarak C:WindowsSystem32LogFiles altına yazar ama bunu özelleştirmek gerekebilir.

# NPS accounting ayarlarını kontrol et
netsh nps show accounting

# Log dosyası konumunu değiştir
netsh nps set accounting logfilepath="D:NPS-Logs"

# Log formatını yapılandır (DTS = SQL uyumlu format)
netsh nps set accounting logfileformat=DTS

# Günlük log rotasyonu ayarla
netsh nps set accounting newlogfrequency=Daily

Logları SQL Server’a yazmak isteyenseniz, ki büyük ortamlarda bunu şiddetle tavsiye ederim, NPS konsolunda “Accounting” bölümünden SQL Server Logging’i aktif edebilirsiniz. Böylece bağlantı geçmişlerini SQL sorgularıyla analiz edebilirsiniz.

Event Viewer üzerinden de NPS olaylarını takip edebilirsiniz:

# Son 50 NPS authentication eventini görüntüle
Get-WinEvent -LogName "Security" -MaxEvents 500 | 
    Where-Object {$_.Id -in @(6272, 6273, 6274, 6275, 6276, 6277, 6278)} |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize

# Event ID'leri:
# 6272: Ağ İlkesi Sunucusu kullanıcıya erişim izni verdi
# 6273: Ağ İlkesi Sunucusu kullanıcıya erişimi reddetti
# 6274: Ağ İlkesi Sunucusu isteği iptal etti

AP Tarafında Yapılandırma

NPS tarafı hazır, şimdi AP’leri ya da controller’ı yapılandırma sırası. Her üretici farklı arayüz kullanıyor ama mantık aynı. Burada genel kavramları veriyorum.

Unifi Controller için temel SSID yapılandırması örneği (informational):

SSID: Kurumsal-Wifi
Security: WPA2 Enterprise
EAP Method: PEAP
RADIUS Authentication Server: 192.168.1.50
RADIUS Port: 1812
RADIUS Secret: Gizli$ifre2024!
RADIUS Accounting Server: 192.168.1.50
RADIUS Accounting Port: 1813
RADIUS Accounting Secret: Gizli$ifre2024!

Cisco WLC tarafında CLI ile yapılandırma:

# WLC CLI örneği - RADIUS sunucu tanımı
config radius auth add 1 192.168.1.50 1812 ascii Gizli$ifre2024!
config radius auth enable 1
config radius acct add 1 192.168.1.50 1813 ascii Gizli$ifre2024!
config radius acct enable 1

# WLAN'a RADIUS ata
config wlan radius_server auth add 1 1
config wlan security wpa akm 802.1x enable 1
config wlan enable 1

Sorun Giderme

En sık karşılaşılan sorunlar ve çözümleri:

“Authentication failed – Reason Code 16” hatası: Bu genellikle NPS’in AD’ye kayıtlı olmamasından kaynaklanır. Yukarıdaki Register-NpsServer komutunu tekrar çalıştırın, sonra NPS servisini yeniden başlatın.

# NPS servisini yeniden başlat
Restart-Service IAS

# Servis durumunu kontrol et
Get-Service IAS | Select-Object Name, Status, StartType

“Reason Code 22 – Client not found” hatası: AP’nin IP adresi RADIUS istemcisi olarak tanımlı değil demektir. RADIUS isteği hangi IP’den geliyor, onu bulup ekleyin.

# NPS event loglarından kaynak IP'yi bul
Get-WinEvent -LogName "Security" -MaxEvents 100 |
    Where-Object {$_.Id -eq 6273} |
    Select-Object -First 5 -ExpandProperty Message

Sertifika güven sorunları: İstemci cihazlar NPS sertifikasını güvenilir bulamıyorsa, bu sertifikayı imzalayan CA sertifikasının istemci cihazların “Trusted Root Certification Authorities” deposuna eklenmesi gerekir. GPO ile bu işlemi otomatize edebilirsiniz:

# CA sertifikasını domain'deki tüm bilgisayarlara GPO ile dagıtmak icin
# Sertifika dosyasını al
$rootCert = Get-ChildItem -Path Cert:LocalMachineRoot | 
    Where-Object {$_.Subject -match "YourCA"}

# Sertifikayı dışa aktar
Export-Certificate -Cert $rootCert -FilePath "C:TempRootCA.cer" -Type CERT

Dışa aktarılan sertifikayı Group Policy Management’ta Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities altına import edin.

Yüksek gecikme ve timeout sorunları: NPS sunucusu meşgul olduğunda kimlik doğrulama zaman aşımına uğrayabilir. AP’lerde RADIUS timeout değerini varsayılan 5 saniyeden 10-15 saniyeye çıkarmak geçici çözüm sağlayabilir, ama asıl sorun NPS performansı ise daha güçlü donanım ya da NPS yük dengeleme düşünülmeli.

Yüksek Erişilebilirlik için İkinci NPS Sunucusu

Production ortamda tek NPS sunucusu risk demektir. İkinci bir NPS sunucusu kurarak AP’lerde her ikisini de primary/secondary olarak tanımlamanız, primary düştüğünde otomatik olarak secondary’e geçiş sağlar.

# Birincil NPS'ten konfigürasyonu export et
netsh nps export filename="\NPSSRV02C$NPS-Importnps-config.xml" exportPSK=YES

# İkinci NPS sunucusunda import et (NPSSRV02 üzerinde çalıştır)
netsh nps import filename="C:NPS-Importnps-config.xml"

# İkinci sunucuyu da AD'ye kaydet
Register-NpsServer -Domain "yourdomain.local"

AP tarafında da her iki sunucuyu tanımlamayı unutmayın. Unifi’de bu primary/secondary RADIUS server alanlarına doldurmakla oluyor, Cisco WLC’de birden fazla RADIUS server ekleyip priority sırası verebiliyorsunuz.

İzleme ve Bakım

Düzenli bakım rutinine şunları eklemenizi öneririm:

# NPS log dosyalarının boyutunu kontrol et
Get-ChildItem "C:WindowsSystem32LogFiles" -Filter "*.log" |
    Select-Object Name, 
        @{N='Size(MB)';E={[math]::Round($_.Length/1MB, 2)}},
        LastWriteTime |
    Sort-Object LastWriteTime -Descending |
    Format-Table

# Sertifika son kullanma tarihlerini kontrol et (aylık yapılması önerilir)
Get-ChildItem -Path Cert:LocalMachineMy |
    Where-Object {$_.EnhancedKeyUsageList -match "Server Authentication"} |
    Select-Object Subject, 
        @{N='KalanGun';E={($_.NotAfter - (Get-Date)).Days}},
        NotAfter |
    Sort-Object KalanGun

# 30 günden az kalan sertifikalar için uyarı
Get-ChildItem -Path Cert:LocalMachineMy |
    Where-Object {
        $_.EnhancedKeyUsageList -match "Server Authentication" -and
        ($_.NotAfter - (Get-Date)).Days -lt 30
    } |
    ForEach-Object {
        Write-Warning "SERTIFIKA YAKINDA SONA ERIYOR: $($_.Subject) - $($_.NotAfter)"
    }

Bu son scripti bir scheduled task’a bağlayıp e-posta bildirimine dönüştürmek, gece 3’te “neden kimse bağlanamıyor” sorusunun önüne geçer. Sertifika süresi dolmuş NPS sunucusu tüm kablosuz erişimi keser, bu deneyimi bir kez yaşarsanız bir daha unutmazsınız.

Sonuç

RADIUS ve NPS kurulumu başta karmaşık görünse de aslında katmanlı bir yapı: AD entegrasyonu, sertifika, RADIUS istemci tanımları, ağ politikaları ve AP konfigürasyonu. Her katmanı doğru oturdurduğunuzda hem güvenli hem de yönetilebilir bir kablosuz ağ altyapısına sahip oluyorsunuz.

Özellikle vurgulamak istediğim birkaç nokta var. NPS’i AD’ye kaydetmeyi atlamayın, bu adım çoğu authentication hatasının kaynağıdır. Sertifika yönetimini ciddiye alın ve son kullanma tarihlerini monitörleyin. Production ortamda mutlaka ikinci NPS sunucusu bulundurun. Log ve accounting’i aktif tutun, bu kayıtlar hem güvenlik incelemeleri hem de sorun giderme için hayat kurtarır.

Active Directory altyapısı olan her kurumda WPA2-PSK yerine 802.1X + RADIUS kullanmak artık bir tercih değil, standart olmalı. Kullanıcı başına kimlik doğrulama, granüler erişim kontrolü ve merkezi yönetim avantajları, kurulum maliyetini fazlasıyla karşılıyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir