תכנון ופריסה של AD

מבוא
הקמה ותכנון של מערכת Active Directory תחת חלונות 2000/2003/2008 היא תהליך המחייב איזון הולם בין שיקולי תכנון מראש לבין תוכנית פריסה בדוקה היטב. מאמר זה לא נועד על מנת לתת למנהל הרשת נקודות כלליות ולהתוות את השיקולים הכלליים שיש להביא בחשבון על-מנת להתמיע בהצלחה Active Directory בארגון בו הוא עובד, ומציג גם טיפים חשובים המתבססים על הניסיון מעשי שלי ושל קולגות. כמו כן, מייקרוסופות ממליצה על גישת ה- Best Practices המבוססת על הניסיון המעשי שרכש צוות הפיתוח של Active Directory בעבודתו עם ארגונים שממשו בהצלחה את הטכנולוגיה. גישה זו תורמת לקיצור סבבי התכנון הודות ליתרונות הבאים:

• קידום תקנים, הליכי תיכון בדוקים של Active Directory.

• התמקדות באפשרויות תיכון שהוכיחו את הצלחתן ב- Windows NOS management role.

• הבהרת אבני הדרך של משימות הפיתוח וסדר המשימות בעזרת תרשימי זרימה וגיליונות עבודה.

• הספקת תרחישים לחיזוק עקרונות התיכון.


רם ברצונך לקרוא עוד חומר בנושא מהאתר הרשמי של מייקרוסופט, אתה מוזמן ללחוץ על הלינק הנ"ל: http://technet.microsoft.com/he-il/windowsserver/2000/default(en-us).aspx

פעולות ראשונות: קביעת מספר ה- forests של Active Directory
עד כמה שהדבר ישמע מובן מאליו, הצעד הראשון שיש לעשות תמיד הוא להבין את סביבת העבודה הקיימת ואת הדרישות והצרכים של הארגון (העכשויים והעתידיים). על התיכנון לשרת את הצרכים והתוכניות הקיימים, אך לתת מענה גם לאלה העתידיים. במהלך התיכון יהיה עליכם להביא בחשבון שיקולים שונים: תכנון namespace (מוסכמות למתן שמות), מספר האובייקטים וגודלם, branches פיסיים ומיקומים גיאוגרפיים, מיזוגים/רכישות ועוד. עיצוב forest כולל היערכות ותכנון של domains, DNS, Organizational Units וטופולוגיה פיסית (אתרים).

ראשית יש לקבוע את מספר ה- forests - יער. הכי קל ופשוט לממש forest יחיד. הוא אופטימלי מבחינה פונקציונלית וגם יעיל במונחים של חיסכון כסף ומשאבים, אולם לא כל ארגון יכול להסתפק במודל המבוסס על forest יחיד. כל ה- domains הכלולים ב- forest משתפים ביניהם סכמה, תצורה (Configuration‏), Global Catalog ויחסי Trust מלאים. forest יחיד יכול לבוא בחשבון במקרה שקיימת הסכמה על הגורם שישלוט בסכמה ובפרמטרי התצורה של כלל ה- forest, וכאשר ברור לכם שניתן לבטוח בבעלי ה- forest ובבעלי ה- domain. בכל מקרה שתבחרו, ה- Domain Controllers חייבים להיות מאובטחים פיסית. עיצוב מרובה-forests טומן כמה השלכות. לא קיים אמון אוטומטי (Trusts) בין forests. Kerberos אינו זמין בין forests ב- Windows 2000. עם זאת, קשרי אמון שקופים חוצי-forest אכן קיימים ב- Windows Server 2003. בנוסף, דרושה טכנולוגיית סנכרון (כגון MMS – Microsoft MetaDirectory Services) כדי שה- Global Catalog יכיל אוסף קולקטיבי של כל האוביקטים ב-Forests השונים. כמו כן, יכולות להיות השפעות על תפקוד ה EXCHANGE וה SQL SERVER.

