אימות LDAP של OpenVPN עובד אבל בדיקת הקבוצה נכשלת: היכן לחפש

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

פרטי הכניסה עוברים, המנהרה מתחילה לעלות, ואז ההפעלה נכשלת בהודעה על הקבוצה ולא על הסיסמה. השילוב הזה ממקם את התקלה במחצית השנייה של עבודת התוסף LDAP: הכריכה ובדיקת הסיסמה הצליחו, והחלטת החברות שאחריה לא. שתי המחציות קוראות מאותו בלוק תצורה, ולכן תיקון במקום אחד יכול להשאיר את השנייה ללא שינוי. התחילו בשורת היומן שמציינת את השלב, ולא בחשבון שאתם בודקים איתו במקרה.

התייחסו לדחייה כתשובה של הרשאה

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

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

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

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

בצורה הזו המסנן מחליט הכול, ולכן RequireGroup חייב להיות false, אחרת התוסף יוצא לחפש אובייקט קבוצה שהמסנן מעולם לא הזכיר. התכונה במסנן חייבת להתקיים על אובייקט המשתמש ולהיות מלאה, וזה אינו מובטח ברגע שהקבוצות מקוננות.

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

הנקודה העיוורת משותפת: השוואת חברות פשוטה אינה מרחיבה קבוצות מקוננות, ולכן חשבון שהגישה שלו מגיעה דרך קבוצת אב נכשל בעוד הקונסולה עדיין מציגה את החברות. Active Directory חושף את member על הקבוצה, סכימות אחרות משתמשות ב-uniqueMember, והצבעה על התכונה הלא נכונה מחזירה תוצאה ריקה במקום שגיאה.

בחרו נקודת קצה שמחזיקה את אובייקט הקבוצה

כתובת ה-URL קובעת באיזו ספרייה התוסף שואל, ובקר דומיין בפורט 389 עונה רק עבור הקשר השמות של עצמו. קטלוג גלובלי בפורט 3268 עונה עבור היער כולו, לקריאה בלבד ועם קבוצת תכונות חלקית. כשהחשבונות יושבים בדומיין אחד וקבוצת ה-VPN באחר, שאילתה של דומיין אחד יכולה למצוא את המשתמש ועדיין להחמיץ את החברות. זה המקרה שבו העברת כתובת ה-URL לפורט הקטלוג פותרת את הדחייה, וזה גם המקרה שבו אנשים מכלילים יותר מדי.

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

שמרו את מצב החשבון והיקף החיפוש בשדות שלהם

דגל ההשבתה שייך למסנן, לא לבדיקת הקבוצה. ב-Active Directory זה הביט השני של userAccountControl, ובלי התנאי הזה חשבון מושבת עם סיסמה תקפה מאמת את עצמו ואז נכשל בשלב הקבוצה, מה שנראה כמו תקלת הרשאה. היקף החיפוש שייך ל-DN הבסיסי, כי התחלה משורש הדומיין איטית יותר ויכולה להתאים לאובייקטים מחוץ ליחידה הארגונית שרציתם לכסות.

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

הוכיחו את התוצאה עם שלושה חשבונות

הריצו את התצורה מול שלוש זהויות: חבר מורשה, חשבון תקף מחוץ לקבוצה וחשבון שהושבת. אם כל השלושה נדחים, הכריכה או שאילתת הקבוצה שבורות; אם כל השלושה מתקבלים, לא מוחל שום תנאי קבוצה. תוצאה מעורבת היא התוצאה היחידה שמוכיחה שהתצורה מבדילה בין המקרים החשובים לכם.

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

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

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

מאמרים קשורים