שאלה על logon לדומיין -

I

ilusy

New member
שאלה על logon לדומיין -

שלום רב :) לפי מה שהבנתי - על מנת שמשתמש יוכל לעשות Logon לדומיין שרץ ה- global catalog חייב להיות פעיל . ננסח זאת אולי אחרת - במידה ושרת ה-gc יהיה למטה לא יהיה ניתן לבצע Logon לדומיין - ( מערכת ההפעלה תשתמש ב-cach ותחבר את המשתמש למחשב הלוקאלי לבד ). שאלה 1 - האם ההנחות הללו נכונות ? שאלה 2 - ההמלצות של מיקרוסופט הינם שיהיה gc כל site . בהנחה שאין sites ויש כמה דומיינים האם זה אחראי שיהיה רק gc אחד ? לפי התאור הנ"ל תפקידו של ה-gc בתהליך האוטנטיקציה כל-כך חשוב שכדאי שיהיו לפחות שתיים ? מה עוזר לנו אם הגדרנו 3 dcs שונים , על מנת לטפל בגישה של משתמשים לדומיין יחיד בעוד ה-gc של ה-forest למטה ? המשך - שרת ה-gc חשוב היות והוא חופן בתוכו את השייכויות של המשתמשים ל-univeral groups , ובכך הוא יכול לאפשר למשתמש מדומיין אחד להשתמש במשאבים הנמצאים בדומיין אחר . לפי מה שקראתי גם ה-dc עם ה-infrastructure role (אחד בדומיין), מחזיק בתוכו את שייכות המשתמשים לקבוצות יויברסליות בכל ה-forest מה שמוביל אותי לשאלה מספר 3 - מדוע שרת ה-infrastructure לא יכול לבדוק את שייכות המשתמשים לקבוצות יוניברסליות ובכך לבצע את שירות האוטנטיקציה במקום ה-gc , במידה וה-gc למטה ? תודה
 
M

Motel

New member
Global Catalog

1. לא מדויק כ"כ. הסיבה שבכלל זקוקים ל-GC היא שבתהליך הכניסה לרשת נבנה security token שכולל בין השאר SID עם כל הקבוצות שאליהן המשתמש שייך (לרבות universal groups). אם ה-DC לא יכול למצוא GC, ינסה לעשות שימוש ב-cache, אם לא קיים cache - לא תהיה כניסה לרשת (יוצא מהכלל: built-in administrator). 2. מה זה אין sites? תמיד יש לפחות את Default-First-Site. מומלץ מסיבות של ביצועים למקם לפחות GC אחד לכל site, אבל במידת-הצורך יכולים לפנות ל-GC שיושב באתר מרוחק.
 
A

antidot

New member
עשית קצת סלט