תכנון Domain
לאחר קביעת מספר ה- forests, ממשיכים בתכנון ה- domains. בחרו forest root domain. בחרו גם את מודל ה- domain: מודל שורש ייעודי (Dedicated Root) מאפשר העברה קלה ופשוטה של בעלות על forest ומבודד את מנהלי המערכת של ה- forests ממנהלי מערכת רגילים. במודלים של domain, כמו ב- forests, עץ בודד הוא הצורה הפשוטה ביותר – במקרה שלא קיים צורך מיוחד בעצים רבים או במרחב שמות מפורק (disjoint namespace). ניתן גם לפצל את ה- domains בצורה גיאוגרפית, כך שימופו למיקומים גלובאליים בפועל. מיפוי למיקומים גיאוגרפיים הולם היטב בדרך-כלל את מתווה הרשת המקומית או המרחבית. המודל מצטיין גם ביציבות, מכיוון שהמערך הגיאוגרפי אינו משתנה באופן יחסי. תנו ל- root domain שם ובחרו עבורו סיומת DNS, תוך התחשבות במגבלות הנובעות ממוסכמות (naming conventions): התווים המותרים הם A-Z, a-z, 0-9, - (מקף אמצעי). חשוב לזכור שאורך התחילית ושם ה- NETBios לא יחרוג מ- 15 תווים. לאחר שקבעתם את סיומת DNS, הקפידו לרשום אותה אצל ספק שירותי האינטרנט. גם אם אינכם מתכננים להשתמש בסיומת זו כיום בצורה גלויה באינטרנט, עליכם להיות הבעלים של שם DNS שבחרתם לצורך יישום ברחבי הארגון. (אבל ביננו, בעידן ה TCPIP, מי עובד עוד עם NETBios ???)

DNS
DNS הוא שירות חשוב ב- Windows 2000 Active Directory domain והכרחי במהדורות מתקדמות יותר (2003 ו 2008) ומשמש לביצוע פעולות רבות, כגון מנגנון DC locator (איתור Domain Controllers). שרת ה- DNS דורש שה- Authoritative DNS Server של שירותי ה- locator עבור DCs יתמוך ברשומות משאבי SRV ‏(SRV Records). כתנאי יסודי של שירותי ה- DCs locator, מומלץ גם שהוא יתמוך בעדכונים דינמיים (RFC2136)‏.

קיימות שלוש אפשרויות בבואכם לחבר את תשתית DNS ו- AD:

• לא קיימת תשתית DNS

• מרחב השמות של AD אינו מתלכד עם מרחב השמות של DNS (לדוגמה, DNS משמש עבור corp.MyCompany.com, ואילו AD משתמש ב- corp.MyCompany.com או ב- MyCompany.net).

• מרחב השמות של AD מתלכד עם זה של DNS (לדוגמה, MyCompany.com משמש את איזור DNS וגם את שם ה- domain).


