GlobalProtect + Azure MFA 2FA: İlk Denemede VPN Bağlanmama Sorunu ve Kesin Çözüm
Kısa Özet:
GlobalProtect Azure MFA ilk denemede VPN olmuyor sorunu çoğunlukla düşük RADIUS timeout, yüksek retry ve challenge-response session timeout kaynaklıdır.
GlobalProtect Azure MFA ilk denemede VPN olmuyor problemi, Palo Alto firewall ve Microsoft Authenticator TOTP kullanılan ortamlarda oldukça sık karşılaşılan bir sorundur. Kullanıcılar çoğu zaman ilk OTP girişinde bağlantı kuramazken ikinci denemede başarılı olur.
Özellikle OTP kodu kullanan yapılarda bu durum kullanıcı tarafında “şifre yanlış mı girdim?” algısı oluşturur.
Aslında sorun çoğu zaman kullanıcı kaynaklı değil, RADIUS challenge-response oturum süresinin doğru yönetilmemesinden kaynaklanır.
Bu yazıda, GlobalProtect + Azure MFA ilk denemede VPN olmuyor probleminin nedenini ve sahada çalışan kesin çözüm adımlarını paylaşıyorum.
Ortam Yapısı
Sorunun yaşandığı mimari şu şekilde:
GlobalProtect Client → Palo Alto Firewall → Windows NPS → Azure MFA Extension → Microsoft 365 / Entra ID
Kullanıcı tarafında 2FA yöntemi olarak Microsoft Authenticator uygulamasından üretilen TOTP (Time-based One-Time Password) kullanılıyor.
Bu yapı içerisinde GlobalProtect:
- Kullanıcı şifresini alır
- OTP kodu için ikinci ekran açar
- Azure MFA doğrulaması tamamlanınca VPN bağlantısını kurar
Sorun tam olarak bu challenge-response aşamasında ortaya çıkar.
Sorun Nasıl Ortaya Çıkıyor?
Kullanıcı aşağıdaki durumu yaşar:
- İlk girişte kullanıcı adı ve parola doğru
- OTP ekranı geliyor
- Kod giriliyor
- VPN bağlanmıyor
- Aynı işlem tekrar yapılınca ikinci denemede bağlanıyor
Bu durum özellikle kullanıcı tarafında çok yanıltıcıdır.
İlk denemede başarısız, ikinci denemede başarılı olması sorunun çözüldüğü anlamına gelmez.
Arka planda çoğu zaman hatalı bir RADIUS session timeout döngüsü çalışıyordur.
Problemin Asıl Nedeni
GlobalProtect üzerinde TOTP ile 2FA akışı RADIUS Challenge-Response mantığıyla çalışır:
- Kullanıcı parolayı girer
- PAN-OS, NPS’e Access-Request gönderir
- NPS Access-Challenge döner
- Kullanıcı OTP kodunu girer
- PAN-OS ikinci Access-Request gönderir
- NPS Access-Accept döner
- VPN bağlantısı kurulur
Sorunun temel nedeni, PAN-OS’un 3. ve 5. adım arasındaki bekleme süresini tek bir RADIUS oturumu içinde saymasıdır.
Kullanıcı OTP kodunu yazarken geçen süre timeout değerini aşarsa:
- PAN-OS mevcut session’ı düşürür
- Yeni retry başlatır
- NPS tarafında önceki challenge state’i hâlâ bellekte kalır
- İkinci deneme başarılı olur
Bu yüzden kullanıcılar:
“İlk sefer olmuyor, ikinci sefer oluyor.”
şeklinde geri bildirim verir.
Çözüm 1: PAN-OS RADIUS Timeout ve Retry Ayarı
Sorunun en kritik çözüm noktası burasıdır.
Düşük timeout değeri challenge-response akışını tamamlamaya yetmez.
Önerilen Ayarlar
- Timeout: 60 saniye
- Retries: 1
Neden Retries = 1?
Retries değeri yüksek olduğunda PAN-OS timeout sonrası yeni bir RADIUS session başlatır.
Bu da:
- birden fazla challenge oluşmasına
- state karışıklığına
- ikinci denemede bağlanma problemine
neden olur.
Ayar Yolu
Device → Server Profiles → RADIUS → [NPS Server]
Timeout : 60
Retries : 1
Bu ayar tek başına çoğu ortamda problemi çözer.
Çözüm 2: Portal ve Gateway İçin Ayrı Authentication Profile Kullanımı
Sahada en sık gördüğüm ikinci hata, Portal ve Gateway tarafında aynı MFA profile’ın kullanılmasıdır.
Bu durumda kullanıcıya iki farklı noktada MFA tetiklenebilir.
Bu da:
- timeout süresini artırır
- challenge state karışıklığı oluşturur
- kullanıcı deneyimini bozar
Doğru Mimari
- Portal → LDAP
- Gateway → RADIUS + Azure MFA
Yani:
- Portal sadece AD kullanıcı adı / parola doğrular
- Gerçek MFA kontrolü sadece Gateway’de yapılır
Yapılandırma
Portal → LDAP Authentication
Gateway → RADIUS + MFA
Neden Bu Daha Doğru?
Bu yaklaşım Palo Alto tarafında best practice olarak kabul edilir.
Çünkü gerçek ağ erişimi Gateway’de verilir.
Portal’ın LDAP olması güvenlik zafiyeti oluşturmaz.
Çözüm 3: NPS ve Azure MFA Extension Kontrolleri
Yukarıdaki iki ayar sonrası hâlâ sorun varsa NPS tarafı kontrol edilmelidir.
Event Viewer Kontrolü
Windows Logs → Security
Event ID 6273 → Reject
Event ID 6272 → Accept
Ayrıca:
Applications and Services Logs
→ Microsoft → AzureMfa → AuthZ → Operational
Burada her denemede farklı CID (Correlation ID) oluşuyorsa session eşleşmesi bozuluyordur.
Saat Senkronizasyonu Çok Kritik
TOTP doğrulamasında kullanıcı cihazı ile NPS sunucusunun saat farkı kritik öneme sahiptir.
Saat farkı olduğunda kullanıcı OTP kodunu doğru girse bile ilk denemede hata oluşabilir.
Bu nedenle NPS sunucusunda:
- Windows Time servisinin çalıştığından
- güvenilir bir NTP kaynağı kullandığından
- domain saat senkronizasyonunun düzgün olduğundan
emin olunmalıdır.
TOTP Clock Skew Toleransı
Ek olarak Azure MFA Extension tarafında aşağıdaki registry değeri önerilir:
HKLM\SOFTWARE\Microsoft\AzureMfa
TOTP_CLOCK_SKEW_TOLERANCE = 2
Bu değer yaklaşık ±60 saniye tolerans sağlar.
Özellikle mobil cihaz saatleri küçük sapmalar gösteriyorsa ciddi fark yaratır.
NPS Sunucusunun Azure Erişimi
Azure MFA Extension her doğrulamada Microsoft servislerine HTTPS isteği gönderir.
Bu yüzden NPS sunucusunun aşağıdaki endpoint’e erişimi mutlaka test edilmelidir:
Test-NetConnection strongauthenticationservice.auth.microsoft.com -Port 443
Sonuç:
TcpTestSucceeded : True
olmalıdır.
Benzer NPS ve Azure MFA sorunları için 802.1X ve NPS ile Güvenli Wi-Fi yazımı da inceleyebilirsiniz.
Microsoft’un Azure MFA NPS Extension dokümantasyonuna göre timeout ve challenge-response akışında doğru oturum yönetimi kritik öneme sahiptir.
Sonuç
Sonuç olarak düşük timeout, fazla retry ve Portal/Gateway tarafında aynı MFA profile kullanımı kullanıcı deneyimini doğrudan bozar. Bu nedenle Timeout değerini 60 saniye, Retries değerini 1 yapmalı ve MFA doğrulamasını yalnızca Gateway üzerinde çalıştırmalısınız. Ayrıca NPS saat senkronizasyonunu ve Azure MFA erişimini kontrol ederek ilk denemede VPN bağlantı problemini tamamen ortadan kaldırabilirsiniz.
Yorum gönder