הגדרת אינטגרציה של Bitrix24 עם LDAP/Active Directory

אינטגרציה של Bitrix24 עם Active Directory: היכן הכניסה נשברת

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

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

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

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

כפילויות של אותו אדם — דומיין, פורטל, חשבון ב-1C — שוברות גם את הדיווח וגם את הרשאות הגישה: לא ברור מי בדיוק פתח את המסמך.

אינטגרציה של Bitrix24 עם Active Directory מבטלת את יצירת העובדים ידנית: הפורטל קורא את עץ הספרייה, מושך שם מלא, תפקיד, יחידה ארגונית ומנהל, וחסימת הרשומה בדומיין סוגרת אוטומטית את הגישה לפורטל.

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

מה נותנת כניסה אחודה דרך ספריית הארגון

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

הסיסמה ב-Bitrix24 לא נשמרת: הכניסה מתבצעת עם חשבון הדומיין, וההרשאות עוברות בירושה מ-Active Directory, ולא מוקצות ידנית לכל עובד חדש.

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

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

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

אפשרויות סנכרון חשבונות: השוואה

הספרייה נשארת מקור האמת: חשבונות, יחידות ארגוניות, תפקידים ומנהלים חיים ב-Active Directory, ו-Bitrix24 מקבל את ההשתקפות שלהם עבור הפורטל, הצ'אטים והתהליכים הפנימיים.

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

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

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

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

שלבי האינטגרציה של Bitrix24 עם Active Directory: ביקורת והעברה

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

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

2. סכימת התאמה בין קבוצות לתפקידים. מתאמים טבלה «קבוצה בספרייה → תפקיד ב-Bitrix24», כולל קבוצות מקוננות, ומקבעים אילו הרשאות נותן כל צימוד ומה קורה כשעובד עובר למחלקה אחרת.

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

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

5. ניפוי מקרי קצה. כפילויות, זהות בשמות משתמש, עובד בכמה קבוצות בו-זמנית, היעדרות ממושכת — כל מקרה מקבל כלל כתוב ולא תיקון ידני.

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

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

מדיניות גישה, סכימות ותיעוד בתוצרים

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

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

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

מקרה בוחן: איך הפסיקו ליצור עובדים ידנית

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

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

מה שינו

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

תוצאות לפני ואחרי

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

פניות שגרתיות כמו "צרו, הוסיפו, הסירו" יצאו מתור התמיכה, והצוות המבוזר כבר לא ממתין למנהל באזור זמן אחר.

במה שונה סנכרון הספרייה מכניסה אחודה?

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

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

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

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

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

ספקות טכניים נפוצים לפני חיבור הספרייה

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

אנחנו צריכים סנכרון רק לחלק מהיחידות הארגוניות — זה אפשרי?

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

מה יקרה אם הספרייה תהפוך ללא זמינה?

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

מה עושים עם קבלנים חיצוניים?

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

נדבר על המשימה ונחזור עם הערכה ותוכנית

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

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

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

תארו את זה במכתב או שנדון בשיחת וידאו — נחזור עם הערכה, תוכנית עבודה ותחומי אחריות.