FortiGate Firewall Active Directory Entegrasyonu: LDAP

FortiGate Firewall Active Directory entegrasyonu, kuralın kaynağına bir IP adresi yerine bir Active Directory grubunu yazmaktır. FortiGate kullanıcının adını ve parolasını LDAP ile domain controller’a sorar; kullanıcı gruptaysa trafiği geçirir ve logda IP adresinin yanına kullanıcının adını yazar. Kurulum dört yerde yapılır: LDAP Servers, User Groups, kural formu ve komut satırındaki kimlik sorma ayarı.

NIST’in firewall rehberi, kullanıcı kimliğine göre karar veren bir firewall’un bu kararı logda da göstermesini istiyor: kullanıcı kendine özel bir kuralla içeri alındıysa yalnız IP adresini yazmak yetmez, kullanıcının kimliği de yazılır. Entegrasyonun asıl kazancı bu satırdır.

Bu yazı FortiGate Firewall ileri seviye rehberimizin 6. adımıdır. Lab’daki dc01 domain controller’ına FortiGate’i bağlıyorum, muhasebe ağının (VLAN 70) internet çıkışını bir AD grubuna yazıyorum ve muhasebedeki bir istemciden giriş yapıyorum.

Lab’da üç şey beklenenden farklı çıktı:

1. Bağlantı testi ekranda gördüğünüz ayarı denemedi. Secure Connection anahtarını kapatıp kaydetmeden test edince FortiGate 389 portuna TLS gönderdi ve ekran “Can’t contact LDAP server” yazdı. Ayar kaydedilince test gerçek hatayı söyledi.
2. Grup kuralı ilk denemede kimseye kimlik sormadı. Kimliği bilinmeyen istek alttaki genel kurala düşüp geçti.
3. Parolası doğru kullanıcının başarısız girişinde log reason="success" yazdı. Sorun paroladaydı sanılır, gruptaydı.

Örnekteki sınır kapısında kulübe sürücülerin listesini kendisi tutmaz. Her sürücünün adını telle merkezdeki kayıt dairesine sorar, yalnız yetkili listede olanı geçirir ve tutanağa plakanın yanına sürücünün adını yazar. FortiGate’te kulübe firewall’un kendisi, kayıt dairesi domain controller, tel LDAP bağlantısı, yetkili liste de AD grubudur.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde Active Directory’si olan kurumlarda firewall kurallarını kullanıcı gruplarına bağlarken izlediğimiz sırayı anlatır.

FortiGate Active Directory Entegrasyonu Nasıl Olmalı?

FortiGate domain controller’a adıyla (FQDN) ve şifreli bir kanaldan bağlanır: LDAPS ya da STARTTLS. Bağlanan hesap yalnız bu iş için açılmış, ayrıcalıksız bir servis hesabıdır. Kurala herkesi kapsayan bir grup değil, işe özel bir AD grubu bağlanır.

Grup kuralı aynı kaynağı kapsayan genel kuralın üstünde durur ve kimliği bilinmeyen trafik alttaki kurala kaçmaz (auth-on-demand always). İzinli trafik bütün oturumlarıyla loglanır; logda IP adresinin yanında kullanıcının adı görünür.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. Microsoft, LDAP signing: Windows Server 2025 ile kurulan yeni Active Directory ortamları imzalamayı fabrika ayarında zorunlu tutuyor ve domain controller şifresiz bağlantı üzerinden gelen basit bağlanma (simple bind) isteklerini reddediyor. Şifresiz bir kanaldan düz parolayla bağlanmak yeni bir domain controller’da çalışmaz, eskisinde de parolayı ağda açık bırakır.
2. Microsoft, Introduction to Active Directory service accounts: servis hesapları ayrıcalıklı gruplara üye olmamalı, çünkü bu üyelik güvenlik riski yaratabilecek yetkiler verir. Denetim ve güvenlik için her servisin kendi servis hesabı olmalı. Aynı sayfa servis hesaplarına svc- gibi bir önek ve sahibini yazan bir açıklama verilmesini öneriyor.
3. Fortinet, Authentication policy extensions: fabrika ayarında kimliği doğrulanmamış trafiğin bir sonraki kurala düşmesine izin verilir. FortiGate kimliği doğrulanmamış kullanıcıyı, ancak eşleşen başka bir kural yoksa kimlik doğrulama kuralına göre oturum açmaya zorlar. Bunu değiştiren ayar auth-on-demand always, yalnız komut satırından yapılıyor. Belge 6.2 sürümünün yenilikleri arasında; fabrika davranışı lab’daki 7.0.10’da da aynı çıktı.
4. NIST SP 800-41 Rev. 1, bölüm 4.3: kullanıcı kimliğine göre kural uygulayan firewall’lar bu kuralları loglarına da yansıtabilmeli. Bölüm 4.4 de boşta kalan bağlantının bir süre sonra kesilmesini anlatıyor: süre, bilgisayarın başından kalkan kullanıcının yerine başkası oturduğunda açık kalan oturumu korur, ama sık kullanılmayan bağlantıları da yorar.

