
Use any authentication protocol ב-Constrained Delegation נועדה למקרה שהמשתמש לא הזדהה ב-Kerberos מול שרת A. ההרצאה מסבירה איזה שלב נוסף נוסף כדי שזה יעבוד.הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על Constrained Delegation עם כל פרוטוקול» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בהרצאה הזו אנחנו נדבר על Constraint Delegation, על הצלת סמכות על שרת, נניח Web, להזדהות בשמם של כל היוזרים בארגון שלי מול שרתים פנימיים, אבל כאן ב-Constraint Delegation אני יכול להגביל מול מי הוא רשאי להזדהות.
האופציה הזאת שנקראת Use Any Authentication Protocol, לא Care בראשון לי, אלא בכל פרוטוקול, היא למעשה באה לחסוך את השלב הראשון הזה.
במקום השלב הראשון הזה, תסתכלו מה קורה, סרוויס A שזיהה את המשתמש לא יודע איך, איך שהוא עשה לו בדיקה מבחינתו של קרברוס היוזר עבר עימות באיזשהו פרוטוקול אחר וסרוויס A מבקש בשמו של יוזר את הסרוויס טיקט לעצמו, אתם רואים זה נקרא סלף, למה הוא צריך סרוויס טיקט לעצמו?
כדי להשתמש בו כהוכחה, זוכרים את השלב הזה של ההוכחה שהסרוויס A צריך לתת הוכחה לדומיין קונטרולר שהיוזר ביקש ממנו את השירות הפונקציה של פרוקסי מבקשת הוכחה אז גם כאן הפרוקסי מופעל עם ההוכחה הפונקציה של פרוקסי מופעלת וכהוכחה צריך לצרף את הסרוויס טיקט אבל את הסרוויס טיקט קיבלנו בשלב קודם רק במקום שהיוזר יביא לי את הסרוויס טיקט מולי
מול סרוויס A היוזר לא הביא לי את הסרוויס טיקט אז אני כסרוויס A מבקש מדומיין קונטרולר תביא לי סרוויס טיקט לעצמי ואז בסרוויס טיקט לעצמי אני אשתמש כדי לבקש סרוויס טיקט ליעד למעשה הוסיפו פה שלב של בקשת סרוויס טיקט לעצמך מנקודת מבטו של A הוא מבקש סרוויס טיקט לעצמו שזה נשמע טיפשי והסוד הגדול שהוא לוקח
את ה-TGS הזה ומשתמש בו כהוכחה לשלב הבא אז לסיכום כשאופציה הזאת מופעלת Any Authentication פרוטוקול במקום שהסרוויס טיקט יגיע מיוזר דרך קרברוס אני מנפיק אותו לעצמי מול דומיין קונטרולר