אשתדל לתמצת בצורה ברורה - התשובה המלאה די ארוכה ומייגעת.. הנחות: - כל שרת GC הוא בהכרח DC. לא כל DC הוא GC - מותר (ורצוי) שיהיו יותר מGC אחד בforest - התפקיד של GC לא כפוף לדומיין, אלא לforest, ז"א שGC שנמצא בדומיין A יכול לשרת גם את הדומיין B (באותו forest ) בתור GC - בתהליך הlogon מי שמבצע את האוטנטיקציה זה DC. יש צורך לתשאל את GC בשביל למשוך את רשימת הuniversal groups אליהן שייך חשבון משתמש/מחשב. בברירת מחדל Domain Admins יכולים לבצע logon אפילו אם אין אף GC זמין. ההגדרה ניתנת לשינוי בGPO של Domain Controllers, ז"א שאפשר לקנפג את הסביבה כך שלא תהיה דרישה לGC זמין בתהליך logon 1 ראה נחות מעלה 2 בכל forest יש לפחות site אחד. לא ייתכן forest ללא sites. התפקיד של sites הוא למפות בצורה את מבנה הרשת של האירגון ו"להציג" את המבנה הלוגי לAD בשביל שהAD יוכל לתפקד בצורה יעילה (רפליקציה, אוטנטיקציה מול DC הקרוב וכו') כיוון שכל site אמור לייצג יחידה לוגית בעלת קישוריות טובה בין כל האובייקטים הנמצאים באותו site, ההמלצה היא לשים לפחות GC אחד בכל site על מנת שלקוח לא יצטרך ללכת לsite מרוחק (דרך WAN ?) על מנת לתשאל GC. ההמלצה היא כללית למדי ויש לא מעט הסתייגויות כאשר מדברים על מה שנקרא branch office deployment. כעקרון זהו כלל אצבע לרב המקרים (אבל לא לכולם). נושא הInfrastructure Master התפקיד של IM שונה מהתפקיד של GC. התפקיד של IM הוא לתחזק מה שנקרא phantom objects ואני אסביר ע"י דוגמא: יש forest בשם domain.loc עם שני תת-דומיינים: child1.domain.loc child2.domain.loc נניח ויש קבוצה לוקלית child1\lgGroup1 שמכילה משתמש child2\user1. כיוון שDC של CHILD1 לא מכיר אובייקטים מדומיינים אחרים, מבחינתו מדובר במה שנקרא foreign security principal שניתן לאתר אותו ע"י אובייקט בIM שייצג את האובייקט מדומיין אחר. אותו phantom object בIM של CHILD1 למעשה מייצג את האובייקט ב-CHILD2 (עבור כל אובייקט כזה מדומיין אחר נוצר Phantom בתוך IM). בנוסף באחריות הIM לעקוב אחרי שינויים של האובייקט אליו הוא מצביע (שינוי שם, שינוי DN וכו') לקוחות קצה לא יכולים לתשאל ישירות את IM. IM מחזיק phantoms רק עבור אובייקטים שהשתמשו בהם בCHILD1. ז"א שאם קיים משתמש user2 בדומיין CHILD2, אבל הוא אף פעם לא הוזכר בCHILD1, ה-IM של CHILD1 לא יכיר בו (עד שמישהו מCHILD1 לא ינסה לפנות לאותו user2 מדומיין CHILD2) יתרה מכך, IM לא מחזיק object attributes בתוך phantom objects. מדובר סה"כ במין "פרוקסי" או יותר נכון "פוינטר" לאובייקט מדומיין אחר. GC מצד שני מחזיק נתונים חלקיים (לא את כל הattributes) על כל האובייקטים בFOREST. כמה נקודות נוספות בעניין GC-ים ו-IM - בforest בעל domain יחיד אין צורך בIM - ניתן להפוך את כל הDC-ים ל-GC-ים עם כמה הסתייגויות: א. בכל דומיין נתון ב-forest מותר שכל הDC-ים יהיו GC-ים ב. אם בforest בעל יותר מדומיין יחיד יש דומיין שבו לא כל הDC-ים הם GC-ים, אזי אסור שהתפקיד של IM ימצא על GC מקווה שהייתי מספיק ברור
 
I

ilusy

New member
תודה וסליחה לגבי -

העניין שכתבי במידה ואין sites , התכוננתי כמובן במידה וקיים רק site אחד שהוא ה-defaultfirssite כברירת מחדל , ולא קיימים שני sites . בכל אופן - עדיין לפי מה שהבנתי , במידה וה-gc לא יהיה זמין, לא תהיה גישה לשום משתמש בדומיין חוץ מאלה החברים בקבוצת domain admins . כלומר - במידה ויש site אחד בו יהיו לצורך העניין 6 דומיינים, עם 10000 משתמשים, gc אחד . במידה וה-gc ייפול לא תהיה גישה לשום משתמש לדומיין , חוץ מקבוצת domain admins . השימוש ב-cache בתחנה המקומית ייתן אפשרות כניסה אך ורק למחשב המקומי, ולא לדומיין עצמו . הפתרון שנתת - לבטל במצב כזה דרך ה-group policy של ה-dcs את החובה של gc בתהליך ה-logon , נראה לי הגיוני . כמו כן רציתי להגיד שלדעתי במידה ויש site אחד מרובה דומיינים כדאי להגדיר עוד gc , על מנת שאם gc אחד ייפול יהיה גיבוי . כמובן שהדבר ייגרום לרפליקציה מוגברת ועומס מסויים , אך לדעתי מדובר בנקודה שיכול להוות פתרון לבעייה קריטית . לגבי התפקיד של ה-gc בתהליך האוטנטיקציה - לא הבנתי מדוע יש חובה שה-gc יהיה זמין בתהליך האוטנטיקציה . במידה ולדוגמא ה-gc לא יהיה זמין , אזי יהיה מצב שהמשתמש לא יהיה שייך לקבוצות היונברסליות אליהם הוא מיועד , אבל מדוע למנוע כניסה בכזה מצב לדומיין לכל המשתמשים הרגילים ( לא admins ), מה ההגיון מאחורי זה ? אולי באמת קיימת סיבה אבטחתית, לכך שיש חובה שהאוטנטיקציה תעבור דרך ה-gc ? האם ל-gc אכן יש גם תפקיד אבטחתי ? וחוץ מזה - תודה רבה על התשובה הארוכה והמושקעת שנתת .
 
A

antidot

New member
אתה מפספס