Kararlar ve lab’daki karşılıkları:

FortiGate Active Directory Ön Koşulları: Servis Hesabı ve Grup

Bu rehber, FortiGate’i bağlayacağınız Active Directory’yi zaten ayağa kaldırdığınızı varsayar. Domain controller kurulumu ayrı bir konudur ve Active Directory kurulum rehberimizde ele alınıyor.

FortiGate’in domain controller’a ağ üzerinden ulaşabilmesi gerekir. Çoğu kurumda domain controller iç ağdadır ve FortiGate ona iç arayüzünden doğrudan ulaşır; lab’da dc01 sunucu ağında (192.168.1.0/24) durduğu için FortiGate’te bu ağa bir statik rota var.

FortiGate domain controller’ı adıyla bulacağı için DNS’i de domain controller’ı göstermelidir: Network → DNS ekranında Specify seçilir ve Primary DNS server alanına domain controller’ın adresi yazılır (lab’da 192.168.1.10). İkinci bir domain controller varsa onun adresi Secondary DNS server alanına girer.

Lab’da tek domain controller var. İkincil alanda bir Public DNS (internetteki herkese açık DNS sunucusu) duruyor ve sunucu seçimi failover, yani dc01 cevap verdiği sürece ona sorulmuyor. Seçimin neden failover olduğunu FortiGate DNS ayarı yazımızda ölçtük.

Active Directory adlarını yalnız AD’nin DNS’i doğru çözer. Lab alanımızda aynı adı bir Public DNS’e sordum:

> nslookup dc01.ad.sistemkusu.com 8.8.8.8
Name:    dc01.ad.sistemkusu.com
Addresses:  216.150.1.1
	  216.150.1.129

Bu adresler domain controller’ın değil, alan adındaki web sitesinin barındırıcısının adresleri. Public DNS’e soran bir FortiGate, LDAPS bağlantısını hiç ilgisi olmayan bir sunucuya kurmaya çalışır.

Active Directory tarafında ise iki şey hazırlanır:

1. Servis hesabı. FortiGate dizinde kullanıcı arayabilmek için önce bir hesapla bağlanır. Lab’da bu iş için svc-fortigate-ldap adında sıradan bir kullanıcı var. Buraya Domain Admin hesabı yazmayın: FortiGate’in yapılandırması ya da yedeği başkasının eline geçerse o parola bütün dizinin anahtarı olur. Servis hesaplarına gereksiz yetki vermenin bedelini AD güvenlik sıkılaştırması yazımızda anlattık.
2. Kurala bağlanacak grup. Kuralı Domain Users gibi herkesi kapsayan bir gruba değil, yalnız bu iş için açılmış bir gruba bağlarsınız. Lab’da muhasebe bölümünün internet grubu USER_GM_MUH_INTERNET; deneme kullanıcısı muhasebe.deneme bu grubun üyesi. Grup adlarının kalıbını Active Directory isimlendirme standardı yazımızda anlattık.

Servis hesabının üyeliklerini dizinden okudum. Açıklamasına da Microsoft’un önerdiği gibi sahibini ve parolanın nerede durduğunu yazdım:

dn: CN=svc-fortigate-ldap,OU=Servis_Kullanicilari,DC=ad,DC=sistemkusu,DC=com
description: FortiGate gmfw01 LDAP okuma hesabi; sahibi: BT ekibi; parola yalniz FortiGate ve kasada
userAccountControl: 66048
primaryGroupID: 513

Kayıtta memberOf satırı yok; hesap yalnız birincil grubu olan Domain Users’ta (513). Kullanıcıyı bulup grubunu okumak için bu yetti. userAccountControl: 66048 parolanın süresi dolmayacak biçimde ayarlandığını söylüyor: süresi dolsaydı FortiGate bir sabah domain controller’a bağlanamazdı. Bu yüzden parola takvime bağlı bir işle değiştirilir ve FortiGate’teki kayıt aynı gün güncellenir.

FortiGate LDAP Sunucusu Tanımı: LDAPS ile 636 Portu

Hesap ve grup hazır olunca FortiGate’e domain controller’ı tanıtırız. User & Authentication → LDAP Servers → Create New ekranında şu alanlar doldurulur:

