מבוא Active Directory

בס"ד

מבוא לעבודה בסביבה עסקית

מהו Domain?

עד עתה עסקנו במערכת Windows 7 שנמצאת בסביבה פרטית, קרי Workgroup. בסביבה שכזאת, כל מחשב "אחראי לעצמו". למשל, אם במחשב שלי בבית יש משתמש בשם Oren עם סיסמה כלשהי, אז המשתמש הנ"ל יוכל להיכנס למערכת עם המשתמש שיצרתי בעבורו. כל מחשב ומחשב שומר את הנתונים על המשתמשים וסיסמאותיהם בחלק של ה-Registry שנקרא: SAM (Security Accounts Manager). לעומת זאת, בסביבה של Domain הדברים קורים מעט אחרת. ההחלטה אם משתמש ייכנס למחשב כזה או אחר נמצאת בידי שרת שנקרא Domain Controller ("שליט הדומיין") ובקיצור: DC. שרת DC לא "נולד כזה". בהתחלה הוא היה שרת רגיל לכל דבר ועניין, רק שבשלב מסויים התקינו עליו את תוכנת Active Directory ומאותו הרגע הוא נהיה "השליט". מעכשיו , כל רשימת המשתמשים שרשאים להיכנס למחשבי החברה יירשמו בתוך Active Directory. מי שרשום מקבל אישור כניסה למערכות בארגון, מי שלא רשום נבעט החוצה בבושת פנים. אתם אולי שואלים כיצד מתקינים Active Directory על שרת וזאת אכן שאלה חשובה שנדון בה, אבל לפני שניכנס לפרטים הטכניים, עלינו להבין מעט - מה זה אומר באמת להיות חלק מסביבה של Domain? ננסה כעת להגדיר מהו Domain.

הגדרת ה-Domain:

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

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

1. גבול השמות:
   
   
   
   • לכל ארגון יש שם, למשל: Google.com, או Intel.co.il. שם הארגון מקבל גם לעתים את הכינוי: Domain Suffix או DNS Suffix.
   
   
   • אנו כבר יודעים שלכל Client בארגון צריך שיהיה שם מחשב ייחודי משלו, למשל: Comp1. כאשר המחשב הוא חלק מארגון, יתווסף שם הארגון (Domain Suffix) לשם המחשב. למשל: Comp1.google.com יהיה המחשב Comp1 בתוך הארגון Google.com.
   
   
   • נמצא אם כך שכל מחשב שסיומתו תהיה Google.com שייך בהכרח ל-Domain ששמו: Google.com. כאשר אנו מציגים את שם המחשב במתכונתו המלאה (עם שם הארגון) הוא מקבל את ההגדרה: FQDN שזה Fully Qualified Domain Name, או בעברית שם "דומייני" מלא של המחשב.
   
   
   • נמצא ש-Comp1 הינו שם המחשב עצמו; Google.com הוא ה-Domain Suffix; וה-FQDN הוא: Comp1.google.com.
   
   
   • עוד דוגמא נפוצה. בהרבה מקרים שרת אינטרנט ייקרא בשם: www. נמצא שה-FQDN שלו בתוך הארגון: Google.com יהיה: www.google.com. נשמע מוכר, לא?
   
   
   
   


2. גבול האוטנטיקצייה והאבטחה:
   
   
   
   • כמו שכבר הגדרנו, כל המחשבים שב-Domain יזוהו על-ידי Active Directory. זאת אומרת, ש-Active Directory יכולה לשלוט רק על מחשבים המשוייכים לארגון. כיצד נשייך מחשבים לארגון? על זה נדבר בשיעור אחר.
   
   
   
   


3. גבול הרפליקצייה:
   
   
   
   • עד עכשיו דיברנו על מצב שבו יש DC אחד ב-Domain והוא שולט על ה-Domain. אבל מה יקרה אם יש שני DCs ב-Domain?
   
   
   • המצב של יותר מ-DC אחד ב-Domain הוא מצב נפוץ מאוד, שכן במידה ואחד נופל השני עדיין מתפקד ועבודת הארגון לא נפגעת.
   
   
   • בעיה שזועקת מכאן היא מה יקרה אם יהיה כתוב בשני ה-DCs מידע שונה? למשל, נניח שב-DC אחד יש מידע על משתמש בשם John וב-DC השני המידע לא נמצא. המשתמש John מעוניין להיכנס למחשבי החברה ולהתחיל את יום העבודה. מה יקרה? האם הוא יוכל להיכנס בזכות ה-DC שבו הוא רשום, או שאולי הוא יידחה בגלל ה-DC השני שלא מכיר אותו?
   
   
   • למזלנו הבעיה מהסעיף הקודם לא מתרחשת במציאות (על מקרים חריגים עוד נדון בהמשך) מכיוון שברגע שיש שינוי של מידע באחד מה-DCs מיד המידע מועתק ל-DC השני. העתקה שכזאת נקראת רפליקצייה.
   
   
   • הטריגרים לקיום רפליקצייה הן:
     
     
     
     1. הוספת אובייקט, כגון הוספת משתמש.
     
     
     2. מחיקת אובייקט, כגון מחיקת משתמש.
     
     
     3. שינוי ב-Properties של אובייקט.
     
     
     4. שינוי מיקומו של אובייקט ב-Active Directory.
     
     
     
     
   
   
   • כך מובטח לנו שהמידע בין כל ה-DCs ב-Domain יהיה זהה ולא יהיה חוסר עקביות לגבי השאלה מי חבר ב-Domain ומי לא.
   
   
   
   

