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

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

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

יש לבחור במצב Windows Server 2003 רק כאשר שרתים במערכת הפעלה זו כבר פרוסים בתשתית שלך ואתה מתכנן להשתמש באחד או יותר מהשרתים האלה בתור בקרי תחום. במקרים אחרים, עליך לבחור במצב Windows Server 2008 או 2008 R2, בהתאם לרשיונות שנרכשו. יש לזכור שתמיד ניתן להגביר את מצב פעולת הדומיין, אך לא ניתן יהיה להוריד אותו (למעט שחזור מעותק גיבוי), לכן יש לגשת לנושא זה בזהירות תוך התחשבות בהרחבות אפשריות, רישיונות בסניפים וכו'. . וכו '

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

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

כתוצאה מכך, הרשת שלנו צריכה לקבל את הטופס הבא:

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

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

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

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

הזמן עובר, הארגון שלך גדל ויש לו סניף בצד השני של העיר וצריך לכלול את הרשת שלהם בתשתית הכוללת של הארגון. במבט ראשון, שום דבר מסובך, אתה מקים ערוץ תקשורת בין משרדים ומציב בו בקר נוסף. הכל יהיה בסדר, אבל יש דבר אחד. אתה לא יכול לשלוט בשרת הזה, ולכן גישה לא מורשית אליו אפשרית, והמנהל המקומי גורם לך לפקפק בכישורים שלו. איך להיות במצב כזה? למטרות אלה, יש סוג מיוחד של בקר במיוחד: בקר תחום לקריאה בלבד (RODC), תכונה זו זמינה במצבי פונקציונליות של תחום מ-Windows Server 2008 ואילך.

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

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

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

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

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

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

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

בשנת 2002, כשהלכתי לאורך המסדרון של המחלקה למדעי המחשב של האוניברסיטה האהובה עלי, ראיתי כרזה חדשה על דלת משרד NT Systems. הפוסטר הראה אייקונים של חשבונות משתמש מקובצים לקבוצות, מהן, בתורו, חיצים עברו לסמלים אחרים. כל זה שולב באופן סכמטי למבנה מסוים, נכתב משהו על מערכת כניסה בודדת, הרשאה וכדומה. עד כמה שהבנתי עכשיו, הפוסטר הזה תיאר את הארכיטקטורה של מערכות Windows NT 4.0 Domains ו-Windows 2000 Active Directory. מאותו רגע התחילה ומיד הסתיימה ההיכרות הראשונה שלי עם Active Directory, כי אז הייתה סשן קשה, חופשה מהנה, שאחריה חבר שיתף דיסקים של FreeBSD 4 ו-Red Hat Linux, ובמשך השנים הבאות צללתי לתוך עולם המערכות דמויות יוניקס, אבל מעולם לא שכחתי את תוכן הפוסטר.
נאלצתי לחזור ולהכיר יותר את מערכות Windows Server כשעברתי לעבוד בחברה שבה ניהול כל תשתית ה-IT התבסס על Active Directory. אני זוכר שהמנהל הראשי של החברה ההיא בכל פגישה אמר כל הזמן משהו על איזשהו שיטות מומלצות של Active Directory. כעת, לאחר 8 שנים של תקשורת תקופתית עם Active Directory, אני מבין היטב איך המערכת הזו עובדת ומהן שיטות העבודה המומלצות של Active Directory.
כפי שבטח כבר ניחשתם, נדבר על Active Directory.
כל מי שמתעניין בנושא זה מוזמן לחתול.

המלצות אלו תקפות עבור מערכות לקוח המתחילות ב-Windows 7 ומעלה, עבור תחומים ויערות ברמת Windows Server 2008/R2 ומעלה.

