לדלג לתוכן

אוטנטיקציה בדומיין ווינדוס מוסברת - מה קורה בדיוק בין הקלדת הסיסמה ללחיצת Enter

הקלדתם סיסמה פעם אחת בבוקר, ומשם ואילך אתם ניגשים לכל שרת ותיקייה משותפת בארגון בלי שאף אחד שואל אתכם שוב סיסמה. זה מרגיש טבעי, אבל מאחורי הקלעים קורה תהליך מתוחכם שנקרא Kerberos, ומי שמבין אותו שלב אחר שלב מבין הרבה יותר טוב גם למה AD כל כך יעיל, וגם למה הוא יעד תקיפה כל כך מבוקש.

למה בכלל צריך פרוטוקול אימות מיוחד

בעולם בלי Kerberos, כל פעם שמשתמש היה רוצה לגשת לשירות אחר ברשת - שרת קבצים, מסד נתונים, מדפסת - הוא היה צריך להזין סיסמה מחדש, ואותה סיסמה הייתה צריכה לעבור בין מכשירים שוב ושוב. Kerberos נבנה כדי לפתור בדיוק את זה - להוכיח זהות פעם אחת, ולקבל תמורת זה "כרטיסים" דיגיטליים שמשמשים הוכחת זהות זמנית לכל שירות שצריך, בלי להזין סיסמה שוב.

שלב ראשון - קבלת כרטיס ראשוני (TGT)

כשמשתמש מתחבר למחשב בדומיין, המחשב שולח בקשה לבקר התחום, בהודעה שנקראת AS-REQ (Authentication Service Request). בקר התחום מוודא את זהות המשתמש, ואם הכל תקין, משיב בהודעת AS-REP שמכילה כרטיס מיוחד שנקרא TGT - Ticket Granting Ticket. הכרטיס הזה הוא ההוכחה שהמשתמש כבר אומת בהצלחה, ותקף לזמן מוגבל, בדרך כלל עשר שעות.

הנקודה החשובה - הסיסמה עצמה לא נשלחת בשום שלב בתהליך הזה. במקום זה, חלק מהתקשורת מוצפן באמצעות ההאש של הסיסמה, כך שרק מי שבאמת יודע את הסיסמה יכול לפענח את התגובה בהצלחה.

שלב שני - בקשת כרטיס שירות (TGS)

עכשיו, כשהמשתמש רוצה לגשת לשירות מסוים, למשל שרת קבצים, המחשב לא פונה שוב לבקר התחום עם הסיסמה. הוא מציג את ה-TGT שכבר קיבל, בהודעה שנקראת TGS-REQ, ומבקש כרטיס ספציפי לשירות המבוקש. בקר התחום מאמת שה-TGT תקף, ומנפיק כרטיס שירות (Service Ticket) שמוצפן באמצעות ההאש של חשבון השירות עצמו, לא של המשתמש.

שלב שלישי - הצגת הכרטיס לשירות עצמו

עכשיו המשתמש מציג את כרטיס השירות ישירות לשרת הקבצים שהוא רוצה לגשת אליו. השרת מפענח את הכרטיס באמצעות ההאש שלו עצמו, ואם זה מצליח, הוא יודע שבקר התחום אישר את הבקשה, ומעניק גישה - בלי שום צורך לפנות בחזרה לבקר התחום כדי לוודא, וללא הזנת סיסמה נוספת מצד המשתמש.

זו בדיוק הסיבה שחוויית ה-SSO, כניסה יחידה, כל כך חלקה בסביבת Windows - כל בקשת גישה חדשה משתמשת בכרטיס שכבר קיים, לא בסיסמה שצריך להזין שוב.

NTLM - כשKerberos לא זמין

NTLM הוא פרוטוקול אימות ישן יותר, שעדיין קיים בסביבות Windows כגיבוי - למשל כשהמכשיר לא מחובר לדומיין, או כשמתחברים לפי כתובת IP ולא שם מארח. NTLM עובד לפי מנגנון challenge-response - השרת שולח "אתגר" קריפטוגרפי, והמחשב מגיב בתשובה שמבוססת על ההאש של הסיסמה. זה לא כולל את מנגנון הכרטיסים המרכזי של Kerberos, וזו בדיוק הסיבה שהוא נחשב פחות מאובטח ופגיע יותר לטכניקות כמו NTLM Relay.

למה זה חשוב להבין, לא רק לדעת שיש "אימות"

הבנה של זרימת Kerberos שלב אחר שלב היא מה שהופכת מושגים כמו Kerberoasting ו-Pass the Hash למובנים באמת, ולא רק שמות של טכניקות תקיפה. Kerberoasting, למשל, מנצל בדיוק את השלב שבו כרטיס שירות מוצפן באמצעות ההאש של חשבון השירות - וברגע שמבינים את השלב הזה, ברור למה תוקף שמקבל כרטיס כזה יכול לנסות לפצח אותו אופליין.

איך מתרגלים את זה בפועל

הדרך הכי טובה להפנים את זרימת Kerberos היא לפתוח כלי כמו Wireshark מול סביבת דומיין אמיתית, ולראות בעיניים את הודעות AS-REQ, AS-REP, TGS-REQ ו-TGS-REP עוברות ברשת, שלב אחר שלב, בדיוק כמו שתיארנו כאן.

קורס הרשתות המלא נמצא כאן, חינם ובעברית, כולל הבנה מעמיקה של אימות ברשתות ארגוניות.

יש לכם שאלה על זרימת Kerberos או NTLM? שאלו בדיסקורד.

הצטרפו לקהילה בדיסקורד

לסיכום

אימות בדומיין ווינדוס בנוי סביב רעיון פשוט אך אלגנטי - להוכיח זהות פעם אחת ולקבל כרטיסים זמניים במקום להזין סיסמה שוב ושוב. הבנה של השלבים המדויקים בין AS-REQ ל-TGS-REP היא לא רק ידע תיאורטי, היא הבסיס להבין גם למה AD כל כך נוח לשימוש, וגם למה הוא נשאר יעד תקיפה מרכזי.