בדיקת קישוריות של LDAP מאובטח

התכונה הזו נתמכת במהדורות הבאות: Frontline Standard ו-Frontline Plus,‏ Business Plus,‏ Enterprise Standard ו-Enterprise Plus,‏ Education Fundamentals,‏ Education Standard ו-Education Plus,‏ Enterprise Essentials Plus. השוואה בין מהדורות

לפני שמנסים לחבר את לקוח ה-LDAP לשירות LDAP מאובטח, אפשר לבצע בדיקת קישוריות מהירה באמצעות כלים פשוטים כמו ldapsearch,‏ ADSI או ldp.exe. אפשר להשתמש בכלים האלה גם לפתרון בעיות אם נתקלים בשגיאות בניסיון לחבר את לקוח ה-LDAP לשירות.

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

המאמר הזה עוסק בנושאים הבאים:

הערה: אם תצטרכו לפנות אל צוות התמיכה של Google Workspace או אל צוות התמיכה של Cloud Identity Premium במהלך התהליך הזה, הקפידו לשמור את הפלט של הפקודות. לפני שמשתפים את הפלט עם צוות התמיכה, חשוב להסיר ממנו פרטים אישיים מזהים.

אימות הקישוריות והרצת שאילתת LDAP

אחרי שמגדירים את שירות LDAP מאובטח במסוף Google Admin, אפשר להשתמש באחד משלושת הכלים הפשוטים האלה כדי לאמת את הקישוריות ל-LDAP מאובטח: ldapsearch,‏ ADSI או ldp.exe. פרטים והוראות מופיעים בקטעים הבאים.

ldapsearch

משתמשים בכלי ldapsearch משורת הפקודה כדי ליצור שאילתת LDAP בסיסית. תוצאה מוצלחת של שאילתת LDAP מציינת שלקוח ה-LDAP, סשן ה-TLS הבסיסי וחיבור ה-TCP פועלים כמצופה.

כדי לבדוק את הקישוריות באמצעות ldapsearch:

  1. יוצרים הגדרת LDAP ומורידים את האישור לפי ההוראות במאמר הוספה של לקוחות LDAP.

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

  2. מריצים שאילתת LDAP. בדוגמה הזו מתבצעת שאילתה לגבי משתמש מסוים (פרטים נוספים זמינים במאמר בנושא OpenLDAP ldapsearch).

    LDAPTLS_CERT={crt_file} LDAPTLS_KEY={key_file} ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} '(mail={user_email})'

    מחליפים את ה-placeholders באופן הבא:

    • {crt_file} השם של קובץ ה-‎ .crt
    • {key_file}: שם הקובץ של קובץ ה-‎ .key
    • {domain} כל חלק בשם הדומיין, לדוגמה: example.com יהפוך ל-dc=example,dc=com
    • {user_email} כתובת האימייל הראשית של משתמש בדומיין.

הערות לגבי השימוש ב-ldapsearch

  • אם לא מציינים ערך של BindDN, הפקודה ldapsearch משתמשת במפתח ובאישור כדי לאשר את החיפוש.
  • אם הערך של BindDN הוא שם משתמש ב-LDAP שנוצר במסוף Admin, הפקודה ldapsearch תשתמש בהרשאות של לקוח ה-LDAP כפי שהוגדרו במסוף Admin.

    ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {ldap_access_credentials_username} -W '(mail={user_email})

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

    ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {workspace_username@domain} -W '(mail={user_email})'

שימוש ב-ldapsearch עם stunnel

אם הפריסה מחייבת שימוש ב-stunnel, צריך לפעול לפי השלבים הבאים:

  1. במסוף Admin, יוצרים פרטי גישה כדי לקבל את שם המשתמש והסיסמה שנדרשים ל-ldapsearch.
  2. משתמשים בפקודה הבאה:

    ldapsearch -x -D "{username}" -w {password} -H ldap://{stunnel_host}:{stunnel_port} -b dc={domain},dc={domain} '(mail={user_email})'

    מחליפים את ה-placeholders באופן הבא:

    • {username} שם המשתמש מפרטי הכניסה שנוצרו במסוף Admin
    • {password} סיסמה מפרטי הכניסה שנוצרו במסוף Admin
    • {stunnel_host} : כתובת ה-IP או שם המארח של המכונה שבה פועל stunnel ברשת שלכם.
    • {stunnel_port} : היציאה שבה stunnel פועל. צריך לבדוק את ההגדרה של stunnel
    • {user_email} כתובת האימייל הראשית של משתמש בדומיין

