Windows Server NPS Kurulumu: RADIUS Sunucusu Adım Adım

Windows Server NPS kurulumu, Network Policy Server rolünü eklemek, sunucuyu Active Directory’ye kaydetmek, ağ cihazlarını RADIUS istemcisi olarak tanıtmak ve kimin hangi koşulla gireceğini bir network policy ile yazmaktır. NPS, Windows’un RADIUS sunucusudur. Switch, access point ya da VPN cihazı kullanıcıyı ona sorar, NPS de cevabı Active Directory’den alır.

Bir süpermarket zincirinin genel müdürlüğünde bir onay masası düşünün. Şubeler bir personelin kodunu bu masaya telefonla sorar, masa da personel siciline bakıp cevap verir. Masa yalnız listesinde kayıtlı şubelerin telefonunu açar ve her şubeyle arasında bir parola vardır. Kimin hangi işi yapabileceği de masadaki kural defterinde yazar.

Bu yazıda lab’daki yeni bir Windows Server 2025’e NPS’i kuruyor ve her adımı bir test istemcisinden gönderdiğim isteklerle sınıyorum. NPS’in reddettiği ve hiç cevap vermediği durumları, event log’da nerede iz bıraktıklarıyla birlikte ölçtüm. Aynı sunucunun Linux karşılığını FreeRADIUS kurulumu rehberimizde anlattık. Ön koşullarınız hazırsa doğrudan rol kurulumuna geçebilirsiniz.

Bu rehber Windows Server rolleri yazımızdaki NPS bölümünün kurulum tarafıdır ve BT Sistem Yönetimi hizmetimize aittir. Switch’e yönetici girişini merkeze bağlamanın yerini switch yapılandırma rehberimizde gösterdik, switch tarafını da switch RADIUS yapılandırması yazımızda ölçtük.

Windows Server NPS Kurulumundan Önce: Sunucu, Domain ve İstemciler

Bu rehber, üzerine NPS kuracağınız Windows Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk yapılandırma ayrı bir konudur ve Windows Server kurulum rehberimizde ele alınmaktadır.

Kuruluma başlamadan önce dört şeyi hazırlıyorum:

1. Sunucu domain üyesi. NPS kullanıcıyı Active Directory’de doğrulayacağı için sunucu domain’e katılmış olmalıdır. Lab sunucusu nps01’i domain’e katarken modemin IPv6 üzerinden dağıttığı DNS sunucusu araya girdi ve katılma DNS_INFO_NO_RECORDS hatasıyla düştü. Bu tuzağı bilgisayarı domain’e ekleme yazımızda anlattık.
2. Sabit bir IP adresi. Switch ve access point’ler NPS’e adresle ulaşır, adres değişirse hepsi aynı anda sahipsiz kalır. Lab’da nps01 192.168.1.50 adresinde duruyor.
3. İstemci listesi. NPS’e soru soracak her cihazın IP adresini baştan yazın. NPS listede olmayan cihaza cevap vermez.
4. Bir Active Directory grubu. Kimin gireceğini kişi kişi değil grupla yönetmek için bir güvenlik grubu açıyorum: NPS-Ag-Yoneticileri. Test için iki hesap var: grupta olan nps-yonetici ve grupta olmayan nps-misafir.

NPS’i domain controller’a da kurabilirsiniz ve küçük kurumlarda bu sık görülür. Ben ayrı bir üye sunucuyu tercih ediyorum, çünkü domain controller’a eklenen her ağ servisi onun saldırı yüzeyini büyütür.

Yaptığımız on üç lokasyonlu bir projede de NPS’i veri merkezindeki ayrı bir sanal sunucuya kurmuştuk; o işi ağ erişimi sıkılaştırma projesinde anlattık. NPS mi FreeRADIUS mu sorusunu RADIUS nedir yazımızda tartıştık.

NPS Rolü Kurulumu: Network Policy and Access Services

NPS tek başına bir rol değil, Network Policy and Access Services rolünün bir servisidir. Server Manager’da Add Roles and Features sihirbazında bu rolü seçip Network Policy Server servisini işaretlemek yeterlidir. Aynı işi PowerShell’de tek satırla yapıyorum:

