מדוע בקשת פרוקסי אחת מבקשת סיסמה בעוד Kerberos עובד לאחרות
מצאו את כלל המדיניות שמקצה לבקשה אחת תחום אימות פרוקסי בלתי צפוי, גם כשבקשות אחרות משתמשות ב-Kerberos בהצלחה.
מספר בקשות משתמשות ב-Kerberos בהצלחה דרך פרוקסי החברה. בקשה אחת מייצרת בקשת סיסמה. לפני החלפת keytab, בדקו איזו מדיניות אימות בחרה אותה בקשה.
שער יכול לבחור תחום וסכימות נתמכות באמצעות מדיניות. שתי עסקאות שמגיעות לאותו פרוקסי מאותו דפדפן אינן חייבות לקבל את אותן דרישות אימות.
שקלו את העקבות ההיפותטיות האלה:
| עסקה | המדיניות הראשונה שמתאימה | אימות זמין |
|---|---|---|
| מסמך ראשי | כלל גלישה מנוהל | Negotiate |
| סקריפט ממארח אחר | חריגת יעד קודמת | Basic או NTLM |
החלפה מוצלחת ראשונה מראה שנתיב נבחר אחד עובד. היא אינה מראה שהעסקה השנייה הגיעה לנתיב הזה. ייתכן שאישור נכון בעוד הכלל שבוחר את מנגנון האימות שלו שגוי.
בדקו את הכלל שנבחר ואת סדרו
קשרו בין היעד והזמן של הבקשה שעוררה אתגר לבין עקבות המדיניות של השער. זהו את התחום, בחירות הסכימה ומצב האימות שהכלל הראשון החל מייצר. השוו ערכים אלה לבקשה מוצלחת מאותו לקוח.
מדיניות המבוססת על זהות המשויכת ל-IP יכולה גם להתנהג אחרת מזו שדורשת אימות על החיבור. אל תניחו שהיעדר לחיצת יד חדשה פירושו שנבחר אותו תחום.
אם המשאב נפל לחריגה לא מכוונת, תקנו את הכלל או את היקפו ובדקו את העקבות שנוצרו. הרחבת שיטות אימות מותרות בכל מקום עלולה להסתיר את אי-ההתאמה, אך משנה את התנהגות הגישה לתעבורה לא קשורה.
אם נבחר התחום המיועד וההחלפה הצפויה נכשלת, המשיכו לראיות החשבון וה-Kerberos. שם הופכים רלוונטיים הכרטיס, שם השירות או אבחון ה-backend.