1. Name: kaydın FortiGate içindeki adı, bir sunucu adı değil; lab’da dc01-ldap.
2. Server IP/Name: domain controller’ın tam adı (FQDN), dc01.ad.sistemkusu.com. Alan IP adresini de kabul eder; adın neden daha doğru olduğunu aşağıda sertifika denetiminde gösteriyoruz.
3. Common Name Identifier: kullanıcının dizinde hangi alanla aranacağını belirler. Active Directory’de sAMAccountName yazılır; kullanıcı giriş sayfasına muhasebe.deneme yazar, FortiGate dizinde sAMAccountName=muhasebe.deneme arar.
4. Distinguished Name: aramanın başlayacağı yer, DC=ad,DC=sistemkusu,DC=com. Yanındaki Browse düğmesi dizin ağacını açar.
5. Bind Type: Regular. Username alanına servis hesabı (svc-fortigate-ldap@ad.sistemkusu.com), Password alanına parolası yazılır.
6. Secure Connection: açık, Protocol LDAPS. Anahtar açılınca port kendiliğinden 636’ya, kapanınca 389’a döner.

Test Connectivity düğmesi servis hesabıyla bağlanmayı dener. Lab’da Connection status satırı Successful oldu.

Komut satırı karşılığı:

config user ldap
    edit "dc01-ldap"
        set server "dc01.ad.sistemkusu.com"
        set cnid "sAMAccountName"
        set dn "DC=ad,DC=sistemkusu,DC=com"
        set type regular
        set username "svc-fortigate-ldap@ad.sistemkusu.com"
        set password <parola>
        set secure ldaps
    next
end

Bağlantı testi yalnız servis hesabını sınar. Bir kullanıcının parolasını ve gruplarını formdaki Test User Credentials düğmesiyle ya da komut satırından sınarsınız: diagnose test authserver ldap dc01-ldap muhasebe.deneme <parola>. Lab’daki çıktı:

authenticate 'muhasebe.deneme' against 'dc01-ldap' succeeded!
Group membership(s) - CN=USER_GM_MUH_INTERNET,OU=Gruplar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sistemkusu,DC=com
                      CN=Domain Users,CN=Users,DC=ad,DC=sistemkusu,DC=com

Çıktı iki şeyi birlikte doğruluyor: parola doğru ve FortiGate kullanıcının hangi gruplarda olduğunu okuyabiliyor. Kurala bağlayacağınız grup bu listede yoksa sonraki adımların hiçbiri çalışmaz.

LDAPS’i komut satırından açarken FortiGate bir uyarı da yazıyor: server-identity-check is disabled because ca-cert is unset. Bağlantı şifreli, ama FortiGate karşısındakinin gerçekten dc01 olup olmadığını denetlemiyor.

Denetimin ön koşulu Server IP/Name alanına yazılan değerdir. Fortinet’in LDAP sunucusu kılavuzuna göre FortiGate, sunucunun sunduğu sertifikada bu alandaki IP’yi ya da adı arar; sertifikada SAN (Subject Alternative Name) alanı varsa yalnız ona bakar. dc01’in LDAPS sertifikasını okudum:

subject=CN = dc01.ad.sistemkusu.com
issuer=DC = com, DC = sistemkusu, DC = ad, CN = SistemKusu-Lab-Root-CA
X509v3 Subject Alternative Name: 
    othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.ad.sistemkusu.com

SAN’da tek ad var ve IP adresi yok. Alana 192.168.1.10 yazılsaydı, Fortinet’in tarif ettiği eşleştirmede sertifika hiçbir zaman eşleşmezdi; sunucuyu FQDN ile tanımlamamın sebebi bu.

Kimlik denetiminin kendisi için domain controller’ın sertifikasını veren sertifika otoritesinin sertifikası FortiGate’e aktarılır ve formdaki Certificate alanında seçilir. Değerlendirme lisanslı lab cihazım CA sertifikası içe aktarmayı reddettiği için (Incorrect certificate file format for CA/LOCAL/CRL/REMOTE cert., yani sertifika dosyasının biçimi yanlış) bu adımı ölçemedim. Gerçek cihazda LDAPS kurulumunun eksik yarısı budur.

389 Portunda Bağlantı Testi: Ekrandaki Ayar mı, Kayıtlı Ayar mı?

Aynı formda Secure Connection’ı kapattım; port kendiliğinden 389’a döndü. Formu kaydetmeden Test Connectivity’ye bastım:

Mesaj bir ağ sorunu gibi okunuyor. Testi yaparken FortiGate ile dc01 arasındaki trafiği yakaladım (yakalama saatleri UTC):

