Samba 4 בתפקיד בקר דומיין: פריסת AD על Linux

Samba AD DC: מה נשבר בדומיין ללא בקר דומיין משלו

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

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

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

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

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

מה נותן דומיין על Linux: כניסה אחידה, הרשאות ועמידות בתקלות

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

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

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

אפשרויות פריסה: שרת נפרד, Samba או דומיין בענן

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

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

שלבי היישום: מביקורת רשת ועד מסירה לתמיכה

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

1. ביקורת תשתית. אוספים את מפת הרשת, רשימת שרתים ושירותים, אזורי DNS קיימים, חשבונות ודרישות השירותים לאימות. בפלט — רשימת מגבלות וצמתים שאסור לגעת בהם.
2. סכמת הדומיין. מגדירים את שם הדומיין, מספר הבקרים, טופולוגיית רפליקציה בין אתרים, סדר סנכרון הזמן וכללי פתרון שמות. את הסכמה מתאמים איתכם לפני תחילת ההגדרה.
3. הגדרת שירות הקטלוג. פורסים בקר דומיין על Linux, מרימים DNS ואימות, מפיצים את תפקידי בעלי הפעולות, מגדירים מדיניויות סיסמאות ומבנה יחידות ארגוניות.
4. העברת נתונים והצטרפות לקוחות. מעבירים משתמשים, קבוצות ומחשבים, מכניסים מכונות לדומיין, מגדירים מיפוי הרשאות במשאבי קבצים כדי שהגישות לא יתרחבו.
5. בדיקת תרחישי כניסה. בודקים כניסה מתחנות עבודה ומשירותים, החלפה ותוקף סיסמאות, חסימות, אמון בין דומיינים והתנהגות בעת תקלה בבקר אחד.
6. גיבוי ושחזור. בודקים במעבדה שחזור של הקטלוג כולו ושל אובייקט בודד — נוהל בלי בדיקה נחשב לא עובד.
7. מסירה לתמיכה. מוסרים גישות, תיעוד ונהלים, מדריכים את המנהלים, מתעדים תוכנית פיתוח הדומיין.

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

מה מוסרים לידיים: קונפיגורציות, סכמות ונהלים

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

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

מקרה בוחן: דומיין ל-300 עובדים בלי שרת ייעודי לקטלוג

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

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

הגירה ללא השבתה

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

קליטת עובד הצטמצמה ל-15–20 דקות במקום שניים-שלושה ימים. שחזור הקטלוג — מעבר לצומת השני תוך דקות, ולא חצי יום של השבתה לכל המשרד. שיעור אירועי הגישה ירד בערך פי ארבעה, והגיבויים נעשים כעת בתדירות גבוהה יותר ונבדקים בשחזור במתחם בדיקות: החזרה לאחור לא מתוארת בהוראה, אלא מתורגלת.

מה לעשות אם הדומיין כבר פרוס על פתרון אחר?

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

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

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

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

ספקות טכניים לפני העברת דומיין ל-Linux

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

כיצד לבצע גיבוי של הדומיין?

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

מה יקרה בתקלה בצומת?

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

האם הרשאות הגישה לקבצים יישמרו?

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

האם הצוות שלנו יוכל לנהל דומיין כזה?

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

נדון במשימה: מה יידרש מצדכם ובמה נתחיל

בקר דומיין על Samba AD DC — לא שרת נפרד, אלא חלק מהרשת: הוא מחזיק פתרון שמות, סנכרון זמן, הרשאות למשאבי קבצים וכניסת עובדים. לכן הערכת העבודה נבנית לא על «מחיר ממוצע לבקר», אלא על הנתונים שלכם. להלן נתוני המקור שאנו מבקשים בשיחה הראשונה; אם משהו חסר, נעזור לאסוף.

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

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

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