תרחיש מוצלח של הפקודה ldapsearch

פלט מוצלח של הפקודה ldapsearch יציג את המשתמש עם כתובת האימייל (כפי שצוין כשיוצרים את לקוח ה-LDAP) בפורמט LDIF.

לדוגמה:

# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
objectClass: dcObject
dc: example

# admin-group, Groups, example.com
dn: cn=admin-group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
objectClass: posixGroup
cn: admin-group
displayName: admin-group
description:
gidNumber: 12345
member: uid=admin,ou=Users,dc=example,dc=com
memberUid: admin
googleAdminCreated: FALSE


# example-user, Users, example.com
dn: uid=example-user,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: example-user
googleUid: example-user
posixUid: example-user
cn: example-user
cn: FirstName LastName
sn: FirstName
displayName: FirstName LastName
givenName: FirstName
mail: example-user@example.com
uidNumber: 12345
gidNumber: 12345
homeDirectory: /home/example-user
loginShell: /bin/bash
gecos:

שגיאות אפשריות

  • הלקוח ו/או הספרייה של OpenLDAP עוברים קומפילציה ללא תמיכה ב-SNI

    ‫SNI (Server Name Indication) נדרש לתמיכה על ידי לקוח ה-LDAP (OpenLDAP במקרה הזה). אם SNI לא זמין, יכול להיות שתופיע שגיאה דומה לזו:

    SASL/EXTERNAL authentication started

    ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
    additional info: SASL(-4): no mechanism available:

    המלצה:
    • אם אתם משתמשים ב-MacOS, ‏ SASL מופעל כברירת מחדל ואפשר לעקוף אותו באמצעות האפשרות ‎-x.
    • מוסיפים את האפשרות -d5 ל-ldapsearch ובודקים את הפלט בשורה הבאה:

      TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
  • הפקודה ldapsearch מחזירה סטטוס 0 (הצלחה) אבל לא מוצגים משתמשים

    הגדרת האפשרות ldapsearch‏ -x (שימוש באימות SASL) עם אישורי לקוח תאמת את הלקוח בהצלחה, אבל לא תציג את המשתמשים בדומיין.

    המלצה: מסירים את האפשרות -x ומנסים שוב.

ADSI Edit (Windows)

  1. פועלים לפי שלבים 1 עד 11 במאמר ldp.exe (Windows) כדי להתקין את אישורי הלקוח.
  2. עוברים אל פעולה > התחברות אל…
  3. מזינים את הגדרות החיבור הבאות:

    שם: מקלידים שם לחיבור, כמו Google LDAP.
    נקודת חיבור: 'בחירה או הקלדה של שם ייחודי או הקשר שמות'
    מזינים את שם הדומיין בפורמט DN (לדוגמה, dc=example,dc=com עבור example.com).

    מחשב: 'בחירה או הקלדה של דומיין או שרת'
    ldap.google.com

    שימוש בהצפנה מבוססת SSL: מסומן
  4. לוחצים על Advanced...‎ ומזינים את הפרטים הבאים:

    Specify credentials: (ציון פרטי כניסה): מסומן
    Username: (שם משתמש): שם המשתמש של פרטי הגישה ממסוף Admin
    Password: (סיסמה): הסיסמה של פרטי הגישה ממסוף Admin
    Port Number: (מספר יציאה): 636
    Protocol: (פרוטוקול): LDAP
    Simple bind authentication: (אימות פשוט של קישור): מסומן
  5. לוחצים על אישור ואז שוב על אישור.
  6. אם החיבור יצליח, התוכן של הספרייה ב-DN הבסיסי יוצג בחלונית השמאלית.