23:54:28.792501 IP 192.168.10.1.15883 > 192.168.1.10.389: Flags [P.], seq 1:325, ack 1, win 11, options [nop,nop,TS val 760624 ecr 11160396], length 324
...
	0x0030:  00aa 4b4c 1603 0101 3f01 0001 3b03 03d1  ..KL....?...;...
...
23:54:28.793264 IP 192.168.1.10.389 > 192.168.10.1.15883: Flags [R.], seq 1, ack 325, win 0, length 0

FortiGate’in gönderdiği ilk baytlar 16 03 01: bu bir TLS el sıkışmasının başlangıcı. Yani test, ekranda kapattığım şifrelemeyi değil kayıtlı ayarı (LDAPS) yeni portla denedi; 389’da düz LDAP bekleyen dc01 de anlamadığı veriyi alınca bağlantıyı kesti (R.). “Can’t contact” mesajı bu kesintiden geliyor; sunucu ayakta ve cevap veriyor.

389 Portunda FortiGate Parolayı Düz Metin Gönderiyor

Aynı ayarı bu kez OK ile kaydettim, formu yeniden açıp testi tekrarladım:

Bu kez yakalamada TLS yok. Paketleri, bind türünü ve cevap kodunu yazan küçük bir betikle açtım (betik İstanbul saatini yazıyor, parolanın kendisini yazdırmıyor):

02:56:10 192.168.10.1 -> 192.168.1.10:389 BindRequest svc-fortigate-ldap@ad.sistemkusu.com | simple (duz parola)
02:56:10 192.168.1.10:389 -> 192.168.10.1 BindResponse resultCode: 8 | 00002028: LdapErr: DSID-0C09035C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v65f4

Yakalamada iki şey görünüyor:

1. FortiGate 389’da servis hesabının parolasını simple bind ile gönderiyor. Simple bind’da parola protokolün içinde şifrelenmez; şifreyi yalnız LDAPS gibi bir taşıma katmanı sağlar.
2. dc01 cevap veriyor ve resultCode: 8 ile reddediyor. Gerekçeyi cevabın kendisi yazıyor: şifreli olmayan bağlantıda imzasız bind kabul etmiyor. LDAP’te 8 numaralı kodun adı strongerAuthRequired; arayüzdeki mesaj bu kodun karşılığı.

Zorunluluk sürümden geliyor. Microsoft’un belgesine göre Windows Server 2025 ile kurulan her yeni Active Directory ortamı imzalamayı ayrı bir enforcement policy’siyle fabrika ayarında zorunlu tutuyor; dc01 bu sürümle sıfırdan kurulmuş bir domain controller.

Aynı belgeye göre Windows Server 2019 ve öncesi imzasız bind’ı kabul ediyor, yükseltilen ortamlar da eski ayarını koruyor. Böyle bir domain controller’da bağlantı testi 389’da Successful der ve servis hesabının parolası her girişte ağda düz metin gider. Yani 389’un çalışması iyi haber değildir.

Eski domain controller’larda imzalamayı elle açmayı AD güvenlik sıkılaştırması yazımızda anlattık. Şifreleme ayarını değiştirdiğinizde de önce kaydedin, sonra test edin.

STARTTLS: 389 Portunda Şifreli Kanal

Formdaki Protocol satırının öbür seçeneği STARTTLS. Bu yolda bağlantı 389’da düz açılır ve ilk iş olarak TLS’e yükseltilir. Lab’da denedim (set secure starttls; port kendiliğinden 389’a döndü):

authenticate 'muhasebe.deneme' against 'dc01-ldap' succeeded!
Group membership(s) - CN=USER_GM_MUH_INTERNET,OU=Gruplar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sistemkusu,DC=com
                      CN=Domain Users,CN=Users,DC=ad,DC=sistemkusu,DC=com

Yakalamada 1.3.6.1.4.1.1466.20037 numarası göründü (StartTLS isteğinin LDAP’teki kimliği) ve betik tek bir düz bind bulamadı; servis hesabının parolası şifreli kanaldan gitti. İki yol da güvenli. Lab’da LDAPS’te kaldım: bağlantı baştan TLS’tir ve firewall kurallarında 636 portu tek başına “şifreli LDAP” demektir.

FortiGate Kullanıcı Grubu: AD Grubunu Eşlemek

LDAP bağlantısı kurulunca FortiGate kullanıcıyı bulabiliyor, ama kurala hangi kullanıcıların gireceğini henüz bilmiyor. Bunu bir FortiGate kullanıcı grubu söyler. User & Authentication → User Groups → Create New ekranında:

