הקדמה:
יותר ויותר חברות מעבירות את השרתים והשירותים שלהן לענן. חלקן מעבירות הכל לענן, וחלקן עוברות למודל היברידי.
אחד הכלים הבסיסיים והכל כך נפוצים בניהול רשתות ארגוניות, זהו Active Directory. התצורה המודרנית שלו – Azure Active Directory, מהווה כלי רבגוני ורב עוצמה להזדהות מאובטחת, ואימות משתמשים להמון שירותים אחרים. כאלה שקיימים OnPrem, או אצל ספקיות שכנות – כמו Google Cloud Platform, AWS, Webex, ServiceNow ועוד ועוד ועוד.
כאשר משתמשים במודל ההיברידי של אקטיב דירקטורי – OnPrem יחד עם Azure Active Directory, הקישוריות בין השירות בענן לשירות OnPrem מהווה חוליה חיונית.
פעילות תקינה של רכיב Azure AD Connect, שומרת על תפעול תקין של כל השירותים. כאשר הרכיב הזה משתבש או לא מוגדר נכון, המון תקלות וסכנות יכולות לצמוח מכך.
להלן אסקור בקצרה כמה דרכים לנהל את הסנכרון.
המאמר נכתב עבור אלה שכבר עובדים בתצורה היברידית עם רכיב Azure AD Connect פעיל. כדי להסביר את ההתקנה וההגדרה הראשוניים של חיבור היברידי, אצטרך לכתוב שורת מאמרים נפרדת.
חשבונות שירות:
כל ארגון מחזיק אצלו ב-Active-Directory רשימה של משתמשים שבאמצעותם מפעילים שירותים ואפליקציות שונים, משימות מתוזמנות ועוד. מטבע הדברים משתמשים אלה רגישים יותר, בחלק מהמקומות הסיסמה שלהם מוחלפת לעיתים רחוקות. במקומות שבהם יש אכיפה טובה יותר של אבטחת מידע, מתבצעת הקשחה של אותם החשבונות כדי שלא יוכלו להתחבר באמצעותם כמשתמש רגיל בממשק משתמש של מחשב, שרת (או RDP), אלא רק כ-Service או batch.
לכן כמעט תמיד משתמשים שכאלה לא אמורים להסתנכרן ל-Azure Active Directory.
את אותו הדבר אפשר להגיד על רוב משתמשי הבדיקות, משתמשים שנוצרו כדי לשמש כתיבות דואר וכו'. בקיצור – כל משתמש שאינו מייצג ישירות עובד מעובדי הארגון.
Azure AD Connect – רכיבים:
סקירה קצרה על רכיביו של המוצר, ה
מקשר ומסנכרן בין Active Directory OnPrem לשירות המנוהל בענן.
בשרת בו מותקן ומנוהל המוצר, מופיעים שלושה רכיבים:
1. Azure AD Connect
2. Synchronization Rule Editor
3. Synchronization Service
יש גם כלים נוספים כמו Web Service Configuration Tool, אבל לא אכסה את הכל במאמר זה.
Azure Active Directory Connect:
זהו אשף ההגדרות העיקרי של השירות.
פה ניתן להגדיר לאיזה דומיין ב-Azure Active Directory מתחברים, איזה מאפיינים של כל חשבון יסתנכרנו, ואיזה OU מתוך המערך של Active Directory יסתנכרן לענן (לא עבד כל כך טוב אצלי), וכו'.
חשוב לזכור!
כל עוד החלון הזה פתוח, שירות הסנכרון מושעה ולא יפעל עד לסגירה של החלון. לכן מי שפותח את האשף כדי לבדוק הגדרות, או שהתחיל הליך של הגדרה והחליט לסיים מאוחר יותר, לקחת בחשבון שצריך לסגור כמה שיותר מהר את האשף, כדי להחזיר לפעילות את השירות.
וזה לא משנה באיזה שלב החלון פתוח. כל עוד הרכיב הספציפי הזה – Azure Active Directory Connect פתוח, שירות הסנכרון אינו פעיל.
Synchronization Rule Editor:
ברכיב הזה מוגדרת החוקיות של הסנכרון. איך כל סוגי החשבונות מסתנכרנים, איך מאפיינים מסוימים שקיימים OnPrem עוברים לענן, ואיך לפעמים הם משתנים בשם ובתצורה במעבר לענן. כאשר לפעמים מאפיין (Attribute) מופיע בשם אחד OnPrem, ובשם אחר בענן.
כך גם אפשר לקבוע חוקים כיצד לסנן משתמשים שלא יסתנכרנו לענן, לפי מאפיינים מסוימים – כמו חברות בקבוצה ספציפית, שם משתמש ספציפי, או כל ערך אחר.
Synchronization Service Manager:
הרכיב הזה מנהל את החלק התפעולי.
פה ניתן לבצע פעולות סנכרון יזומות, או לעקוב אחר פעולות הסנכרון הסדירות והמתוזמנות. פה גם ניתן לאתר שגיאות בסנכרון, או למצוא אובייקטים במטמון (Cache) של Active Directory OnPrem או בענן.
כפי שניתן לראות בתמונה, ישנן 4 לשוניות עיקריות.
Operations – זהו בגדול יומן פעילויות. פה רואים את הפעילויות הסדירות, מתי הן התרחשו, מה קרה בכל פעילות וכו'.
Connectors – כאן מדובר על נקודות קצה. כאשר בארגון ממוצע יהיו שתים כאלה – האחת OnPrem והשניה בענן. אלה מסנכרנים מידע האחד לשני, לפי החוקיות וההגדרות שנקבעו עבורם ב-AD Connect, או בהגדרות Azure.
בלחיצה על כל אחד מה-Connectors יתאפשר לבחור לבצע בצורה יזומה את הפעולות, כמו יבוא, יצוא, סנכרון משלים או סנכרון מלא וכו'.
ניתן גם לנקות את המטמון של אותו Connector. פעולה זו מבצעים כאשר ישנן שגיאות מסוימות בסנכרון שחוזרות על עצמן שוב ושוב, ונראה שאין להן הצדקה אמיתית ורק משהו נתקע במטמון.
שתי הלשוניות האחרות קשורות לתצורת המאפיינים המסתנכרנים, כיצד הם מופיעים במטמון ואיך אפשר לחפש אובייקטים במטמון לפי המאפיינים האלה.
לא אתעכב על זה, רק אציין שלי יצא להשתמש בהן רק עבור איתור שגיאות סנכרון
חוק לסינון סנכרון:
כאמור לעיל, פעמים רבות נרצה לסנן משתמשים מסנכרון לענן. זה יכול להיות לפי חברות בקבוצה, או לפי מאפיינים אחרים. כאן יוסבר כיצד לבצע את הסינון, ועל פי איזו חוקיות.
כפי שכתבתי לעיל, ישנה אפשרות להגדיר באשף של Azure AD Connect לסנכרן רק OU מסוימים מתוך Active Directory. אבל לפחות מהנסיון שלי, זה גורם להמון תקלות ומשבש את כל הסנכרון. כאן נשתמש בחוקי הסנכרון על מנת לבצע את הסינון.
לפני עריכת חוקי הסנכרון, כדאי להשבית את פעולות הסנכרון הסדירות. אפשר לפתוח PowerShell Admin בשרת שבו מותקן המוצר, ולהזין את הפקודה הבאה
Set-ADSyncScheduler -SyncCycleEnabled $falseאז פותחים את הרכיב של Synchronization Rule Editor, ולוחצים על Add new rule שנמצא למעלה מימין.
אפשר לפני כן לשים לב לרשימת החוקים שיש שם. לראות שחלקם מתייחסים למשתמש, חלקם לקבוצה, חלקם מוציאים מ-OnPrem לענן ואחרים להיפך. אצל כולם יש Precedence שקובע את הסדר שבו חלים החוקים. כברירת מחדל הם מתחילים במספר 100 ועולים למעלה, כאשר 100 ראשון בסדר.
פה נתמקד בסינון מ-OnPrem לענן, וסינון משתמשים דווקא. לכן ניצור חוק וניתן לו מספר סידורי שקטן מ-100, כדי שיחול ראשון ויסנן מלכתחילה את כל מה שלא נרצה לסנכרן.
כאשר לוחצים Add new rule, נפתח חלון האשף שמגדיר את החוק. האשף מכיל ארבע לשוניות.
Description:
Connected System – פה מגדירים על מה חל החוק – איזה Connector. בוחרים ב-OnPrem.
Connected System Object Type – על איזה סוג של אובייקט באותו Connector יחול החוק. בגלל שזה OnPrem, זה User.
Metaverse Object Type – איך יתורגם וימופה האובייקט כשיעלה למטמון ויכנס לעיבוד. במקרה זה – person. עם שאיבת הנתונים מ-OnPrem, בתוך התהליך של AD Connect, User הופך ל-Person.
Lynk Type – באיזו פעולה אמור לשלוט החוק. בוחרים Join.
Precedence – כאמור לעיל, נבחר מספר נמוך מ-100, כדי שהחוק הזה יחול לפני כל החוקים. אפשר 50 או 80 או 20.
לוחצים Next.
Scoping filter:
בלשונית זו קובעים על מי החוק יחול. אם בלשונית הקודמת נקבע שהחוק יחול על משתמשים שמסתנכרנים מ-OnPrem לענן בתצורת Join, הלשונית הנוכחית קובעת על מי מבין המשתמשים החוק יחול.
כפי שניתן לראות, בלשונית זו אפשר להוסיף group ו-clause. כאשר group יכול להחיל כמה clause.
החוקיות עובדת בתצורה הבאה:
כל clause מהווה כלל. כל מה שתואם את הכלל הזה, החוק חל עליו.
clause שקיימים בתוך group אחד, עובדים בתצורת and. כלומר – כדי שהחוק יחול על משתמש, כל ה-clause באותו group חייבים להיות נכונים לגביו.
אבל group עובדים בתצורת or. כלומר – כדי שהחוק יחול על משתמש, צריך שיחול עליו group אחד, או group אחר.
לדוגמה מהצילום:
יש את ה-group הראשון. שם יש clause שאומר שהכלל חל על כל מי שנמצא במחלקת finance – או לכל הפחות, ב-Attribute של Department במשתמש שלו ב-Active Directory, צריך להיות הערך finance.
אבל בגלל שיש בתוך ה-group עוד clause, הכלל לא יחול על כל מי שבמחלקת finance. למעשה, הכלל יחול על מי שגם נמצא במחלקת finance וגם ראשי התיבות של השם שלו אינם תואמים ל-yc.
אבל יש עוד group. יכול להיות שיש מישהו שאינו ממחלקת finance, והחוק יחול עליו – כי רשום שהמנהל שלו זה דני.
אפשר להגדיר שכל מי שחבר בקבוצת HelpDesk, הערך הזה יכנס ל-extentionAttribute (או כל ערך אחר שאפשר לקבוע בעריכת ה-Schema של Active Directory). ואז ניתן לקבוע שהחוק יחול על כל מי שבקבוצת HelpDesk למעט ברנש בשם גד.
אז על מי יחול החוק?
על חברי מחלקת finance – חוץ ממי שראשי התיבות שלו הם yc.
או על מי שהמנהל שלו זה דני.
או על מי שחבר ב-HelpDesk ולא קוראים לו גד. – זה בהנחה והכניסו את הערך של הקבוצה לאותו Attribute!
Join rules:
בגלל שזה חוק לסינון משתמשים, כלומר – החוק נועד לגרום לכך שאובייקטים לא יבצעו Join, לא מכניסים שום ערך בלשונית זו.
Transformation:
הלשונית הזו קובעת מה יקרה לכל מי שחל עליו החוק עד עכשיו. במקרה שלנו, אנחנו רוצים לקבוע שכל מי שחל עליו החוק, לא יסתנכרן לענן. לכן מכניסים את הנתונים הבאים:
אז לוחצים Save, והחוק נשמר.
עכשיו חוזרים ל-Powershell ומכניסים את הפקודה הבאה:
Set-ADSyncScheduler -SyncCycleEnabled $trueשמחזירה לפעילות את הסנכרון הסדיר.
רף מחיקה:
הפעלת חוק זה תמנע סנכרון עתידי של משתמשים שמתאימים לכללים שנקבעו, ותמחק מתוך Azure Active Directory משתמשים כאלה שכבר קיימים שם.
הפעלה של חוק כזה יכולה לגרום לשינוי ומחיקה של המוני אובייקטים. צריך לקחת את זה בחשבון ולהיות מודעים להשלכות.
כדי למנוע תאונות שבהן נמחקת כמות גדולה של אובייקטים מן הענן, מוגדר ערך ברירת מחדל, מגבלה שאם מגיעים אליה, אובייקטים נוספים לא ימחקו עד הסנכרון הבא.
כברירת מחדל מוגדר המספר 500.
אפשר לקבל את הערך המוגדר באמצעות הזנת הפקודה ב-PowerShell:
Get-ADSyncExportDeletionThresholdאם מחילים חוק חדש או רוצים בנסיבות אחרות למחוק הרבה אובייקטים, אפשר להשבית את המגבלה באמצעות הפקודה:
Disable-ADSyncExportDeletionThresholdואם רוצים להחזיר את המגבלה או לשנות אותה למספר אחר (אני מגדיר 20), משתמשים בפקודה הבאה:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 20User Account Control:
מאפיין נוסף שכדאי לסנן באמצעותו, זה UserAccountControl. המאפיין הזה מכיל תמיד ערך מספרי – וישנם המון אפשרויות לערכים שהמאפיין יכול להכיל.
בלשונית Account של חשבון ב-Active Directory, יש בחלק התחתון כל מיני אפשרויות שניתן לסמן. כמו משתמש שסיסמתו לעולם אינה פגה, משתמש שלא יכול לשנות סיסמה, הצפנות Kerberos עבור חשבון זה וכו'.
אצל משתמש ממוצע הערך הוא 512. אבל ישנן כל כך הרבה אפשרויות, והערך נקבע על פי האפשרויות ברשימה שמסומנות או אינן מסומנות. בסוף הכל מחושב ויש מספר שהוא סיכום סופי, וזה הערך של UserAccountControl.
כך אפשר לקבוע חוק שיסנן משתמשים שהמאפיין הזה מכיל אצלם את הערך 66048 – שזה משתמש שסיסמתו לעולם אינה פגה. סתם דוגמה.
מחזור הסנכרון:
באשף ההגדרות אפשר לקבוע כל כמה זמן יתבצע סנכרון. ברירת המחדל היא כל חצי שעה.
אובייקט חדש או שינוי, נקלטים ועוברים מ-OnPrem לענן רק לאחר 2 מעגלי סנכרון. בסנכרון הראשון השינוי נרשם, בסנכרון השני השינוי מאושר ומופיע בצורה מלאה.
כך לדוגמה – משתמש חדש שנוצר OnPrem, יופיע ב-Azure Active Directory תוך 31-60 דקות. תלוי מתי היה הסנכרון האחרון.
אם נוצר משתמש חדש ולא רוצים לחכות, או שרוצים לבצע סנכרון יזום, ישנן שתי אפשרויות:
1. סנכרון אובייקט בודד. מתבצע באמצעות הפקודה הבאה ב-PowerShell:
Invoke-ADSyncSingleObjectSync -DistinguishedName "CN=user,OU=finance,DC=comp,DC=com"דבר שחייבים לזכור, אם בוחרים להשתמש בפעולה זו – זהו סנכרון של אובייקט בודד. כך לדוגמה, המשתמש עצמו יסתנכרן. אך בגלל שהקבוצות שהוא חבר בהן לא מסתנכרנות, הוא יופיע בענן כשרשימת הקבוצות שהוא חבר בהן ריקה.
2. הפעלה ידנית של סנכרון/יצוא מתוך ה-Synchronization Service Manager.
כאמור, צריך לסנכרן פעמיים לפני שרואים את האובייקט המבוקש בענן.