במקרה שמרחבי השמות אינם מתלכדים, פשוט הקצו (delegate) את האיזור (DNS Zone) אל Windows DNS Server (לדוגמה, מ- MyCompany.com, הקצו את corp.MyCompany.com ל- AD domain DNS Server). אם פעלתם לפי נוהלי העבודה הנאותים לבחירת שמות בשלבי תהליך השיום (נתינת שמות ע"פ מוסכמות), כל שעליכם לעשות הוא להקצות שליטה בשם שבחרתם עבור שרתי Windows DNS הרצים ב- AD domain controllers.

כאשר משתמשים בשרתי Windows 2000 DNS Server, מומלץ גם לאחסן את אזורי ה-DNS ב-AD ‏(Active Directory integrated zones). כאשר אזורי DNS מאוחסנים ב- AD, הם משתכפלים ב- Domain Controllers נוספים, ובאפשרותכם להשתמש בעדכונים דינמיים מאובטחים. אם משתמשים ב-AD Integrated Zones וקורה משהו לשרת ה- DNS, כל שצריך לעשות הוא להוסיף את שירות ה- DNS בשרת אחר, והוא יקרא את כל המידע על ה-Zones ופרטי הרישום מתוך Active Directory. אחד מה- Best Practices החשובים ביותר בטיפול ב- DNS, הוא להקצות את האיזור _msdcs.ForestRoot.com לכל שרתי ה- child domains DNS Server ולהפוך אותם ל- Authoritative עבור איזור זה. יש להקצות את איזור ה- forest root הנדון ולהפוך את כל שרתי ה- DNS Server ל- Authoritative עבור איזור זה, בעוד ששרתי ה- Forest Root DNS Server נותרים בתור שרתים ראשיים (Primary), וכל שאר שרתי ה- DNS הופכים למשניים (Secondaries) עבור איזור זה. הקצאה זו חשובה, מכיוון שאם אתר מרוחק מאבד קישוריות רשת כלפי שאר חלקי הארגון, הוא מאפשר לאתר את ה- Global Catalogs ואת replication partners ‏(Domain Controllers) המקומיים.

באשר לתצורת תחנות העבודה מול ה DNS: יש להגדיר כל לקוח כך שיוכל לתשאל לפחות שני שרתי DNS הקרובים ביותר. כך מגדילים את העמידות לתקלות ומצמצמים את נפח תעבורת הרשת. מומלץ מאוד גם שה- Primary DNS Suffix של מחשבים תהיה זהה לשם ה- Domain DNS. אם אין התאמה בין השניים, המשתמשים יהיו רשאים לגשת לשרתים בשמותיהם הישנים, אך אימות Kerberos לא יהיה אפשרי ללא עדכונים ידניים של חשבון מחשב השרת.

באפשרותכם לבצע משימות DNS רבות משורת הפקודה בעזרת התוכנית DNSCMD.exe הכלולה בכלי התמיכה של Windows - ניהול Zones, הוספה/הסרה של רשומות מ- DNS ועוד.

DNS של Windows Server 2003 יציג כמה שיפורים חדשים, כגון Conditional forwarding (העברה מותנית של טיפול בבקשות DNS Resolution) ו- Stub Zones, בתוספת רכיבים חדשים נוספים. Windows .NET יכלול גם הגדרות Group Policy השולטות בהגדרות DNS של הלקוח (כגון סיומת DNS ורשימת DNS Servers).

יחידות ארגוניות – Organizational Units
Organizational Units (יחידות ארגוניות, בקיצור – OU) מייצגות את המבנה הלוגי של עץ Active Directory, ו- Sites, subnets ו- site links מייצגים את המתווה הפיסי של הרשת. חשוב לזכור להבדיל בין המתווה הלוגי לבין המתווה הפיסי בתהליך התיכון.

יש להצדיק כל OU (יחידה ארגונית) שמוסיפים ל- domain. זכרו שהיחידות הארגוניות משמשות להכלת אובייקטים כדי להקצות הרשאות, להקצות הגדרות מדיניות (Group Policies) והסתרת אובייקטים או חלקים של מבנה העץ. למרות שלא קיימת מגבלה טכנית כלשהי, מומלץ להגביל את קינון היחידות הארגוניות (OU nesting) ל- 10 רמות או פחות, כדי להימנע מסיבוכים תהליך התיכון והניהול השוטף של אובייקטים. זכרו תמיד כי ההיררכיה המחלקתית אינה חייבת בהכרח לשקף את ההיררכיה של OUs; היא אינה צריכה לייצג את תרשים מבנה הארגון, אך תוכלו לעשות זאת, אם תצדיקו את המבנה בעזרת סיבות הולמות (delegation‏, Group Policies וכו'). אם קיימת יחידה ארגונית שאין לה מטרה מוגדרת, קרוב לוודאי שלא היה צורך ליצור אותה.

אתרים – Sites
תהליך תכנון אתרים צריך לכלול את השלבים הבאים:

1.
זיהוי מיקומים פיסיים

2.
הצבת DCs במיקומים בהתאם לצרכים שלהם

3.
הגדרת מיקומים עם DCs כאתרים (Sites)


יש להציב את PDC Emulator FSMO role DC באתר בעל קישוריות רשת טובה, ובמידת האפשר באתר בעל מספר המשתמשים הגדול ביותר ב- domain. אם מספר האתרים במיקום אחד עולה על 200 ו/או מספר ה- Site Links שלו עולה על 20, פעלו בהתאם להמלצות של מדריך הפריסה של Active Directory Branch Office Planning Guide. במקרים מסוימים, כאשר מספר האתרים גדול מאוד, יש להשבית את ISTG ‏(Inter Site Topology Generator) בסביבת Windows 2000‏. Windows .NET, לעומת זאת, מטפלת בנושא ללא קושי, הודות לביצועים המשופרים שלה ברכיב ה-KCC שנכתב מחדש.

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

זהו בקצרה.