זה נכון שבמידה ואין GC זמין (בכל הforest), אין אפשרות למשתמשים רגילים לבצע logon. מצד שני אין שום סיבה שבדומיין בעל 6 דומיינים יהיה אך ורק GC יחיד. כפי שכבר אמרתי: ניתן להפוך את כל הDC-ים לGC-ים. הפתרון הוא לא להתעסק עם GPO, אלא להגדיר יותר מGC אחד בforest. עוד נקודה: site לא קשור כ"כ לדומיינים. site הוא מונח השייך ל forest ומתאר סגמנט רשת לוגי (המוגדר לפי subnets ששייכים לאותו site ) למה לחסום גישה כאשר GC לא זמין ? כי לא מדובר אך ורק על קבוצות אוניברסליות. אם תוסיף לסביבה שלך Exchange (שנשען בצורה כבדה על GC) תבין שבסביבה שבה אין GC מתפקד אתה לא רוצה משתמשים ברשת, כי המצב חרבנה ואתה צריך לתקן אותו. הסיבה לחסימה היא גם קונסיסטניות וחלקית גם אבטחתית: תאר לעצמך מצב בו חסמת גישה למשאב ע"י DENY לקבוצה אוניברסלית. מה קורה במצב כזה אני משאיר כתרגיל לקוראים. נקודת הרפליקציה שהעלת במקרה של יותר מGC יחיד הינה נקודה לגיטימית, אבל מוכרת היטב. יש המון דרכים לייעל רפליקציה, אבל קטונתי מלהסביר את העניין על גבי הפורום - יש המון ספרים בנושא. המלצה אישית: Inside Active Directory
 
ה

הקטור זולטן

New member
שאלה

הXCH נשען בצורה כבדה על הGC בשביל ה - Directory Service שלו? אם לא, אז למה? ועוד שאלה קודמי הניח ששווה לגבות את הGC וליצור עוד אחד למקרה שהוא נופל במצב של ריבוי דומיינים ויחידות של GC אבל לא יהיה נכון להניח שאם הGC נמצא על DC, והוא ייפול, כנראה שכל הDC נפל? \ לא עדיף לגבות דברים קריטיים יותר?
 
I

ilusy

New member
כמו ש-anti אומר - "סלט"

application directory service הינו partition נוסף ( חלק נוסף ), שהתווסף לסינכרון ב-ad . ב-win2000 היו רק 3 partition שהם -schema, domain, configuration . מה שהתכוונת לדעתי להגיד הוא שה-exhchange משתמש ב-feature החדש של ad 2003 , על מנת לבצע סינכרון . כמו שאמרו מקודם - חייב להיות gc אחד בכל ה-forest , ה-gc הינו domain controller שלקח על עצמו role מיוחד - לאסוף מידע (חלקי) על כל האובייקטים בכל ה-forest . במידה וה-gc ייפול ברור שה-dc שיחד איתו ייפול ( כמו שהגדרת את זה ). במידה ויהיה עוד dcs בדומיין תוכל להתבצע אוטנטיקציה וכניסה לדומיין , דרך אותם dcs . ( במידה כמובן ויש עוד gc בכל ה-forest ). בד"כ מקובל, אם אפשר להגיד דבר כזה שיש 2-4 dcs בדומיין . כך שאם יש 3 דומיינים תעשה את החישוב כמה dcs יכולים להיות . ולכן אם dcs אחד נופל , עדיין ניתן להכנס לדומיין . במידה וה-gc שהוא גם dc מן הסתם, נופל , רצוי שיהיה עוד gc ב-forest כמו שדובר בהודעות הקודמות . אין הדבר אומר שאם ה-gc נפל, לא יהיו dcs לבצע מולם אוטנטיקציה .
 
A

antidot

New member
המממ

הערות: - אין דבר כזה "application directory service". אני מתאר לעצמי שהכוונה שלך ל Application Partitions - פיצ'ר שאכן התווסף החל מW2K3 ומאפשר ליצור "מחיצות" LDAP נוספות בAD (פרט ל Domain/Configuration/Schema). אחד השימושים הנפוצים הוא אינטגרציה של DNS בתוך App Partition נפרד שמאפשר לרפלק את הנתונים של DNS zones בצורה יותר יעילה. כל partition בAD הוא יחידת רפליקציה. עבור כל יחידת רפליקציה קיימת טופולוגיית רפליקציה משלה, דבר המאפשר לדוגמא לרפלק Application Partition לקבוצת שרתי DC מצומצמת (ולא לכולם כמו במקרה של מחיצות סטנדרטיות). - שרתי EXCH עד גרסא 5.5 (כולל) החזיקו שירות LDAP עצמאי ששימש אותם עבור שירותי ספריה (Directory Services). החל מE2K, שרתי Exchange משתמשים בAD כשירותי ספרי והDB של Exchange מחזיק רק את הדואר ו-public folders. - כיוון שExch מטבע מהותו צריך מידע על כל האובייקטים בForest, הוא חייב גישה ל-GC (הוא צריך לדגומא לדעת את כתובות הדוא"ל של כל האירגון ולא רק של המשתמשים בדומיין יחיד) - כמות הDC-ים בארגון מאוד תלויה בגודל האירגון ופריסה גאוגרפית שלו. אני מכיר אישית אירגונים עם מעל 300 DC-ים פר דומיין. כמות המשתמשים ו/או כמות הדומיינים אינם השיקולים היחידים לקביעת מספר DC-ים באירגון. יש המון שיקולים נוספים כגון: - פריסה גיאוגרפית - כמות אתרים מרוחקים - עלויות קישוריות בין האתרים השונים (אפילו אם יש לי לינק של 100Mbit בין אירופה לארה"ב, אני אשים לפחות DC אחד בכל יבשת על מנת לא להקטין את כמות התעבורה על לינק בין-יבשתי משיקולי עלויות וכו') - עומסים - ועוד ועוד...
 
I

ilusy

New member
לגבי התרגיל :)

אני מניח שאם ייתבצע deny לקבוצה אוניברסלית . אותם משתמשים הנמצאים בקבוצה האונברסלית לא יוכלו לגשת למשאבים שניתנת בהם גישה לקבוצה האוניברסלית , למרות שהם חברים בקבוצה לוקאלית אחרת שגם לה יש הרשאות על האובייקט . לגבי הנמשל - במידה ואין גישה ל-gc האם זה אומר שיש להם הרשאת deny , או שפשוט אין להם הרשאה (שזה כמובן דברים שונים ). בכל אופן הבנתי שהתפקיד של ה-gc הוא כל כך אקוטי וחשוב , שעדיף שלא לתת למשתמשים גישה לדומיין אם ה- gc לא זמין . כאשר אני חושב על זה לעומק , יש בזה הגיון מסויים . במידה ודומיין מסויים מייצר אובייקט חדש כלשהו , האובייקט לא יגיע ל-gc היות והוא לא זמין, ובכך יכולים להתחיל בעיות קונסיסטיות, וחוסר integrity של כל ה-db של ה-ad. אז הקונספציה אומרת - שרת ה-gc הוא כל-כך חושב , שעדיף שאם אין שרת gc זמין ב-forest המשתמשים לא יוכלו להתחבר . אני חושב שבאתי על סיפוקי . או במילים אחרות סופקתי .
 
A

antidot

New member
------->

כאשר מתבצעת אוטנטיקציה, הDC מולו אתה מבצע אוטנטיקציה, בונה את הsecurity token שכולל את הSID-ים של קבוצות אליהן שייך החשבון. קבוצות לוקליות וגלובליות נלקחות מDC. קבוצות אוניברסליות נלקחות מGC. עכשיו תאר לעצמך שנבנה security token ולא התווספו לחשבון שלי קבוצות אוניברסליות. אני מנסה לגשת למשאב והוא משווה את הACL שלו מול רשימת הSID-ים שיש בsecurity token שלי. כיוון שהtoken שלי לא כולל את הקבוצה אוניברסלית שעבורה הוגדר DENY (ובמידה למשל של Authenticated Users יש הרשאת קריאה), אזי אוכל לגשת למשאב בלי שאחסם - מצב לא הכי בריא.
 
ט

טופי

New member
../images/Emo45.gif אחלה תשובה ללימוד.

יש פקודה שאומרת מי מDCים מחזיק באיזה תפקיד, מה הסינטקס שלה?
 
A

antidot

New member
---->

בW2K3 או XP ניתן להשתמש ב dsquery:
C:\>dsquery server -hasfsmo schema "CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net" C:\>dsquery server -hasfsmo name "CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net" C:\>dsquery server -hasfsmo pdc "CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net" C:\>dsquery server -hasfsmo rid "CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net" C:\>dsquery server -hasfsmo infr "CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net"​
אפשר גם לתשאל DC ספציפי ע"י שימוש בdcdiag:
C:\>dcdiag /s:descartes /test:KnowsOfRoleHolders [SNIP] Starting test: KnowsOfRoleHolders Role Schema Owner = CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net Role Domain Owner = CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net Role PDC Owner = CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net Role Rid Owner = CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net Role Infrastructure Update Owner = CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=antid0t,DC=net ......................... DESCARTES passed test KnowsOfRoleHolders [/SNIP]​
אפשר דרך סקריפט: http://www.rallenhome.com/books/adcookbook/src/03.25-find_fsmos.vbs.txt אפשר לתשאל את AD דרך LDAP ישירות ע"י תשאול attribute בשם fsmoroleowner של האובייקטים הרלוונטיים (ראה מעלה את הדוגמא של הסקריפט) וכמובן אפשר בדרך המשעממם דרך GUI.
 
You must log in or register to reply here.

Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.

למעלה