‫ldp.exe‏ (Windows)

  1. מתקינים את OpenSSL.
  2. ממירים את קובצי האישור והמפתח לקובץ אחד בפורמט PKCS12. בשורת הפקודה, מזינים את הפקודה הבאה:

    openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12

    מזינים סיסמה להצפנת קובץ הפלט.
  3. עוברים אל לוח הבקרה.
  4. בתיבת החיפוש, מחפשים את האפשרות 'אישור' ולוחצים על ניהול אישורים של משתמשים.
  5. עוברים אל פעולה > כל המשימות > ייבוא…
  6. בוחרים באפשרות משתמש נוכחי ולוחצים על הבא.
  7. לוחצים על עיון….
  8. בתפריט הנפתח סוג הקובץ בפינה השמאלית התחתונה של תיבת הדו-שיח, בוחרים באפשרות Personal Information Exchange (‎&ast;.pfx;‎&ast;.p12).
  9. בוחרים את הקובץ ldap-client.p12 מהשלב 2, לוחצים על פתיחה ואז על הבא.
  10. מזינים את הסיסמה משלב 2 ולוחצים על הבא.
  11. בוחרים את מאגר האישורים Personal, לוחצים על Next ואז על Finish.
  12. מריצים את Ldp.exe.
  13. עוברים אל חיבור > חיבור...
  14. מזינים את פרטי החיבור הבאים:

    שרת: ldap.google.com
    יציאה: 636
    ללא חיבור: לא מסומן
    SSL: מסומן
  15. לוחצים על אישור.
  16. עוברים אל תצוגה > עץ.
  17. מזינים את שם הדומיין הבסיסי. זה שם הדומיין שלכם בפורמט DN. (לדוגמה, dc=example,dc=com עבור example.com).
  18. לוחצים על אישור.
  19. אם החיבור יצליח, התוכן של הספרייה ב-DN הבסיסי יוצג בחלונית השמאלית.

אם צריך, מריצים בדיקת קישוריות בסיסית

אם לא הצלחתם לקבל תוצאה חיובית באימות הקישוריות והרצת שאילתת LDAP, פועלים לפי ההוראות שבקטע הזה לביצוע בדיקת קישוריות. אם הפקודה ldapsearch לא מחזירה את המשתמש הצפוי ולא מציינת בצורה ברורה שהסשן הבסיסי של TLS הצליח, צריך להשתמש בלקוח OpenSSL כדי לוודא ששכבות הרשת ש-OpenLDAP מסתמך עליהן פועלות כמצופה.

כדי לבצע בדיקות קישוריות בסיסיות:

  1. מתקינים את כלי הלקוח openssl עבור מערכת ההפעלה.

    ברוב הפצות GNU/Linux נעשה שימוש בשם החבילה openssl. פרטים על מערכות הפעלה אחרות

  2. יוצרים חיבור ידני לשירות LDAP מאובטח באמצעות לקוח openssl:

    openssl s_client -connect ldap.google.com:636
    

    כדי לוודא שהמשא ומתן על SSL הצליח, בודקים אם השורה הבאה מופיעה בסוף הפלט של openssl s_client:

    Verify return code: 0 (ok)
    

שגיאות אפשריות

לקוח או ספרייה של OpenSSL לא תומכים ב-SNI (Server Name Indication)

במהלך בדיקת הקישוריות, יכול להיות שיוחזר הפלט הבא:

Verify return code: 18 (self signed certificate)

שירות LDAP מאובטח דורש לקוח TLS שתומך בסשן TLS ומתחיל אותו באמצעות SNI (אינדיקציה של שם השרת). אם לקוח ה-TLS לא תומך ב-SNI, שרת ה-TLS‏ (ldap.google.com) מחזיר אישור בחתימה עצמית שלא יעבור את בדיקות האימות של רשות האישורים, כדי לציין שנדרש SNI.

אפשר לאשר את ההתנהגות הזו על ידי בדיקת הפלט של לקוח OpenSSL לשורה הבאה, קרוב לתחילת הפלט:

depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid

הסיבות לשגיאה הזו יכולות להיות גרסת OpenSSL שלא תומכת ב-SNI, או אפליקציה שמשתמשת בספריית OpenSSL עם SNI שמושבת באופן מפורש.

החיבור נדחה

אם הפלט הבא מוחזר – כאשר {timestamp} הוא חותמת זמן של מערכת UNIX במיקרו-שניות – חיבור ה-TCP נדחה באופן פעיל לפני שתהליך המשא ומתן של TLS יכול להתחיל:

{timestamp}:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110:
{timestamp}:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111:connect:errno=111

יכולות להיות לכך כמה סיבות:

  • חומת אש ברמת האפליקציה או ברמת המערכת במחשב המקומי
  • חומת אש באותה רשת פיזית או ברשת במעלה הזרם

כדי לבדוק את הבעיה, משתמשים ב-tcptraceroute כדי לזהות את המארח שמסרב לחיבור – לדוגמה, tcptraceroute ldap.google.com 636.