על עצים ויערות:

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

Tree: כאשר יש לדומיין מסויים תת-דומיין, שמו יורכב משם ייחודי משלו בתחילה ולאחר מכן שם הדומיין שמעליו (Parent Domain). למשל, תחת ה-Domain בשם Google.com יכול להיות דומיין בשם: North.google.com. מחשב בשם comp1 בתת-הדומיין יקבל את ה-FQDN: comp1.North.google.com. שמות "עקביים" שכאלה נקראים בשם: Contiguous Name Space.

מבנה כפי שהגדרנו נקרא עץ, או Tree. כאשר הדומיין הראשון שהעץ יוצא ממנו נקרא: Tree Root (שורש העץ). שמתם לב שהעץ הוא קצת הפוך? ?

Forest:

אבל ניתן גם ליצור Tree חדש לחלוטין, וכך בעצם יש לנו "יער". המונח באנגלית הוא: Forest. בעוד שתתי-דומיינים בתוך Tree מחוייבים להיות עם Contiguous Name Space, בין Trees שונים אין שום דרישה שכזאת. למשל, ייתכן ויהיה לנו דומיין בשם: Google.com ודומיין בשם: Commit.co.il ושניהם שייכים לאותו הארגון – או במלים אחרות, הם באותו ה-Forest.

הדומיין הראשון בכל ה-Forest נקרא: Forest Root.

שאלה: האם ייתכן שדומיין יהיה גם Forest Root וגם Domain Root?

לכאורה, הדבר הוא קשה מאוד. לפחות בין דומיינים באותו Tree אנחנו רואים קשר מסויים, אבל בין דומיינים ב-Forest לא רואים שום קשר. מה, איפוא, בכלל מחבר ביניהם? למה Commit.co.il כן נמצא באותו ה-Forest עם Google.com – בעוד Ebay.com לא נמצא?

התשובה היא: מה שמחבר בין כל הדומיינים ב-Forest – מה שקיים בין Google.com ו-Commit.co.il בודגמא שלנו הוא: Implicit 2-way Transitive Trust!

Implicit 2-way Transitive Trust:

נבאר את המונח דווקא לא לפי הסדר:

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


• Implicit – "משתמע". הכוונה היא שברגע שבו יצרתי Forest כבר קיים ה-Trust הנ"ל. אין לי צורך ליצור אותו, וגם אין לי יכולת להסיר אותו! לא מעוניינים ב-Trust? אל תצרו Forest.


• 2-way – "דו-כיווני". כשם שדומיין אחד סומך על השני, כך גם להיפך.


• Transitive – ה-Trust מקיים את כלל הטרנזיטיביות. הרעיון הוא כזה: אם דומיין A סומך על דומיין B, ודומיין B סומך על דומיין C – נמצא שדומיין A סומך על דומיין C.

הקמת DC (התקנת Active Directory) –

• שימו לב שהשרת מחולק ל-Roles ו-Features. Role הינו "שרת" שניתן להתקנה, ו-Feature היא פונקציה שניתן להוסיף. למשל, שרת DNS יהיה Role והיכולת להשתמש ב-Wi-Fi תהיה Feature. לעתים התקנת שרת תתקין באופן אוטומטי Feature שהשרת משתמש בו.


• כניסה לשליטה על Roles ו-Features תהיה דרך Server Manager.


• אחד מה-Roles הינו Active Directory Domain Services או AD DS. ננסה להתקין את ה-Role הנ"ל.


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


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


• ניתן להשתמש בתוכנת DCPromo באופן ישיר, גם מבלי להתקין את AD DS Role לפני.


• אם יש כבר על השרת Active Directory, אז תוכנת DCPromo תעשה את הפעולה ההפוכה – קרי, תמחוק את Active Directory!

תרגיל: התקינו A.D. על שרת חבר בדומיין, כך שיהיו שני DCs בדומיין. הוכיחו כי הוספת משתמש ב-A.D. אחת, תגרור מיד רפליקצייה של המידע ל-A.D. השניה.