דילוג לתוכן הראשי
AD Academy
אבטחת רשת: Fortinet
בינוני16 דקותעודכן לאחרונה: נושא 9 מתוך 14

FSSO — איך חומת האש יודעת מי המשתמש ב־AD

מיפוי «משתמש ↔ IP» מתוך אירועי הכניסה של ה־DC, ומדיניות חומת אש לפי קבוצות AD.

לא הושלם

מה תלמדו כאן

  • נושאים קשורים בקורס
  • איך זה עובד
  • שני מצבי עבודה

כדאי לקרוא לפני הנושא הזה:לוגים ואבחון תקלות

חומת אש חושבת בכתובות IP, אבל מדיניות אבטחה מנוסחת במונחים של משתמשים וקבוצות : «הנהלת חשבונות רשאית, האחרים לא». (Fortinet Single Sign-On) הוא המנגנון שבעזרתו FortiGate יודע איזה משתמש יושב מאחורי איזו כתובת IP, ומחיל מדיניות לפי קבוצות AD.

המשתמש מתחבר לדומיין, ה־DC רושם אירוע 4624, ה־Collector Agent קורא את היומן ושולח ל־FortiGate מיפוי «משתמש ↔ IP». קבוצות נשלפות ב־LDAP, והמדיניות נכתבת לפי קבוצות AD. נקודות עיוורון: מחשב משותף, החלפת כתובת IP והתקנים שאינם בדומיין.

בקצרה ובפשטות

  • FSSO לא מאמת אף אחד — הוא רק לומד מי כבר נכנס לדומיין ומאיזו כתובת IP.
  • המקור הוא אירוע 4624 ביומן האבטחה של ה־DC; הקבוצות מגיעות בנפרד ב־LDAP.
  • המדיניות נכתבת בשם קבוצה («G-Finance»), לא במספרים — ולכן היא שורדת שינויי IP.
  • מחשב משותף, BYOD או כיבוי לא תקין = מיפוי לא מדויק עד ה־timeout.

דוגמה מהחייםמשתמש מדווח שאין לו גישה ל־ERP למרות שהוא בקבוצה. diagnose debug authd fsso list מראה שהכתובת שלו ממופה למשתמש הקודם שישב על אותה תחנה.

נושאים קשורים בקורס

  • Event ID 4624 — אותו אירוע כניסה שממנו ה־ בונה את המיפוי (מדריך Event IDs).
  • — HasSession: גם שם השאלה היא «מי יושב על איזו מכונה» (/course/tools/bloodhound-walkthrough).
  • Tiering — מדיניות לפי קבוצות היא הדרך לאכוף הפרדת שכבות גם ברמת הרשת.

איך זה עובד

  • המשתמש מתחבר לדומיין — כניסה רגילה עם , שום דבר חדש בצד הלקוח.
  • על ה־DC (או על שרת ייעודי) רץ שקורא את יומן האבטחה ורואה את אירוע הכניסה 4624.
  • הסוכן ממפה משתמש לכתובת IP של התחנה ושולח את המפה ל־FortiGate (TCP, ברירת מחדל פורט 8000).
  • FortiGate מחיל מדיניות לפי הקבוצה: CN=Teachers → כלל «אפשר», CN=Students → כלל «אסור».

שני מצבי עבודה

  • Event Log / Polling mode — על שרת ייעודי מתשאל את ה־DC ואוסף אירועי כניסה.
  • Kerberos-based — סוכן קל מותקן על כל DC ומאזין לאימות ; מתאים יותר לרשתות גדולות.
  • קיים גם מבוסס Accounting (לרשתות Wi-Fi) — אותו רעיון, מקור אחר למפה.

תרגול במעבדה

  • התקינו על שרת Windows בדומיין המעבדה corp.local. צרו חשבון שירות svc-fsso עם סיסמה ללא תפוגה והרשאות Event Log Readers בלבד — לא Admin.
  • ב־ הגדירו את ה־DC, סיסמת החיבור ל־FortiGate והפורט (ברירת מחדל 8000).
config user fsso-agent
    edit "FSSO-CA"
        set server "10.0.0.10"
        set password <password-from-collector-agent>
    next
end
bash

עכשיו מקשרים קבוצת FortiGate לקבוצת :

config user group
    edit "FSSO-Teachers"
        set member "FSSO-CA"
        config match
            edit 0
                set server-name "FSSO-CA"
                set group-name "CN=Teachers,OU=Groups,DC=corp,DC=local"
            next
        end
    next
end
bash

בסיום השתמשו בקבוצה במדיניות (Policy & Objects → Firewall Policy → Source: FSSO-Teachers). בדיקה: מתחנה עם משתמש מקבוצת Teachers פתחו אתר — הסשן אמור להופיע תחת Security Fabric → User & Device → .

סיכונים וזיהוי

  • חשבון ה־: פריצה אליו = יכולת לקרוא יומנים ולהשפיע על המיפוי. הרשאות מינימום, ניטור 4624 בשם החשבון הזה.
  • התעבורה בין הסוכן ל־FortiGate אינה VPN — השתמשו בסגמנט ניהול מבודד. זו תקשורת Tier 0.
  • מיפויים «מתים»: תחנה שכובתה בצורה לא תקינה משאירה זוג «משתמש ↔ IP» עד ה־timeout. קחו זאת בחשבון בכללים רגישים.

מיטיגציה

  • VLAN נפרד לניהול בין FortiGate ל־.
  • חשבון הסוכן: Event Log Readers + Deny interactive logon.
  • ביקורת קבועה: השוואת סשנים פעילים ב־ מול כניסות אמיתיות (quser / whoami בתחנות חשודות).
  • כללים רגישים (גישה לשרתי Tier 1) — לא רק לפי קבוצת אלא גם לפי טווח IP של הסגמנט.

בדוק את עצמך

מהו המקור למיפוי «משתמש ↔ IP» ב־FSSO?

אילו הרשאות מספיקות לחשבון השירות של Collector Agent?

מדוע פריצה ל־AD הופכת גם את מדיניות ה־FSSO ללא אמינה?

מתי המיפוי «משתמש ↔ IP» עלול להצביע על המשתמש הלא נכון?

העמוד הזה עזר לך?