1. Name alanına muhasebe-internet yazılır, Type Firewall kalır.
2. Remote Groups bölümünde Add düğmesi Add Group Match panelini açar; Remote Server olarak dc01-ldap seçilir.
3. Panel dizindeki grupları listeler (lab’da 57 grup). Arama kutusuna USER_GM yazılır, USER_GM_MUH_INTERNET satırına sağ tıklanır ve Add Selected seçilir.

Panel kapanınca grup formunda eşleme bir satır olarak duruyor:

Komut satırı karşılığı:

config user group
    edit "muhasebe-internet"
        set member "dc01-ldap"
        config match
            edit 1
                set server-name "dc01-ldap"
                set group-name "CN=USER_GM_MUH_INTERNET,OU=Gruplar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sistemkusu,DC=com"
            next
        end
    next
end

FortiGate her girişte kullanıcının gruplarını domain controller’dan yeniden okuyor; muhasebeye yeni biri başladığında FortiGate’e dokunmazsınız, kişiyi AD’de gruba eklersiniz.

FortiGate Kullanıcı Tabanlı Kural: Kaynağa Grubu Yazmak

Grup hazır; sıra onu bir kurala bağlamakta. Policy & Objects → Firewall Policy → Create New ekranında:

1. Name: Muhasebe internet (AD grubu).
2. Incoming Interface ic-bolumler, Outgoing Interface dis-hatlar.
3. Source: muhasebe ağının adres nesnesi n-muhasebe ve muhasebe-internet grubu, ikisi aynı alanda.
4. Service: genel kuralla aynı, HTTP, HTTPS ve PING.
5. Log Allowed Traffic: All Sessions.

FortiGate kaynaktaki iki şeyi birlikte arar: trafik muhasebe ağından gelmeli ve kullanıcı bu gruptan biri olarak giriş yapmış olmalı. Adres alanında all kalırsa kuralı tek başına grup belirler.

Log Allowed Traffic ayarı fabrika değeri Security Events’te kalırsa izinli trafik logda hiç görünmez; NIST’in istediği kullanıcı adlı satır da yazılmaz. Farkı log ayarları yazımızda ölçtük. Komut satırı karşılığı:

config firewall policy
    edit 12
        set name "Muhasebe internet (AD grubu)"
        set srcintf "ic-bolumler"
        set dstintf "dis-hatlar"
        set action accept
        set srcaddr "n-muhasebe"
        set dstaddr "all"
        set schedule "always"
        set service "HTTP" "HTTPS" "PING"
        set groups "muhasebe-internet"
        set logtraffic all
        set nat enable
    next
    move 12 before 5
end

Son satır kuralın listedeki yerini belirliyor. Grup kuralı, aynı kaynağı kapsayan genel kuralın (5) üstünde durmalı; yoksa trafik genel kurala takılır ve grup kuralına hiç sıra gelmez. Paketin listede ilk uyduğu kuralda durduğunu kural seti yazımızda anlattık.

FortiGate auth-on-demand: Grup Kuralı Neden Kimlik Sormadı?

Beklenen şuydu: muhasebe ağındaki bir bilgisayardan henüz kimse giriş yapmamışken biri internete çıkmak isterse grup kuralı (12) devreye girecek ve FortiGate tarayıcıda bir giriş sayfası açacaktı. Kullanıcı adını ve parolasını girmeyen internete çıkamayacaktı.

Olmadı. Muhasebe istemcisinden giriş yapmadan bir web sayfası istedim. FortiGate giriş sayfası göstermedi, sayfa doğrudan geldi (200). Sebebi oturum tablosu gösterdi (diagnose sys session list):

session info: proto=6 proto_state=05 duration=0 expire=0 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
...
misc=0 policy_id=5 pol_uuid_idx=14743 auth_info=0 chk_client_info=0 vd=0

Bağlantı grup kuralından (12) değil, altındaki genel kuraldan (5) geçmiş ve credential (kimlik bilgisi) taşımıyor (auth_info=0). Fortinet’in belgesinin tarif ettiği davranış tam bu: FortiGate kimliği bilinmeyen trafik için giriş sayfası açmak yerine sonraki kurallara baktı, genel kuralı eşleşmiş buldu ve kullanıcıyı hiç sormadan geçirdi.

Örnekteki kulübede bunun karşılığı şu: kimliğini göstermeyen sürücüye görevli “ad soyad” demek yerine önce yan şeride bakıyor; yan şerit herkese açıksa sürücüyü oradan geçiriyor. Yetkili liste kuruldu, ama listeye bakılacak an hiç gelmedi.

Bu davranışı FortiGate’in kimlik sorma ayarı auth-on-demand belirliyor. İki değeri var:

1. implicitly (fabrika ayarı): kimliği bilinmeyen trafik için FortiGate önce listedeki sonraki kurallara bakar. Kimlik istemeyen bir kural trafiği karşılıyorsa trafik oradan geçer ve giriş sayfası hiç açılmaz. Lab’daki durum buydu.
2. always: trafik kimlik isteyen bir kurala uyuyorsa FortiGate her durumda önce giriş sayfasını açar.

Ayar arayüzde yok. User & Authentication → Authentication Settings ekranında zaman aşımı, protokoller ve sertifika var, ama bu seçenek yok:

Ayar komut satırından değiştirilir:

config user setting
    set auth-on-demand always
end

Öbür yol, aynı kaynağı kapsayan genel izin kuralını kaldırmaktır; Fortinet’in belgesine göre eşleşen başka kural kalmayınca giriş zorlanıyor. Ben always yolunu ölçtüm. Ayarı değiştirdikten sonra aynı istek FortiGate’ten şu cevabı aldı:

HTTP/1.1 200 OK
...
<html><body><script language="JavaScript">window.location="http://10.34.70.1:1000/fgtauth?0209088e9786ea69";</script></body></html>

FortiGate isteği araya girip kendisi karşıladı ve tarayıcıyı muhasebe arayüzünün 1000 portundaki giriş sayfasına yönlendirdi. Araya girme, Authentication Settings ekranındaki Protocol support listesindeki protokollerde oluyor: HTTP, HTTPS, FTP ve TELNET.

HTTPS’te durum başka. Değerlendirme lisanslı lab cihazım HTTPS isteğini yalnız TLS 1.0 ile karşıladı; güncel istemci bağlantıyı kurmadı:

curl: (35) OpenSSL/3.0.13: error:0A00042E:SSL routines::tlsv1 alert protocol version

Bunu lisansın şifreleme kısıtına bağlıyorum, tam lisanslı cihazda ölçmedim. Eski TLS’e izin verdiğimde FortiGate isteği kendi sertifikasıyla karşıladı ve giriş sayfasının HTTPS adresine yönlendirdi:

* SSL connection using TLSv1 / ECDHE-RSA-AES256-SHA / prime256v1 / rsaEncryption
*  subject: C=US; ST=California; L=Sunnyvale; O=Fortinet; OU=FortiGate; CN=FortiGate; emailAddress=support@fortinet.com
*  issuer: C=US; ST=California; L=Sunnyvale; O=Fortinet; OU=Certificate Authority; CN=support; emailAddress=support@fortinet.com
<html><body><script language="JavaScript">window.location="https://10.34.70.1:1003/fgtauth?01040e889483e988";</script></body></html>

Sertifikayı doğrulayan istemci ise bağlantıyı reddetti: SSL certificate problem: self-signed certificate in certificate chain. Tarayıcıdaki karşılığı, kullanıcının giriş yapmadan açtığı ilk HTTPS sitesinde bir sertifika uyarısıdır. FortiGate’in bu isteklerde sunduğu sertifika aynı ekrandaki Certificate alanında seçilir; fabrika ayarında Fortinet_Factory. Uyarıyı kaldırmanın yolu bu alana kurumun CA’sından alınmış, bilgisayarların zaten güvendiği bir sertifika koymaktır; değerlendirme lisansı sertifika içe aktarmadığı için bunu da ölçemedim.

Giriş sayfasının bu sürtünmesini tamamen kaldıran yol, kimliği kullanıcının Windows oturumundan almaktır. FortiGate’te bunun adı FSSO’dur ve User & Authentication → Single Sign-On ekranında kurulur; lab’da Windows oturumu açan bir istemci FortiGate’in arkasında olmadığı için bu yazıya almadım.

FortiGate Kimlik Doğrulamasını Doğrulamak: Oturum ve Log

Muhasebe istemcisinin tarayıcısı giriş sayfasını açtı. Sayfanın başlığı Firewall Authentication:

muhasebe.deneme ile giriş yaptım. FortiGate 303 See Other ile beni ilk istediğim adrese geri gönderdi:

HTTP/1.1 303 See Other
Location: http://203.0.113.66/

Girişin geçtiğini üç yerden doğruladım. Kimliği doğrulanmış kullanıcılar listesi (diagnose firewall auth list) IP adresiyle kullanıcıyı eşliyor:

10.34.70.10, muhasebe.deneme
	src_mac: 00:0c:29:a0:71:ae
	type: fw, id: 0, duration: 33, idled: 0
	expire: 300, allow-idle: 300
	server: dc01-ldap
	packets: in 10 out 10, bytes: in 946 out 686
	group_id: 3
	group_name: muhasebe-internet

allow-idle: 300, kullanıcının 300 saniye boyunca trafiği olmazsa listeden düşeceğini söylüyor. Authentication Settings ekranındaki Authentication timeout fabrika ayarında 5 dakika ve türü boşta kalma süresi; süre dolunca kullanıcı giriş sayfasını yeniden görür. NIST’in 4.4 bölümündeki denge burada: süre kısaldıkça masasından kalkan kullanıcının açık bıraktığı kimlik daha çabuk düşer, ama kullanıcı giriş sayfasını daha sık görür.

Oturum tablosu bağlantının artık kural 12’den geçtiğini ve kullanıcının adını taşıdığını gösteriyor:

session info: proto=6 proto_state=05 duration=0 expire=0 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
...
user=muhasebe.deneme auth_server=dc01-ldap state=log may_dirty authed f00 acct-ext 
...
misc=0 policy_id=12 pol_uuid_idx=14746 auth_info=3 chk_client_info=0 vd=0

Bu satırı kimliksiz denemedeki policy_id=5 ... auth_info=0 satırıyla yan yana okuyun: aynı istemci, aynı hedef, giriş öncesi ve sonrası iki ayrı kural.

Trafik logu sonucu arayüzde gösteriyor (Log & Report → Forward Traffic):

Log ölçümün sırasını aşağıdan yukarı anlatıyor. En alttaki satır auth-on-demand değişmeden önceki kimliksiz geçiş: kural 5. Üstündeki kullanıcısız Deny: policy violation satırları giriş sayfasına yönlendirilen isteklerdir; FortiGate araya girdiği isteği kuralın reddi olarak logluyor. İlk bakışta engellenen trafik gibi görünür, ama giriş sayfası gösterilen her istek böyle bir satır bırakır. En üstteki satırların Source sütunu muhasebe.deneme (10.34.70.10) diyor.

Örnekteki sınır kapısında tutanağa artık yalnız plaka değil sürücünün adı da yazılıyor. Bir olayın ardından “bu IP kimdi” diye sormak yerine logda adı okursunuz.

Aynı eşleşme 5651 kaydında da işe yarar. Kurumdan çıkan bir trafik yüzünden bütün kurum zan altında kaldığında, bağlantıyı kimin açtığını bulmak için IP adresini DHCP kayıtlarında bir MAC adresine, MAC adresini bir bilgisayara, bilgisayarı da bir kullanıcıya bağlamak gerekir. Trafik logunda kullanıcı adı varsa bu zincir kısalır: satır, bağlantıyı açan hesabı doğrudan söyler.

5651’in istediği iç IP ve NAT kaydı yine tutulur, kullanıcı adı onun yerine geçmez, yanına eklenir. Adın da bir sınırı var: logdaki ad o anda giriş yapmış hesaptır, parolasını paylaşan bir çalışanın hesabıyla başkası da çıkmış olabilir.

FortiGate AD Sorun Giderme: Parola Doğru, Giriş Başarısız

Kimlik doğrulaması çalışmadığında FortiGate’in olay logu nerede durduğunu söyler, ama bir satırı ilk bakışta ters okunur.

Bunu görmek için gruptaki eşlemeyi geçici olarak kullanıcının üyesi olmadığı bir AD grubuna (Domain Admins) çevirdim ve aynı kullanıcıyla doğru parolayla giriş denedim. Giriş sayfası Authentication Failed dedi. Olay logunun kullanıcı kayıtlarında (Log & Report → Events → User Events; komut satırında execute log filter category 1, execute log filter field subtype user, execute log display) bu deneme ve eşleme geri alındıktan sonraki giriş yan yana:

2: date=2026-10-02 time=03:06:51 ... logdesc="Authentication success" srcip=10.34.70.10 dstip=10.34.70.1 policyid=12 interface="muhasebe" user="muhasebe.deneme" group="muhasebe-internet" authproto="HTTP(10.34.70.10)" action="authentication" status="success" reason="N/A" msg="User muhasebe.deneme succeeded in authentication"
3: date=2026-10-02 time=03:06:45 ... logdesc="Authentication failed" srcip=10.34.70.10 dstip=10.34.70.1 policyid=12 interface="muhasebe" user="muhasebe.deneme" group="N/A" authproto="HTTP(10.34.70.10)" action="authentication" status="failure" reason="success" msg="User muhasebe.deneme failed in authentication"

Başarısız satırda status="failure" ile reason="success" yan yana duruyor ve group alanı N/A. Çelişki gibi okunur; benim okumam şu: parola doğrulandı, grup eşleşmedi. Eşlemeyi geri aldığımda aynı parolayla giriş altı saniye sonra geçti. Böyle bir satırda kullanıcının parolasını sıfırlamak işe yaramaz; bakılacak yer kullanıcının AD’deki grup üyeliği ve FortiGate grubundaki eşlemedir.

Teşhiste işe yarayan iki ayrıntı daha var:

1. Girişi adım adım izlemek. diagnose debug application fnbamd -1 ve diagnose debug enable ile kimlik doğrulama sürecinin çıktısı açılır; iş bitince diagnose debug disable ve diagnose debug reset. Arayüzden yapılan girişte sıra şöyleydi: kullanıcı araması, servis hesabıyla bağlanma, kullanıcının kendi parolasıyla bağlanma, memberOf okuma ve sonuç.

   FortiGate CLI Çıktısı

   [1717] fnbamd_ldap_init-search filter is: sAMAccountName=muhasebe.deneme
   ...
   [363] __ldap_build_bind_req-Binding to 'svc-fortigate-ldap@ad.sistemkusu.com'
   ...
   [363] __ldap_build_bind_req-Binding to 'CN=muhasebe.deneme,OU=Kullanicilar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sistemkusu,DC=com'
   ...
   [542] __retrieve_group_values-val[0]='CN=USER_GM_MUH_INTERNET,OU=Gruplar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sistemkusu,DC=com'
   ...
   [2678] fnbamd_ldap_result-Result for ldap svr dc01.ad.sistemkusu.com(dc01-ldap) is SUCCESS

   Sorun hangi satırda kesiliyorsa orada aranır: servis hesabının bağlanması kesiliyorsa hesap ya da parola, kullanıcı araması boş dönüyorsa Distinguished Name ya da Common Name Identifier, memberOf beklenen grubu getirmiyorsa AD’deki üyelik.

2. Ayarı kaydedin, sonra birkaç saniye bekleyin. Kaydedilmemiş formun testi yukarıda gördüğümüz gibi başka bir ayarı deniyor. Kaydedildikten hemen sonraki test de yanıltabilir: önceki ölçümümde LDAP kaydında portu değiştirip hemen diagnose test authserver çalıştırdığımda iki kez önceki ayarın sonucunu aldım. Birkaç saniye sonra tekrarlanan test yeni ayarı yansıttı.

Doğrulama: FortiGate Active Directory Entegrasyonu Doğru Kuruldu mu?

1. LDAP kaydı FQDN ile, LDAPS ya da STARTTLS’te; Test Connectivity kaydedilmiş ayarla Successful.
2. Servis hesabı hiçbir ayrıcalıklı grupta değil; açıklamasında sahibi yazıyor.
3. Test User Credentials ya da diagnose test authserver kullanıcının kurala bağlı grubunu listeliyor.
4. Kural sırası: grup kuralı aynı kaynağı kapsayan genel kuralın üstünde.
5. Kimliksiz istek giriş sayfasına yönleniyor, genel kurala düşmüyor (auth-on-demand always).
6. Oturum ve log: giriş sonrası oturumda user= alanı ve grup kuralının numarası, trafik logunda kullanıcının adı var.

Sonuç: FortiGate Kimliği Sormaz, Domain Controller’a Sordurur

FortiGate kullanıcıların listesini kendisi tutmaz; her girişte domain controller’a sorar ve kararı o cevaba göre verir. Bu yüzden entegrasyon üç ayağa dayanır:

1. Soru şifreli bir kanaldan gider. LDAPS ya da STARTTLS. 389’da parola düz metin gider; yeni bir Windows Server 2025 domain controller’ı da bunu reddeder. Testi ayarı kaydettikten sonra yapın: kaydedilmemiş form başka bir ayarı denedi ve yanıltıcı bir “Can’t contact” yazdı.
2. Doğru grup kurala bağlanır. Üyelik AD’de tutulur, FortiGate her girişte okur; bağlanan servis hesabı ayrıcalıksızdır.
3. Kimliği bilinmeyen trafik başka kurala kaçmaz. Fabrika ayarındaki auth-on-demand implicitly, grup kuralının altındaki genel kuralı açık kapı yapar.

Lab’daki son hâl: dc01-ldap LDAPS’te ve auth-on-demand always açık. Muhasebe ağı başka yazıların ölçümlerinde de kullanıldığı için grup kuralı ve muhasebe-internet grubu ölçüm bitince kaldırıldı.

Örnekteki sınır kapısında kulübe sürücüyü kayıt dairesine açık bir telsizden sormaz ve listede olmayan sürücüyü yan şeritten geçirmez; tutanaktaki ad ancak o zaman bir şey anlatır. Sıradaki adım rehberin 7. adımı, RADIUS ile yönetici girişi; FortiGate orada aynı soruyu kendi yöneticileri için sorduruyor.

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