תְקִינָה
תכנון עבור Active Directory צריך להתחיל בפיתוח סטנדרטים משלך למתן שמות לאובייקטים ומיקומם בספריה. יש צורך ליצור מסמך שבו מגדירים את כל התקנים הדרושים. כמובן, זוהי המלצה נפוצה למדי עבור אנשי IT. העיקרון "קודם כל כותבים תיעוד, ואחר כך בונים מערכת המבוססת על התיעוד הזה" הוא טוב מאוד, אבל הוא מיושם הלכה למעשה מסיבות רבות. בין הסיבות הללו - עצלות אנושית פשוטה או חוסר יכולת מתאימה, שאר הסיבות נגזרות משתי הראשונות.
אני ממליץ - קודם כל תכתוב את התיעוד, תחשוב על זה, ורק אז תתקדם עם התקנת בקר התחום הראשון.
לדוגמה, אני אתן חלק מהמסמך על הסטנדרטים למתן שמות לאובייקטים של Active Directory.
מתן שם לאובייקט.

  • שם קבוצות המשתמש חייב להתחיל בקידומת GRUS_ (GR - Group, US - Users)
  • השם של קבוצות מחשבים לא יכול להתחיל בקידומת GRCP_ (GR - Group, CP - Computers)
  • השם של קבוצות האצלה חייב להתחיל בקידומת GRDL_ (GR - Group, DL - Delegation)
  • השם של קבוצות הגישה למשאבים חייב להתחיל בקידומת GRRS_ (GR - Group, RS - משאבים)
  • שם הקבוצות עבור מדיניות חייב להתחיל בקידומות GPUS_, GPCP_ (GP - מדיניות קבוצתית, ארה"ב - משתמשים, CP - מחשבים)
  • השם של מחשבי הלקוח צריך להיות מורכב משתיים או שלוש אותיות משם הארגון, ואחריהן מספר דרך מקף, למשל, nnt-01.
  • שמות שרתים חייבים להתחיל בשתי אותיות בלבד, ואחריו מקף ואחריו תפקיד השרת ומספר השרת, לדוגמה, nn-dc01.
אני ממליץ לתת שמות לאובייקטים של Active Directory בצורה כזו שלא תצטרך למלא את השדה "תיאור". לדוגמה, משמה של הקבוצה GPCP_Restricted_Groups, ברור שמדובר בקבוצה למדיניות המוחלת על מחשבים ומבצעת את עבודת מנגנון ה-Restricted Groups.
הגישה שלך לכתיבת תיעוד צריכה להיות מאוד יסודית, זה יחסוך הרבה זמן מאוחר יותר.

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

פעל לפי העיקרון - "אובייקט - קבוצה"
התחל ליצור אובייקטים של Active Directory על ידי יצירת קבוצה עבור אובייקט זה, וכבר הקצה את הזכויות הדרושות לקבוצה. בואו נסתכל על דוגמה. עליך ליצור חשבון מנהל ראשי. תחילה צור את קבוצת Head Admins ורק לאחר מכן צור את החשבון עצמו והוסף אותו לקבוצה זו. הקצה לקבוצת המנהלים הראשיים את הזכויות של המנהל הראשי, למשל, על ידי הוספה לקבוצת מנהלי הדומיין. כמעט תמיד מסתבר שאחרי זמן מה מגיע לעבודה עובד נוסף שזקוק לזכויות דומות, ובמקום להאציל זכויות למקטעים שונים ב-Active Directory, ניתן יהיה פשוט לצרף אותו לקבוצה הנדרשת, שהמערכת כבר עשתה לה. הגדיר תפקיד והאציל את הסמכות הדרושה.
עוד דוגמה אחת. עליך להאציל זכויות ל-OU עם משתמשים לקבוצת מנהלי המערכת. אל תאציל זכויות ישירות לקבוצת המנהלים, אלא צור קבוצה מיוחדת כמו GRDL_OUName_Operator_Accounts שאליה אתה מקצה זכויות. לאחר מכן פשוט הוסף את קבוצת המנהלים האחראים לקבוצת GRDL_OUName_Operator_Accounts. בהחלט יתברר שבעתיד הקרוב, תצטרך להאציל זכויות ל-OU זה לקבוצה אחרת של מנהלים. ובמקרה זה, פשוט תוסיף את קבוצת הנתונים של מנהל המערכת לקבוצת האצלת GRDL_OUName_Operator_Accounts.
אני מציע את מבנה הקבוצה הבא.

  • קבוצות משתמשים (GRUS_)
  • קבוצות מנהלים (GRAD_)
  • קבוצות נציגות (GRDL_)
  • קבוצות מדיניות (GRGP_)
קבוצות מחשבים
  • קבוצות שרתים (GRSR_)
  • קבוצות מחשבי לקוח (GRCP_)
קבוצות גישה למשאבים
  • קבוצות גישה למשאבים משותפים (GRRS_)
  • קבוצות גישה למדפסת (GRPR_)
במערכת הבנויה סביב הנחיות אלו, כמעט כל הניהול יוסיף קבוצות לקבוצות.
שמרו על איזון, הגבל את מספר התפקידים לקבוצות, וזכרו ששם הקבוצה צריך לתאר באופן אידיאלי את תפקידה במלואו.

ארכיטקטורת OU.
יש לחשוב קודם כל על הארכיטקטורה של OU מנקודת מבט של אבטחה והאצלת זכויות ל-OU זה למנהלי מערכת. אני לא ממליץ לתכנן את ארכיטקטורת ה-OU במונחים של קישור מדיניות קבוצתית אליהם (למרות שזה נעשה לרוב). עבור חלק, ההמלצה שלי תיראה קצת מוזרה, אבל אני לא ממליץ לקשר מדיניות קבוצתית ל-OU בכלל. קרא עוד בסעיף מדיניות קבוצתית.
מנהלי OU
אני ממליץ להקצות OU נפרד לחשבונות וקבוצות מנהליים, היכן למקם את החשבונות והקבוצות של כל המנהלים ומהנדסי התמיכה הטכנית. הגישה ל-OU זה צריכה להיות מוגבלת למשתמשים רגילים, ויש להאציל את ניהול האובייקטים מ-OU זה רק למנהלים הראשיים.
OU מחשבים
יחידות OU מחשב מתוכננות בצורה הטובה ביותר מבחינת גיאוגרפית מחשבים וסוגי מחשבים. הפצת מחשבים ממיקומים גיאוגרפיים שונים ליחידות ארגוניות שונות, ובתמורה לחלק אותם למחשבי לקוח ולשרתים. ניתן לחלק שרתים עוד יותר ל- Exchange, SQL ואחרים.

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

  • עם זכויות מנהל למחשבי משתמש, אך לא לשרתים. חייב להיות מורכב מראשי התיבות של הבעלים ואחריהם הקידומת local (למשל iivlocal)
  • עם זכויות לניהול שרתים ו-Active Directory. חייב להכיל ראשי תיבות בלבד (לדוגמה, iiv).
שדה שם המשפחה של שני סוגי החשבונות האדמיניסטרטיביים צריך להתחיל באות I (לדוגמה, iPetrov P Vasily)
תן לי להסביר מדוע עליך להפריד חשבונות ניהול למנהלי שרתים ומנהלי מחשבי לקוח. זה הכרחי מסיבות אבטחה. למנהלי מחשבי לקוח תהיה הזכות להתקין תוכנה על מחשבי לקוח. מה ולמה תותקן התוכנה, אתה אף פעם לא יכול לומר בוודאות. לכן, זה לא בטוח להפעיל את ההתקנה של התוכנית עם זכויות מנהל דומיין; אתה יכול לסכן את כל הדומיין. עליך לנהל מחשבי לקוח רק עם זכויות מנהל מקומיות עבור אותו מחשב. זה יאפשר מספר התקפות על חשבונות של מנהלי תחום, כגון "Pass The Hash". בנוסף, מנהלי מחשבי לקוח חייבים לסגור את חיבור שירותי המסוף ואת חיבור הרשת למחשב. יש למקם מחשבים לתמיכה טכנית ומנהלי מערכת ב-VLAN נפרד כדי להגביל את הגישה אליהם מרשת מחשבי הלקוח.
הענקת זכויות מנהל למשתמשים
אם אתה צריך לתת זכויות מנהל למשתמש, אל תכניס את החשבון היומיומי שלו לקבוצת המנהלים המקומית של המחשב בשום מקרה. חשבון לעבודה יומיומית צריך תמיד להיות מוגבל בזכויות. צור חשבון ניהול נפרד מסוג namelocal עבורו והוסף חשבון זה לקבוצת המנהלים המקומיים באמצעות המדיניות, תוך הגבלת השימוש בו רק במחשב המשתמש באמצעות מיקוד ברמת הפריט. המשתמש יוכל להשתמש בחשבון זה באמצעות מנגנון Run AS.
מדיניות סיסמאות
צור מדיניות סיסמאות נפרדת עבור משתמשים ומנהלי מערכת באמצעות מדיניות סיסמאות מעודנת. רצוי שסיסמת המשתמש תהיה באורך של לפחות 8 תווים ותשנה לפחות מדי רבעון. רצוי שמנהלי מערכת ישנו את הסיסמה כל חודשיים, והיא צריכה להיות באורך של 10-15 תווים לפחות ולעמוד בדרישות המורכבות.

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

חשבונות מנהל מקומיים
באמצעות מנגנון הקבוצות מוגבלות, עליך לנעול חשבונות מנהל מקומיים במחשבים מקומיים, לנעול חשבונות אורחים ולנקות את קבוצת המנהלים המקומיים במחשבים מקומיים. לעולם אל תשתמש במדיניות קבוצתית כדי להגדיר סיסמאות עבור חשבונות מנהל מקומיים. מנגנון זה אינו מאובטח, ניתן לאחזר את הסיסמה ישירות מהפוליסה. אבל, אם תחליט לא לחסום חשבונות מנהל מקומיים, השתמש במנגנון LAPS כדי להגדיר נכון סיסמאות ולסובב אותן. למרבה הצער, תצורת ה-LAPS אינה אוטומטית לחלוטין, ולכן יהיה צורך להוסיף תכונות ידנית לסכימת Active Directory, להעניק להן זכויות, להקצות קבוצות וכן הלאה. לכן, קל יותר לחסום חשבונות מנהל מקומיים.
חשבונות שירות.
כדי להפעיל שירותים, השתמש בחשבונות שירות ובמנגנון gMSA (זמין במערכות Windows 2012 ומעלה)

מדיניות קבוצתית
מסמכי מדיניות לפני יצירה/שינוי.
בעת יצירת מדיניות, השתמש בעקרון "מדיניות - קבוצה". כלומר, לפני יצירת מדיניות, תחילה צור קבוצה עבור מדיניות זו, הסר את קבוצת המשתמשים המאומתים מהיקף המדיניות והוסף את הקבוצה שנוצרה. לאגד את המדיניות לא ל-OU, אלא לשורש הדומיין ולהסדיר את היקף היישום שלו על ידי הוספת אובייקטים לקבוצת המדיניות. אני רואה במנגנון כזה גמיש ומובן יותר מאשר קישור של מדיניות ל-OU. (על זה כתבתי במדור אדריכלות OU).
התאם תמיד את היקף הפוליסה. אם יצרת מדיניות עבור משתמשים בלבד, אז השבת את מבנה המחשב ולהיפך, השבת את מבנה המשתמש אם יצרת מדיניות עבור מחשבים בלבד. הודות להגדרות אלו, המדיניות תיושם מהר יותר.
הגדר גיבויים יומיים של מדיניות באמצעות Power Shell כך שבמקרה של שגיאות תצורה, תמיד תוכל להחזיר את ההגדרות לאלו המקוריות.
תבניות חנות מרכזית (חנות מרכזית)
החל מ-Windows 2008, ניתן היה לאחסן תבניות ADMX של מדיניות קבוצתית בחנות מרכזית, ב-SYSVOL. לפני כן, כברירת מחדל, כל תבניות המדיניות נשמרו באופן מקומי, בלקוחות. כדי למקם את תבניות ה-ADMX בחנות המרכזית, העתק את התוכן של התיקייה %SystemDrive%\Windows\PolicyDefinitions יחד עם תיקיות משנה ממערכות לקוח (Windows 7/8/8.1) ל-%SystemDrive%\Windows\SYSVOL\domain של בקר התחום של בקר התחום. ספריית \Policies\PolicyDefinitions עם מיזוג תוכן אך ללא תחליף. לאחר מכן, עליך ליצור את אותו עותק ממערכות השרת, החל מהישן ביותר. לבסוף, בעת העתקת תיקיות וקבצים מהגרסה העדכנית ביותר של השרת, בצע העתקה של מיזוג והחלפה.

העתקת תבניות ADMX

בנוסף, ניתן למקם באחסון המרכזי תבניות ADMX עבור כל מוצרי תוכנה, כגון Microsoft Office, מוצרי Adobe, מוצרי Google ואחרים. עבור אל אתר האינטרנט של ספק התוכנה, הורד את תבנית ADMX של מדיניות קבוצתית וחלץ אותה לתיקיית %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions בכל אחד מבקרי התחום שלך. עכשיו אתה יכול לנהל את מוצר התוכנה שאתה צריך באמצעות מדיניות קבוצתית.
מסנני WMI
מסנני WMI אינם מהירים במיוחד, ולכן עדיף מיקוד ברמת הפריט. אבל אם לא ניתן להשתמש במיקוד ברמת הפריט, ואתה מחליט להשתמש ב-WMI, אז אני ממליץ לך ליצור מיד כמה מהפילטרים הנפוצים ביותר עבור עצמך: המסנן "רק מערכות הפעלה של לקוח", "רק מערכות הפעלה של שרתים", מסננים "Windows 7", מסנן "Windows 8", "Windows 8.1", "Windows 10". אם יש לך סטים מוכנים של מסנני WMI, אז יהיה קל יותר להחיל את המסנן הרצוי על המדיניות הרצויה מאוחר יותר.

ביקורת אירועי Active Directory
הקפד להפעיל ביקורת אירועים בבקרי תחום ושרתים אחרים. אני ממליץ לאפשר ביקורת של האובייקטים הבאים:

  • ביקורת ניהול חשבון מחשב - הצלחה, כישלון
  • ביקורת אירועי ניהול חשבון אחרים - הצלחה, כישלון
  • ניהול קבוצת אבטחה ביקורת - הצלחה, כישלון
  • ביקורת ניהול חשבון משתמש - הצלחה, כישלון
  • ביקורת שירות אימות Kerberos - כשל
  • ביקורת אירועי כניסה אחרים לחשבון - כשל
  • שינוי מדיניות ביקורת ביקורת - הצלחה, כישלון
יש להגדיר את הביקורת בסעיף תצורת מדיניות ביקורת מתקדמתוהקפד לכלול את ההגדרה בסעיף מדיניות מקומית/אפשרויות אבטחה - כפה על הגדרות תת-קטגוריות של מדיניות ביקורת (Windows Vista ואילך) כדי לעקוף את הגדרות קטגוריית מדיניות הביקורת, שיעקוף את ההגדרות ברמה העליונה ויחיל את המתקדמות.

הגדרות ביקורת מתקדמות

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

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

ניהול ידני
חלק מפעולות הניהול אתה ועמיתיך תצטרכו לבצע באופן ידני. למטרות אלו, אני ממליץ להשתמש בקונסולת mmc עם רכיבי Snap-ins שנוספו אליה.
כפי שנדון בהמשך, בקרי התחום שלך חייבים לפעול במצב Server Core, כלומר, יש לבצע ניהול של כל סביבת AD רק מהמחשב שלך באמצעות קונסולות. כדי לנהל את Active Directory, עליך להתקין את כלי ניהול השרת המרוחק במחשב שלך. קונסולות צריכות להיות מופעלות במחשב שלך כמשתמש עם זכויות מנהל ב-Active Directory שאליו הוקצתה השליטה.
אומנות הניהול של Active Directory באמצעות קונסולות דורשת מאמר נפרד, ואולי אפילו סרטון הדרכה נפרד, אז כאן אני מדבר רק על העיקרון עצמו.

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

תפקידי FSMO, בקרים ראשוניים ומשניים
תפקידי בקר תחום FSMO ממשיכים לעורר פחד במוחם של מנהלים מתחילים. לעתים קרובות, מתחילים לומדים את Active Directory באמצעות תיעוד מיושן או מאזינים לסיפורים ממנהלי מערכת אחרים שקראו משהו איפשהו.
עבור כל חמשת התפקידים + 1, יש לומר בקצרה את הדברים הבאים. החל מ-Windows Server 2008, אין עוד בקרי תחום ראשיים ומשניים. כל חמשת תפקידי בקר התחום הם ניידים, אך לא ניתן לארח אותם ביותר מבקר תחום אחד בו-זמנית. אם ניקח את אחד מהבקרים, שהיה למשל הבעלים של 4 תפקידים ונמחק אותו, אז נוכל להעביר את כל התפקידים הללו בקלות לבקרים אחרים, ולא יקרה שום דבר נורא בדומיין, שום דבר לא ישבר. זה אפשרי מכיוון שכל המידע על העבודה הקשורה לתפקיד מסוים מאוחסן על ידי בעליו ישירות ב-Active Directory. ואם נעביר את התפקיד לבקר אחר, אז הוא קודם כל מבקש את המידע המאוחסן ב-Active Directory ומתחיל לשרת. דומיין יכול להתקיים די הרבה זמן ללא בעלי תפקידים. ה"תפקיד" היחיד שצריך להיות תמיד ב-Active Directory, ובלעדיו הכל יהיה רע מאוד, הוא תפקידו של הקטלוג הגלובלי (GC), הוא יכול להתבצע על ידי כל הבקרים בתחום. אני ממליץ להקצות את תפקיד ה-GC לכל בקר בתחום, כמה שיותר, יותר טוב. כמובן, אתה יכול למצוא מקרים שבהם אתה לא צריך להתקין את תפקיד GC על בקר תחום. ובכן, אם אתה לא צריך, אז אתה לא חייב. עקבו אחר ההמלצות ללא קנאות.

שירות DNS
שירות ה-DNS הוא קריטי לתפעול של Active Directory ואמור לפעול בצורה חלקה. את שירות ה-DNS מומלץ לשים על כל בקר תחום ולאחסן אזורי DNS ב-Active Directory עצמו. אם תשתמש ב-Active Directory לאחסון אזורי DNS, עליך להגדיר את המאפיינים של חיבור ה-TCP/IP בבקרי התחום כך שלכל בקר יהיה כל שרת DNS אחר כשרת ה-DNS הראשי, ותוכל להגדיר את שרת ה-DNS המשני. כתובת 127.0.0.1. תצורה זו נחוצה מכיוון שלהתחלה רגילה של שירות Active Directory, נדרש DNS עובד, וכדי שה-DNS יתחיל, שירות Active Directory חייב לפעול, מכיוון שהוא מכיל את אזור ה-DNS עצמו.
הקפד להגדיר אזורי חיפוש הפוך עבור כל הרשתות שלך ולאפשר עדכון מאובטח אוטומטי של רשומות PTR.
אני ממליץ לך להפעיל בנוסף ניקוי אוטומטי של האזור מרשומות DNS מיושנות (ניקוי dns).
אני ממליץ לציין שרתי Yandex מאובטחים כמעבירי DNS אם אין שרתי מהירים יותר במיקום הגיאוגרפי שלך.

אתרים ושכפול
מנהלי מערכת רבים נוטים לחשוב על אתרים כעל קיבוץ גיאוגרפי של מחשבים. למשל, אתר מוסקבה, אתר סנט פטרסבורג. השקפה זו הופיעה בשל העובדה שהחלוקה המקורית של Active Directory לאתרים נעשתה על מנת לאזן ולהפריד בין תעבורת רשת שכפול. בקרי תחום במוסקבה לא צריכים לדעת שעשרה חשבונות מחשב נוצרו כעת בסנט פטרסבורג. ולכן, מידע כזה על שינויים יכול להיות מועבר פעם בשעה לפי לוח זמנים. או אפילו לשכפל שינויים פעם ביום ורק בלילה, כדי לחסוך ברוחב פס.
לגבי אתרים, הייתי אומר את זה: אתרים הם קבוצות מחשבים הגיוניות. מחשבים המחוברים ביניהם באמצעות חיבור רשת טוב. והאתרים עצמם קשורים ביניהם בחיבור ברוחב פס נמוך, דבר נדיר בתקופתנו. לכן, אני מחלק את Active Directory לאתרים לא לאיזון תעבורת רפליקציה, אלא לאיזון עומס ברשת באופן כללי ולעיבוד מהיר יותר של בקשות לקוח ממחשבי האתר. תן לי להסביר עם דוגמה. קיימת רשת מקומית של 100 מגה-ביט של הארגון, אשר מוגשת על ידי שני בקרי תחום, וישנו ענן שבו שרתי האפליקציות של ארגון זה נמצאים עם שני בקרי ענן נוספים. אחלק רשת כזו לשני אתרים כך שהבקרים ברשת המקומית יעבדו בקשות לקוח מהרשת המקומית, והבקרים בענן יעבדו בקשות משרתי אפליקציות. בנוסף, זה יפריד בקשות לשירותי DFS ו-Exchange. ומכיוון שכעת אני כמעט ולא רואה ערוץ אינטרנט של פחות מ-10 מגה-ביט לשנייה, אני אאפשר את Notify Based Replication, זה כאשר הנתונים משוכפלים ברגע שיש שינויים כלשהם ב-Active Directory.

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

אתה יכול לעזור ולהעביר כמה כספים לפיתוח האתר

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

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

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

נכון להיום, רוב שירותי המדריך של חברות שונות מבוססים על התקן X.500. כדי לגשת למידע המאוחסן בשירותי ספרייה, נעשה בדרך כלל שימוש בפרוטוקול. (LDAP). עם ההתפתחות המהירה של רשתות TCP/IP, LDAP הופך לסטנדרט עבור שירותי ספרייה ויישומים מוכווני ספרייה.

שירות ספריות Active Directory היא הבסיס למבנה הלוגי של רשתות ארגוניות המבוססות על מערכת Windows. התנאי " קָטָלוֹג"במובן הרחב פירושו" מַדרִיך", א שירות ספריותרשת ארגונית היא ספרייה ארגונית מרכזית. הספרייה הארגונית יכולה להכיל מידע על אובייקטים מסוגים שונים. שירות ספריות Active Directory מכילה בעיקר את האובייקטים עליהם מבוססת מערכת אבטחת הרשת של Windows - חשבונות משתמשים, קבוצות ומחשבים. חשבונות מאורגנים במבנים לוגיים: תחום, עץ, יער, יחידות ארגוניות.

מנקודת מבט של לימוד החומר של הקורס "רשת מִנהָל"אפשר בהחלט לעבור על המדריך באופן הבא: תחילה למד את החלק הראשון של סעיף זה (ממושגים בסיסיים ועד להתקנת בקרי תחום), לאחר מכן עבור אל "שירות קבצים והדפסה", ולאחר לימוד "שירות קבצים והדפסה" חזור אל "Active Directory Service Directory" כדי ללמוד מושגים מתקדמים יותר של שירותי ספרייה.

6.1 מונחים ומושגים בסיסיים (יער, עץ, תחום, יחידה ארגונית). תכנון עבור מרחב שמות של AD. התקנת בקרי דומיין

מודלים לניהול אבטחה: מודל קבוצת עבודה ומודל תחום מרכזי

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

דגם "קבוצת עבודה"

מודל ניהול אבטחת הרשת הארגונית הזה הוא הפרימיטיבי ביותר. הוא מיועד לשימוש בקטנים רשתות עמית לעמית(3–10 מחשבים) והוא מבוסס על העובדה שלכל מחשב ברשת עם מערכות הפעלה Windows NT/2000/XP/2003 יש מסד נתונים מקומי משלו של חשבונות, ומסד נתונים מקומי זה שולט בגישה למשאבים של מחשב זה. מסד הנתונים המקומי של חשבונות נקרא מסד הנתונים SAM (מנהל חשבון אבטחה) ומאוחסן ברישום של מערכת ההפעלה. מסדי הנתונים של מחשבים בודדים מבודדים לחלוטין זה מזה ואינם מחוברים בשום צורה.

דוגמה לבקרת גישה באמצעות מודל כזה מוצגת באיור. 6.1.


אורז. 6.1.

דוגמה זו מציגה שני שרתים (SRV-1 ו-SRV-2) ושתי תחנות עבודה (WS-1 ו-WS-2). מסדי הנתונים של SAM שלהם מסומנים SAM-1, SAM-2, SAM-3 ו-SAM-4, בהתאמה (מסדי הנתונים של SAM מוצגים כסגלגל באיור). לכל מסד נתונים יש חשבונות משתמש User1 ו-User2. שם המשתמש המלא של User1 בשרת SRV-1 ייראה כמו "SRV-1\User1", והשם המלא של User1 בתחנת העבודה WS-1 ייראה כמו "WS-1\User1". בואו נדמיין שנוצרת תיקיית Folder בשרת SRV-1, אליה ניתנת גישה דרך הרשת למשתמשים User1 - לקריאה (R), User2 - לקריאה וכתיבה (RW). הנקודה העיקרית במודל זה היא שמחשב SRV-1 "לא יודע" דבר על החשבונות של מחשבי SRV-2, WS-1, WS-2, כמו גם כל שאר המחשבים ברשת. אם משתמש בשם User1 מתחבר באופן מקומי במחשב, למשל, WS-2 (או, כמו שאומרים, "נכנס עם השם המקומי User1 במחשב WS-2"), אז כאשר מנסים לגשת מהמחשב הזה מעל הרשת, תיקייה בשרת SRV-1, השרת יבקש מהמשתמש שם משתמש וסיסמה (למעט אם למשתמשים עם אותו שם משתמש יש אותה סיסמה).

מודל "קבוצת העבודה" קל יותר ללמידה, אין צורך ללמוד את המושגים המורכבים של Active Directory. אבל בשימוש ברשת עם מספר רב של מחשבים ומשאבי רשת, זה הופך להיות קשה מאוד לנהל את שמות המשתמש והסיסמאות שלהם - אתה צריך ליצור באופן ידני את אותם חשבונות עם אותן סיסמאות בכל מחשב (מה שמספק את המשאבים שלו לשיתוף ב- הרשת), מה שעמל מאוד, או ליצור חשבון אחד לכל המשתמשים עם סיסמה אחת לכולם (או ללא סיסמה בכלל), מה שמפחית מאוד את רמת ההגנה על המידע. לכן, מודל "קבוצת עבודה" מומלץ רק לרשתות עם 3 עד 10 מחשבים (ואפילו עדיף - לא יותר מ-5), בתנאי שבין כל המחשבים אין אחד עם מערכת Windows Server.

מודל תחום

במודל התחום, קיים מסד נתונים יחיד של שירותי ספרייה הזמין לכל המחשבים ברשת. לשם כך, מותקנים ברשת שרתים מיוחדים, הנקראים בקרי תחוםהמאחסנים את מסד הנתונים הזה בכוננים הקשיחים שלהם. על איור. 6.2. התרשים של מודל התחום מוצג. השרתים DC-1 ו-DC-2 הם בקרי תחום, הם מאחסנים את מסד הנתונים של החשבונות של הדומיין (כל בקר שומר עותק משלו של מסד הנתונים, אבל כל השינויים שנעשו במסד הנתונים באחד השרתים משוכפלים לבקרים אחרים).


אורז. 6.2.

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

מטרת שירות הספריות של Active Directory

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

Active Directory אחראית לא רק על יצירה וארגון של אובייקטים קטנים אלה, אלא גם על אובייקטים גדולים כגון דומיינים, OUs (יחידות ארגוניות) ואתרים.

קרא להלן עבור מונחים בסיסיים המשמשים בהקשר של שירות הספריות של Active Directory.

שירות ספריות Active Directory (בקיצור AD) מאפשרת תפעול יעיל של סביבה ארגונית מורכבת על ידי מתן התכונות הבאות:

  • כניסה יחידה באינטרנט; משתמשים יכולים להיכנס לרשת עם שם משתמש וסיסמה בודדים ועדיין יש להם גישה לכל משאבי הרשת והשירותים (שירותי תשתית רשת, שירותי קבצים והדפסה, שרתי יישומים ומסד נתונים וכו');
  • אבטחת מידע. בקרות אימות וגישה למשאבים המובנים ב-Active Directory מספקות אבטחת רשת מרכזית;
  • ניהול מרכזי. מנהלי מערכת יכולים לנהל באופן מרכזי את כל המשאבים הארגוניים;
  • ניהול באמצעות מדיניות קבוצתית. כאשר מחשב מאתחל או משתמש נכנס למערכת, דרישות המדיניות הקבוצתית מתקיימות; ההגדרות שלהם מאוחסנות ב אובייקטי מדיניות קבוצתית(GPO) ויחול על כל חשבונות המשתמשים והמחשבים הממוקמים באתרים, בדומיינים או ביחידות ארגוניות;
  • שילוב DNS. התפקוד של שירותי המדריך תלוי לחלוטין בתפעול שירות ה-DNS. בתורו, שרתי DNS יכולים לאחסן מידע על אזורים במסד הנתונים של Active Directory;
  • אפשרות הרחבה של ספריות. מנהלי מערכת יכולים להוסיף מחלקות אובייקטים חדשות לסכימת הקטלוג או להוסיף תכונות חדשות למחלקות קיימות;
  • מדרגיות. שירות Active Directory יכול לכסות גם דומיין אחד וגם דומיינים רבים המשולבים לעץ של דומיינים, וניתן לבנות יער מכמה עצי דומיין;
  • שכפול מידע. Active Directory משתמש בשכפול תקורה בסכימה מרובת מאסטר ( רב מאסטר), המאפשר לך לשנות את מסד הנתונים של Active Directory בכל בקר תחום. נוכחותם של מספר בקרים בתחום מספקת סובלנות לתקלות ויכולת לפזר עומס ברשת;
  • גמישות של שאילתות ספריות. ניתן להשתמש במסד נתונים של Active Directory כדי לחפש במהירות כל אובייקט AD באמצעות המאפיינים שלו (לדוגמה, שם משתמש או כתובת דואר אלקטרוני, סוג מדפסת או מיקום וכו');
  • ממשקי תכנות סטנדרטיים. עבור מפתחי תוכנה, שירות הספריות מספק גישה לכל התכונות (כלים) של הספרייה ותומך בתקנים מקובלים ובממשקי תכנות (API).

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

טרמינולוגיה

שירות ספריות Windows Server בנוי על תקני טכנולוגיה מקובלים. התקן המקורי לשירותי מדריכים היה X.500, שנועדה לבנות ספריות מדרגיות דמויות עץ היררכיות עם יכולת להרחיב גם מחלקות אובייקט וגם קבוצות של תכונות (מאפיינים) של כל מחלקה בודדת. עם זאת, היישום המעשי של תקן זה הוכח כלא יעיל מבחינת ביצועים. לאחר מכן, על בסיס תקן X.500, פותחה גרסה פשוטה (קלת משקל) של תקן בניית ספריות, הנקראת LDAP (פרוטוקול גישה למדריך קל משקל). פרוטוקול LDAP שומר על כל המאפיינים הבסיסיים של X.500 (מערכת בניית ספריות היררכית, מדרגיות, הרחבה ), אך בו זמנית מאפשר לך ליישם ביעילות את התקן הזה בפועל. התנאי " קל " (" קל") בשם LDAP משקף את המטרה העיקרית של פיתוח הפרוטוקול: ליצור ערכת כלים לבניית שירות מדריכים שיש לו כוח פונקציונלי מספיק כדי לפתור משימות בסיסיות, אך אינו עמוס בטכנולוגיות מורכבות שהופכות את היישום של שירותי מדריכים ללא יעיל. נכון לעכשיו, LDAP היא השיטה הסטנדרטית לגישה למידע מדריכים מקוונים וממלאת תפקיד בסיסי במגוון מוצרים כגון מערכות אימות, תוכניות דואר אלקטרוני ויישומי מסחר אלקטרוני. ישנם למעלה מ-60 שרתי LDAP מסחריים בשוק כיום, כאשר כ-90% מהם הם שרתי LDAP עצמאיים, כאשר השאר מוצעים כרכיבים של יישומים אחרים.

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

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

מלבד LDAP שירות ספריות Active Directory משתמשת גם בפרוטוקול אימות קרברוסושירות DNS לחיפוש רשת של רכיבי שירותי ספרייה (בקרי תחום, שרתי קטלוגים גלובליים, שירות Kerberos וכו').

תְחוּם

היחידה הבסיסית של מערכת האבטחה Active Directory היא תְחוּם. התחום מהווה את תחום האחריות הניהולית. מסד הנתונים של הדומיין מכיל חשבונות משתמשים, קבוצותו מחשבים. רוב פונקציות ניהול הספריות פועלות ברמת התחום (אימות משתמש, בקרת גישה למשאבים, בקרת שירות, בקרת שכפול, מדיניות אבטחה).

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

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

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

מומלץ מאוד להתקין לפחות שני בקרי תחום בכל תחום - ראשית, כדי להגן מפני אובדן מסד הנתונים של Active Directory במקרה של כשל בבקר, ושנית, לחלק את העומס בין controllers.it.company.ru יש לו תת-דומיין dev.it.company.ru , שנוצר עבור מחלקת פיתוח התוכנה של שירות ה-IT.

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

יחידות ארגוניות (OD).

יחידות ארגוניות (יחידות ארגוניות, ou) - מיכלים בתוך AD שנוצרו כדי לקבץ אובייקטים יחד למטרות האצלת זכויות מנהליותו החלת מדיניות קבוצתיתבתחום. OP קיים רק בתוך תחומיםויכול לשלב רק אובייקטים מהדומיין הפרטי. ניתן לקנן את OPs זה בתוך זה, מה שמאפשר לבנות היררכיה מורכבת דמוית עץ של קונטיינרים בתוך תחום ולהפעיל שליטה ניהולית גמישה יותר. בנוסף, ניתן ליצור OPs כדי לשקף את ההיררכיה האדמיניסטרטיבית והמבנה הארגוני של חברה.

מדריך גלובלי

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

Active Directory

Active Directory("ספריות פעילות", מוֹדָעָה) - LDAP-יישום תואם של שירות מדריכים של תאגיד מיקרוסופטלמערכות הפעלה של המשפחה Windows NT. Active Directoryמאפשר למנהלי מערכת להשתמש במדיניות קבוצתית כדי להבטיח הגדרת חווית משתמש עקבית, לפרוס תוכנה למספר מחשבים באמצעות מדיניות קבוצתית או באמצעות מנהל תצורת מרכז המערכת(קוֹדֶם שרת ניהול מערכות של מיקרוסופט), להתקין עדכוני מערכת הפעלה, אפליקציות ותוכנות שרת בכל המחשבים ברשת באמצעות שירות העדכונים Windows Server . Active Directoryמאחסן נתוני סביבה והגדרות במסד נתונים מרכזי. רשתות Active Directoryיכול להיות בגדלים שונים: מכמה עשרות ועד כמה מיליוני חפצים.

ביצועים Active Directoryהתרחש בשנת 1999, המוצר יצא לראשונה עם Windows 2000 Server, ולאחר מכן שונתה ושופרה עם השחרור Windows Server 2003. כתוצאה מכך Active Directoryשופר ב Windows Server 2003 R2, Windows Server 2008ו Windows Server 2008 R2ושם שונה ל שירותי תחום Active Directory. שירות הספריות נקרא בעבר שירות ספריות NT (NTDS), עדיין ניתן למצוא את השם הזה בחלק מקובצי ההפעלה.

בניגוד לגרסאות חלונותלפני Windows 2000שהשתמש בעיקר בפרוטוקול NetBIOSעבור רשתות, שירות Active Directoryמשולב עם DNSו TCP/IP. ברירת המחדל של פרוטוקול האימות הוא קרברוס. אם הלקוח או האפליקציה אינם תומכים באימות קרברוס, נעשה שימוש בפרוטוקול NTLM .

התקן

חפצים

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

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

הסכימה עצמה מורכבת משני סוגים של אובייקטים: אובייקטי מחלקת schema ואובייקטים של תכונות schema. אובייקט מחלקת סכימה אחת מגדיר סוג אובייקט אחד Active Directory(לדוגמה, אובייקט User), ואובייקט אחד של תכונת סכימה מגדיר תכונה שיכולה להיות לאובייקט.

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

מְכוֹלָהדוֹמֶה לְהִתְנַגֵדבמובן זה שיש לו גם תכונות ושייך ל-namespace , אבל בניגוד לאובייקט, קונטיינר אינו מייצג שום דבר ספציפי: הוא יכול להכיל קבוצת אובייקטים או מיכלים אחרים.

מִבְנֶה

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

ניתן לקבץ אובייקטים בדומיין לקונטיינרים - OUs. יחידות ארגוניות מאפשרות לך ליצור היררכיה בתוך תחום, לפשט את הניהול שלו ולאפשר לך לעצב את המבנה הארגוני ו/או הגיאוגרפי של חברה ב Active Directory. חטיבות יכולות להכיל חטיבות אחרות. תַאֲגִיד מיקרוסופטממליץ להשתמש בכמה שפחות דומיינים Active Directory, ולהשתמש בחטיבות למבנה ולמדיניות. מדיניות קבוצתית מיושמת לעתים קרובות במיוחד על יחידות ארגוניות. מדיניות קבוצתית היא בעצמה אובייקט. חטיבה היא הרמה הנמוכה ביותר שבה ניתן להאציל סמכות מנהלית.

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

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

מבנה פיזי ושכפול

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

שכפול Active Directoryמבוצע לפי בקשה. שֵׁרוּת בודק עקביות ידעיוצר טופולוגיית שכפול המשתמשת באתרים המוגדרים במערכת לניהול תעבורה. שכפול תוך-אתר מבוצע באופן תדיר ואוטומטי על ידי בודק עקביות (על ידי הודעה לשותפים לשכפול על שינויים). ניתן להגדיר שכפול בין אתרים לכל ערוץ של אתר (בהתאם לאיכות הערוץ) - ניתן להקצות "תעריף" (או "עלות") שונה לכל ערוץ (למשל DS3, , ISDNוכו') ותעבורת השכפול תהיה מוגבלת, מתוזמנת ותנותב בהתאם לאומדן הקישור שהוקצה. נתוני שכפול יכולים לעבור באופן טרנזיטיבי על פני מספר אתרים דרך גשרי קישורי אתר אם ה"ציון" נמוך, אם כי AD מקצה באופן אוטומטי ציון נמוך יותר עבור קישורים לאתר לאתר מאשר עבור קישורים מעבר. שכפול אתר לאתר מתבצע על ידי שרתי ראשי גשר בכל אתר, אשר לאחר מכן משכפלים את השינויים לכל בקר תחום באתר שלהם. שכפול תוך-דומיין מתבצע על פי הפרוטוקול RPCנוהל IP, cross-domain - יכול גם להשתמש בפרוטוקול SMTP.

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

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

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

שִׁיוּם

Active Directoryתומך בפורמטים הבאים של מתן שמות לאובייקטים: שמות טיפוסים גנריים UNC, כתובת אתרו כתובת אתר LDAP. גִרְסָה LDAPפורמט מתן שמות X.500 משמש באופן פנימי Active Directory.

לכל חפץ יש שם מכובד (אנגלית) שם מכובד, DN). לדוגמה, אובייקט מדפסת בשם HPLaser3ב-Marketing OU ובדומיין foo.org יהיה ה-DN הבא: CN=HPLaser3,OU=Marketing,DC=foo,DC=org , כאשר CN הוא השם הנפוץ, OU הוא הקטע, ו-DC הוא הדומיין מחלקת אובייקט. לשמות נכבדים יכולים להיות חלקים רבים יותר מאשר ארבעת החלקים בדוגמה זו. לאובייקטים יש גם שמות קנוניים. אלו הם השמות הנכבדים שנכתבו בסדר הפוך, ללא מזהים ושימוש בלוכסנים קדימה כמפרידים: foo.org/Marketing/HPLaser3. כדי להגדיר אובייקט בתוך המיכל שלו, השתמש שם מובהק יחסית : CN=HPLaser3 . לכל אובייקט יש גם מזהה ייחודי גלובלי ( GUID) היא מחרוזת 128 סיביות ייחודית ובלתי ניתנת לשינוי המשמשת ב Active Directoryלחיפוש ושכפול. לאובייקטים מסוימים יש גם שם עיקרי משתמש ( UPN, בהתאם ל RFC 822) בפורמט object@domain.

אינטגרציה עם UNIX

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

ספקי צד שלישי מציעים אינטגרציה Active Directoryעל פלטפורמות UNIX, כולל UNIX, לינוקס, MacOS Xומספר יישומים מבוססים Java, עם חבילת מוצר:

תוספות סכמטיות המסופקות עם Windows Server 2003 R2כוללים תכונות שקשורות מספיק ל-RFC 2307 כדי שיהיו שימוש כללי. יישומי בסיס של RFC 2307, nss_ldap ו-pam_ldap, מוצעים PADL.com, תומכים ישירות בתכונות אלו. הסכימה הסטנדרטית לחברות בקבוצה עוקבת אחר RFC 2307bis (מוצע). Windows Server 2003 R2כולל את Microsoft Management Console ליצירה ועריכה של תכונות.

חלופה היא להשתמש בשירות מדריכים אחר כמו שרת ספריות 389(קוֹדֶם שרת ספריות של פדורה, FDS), eB2Bcom ViewDS v7.1 ספרייה מופעלת ב-XMLאוֹ Sun Java System Directory Serverמ סאן מיקרוסיסטמס, המבצע סנכרון דו כיווני עם Active Directory, ובכך ליישם אינטגרציה "משתקפת" כאשר לקוחות UNIXו לינוקסמאומתים FDS, ולקוחות חלונותמאומתים Active Directory. אפשרות נוספת היא להשתמש OpenLDAPעם אפשרות של שכבת-על שקוף, הרחבת האלמנטים של השרת המרוחק LDAPתכונות נוספות המאוחסנות במסד הנתונים המקומי.

Active Directoryשימוש אוטומטי פגז כוח .

סִפְרוּת

  • ראנד מורימוטו, קנטון גרדינר, מייקל נואל, ג'ו קוקה Microsoft Exchange Server 2003. מדריך מלא = Microsoft Exchange Server 2003 שוחרר. - מ .: "וויליאמס", 2006. - ס' 1024. - ISBN 0-672-32581-0

ראה גם

קישורים

הערות

מה יעזור Active Directoryמומחים?

אני אתן רשימה קטנה של "טובים" שניתן להשיג על ידי פריסת Active Directory:

  • מסד נתונים של רישום משתמש יחיד, המאוחסן באופן מרכזי בשרת אחד או יותר; לפיכך, כאשר עובד חדש יופיע במשרד, תצטרך רק ליצור עבורו חשבון בשרת ולציין לאילו תחנות עבודה הוא יוכל לגשת;
  • מאחר שכל משאבי התחום מתווספים לאינדקס, הדבר מאפשר חיפוש פשוט ומהיר עבור משתמשים; לדוגמה, אם אתה צריך למצוא מדפסת צבעונית במחלקה;
  • השילוב של החלת הרשאות NTFS, מדיניות קבוצתית והאצלת שליטה יאפשרו לך לכוונן ולהפיץ זכויות בין חברי דומיין;
  • פרופילי משתמש נודדים מאפשרים לך לאחסן מידע חשוב והגדרות תצורה בשרת; למעשה, אם משתמש עם פרופיל נודד בדומיין מתיישב לעבוד על מחשב אחר ומזין את שם המשתמש והסיסמה שלו, הוא יראה את שולחן העבודה שלו עם ההגדרות הרגילות שלו;
  • באמצעות מדיניות קבוצתית, ניתן לשנות את ההגדרות של מערכות ההפעלה של המשתמשים, החל ממתן אפשרות למשתמש להגדיר טפט על שולחן העבודה להגדרות אבטחה, וכן להפיץ תוכנות ברשת, למשל, לקוח Volume Shadow Copy וכו';
  • תוכניות רבות (שרתי פרוקסי, שרתי מסד נתונים וכו') לא רק המיוצרות על ידי מיקרוסופט כיום למדו להשתמש באימות תחום, כך שאינך צריך ליצור מסד נתונים משתמש נוסף, אלא אתה יכול להשתמש באחד קיים;
  • השימוש בשירותי התקנה מרחוק מקל על התקנת מערכות בתחנות העבודה, אך, בתורו, עובד רק עם שירות הספריות המוטבע.

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

דומיינים -זוהי יחידת הבנייה הלוגית הבסיסית. בהשוואה לקבוצות עבודה דומיינים של ADהן קבוצות אבטחה שיש להן בסיס רישום יחיד, בעוד שקבוצות עבודה הן רק קיבוץ לוגי של מכונות. AD משתמשת ב-DNS (שרת שמות דומיין) לשירותי מתן שמות וחיפוש, ולא ב-WINS (שירות שמות אינטרנט של Windows), כפי שהיה בגירסאות קודמות של NT. לפיכך, שמות מחשבים בדומיין הם, למשל, buh.work.com, כאשר buh הוא שם של מחשב בדומיין work.com (אם כי זה לא תמיד המקרה).

קבוצות עבודה משתמשות בשמות NetBIOS. לארח מבנה דומיין מוֹדָעָהייתכן שאתה משתמש בשרת DNS שאינו של מיקרוסופט. אבל זה חייב להיות תואם ל-BIND 8.1.2 ומעלה ולתמוך ברשומות SRV() כמו גם בפרוטוקול הרישום הדינמי (RFC 2136). לכל תחום יש לפחות בקר תחום אחד המארח את מסד הנתונים המרכזי.

עצים -מדובר במבנים מרובי תחומים. השורש של המבנה הזה הוא הדומיין הראשי שעבורו אתה יוצר דומיינים צאצאים. למעשה, Active Directory משתמשת במערכת בנייה היררכית הדומה למבנה של תחומים ב-DNS.

אם יש לנו דומיין work.com (דומיין ברמה ראשונה) ויוצרים עבורו שני דומיינים צאצאים, first.work.com ו-second.work.com (כאן, הראשון והשני הם דומיינים ברמה השנייה, לא מחשב ב- domain, כמו במקרה שתואר לעיל), אז כתוצאה מכך נקבל עץ של תחומים.

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

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

לפיכך, יצירת הדומיין first.work.com מובילה לארגון אוטומטי של יחסי אמון דו-כיווניים בין האב work.com לילד first.work.com (בדומה ל-second.work.com). לכן, ניתן להחיל הרשאות מדומיין האב לדומיין הילד, ולהיפך. לא קשה להניח שיחסי אמון יתקיימו גם עבור תחומי ילדים.

תכונה נוספת של יחסי אמון היא טרנזיטיביות. אנו מקבלים - נוצר קשר אמון עם דומיין work.com עבור דומיין net.first.work.com.

יער -בדיוק כמו עצים, הם מבנים מרובי תחומים. אבל יַעַרהוא איחוד של עצים שיש להם תחומי שורש שונים.

נניח שאתה מחליט להחזיק במספר דומיינים בשם work.com ו-home.net וליצור עבורם דומיינים צאצאים, אך מכיוון ש-tld (דומיין ברמה העליונה) אינו בשליטתך, במקרה זה תוכל לארגן יער על ידי בחירת אחד מהראשונים דומיינים ברמה היא השורש. היופי ביצירת יער במקרה זה הוא יחסי האמון הדו-כיווניים בין שני התחומים הללו לבין תחומי הילד שלהם.

עם זאת, כאשר עובדים עם יערות ועצים, זכור את הדברים הבאים:

  • לא ניתן להוסיף דומיין קיים לעץ
  • לא ניתן לכלול עץ שכבר קיים ביער
  • אם דומיינים ממוקמים ביער, לא ניתן להעביר אותם ליער אחר
  • אינך יכול למחוק דומיין שיש לו דומיינים צאצאים

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

במילים פשוטות, אפשר להגדיר מנהל בדומיין שיכול לנהל את ה-OU, אבל אין לו את הזכויות לנהל את כל הדומיין.

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

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

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

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

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

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

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

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

קבוצות משתמשים ומחשבים -משמשים למטרות ניהול ויש להם אותה משמעות כמו בשימוש במכונות מקומיות ברשת. בניגוד לארגונים ארגוניים, לא ניתן להחיל מדיניות קבוצתית על קבוצות, אך ניתן להאציל עליהן שליטה. במסגרת סכימת Active Directory, ישנם שני סוגים של קבוצות: קבוצות אבטחה (המשמשות להבדיל זכויות גישה לאובייקטים ברשת) וקבוצות הפצה (המשמשות בעיקר לשליחת הודעות דואר, למשל, ב-Microsoft Exchange Server).

הם מסווגים לפי היקפם:

  • קבוצות אוניברסליותעשוי לכלול משתמשים בתוך היער וכן קבוצות אוניברסליות אחרות או קבוצות גלובליות מכל תחום ביער
  • קבוצות גלובליות בתחוםעשוי לכלול משתמשי דומיין וקבוצות גלובליות אחרות באותו דומיין
  • קבוצות מקומיות בתחוםמשמש להבדיל זכויות גישה, יכול לכלול משתמשי דומיין, כמו גם קבוצות אוניברסליות וקבוצות גלובליות של כל דומיין ביער
  • קבוצות מחשבים מקומיות– קבוצות שה-SAM (מנהל חשבונות האבטחה) של המחשב המקומי מכיל. ההיקף שלהם מוגבל רק למחשב הזה, אבל הם יכולים לכלול קבוצות מקומיות של התחום שבו נמצא המחשב, כמו גם קבוצות אוניברסליות וגלובליות של תחום משלהם או אחר שהם סומכים עליהם. לדוגמה, אתה יכול לכלול משתמש מהקבוצה המקומית של הדומיין משתמשים בקבוצת המנהלים של המחשב המקומי, ובכך לתת לו זכויות ניהול, אבל רק עבור מחשב זה
דירוג מאמר:
כוכב אחד2 כוכבים3 כוכבים4 כוכבים5 כוכבים(עדיין אין דירוגים)
טוען...
לשיתוף עם חברים:
מאמרים קשורים
סגור
מצא באתר
לדוגמה: סוגי קיר גבס