Install-WindowsFeature NPAS -IncludeManagementTools

Kurulum lab’da 310 saniye sürdü ve yeniden başlatma istemedi. -IncludeManagementTools NPS konsolunu da getirir, onsuz rol kurulur ama yönetecek ekran gelmez.

Güvenlik Duvarı: NPS RADIUS Paketini Gerçekten Alıyor mu?

Kurulumdan sonra ilk sorulacak soru, cihazdan gelen paketin NPS’e ulaşıp ulaşmadığıdır. Microsoft’un kendi belgesi Windows Server 2019 için bir tuzak tarif ediyor: güvenlik duvarı kuralları kurulumla birlikte açılıyor ama NPS servisinin güvenlik kimliği yüzünden RADIUS trafiğini yine düşürüyor. Önerilen çözüm servisin kimlik türünü değiştirmek (Microsoft Learn, Configure Firewalls for RADIUS Traffic):

sc sidtype IAS unrestricted

Belge bu adımı 2019 için yazıyor, 2022 ve 2025 hakkında bir şey söylemiyor. Server 2025’te gerekip gerekmediğini bir şey değiştirmeden önce okudum:

sc qsidtype IAS

[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: IAS
SERVICE_SID_TYPE:  UNRESTRICTED

Değer kurulumdan hemen sonra zaten UNRESTRICTED. Yani 2019’daki düzeltme bu sürümde varsayılan olarak gelmiş. Kurulum güvenlik duvarına da altı kural eklemişti:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | Format-Table DisplayName, Enabled, Action

DisplayName                                                   Enabled Action
-----------                                                   ------- ------
Network Policy Server (Legacy RADIUS Authentication - UDP-In)    True  Allow
Network Policy Server (Legacy RADIUS Accounting - UDP-In)        True  Allow
Network Policy Server (DCOM-In)                                  True  Allow
Network Policy Server (RPC)                                      True  Allow
Network Policy Server (RADIUS Authentication - UDP-In)           True  Allow
Network Policy Server (RADIUS Accounting - UDP-In)               True  Allow

Yine de ayara bakmak yetmez, paketin gerçekten ulaştığını görmek gerekir. Bunun için NPS’e henüz tanıtmadığım bir Linux makineden (ntp01, 192.168.1.15) istek gönderdim:

Sent Access-Request Id 38 from 0.0.0.0:50796 to 192.168.1.50:1812 length 80
...
Sent Access-Request Id 38 from 0.0.0.0:50796 to 192.168.1.50:1812 length 80
...
Sent Access-Request Id 38 from 0.0.0.0:50796 to 192.168.1.50:1812 length 80
...
(0) No reply from server for ID 38 socket 3

İstemci üç kez 5 saniye bekledi ve 15 saniyenin sonunda cevapsız kaldı. Bu çıktı tek başına güvenlik duvarının paketi düşürdüğünü de düşündürebilir. Cevabı NPS’in System günlüğü veriyor. Aynı üç saniyede üç kayıt düştü:

A RADIUS message was received from the invalid RADIUS client IP address 192.168.1.15.

Event 13, paketin güvenlik duvarını geçip NPS’e ulaştığını kanıtlar. NPS istemciyi tanımadığı için paketi okudu ve cevap vermeden attı. Onay masası da listesinde olmayan bir şubenin telefonunu açmaz. Benzetme burada kopuyor: gerçek bir şube meşgul sesi duyardı, RADIUS istemcisi ise hiçbir şey duymaz ve sessizliği ancak zaman aşımıyla anlar. UDP’de sessizliğin ne anlama geldiğini port yazımızda anlattık.

NPS’i Active Directory’ye Kaydetmek

Rol kuruldu, ama NPS henüz kullanıcı hesaplarının içine bakmaya yetkili değil. NPS bir girişe karar verirken yalnız parolayı sormaz, hesabın Dial-in sekmesindeki Network Access Permission ayarına da bakar. Bu ayar üç değerden birini taşır: Allow access, Deny access ya da kararı network policy’ye bırakan Control access through NPS Network Policy.

NPS’in bu ayarı okuyabilmesi için Active Directory’ye tanıtılması gerekir. Buna NPS’i Active Directory’ye kaydetmek denir. Arka planda olan tek şey, NPS sunucusunun bilgisayar hesabının domain’deki RAS and IAS Servers grubuna eklenmesidir. Bu grup, kullanıcı hesaplarındaki uzaktan erişim bilgilerini okuma iznine sahiptir; sunucu gruba girince aynı izin ona da geçer.

Konsolda NPS (Local) üzerine sağ tıklayıp Register server in Active Directory seçilir. Aynı iş komutla şöyle yapılır:

netsh nps add registeredserver

Ok.

Kaydın tuttuğunu görmek için:

netsh ras show registeredserver

The following Remote Access server is registered:
  Remote Access Server:  NPS01
  Domain:                ad.sistemkusu.com

Kayıtsız NPS Neden Çalışıyor Gibi Görünür?

Bu adım kolayca atlanır, çünkü atlandığında çoğu zaman hiçbir şey bozulmaz. Lab’da da öyle oldu. Kayıttan önce nps-yonetici hesabının Dial-in ayarını Deny access yaptım ve NPS bu ayarı okuyup girişi reddetti.

Kayıt olmadan okuma izni nereden geldi? Domain’in Pre-Windows 2000 Compatible Access grubunda Authenticated Users üyesi vardı. Bu üyelik eski uygulamalarla uyumluluk için durur ve domain’deki her bilgisayar hesabına aynı okumayı sağlar.

Asıl soru, bu üyeliği kaldırmış bir domain’de ne olduğudur. Üyeliği geçici olarak kaldırıp aynı isteği kayıtsız NPS’e gönderdim. NPS ne kabul etti ne reddetti, isteği sessizce attı. Security günlüğüne şu düştü:

Reason Code:  6
Reason:       The NPS server is unavailable because of low hardware resources or because it failed to receive the name of a domain controller, which can be due to a security accounts manager (SAM) database failure on the local computer or an NT directory service (NTDS) failure.

System günlüğü de There is no domain controller available for domain SISTEMKUSU. dedi. Oysa domain controller ayaktaydı ve iki dakika önce aynı NPS ona bağlanmıştı. Mesaj donanıma ve domain controller’a işaret ediyor, gerçek sebep ise eksik kayıt. Kaydı yapıp aynı isteği tekrar gönderdim ve NPS bu kez hesabın Deny ayarını okuyup doğru bir Access-Reject döndürdü.

Ölçümden sonra üyeliği geri koydum. Kayıt, domain bugün sıkılaştırılmamış olsa bile yapılır, çünkü kayıtsız bir NPS o değişikliğin yapıldığı gün sessizce durur ve arıza başka bir yerde aranır. Personel siciline bakma yetkisi masaya bir kez resmen verilir, bir koridor kapısının açık kalmasına güvenilmez.

RADIUS İstemcisi Eklemek: Cihazı NPS’e Tanıtmak

NPS’in soru kabul edeceği her cihaz bir RADIUS istemcisi olarak tanımlanır. İstemcinin üç parçası vardır: bir ad, cihazın IP adresi ve cihazla NPS’in ortak bildiği paylaşılan anahtar (shared secret). Konsolda RADIUS Clients and Servers → RADIUS Clients → New yolundan eklenir. Komutla:

New-NpsRadiusClient -Name "ntp01-test" -Address "192.168.1.15" -SharedSecret "<paylaşılan anahtar>"

Paylaşılan anahtar, cihazla NPS arasındaki paketin kimliğini doğrular ve PAP’ta parolayı gizler. Bu yüzden kısa ya da tahmin edilebilir olmamalıdır. Lab’da 32 karakterlik rastgele bir anahtar kullandım. Konsoldaki Generate seçeneği de aynı işi yapar. Anahtarın neden RADIUS’un en zayıf halkası olduğunu RADIUS nedir yazımızda anlattık.

Bir şeyi bilerek yazıyorum: bu anahtar sunucuda okunabilir duruyor. Get-NpsRadiusClient onu düz metin olarak basıyor (netsh nps show client de aynısını yapıyor):

Get-NpsRadiusClient

Name                  : ntp01-test
Address               : 192.168.1.15
AuthAttributeRequired : True
SharedSecret          : ANBoi9Ww...
VendorName            : RADIUS Standard
Enabled               : True

Yani NPS sunucusunda yönetici olan herkes bütün cihazların anahtarını görür. Anahtarı her cihaz için ayrı üretin ki biri sızdığında yalnız o cihazın anahtarı değişsin. Çıktıyı ölçümlerin sonunda aldım. AuthAttributeRequired : True satırı, Blast-RADIUS bölümünde açtığım ayardır ve yeni eklenen bir istemcide False gelir.

NPS Network Policy: Hangi Grup, Hangi Koşulla Girer?

İstemci tanımlandı, artık NPS soruyu kabul ediyor. Şimdi cevabı belirleyen kuralı yazıyorum. Network policy üç şeyi tanımlar:

1. Koşul: isteğin bu policy’ye düşmesi için ne gerekir. Lab’da tek koşul var, kullanıcı NPS-Ag-Yoneticileri grubunda olmalıdır (User Groups).
2. İzin: koşul tutarsa erişim verilir mi reddedilir mi (Access granted).
3. Kısıtlar: hangi kimlik doğrulama yöntemine izin verilir. Lab’da yalnız Unencrypted authentication (PAP, SPAP) açık.

PAP’ı bilerek açıyorum. Switch ve access point’ler yönetici girişini RADIUS’a genellikle PAP ile sorar ve parolayı paylaşılan anahtarla gizler. Wi-Fi ya da kablolu 802.1X için bu değil PEAP gibi bir EAP yöntemi seçilir ve sunucunun bir sertifikaya ihtiyacı olur. O tarafı ağ erişim kontrolü sayfamızda anlattık.

Konsolda Policies → Network Policies → New sihirbazı bu üç ekranı sırayla açar. Ben aynı policy’yi komutla yazdım. Grup koşulu, grubun SID’iyle verilir:

netsh nps add np name="Ag Yoneticileri - PAP" state=enable processingorder=1 conditionid="0x1fb5" conditiondata="S-1-5-21-1635381480-226284308-505078058-1146" profileid="0x100f" profiledata="TRUE" profileid="0x1009" profiledata="0x1"

0x100f erişim iznidir (TRUE verilir), 0x1009 kimlik doğrulama türüdür (0x1 PAP). netsh nps show np policy’yi şöyle gösterdi:

Name             = Ag Yoneticileri - PAP
State            = Enabled
Processing order = 1
...
Condition0                              0x1fb5      "S-1-5-21-1635381480-226284308-505078058-1146"
...
NP-Allow-Dial-in                        0x100f      "TRUE"
NP-Authentication-Type                  0x1009      "0x1"

Policy’ye sonradan bir öznitelik eklerken dikkat edin. netsh nps set np verdiğiniz özniteliği profile eklemez, profili baştan yazar. Lab’da policy’ye yalnız bir öznitelik eklemek istedim ve komutta yalnız onu verdim. Sonuçta erişim izni (0x100f) silindi, kimlik doğrulama türü de varsayılana döndü ve PAP listeden çıktı. O hâliyle her giriş reddedilirdi.

Profili komutla değiştirirken bütün öznitelikleri aynı satırda yeniden verin, sonra netsh nps show np ile okuyun.

Kullanıcıları gruba eklemeyi ve grup mimarisini Active Directory kullanıcı, grup ve OU yönetimi yazımızda anlattık.

Connection Request Policy ile Network Policy Farkı

NPS’te iki tür policy vardır ve adları birbirine karışır. Connection Request Policy isteğin nerede işleneceğine karar verir: bu sunucuda mı, yoksa başka bir RADIUS sunucusuna mı iletilecek. Network Policy ise işlenen isteğe evet ya da hayır der.

Kurulumla birlikte gelen Use Windows authentication for all users connection request policy’si her isteği bu sunucuda Active Directory ile doğrular. Tek bir NPS kullanan kurumda bu policy’ye dokunmak gerekmez.

Network Policy’lerde Sıra: İlk Eşleşen Karar Verir

NPS network policy’leri Processing order sırasıyla okur ve koşulu tutan ilk policy’de durur. Kurulumla iki policy daha gelir ve ikisi de en sonda, reddetmek üzere durur: Connections to Microsoft Routing and Remote Access server (999998) ve Connections to other access servers (999999). Hiçbir policy’ye uymayan istek sondaki bu policy’ye düşer ve reddedilir.

Bunun event log’undaki görüntüsü yanıltıcıdır. Gruba üye olmayan nps-misafir reddedildiğinde 6273 kaydı şunu yazdı:

User:
    Account Name:            nps-misafir
...
Authentication Details:
    Connection Request Policy Name:    Use Windows authentication for all users
    Network Policy Name:        Connections to other access servers
    Authentication Type:        PAP
...
    Reason Code:            65
    Reason:                The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user.

Kayıt sebebi hesabın Dial-in ayarına yüklüyor. Oysa hesapta hiçbir ayar yoktu. Aynı kodu Deny ayarlı nps-yonetici de aldı. İki durumu ayıran tek alan Network Policy Name’dir:

Reason Code 65 gördüğünüzde önce bu alana bakın. Varsayılan network policy’nin adı yazıyorsa sorun hesapta değil, kendi network policy’nizin koşulundadır.

NPS Kurulumunu Doğrulamak: Access-Accept ve Access-Reject

Windows’ta yerleşik bir RADIUS test aracı yok. Sınamayı iki yoldan yapabilirsiniz: cihazın kendisinden gerçek bir girişle ya da bir Linux makineden radtest ile. Ben ntp01’de freeradius-utils paketindeki radtest’i kullandım. Önce gruptaki hesap ve doğru parola:

radtest -t pap nps-yonetici '<parola>' 192.168.1.50 0 '<paylaşılan anahtar>'

Sent Access-Request Id 129 from 0.0.0.0:40012 to 192.168.1.50:1812 length 82
	User-Name = "nps-yonetici"
	User-Password = "..."
	Message-Authenticator = 0x00
Received Access-Accept Id 129 from 192.168.1.50:1812 to 192.168.1.15:40012 length 84
	Message-Authenticator = 0x85c93ea6a02aae2b7787b14c19ccf743
	Class = 0x607404e8...

Sonra aynı istemciden, aynı dakikada, üç hatalı deneme daha:

İlk üç satır beklenen davranıştır: NPS ya kabul eder ya reddeder ve bunu 0,2 saniyenin altında söyler. Dördüncü satır farklı. Paylaşılan anahtar yanlışsa NPS paketin kimliğini doğrulayamaz, paketi reddetmez, atar. Cihaz tarafında bu durum, NPS’in hiç çalışmadığı durumdan ayırt edilemez. Doğrulama burada tutmuyorsa aşağıdaki sık yapılan hatalar listesine ve System günlüğüne bakın.

NPS Olay Kayıtları: Event ID 6272 ve 6273

NPS her kararı Windows event log’a yazar. Kararların hepsini tek yerde görmek için Event Viewer → Custom Views → Server Roles → Network Policy and Access Services görünümünü açın. Kayıtların düşmesi için Network Policy Server denetim alt kategorisinin açık olması gerekir. Server 2025’te kurulumdan hemen sonra açıktı:

auditpol /get /subcategory:"Network Policy Server"

Category/Subcategory                      Setting
Logon/Logoff
  Network Policy Server                   Success and Failure

Lab’da ölçtüğüm her durumun NPS’te bıraktığı iz şöyle:

Tablonun asıl bilgisi günlük sütunundadır. Yanlış paylaşılan anahtar ve tanımlı olmayan istemci Security günlüğüne hiç düşmez, çünkü NPS isteği kimliği doğrulanmış bir istek saymaz ve karar vermez. Yalnız 6273’e bakan yönetici bu iki hatayı hiçbir zaman görmez. Cihaz zaman aşımı görüyorsa önce System günlüğüne bakın.

NPS Kayıt Dosyası: IN*.log

Event log’un yanında NPS her isteği bir metin dosyasına da yazar. Dosya C:\Windows\System32\LogFiles\ altında ay başına bir tanedir; lab’da IN2609.log adını taşıyordu. Gruba üye olmayan nps-misafir’in reddi dosyada şöyle iki satır bıraktı:

"NPS01","IAS",09/26/2026,04:36:55,1,"nps-misafir","ad.sistemkusu.com/Users/nps-misafir",...,"192.168.1.15","ntp01-test",...,"Connections to other access servers",0,...
"NPS01","IAS",09/26/2026,04:36:55,3,,"ad.sistemkusu.com/Users/nps-misafir",...,"192.168.1.15","ntp01-test",...,"Connections to other access servers",65,...

Satırlarda okunacak dört alan var:

1. Paket türü, tarihten sonraki ilk sayıdır: 1 istek, 2 kabul, 3 ret, 4 oturum kaydı (accounting).
2. Kullanıcı ve Active Directory’deki tam adı.
3. İstemci, yani soruyu soran cihazın adresi ve NPS’teki adı (ntp01-test).
4. Network Policy Name ve Reason Code, event log’dakiyle aynı değerlerdir.

Cihaz 1813 portuna oturum kaydı gönderiyorsa, oturumun başı ve sonu da paket türü 4 olarak aynı dosyaya düşer. Dosyada eksik olan da öğreticidir: yanlış paylaşılan anahtarla gönderdiğim istek burada da hiç yok. Sessiz kalan hataların izi yalnız System günlüğündedir.

Blast-RADIUS Sonrası NPS: Message-Authenticator Ayarları

2024’te duyurulan Blast-RADIUS açığı (CVE-2024-3596), araya giren birinin bir Access-Reject’i Access-Accept’e çevirebilmesine dayanır. Korumanın temeli, her pakete eklenen Message-Authenticator özniteliğidir. Microsoft Temmuz 2024 güncellemesiyle NPS’e bu özniteliği zorunlu kılan ayarlar ekledi. Ancak ayarların hepsi varsayılan olarak kapalı geliyor (KB5040268). Lab’da da öyleydi:

netsh nps show limitproxystate
netsh nps show requiremsgauth

Limit Proxy State           = disable
Ok.

Require Message Auth       = disable
Ok.

NPS bunu servis her başladığında System günlüğüne Event 4421 olarak da yazıyor. Üç ayarın işi birbirinden farklı:

• İstemci başına “Message-Authenticator zorunlu” ayarı, o cihazdan gelen her Access-Request’te özniteliği arar ve yoksa paketi atar. NPS’in cihazlara sunucu olarak hizmet verdiği düzende asıl koruma budur. Konsolda istemcinin Advanced sekmesindedir.
• limitproxystate, Proxy-State taşıyıp Message-Authenticator taşımayan istekleri atar.
• requiremsgauth, NPS başka bir RADIUS sunucusuna vekillik ederken o sunucudan gelen cevaplarda özniteliği arar.

İstemci ayarının etkisini ölçmek için Message-Authenticator göndermeyen eski bir cihazı taklit eden küçük bir istemci kullandım. Varsayılan ayarla NPS bu isteği kabul etti. Ayarı açtım:

Set-NpsRadiusClient -Name "ntp01-test" -AuthAttributeRequired $true

Ayar değiştiği hâlde aynı istek yine kabul edildi. NPS servisini yeniden başlattıktan sonra istek sessizce atıldı ve System günlüğüne Event 17 düştü: “…without a Message-Authenticator attribute when a Message-Authenticator attribute is required.” Lab’da bu ayar ancak servis yeniden başlayınca devreye girdi. Ayarı açtıktan sonra mutlaka bir test isteği gönderin.

Ayarı açmadan önce cihazlarınızın bu özniteliği gönderdiğinden emin olun. Göndermeyen bir cihaz, ayar açıldığı anda zaman aşımına düşer. Microsoft da güncellemeden sonra bazı güvenlik duvarı ve VPN cihazlarında girişin kesildiğini yazıyor (KB5043417). Lab’da radtest özniteliği her istekte gönderiyordu ve ayar açıkken de kabul aldı.

İkinci NPS Sunucusu: Yapılandırmayı Dışa Aktarmak

Tek bir NPS, arkasındaki bütün cihazların girişini tek bir sunucuya bağlar. O sunucu durursa hiçbir yönetici hiçbir cihaza merkezi hesabıyla giremez. Nedenini tek RADIUS sunucusu neden yetmez bölümünde anlattık. İkinci sunucuyu sıfırdan kurmak yerine birincinin yapılandırması aktarılır:

Export-NpsConfiguration -Path C:\Users\Public\nps-yedek.xml

Ortaya çıkan 60 KB’lık XML dosyası istemcileri, policy’leri ve ayarları taşır. İkinci sunucuda Import-NpsConfiguration ile içe alınır ve o sunucu da Active Directory’ye kaydedilir. Aktarımı ikinci bir sunucuda denemedim, ama dosyanın içine baktım:

<Shared_Secret xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">ANBoi9Ww...

Paylaşılan anahtarlar dosyada düz metin duruyor. Bu dosya bir yedek değil, bütün ağ cihazlarının anahtarıdır. Onu paylaşılan bir klasörde ya da e-postada bırakmayın, aktarım bitince silin. Cihaz tarafında da ikinci sunucu ayrıca tanımlanır, yoksa cihaz yalnız birinciye sormaya devam eder.

Windows Server NPS Kurulumunda Sık Yapılan Hatalar

• Kaydı atlamak. Varsayılan domain’de fark edilmez. Domain sıkılaştırıldığı gün istekler sessizce atılır ve event log sebebi domain controller’a yükler.
• Yalnız Security günlüğüne bakmak. Yanlış anahtar (18), tanımsız istemci (13) ve eksik Message-Authenticator (17) System günlüğündedir.
• Reason Code 65’te hesabı kurcalamak. Network Policy Name alanında varsayılan deny policy’sinin adı yazıyorsa sorun kendi policy’nizin koşulundadır.
• Policy’yi netsh nps set np ile yarım yazmak. Komut profili baştan yazar; yalnız eklemek istediğiniz özniteliği verirseniz erişim izni ve kimlik doğrulama türü silinir.
• Aynı paylaşılan anahtarı bütün cihazlara vermek. Anahtar sunucuda düz metin okunur. Biri sızarsa hepsi değişmek zorunda kalır.
• İkinci sunucuyu ertelemek. NPS durduğunda merkezi hesapla hiçbir cihaza girilemez. Cihazlarda yerel acil durum hesabı da bu yüzden durur.
• 2019’un düzeltmesini körü körüne uygulamak. Server 2025’te servis kimliği zaten UNRESTRICTED geliyor. Paketin ulaşıp ulaşmadığını Event 13’le görmek, komut uygulamaktan daha kesin bir sınamadır.

Bağlanamayan bir kullanıcıda hangi sırayla ilerleneceğini RADIUS teşhisi bölümünde anlattık.

Sonuç: NPS Sustuğunda Cevap System Günlüğündedir

NPS’i kurmak dört adımdır: rolü eklemek, sunucuyu Active Directory’ye kaydetmek, cihazları istemci olarak tanıtmak ve grup koşullu bir network policy yazmak. Lab’da bu dört adım 0,2 saniyede dönen bir Access-Accept verdi. Asıl öğretici olan ise hataların nasıl göründüğüydü. Ölçtüğüm yedi hatalı durumun dördünde NPS hiç cevap vermedi, cihaz yalnız zaman aşımı gördü.

Tanımsız istemci, yanlış anahtar, eksik Message-Authenticator ve kayıtsız sunucu aynı sessizliği üretiyor. Aralarındaki farkı yalnız NPS’in kendi günlüğü söylüyor ve dördünden üçü Security’de değil System günlüğünde. Onay masası tanımadığı telefonu açmaz, ama neden açmadığını defterine yazar.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn