הסבר על Kerberos
קרברוס או סרברוס (Cerberus) ע"פ המיתולוגיה היוונית הוא כלב הציד של אדס אל השאול, מתואר ככלב עם 3 ראשים והוא שומר על הכניסה לממלכתו של אדס.
אבל Kerberos שאני אכתוב עליו שייך למייקרוסופט והוא פרוטוקול אבטחה לביצוע "אימות" Authentication, קרברוס נמצא בגרסה 5 ורשום כ- KerberosV5, תיאור הכלב ציד עם ה 3 ראשים מושווה ל KDC ה Key Distribution Center ל User המשתמש עצמו ול Server.
הKDC מותקן ביחד עם Active Directory והוא מבצע 2 פעולות עיקריות, ביצוע אימות AS שהוא Authentication Service ושירות ה TGS ה Ticket Granted Service.
- כאשר מתחבר למחשב, הוא מספק שם משתמש וסיסמא ולמעשה מבצע את זה מול ה AS של ה KDC
המשתמש בבקשת הזיהוי שולח לKDC הנמצא ב Active Directory : שם משתמש UPN (תצורת אימייל – user@domain.com) שם הדומיין ו secret key שבנוי מה PasswordHash של המשתמש
כעת ה KDC יוצר קשר עם AD בשביל לוודא שהסיסמא והפרטים נכונים וגם אילו קבוצות חבר המשתמש - לאחר ההתחברות המשתמש מקבל TGT קיצור של Ticket Granted Ticket אשר מוצפן על ידי הסיסמא של המשתמש krbtgt כך למעשה המשתמש מקבל את האפשרות לקבל כרטיסים Ticket To Get Tickets, ה TGT שהמשתמש מקבל תקף ל 10 שעות (ע"פ מדיניות ה Policy ב Group Policy) – ה TGT מאוחסן בזיכרון ה RAM לרגע בו המשתמש שוב יצטרך אותוה TGT יכיל בתוכו:
* Session Key המוצפן על ידי המפתח הפרטי של ה KDC ורק ה KDC יכול לפתוח אותו
* פרטים על המשתמש, הרשאות, אילו קבוצות הוא חבר.
כאשר המשתמש מזדהה מול ה Authentication Service של ה KDC הוא משתמש בחותמת זמן (מה השעה כעת) והיא מוצפנת על ידי הסיסמא של המשתמש (יותר נכון ה Hash שלו) ואז ה KDC בודק את חתימת הזמן (ע"י הPassowrd Hash של המשתמש, שקיים ב Active Directory) ה KDC יודע איזה בקשה חדשה ואיזה ישנה \ קודמת את ההצפנה של חותמת הזמן אפשר לבטל על ידי הפיצ'ר ב Active Directory שנקרא Do not require kerberos preauthentication
כאשר ה KDC מאשר את בקשה של המשתמש לTGT הוא מגיב לו ב AS Reply ומכיל בתוכו TGT מוצפן עם מפתח שרק ה KDC שירות (ה TGS שלו) יכול לפתוח.
ו session key נוסף נוצר ומוצפן על ידי הסיסמא של המשתמש ( Hash Passwrod) כיוון שה TGT מוצפן ואין למשתמש את הסיסמא לפתוח אותה הוא חייב להציג את ה TGT ל TGS ה( Ticket Granting Service) בלי לדעת מה הוא מכיל.
- כאשר משתמש רוצה לגשת לשירות מסוים הוא צריך לבקש Service Ticket וכיוון שיש לו TGT הוא רק צריך לצרף לבקשה את הדברים הבאים:
*כתובת השרת \ השירות
*הTGT של המשתמש עצמו
* מזהה התחברות – מוצפן על ידי ה User Session Key
את כל זה המשתמש מבצע מול ה KDC ולא מול השרת - כעת הTGS שב KDC מפענח את ההצפנה של מזהה התחברות של המשתמש על ידי כך שיש לKDC את הסיסמא של המשתמש, על ידי כך הוא מאמת שהכל תקין.
- לאחר שהוא אימת אותו הוא מייצר למשתמש
* "כרטיס שירות" Service Ticket
* Session Key אשר מוצפן על ידי הסיסמא ( Password Hash) של השרת \ השירות אותו המשתמש רוצה
* וSession Key שמוצפן על ידי הסיסמא של המשתמש עצמו - המשתמש מעביר לשרת את ה TGT של השרת שקיבל מה TGS והשרת פותח את ה TGT הזה על ידי ה Password Hash שלו, שכן ה TGS כשנתן את הכרטיס למשתמש הוא הצפין חלק מהכרטיס על ידי ה Password Hash של אותו שרת.
- כאשר השרת מקבל את "הכרטיס" והוא מצליח לפתוח את חתימת הזמן ( שהוצפנה על ידי ה TGS ע"י הסיסמא של השרת עצמו) הוא מבין שה"גורם" שהביא לו את ה TGT מהימן, וכאשר הוא סומך על המשתמש , המשתמש גם סומך עליו שכן הוא הצליח לפתוח את ההצפנה הזו.
- בתצורה זו השרת אינו צריך לפנות ל TGS אשר ב KDC כיוון שהTGS משתמש בסיסמא של השרת ששמורה ב Active Directory והשרת עצמו יודע את הסיסמא שלו.
כעת אחרי שהבנו את הקטע היותר טכני, העבור להסבר פשוט יותר:
המשתמש מיוצג כ Client
המשתמש שולח Authenticator המכיל בתוכו את כל הפרטים שלו, זמן ושעה
*לכן אסור שיהיה הבדלי זמן של יותר מחמש דקות, כיוון שקרברוס מונע משימוש חוזר של אותו Authenticator בזמן אחר
המשתמש מצפין את ה Authenticator על ידי ה Password Hash שלו ויוצר Secret Key, אותו הוא שולח ל Domain Controller
*ה Authenticator מסומן כתיקייה אדומה שכן המפתח האדום של המשתמש יכול לפתוח אותו
כעת המשתמש שולח את ה Authenticator בשביל לקבל TGT, ה KDC שיודע את סיסמתו של המשתמש פותח את ה Authenticator ובגלל שהמפתח (הסיסמא ששמורה ל KDC ) פתח את ה Authenticator הKDC יודע שהמשתמש הזה לגטימי
כעת ה TGS לוקח את ה TGT ומצפין אותו עם הסיסמא שלו ( של המשתמש krbtgt)
כעת המשתמש מבסוט ויש לו TGT, פתאום המשתמש רוצה לגשת לשרת (נמצא בצד שמאל)
המשתמש שולח את ה TGT שלו ל KDC, ה KDC לוקח את המפתח שלו ובודק שבאמת זה המשתמש, כך לא צריך ה KDC לבדוק בAD האם המשתמש באמת זה הוא.
הוא פשוט בודק שהמפתח שלו תואם את ה TGT
כאשר הוא ווידא שהמשתמש זה המשתמש, הוא צריך לתת לו Service Ticket לשרת
הKDC לוקח את הכרטיס ומצפין אותו עם הסיסמא של השרת, שכן יש ל KDC את הסיסמא לשרת
המשתמש כרגע מחזיק ב Service Ticket של השרת וגם TGT
כעת המשתמש רוצה לגשת אל השרת, הוא שולח אליו את ה Service Ticket, השרת על מנת לוודא שזה באמת המשתמש, משתמש בסיסמה שלו על מנת לנסות לפתוח את ה Service Ticket אם הצליח, הרי שזה באמת משתמש לגטימי ואם לא, אז המשתמש הזה אינו לגיטימי
מקווה שהבנתם !