אתה משתמש בדפדפן מיושן. יתכן והאתר הנוכחי יוצג באופן שגוי, כמו כן אתרים אחרים ברשת.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
שאלה על Global Catalog
- פותח הנושא snup
- פורסם בתאריך
------->
קודם כל, כאשר מדברים על שם משתמש, יש לזכור שבAD לכל חשבון יש למעשה 2 שמות: sAMAccountName - מופיע בממשקים הגרפיים בתור pre-Windows 2000. מדובר בשם משתמש כפי שהוא מוגדר עוד בתקופה של NT userPrincipalName - הUPN של חשבון. מדובר בשם מהצורה [email protected] sAMAccountName חייב להיות ייחודי ב*דומיין* UPN חייב להיות ייחודי בForest בכל מקרה, לGC אין שום בעיה עם חשבונות בעלי samAccountName זהה. הסיבה היא שהאובייקטים בDC (ובGC בפרט) מאותרים לא לפי השם חשבון, אלא לפי Distinguished Name - הPATH המלא לאובייקט. ז"א שאם קיימים חשבונות בשם joe בשני דומיינים שונים, הDN שלהם שונה: cn=joe,ou=accounts,dc=child2,dc=domain,dc=local cn=joe,ou=haifa,dc=child1,dc=domain,dc=local צריך להבין שGC לא "רושם" שמות. GC מחזיק עותק חלקי (PAS-Partial Attribute Set) של כל האובייקטים בForest, כאשר כל דומיין הוא בעל namespace שונה ולכן לא יכול להווצר מצב של התנגשות במקרה של sAMAccountName. המקרה של UPN קצת יותר מסובך: UPN חייב להיות ייחודי בForest (לא ייתכן מצב של שני אובייקטים בעלי UPN זהה). הסיבה לכך היא שUPN הוא שם אוניברסלי בForest הסתייגויות/הערות: - כעקרון יש שם נוסף לחשבון וזה הimplicit Kerberos principal. (הUPN הוא explicit), אבל נדלג על זה בינתיים כיוון שלא מדובר בattribute בAD. - מעשית ניתן ליצור מצב של חשבונות בעלי upn זהה בforest, אך זהו מצב לא תקין שגורם לתקלות
קודם כל, כאשר מדברים על שם משתמש, יש לזכור שבAD לכל חשבון יש למעשה 2 שמות: sAMAccountName - מופיע בממשקים הגרפיים בתור pre-Windows 2000. מדובר בשם משתמש כפי שהוא מוגדר עוד בתקופה של NT userPrincipalName - הUPN של חשבון. מדובר בשם מהצורה [email protected] sAMAccountName חייב להיות ייחודי ב*דומיין* UPN חייב להיות ייחודי בForest בכל מקרה, לGC אין שום בעיה עם חשבונות בעלי samAccountName זהה. הסיבה היא שהאובייקטים בDC (ובGC בפרט) מאותרים לא לפי השם חשבון, אלא לפי Distinguished Name - הPATH המלא לאובייקט. ז"א שאם קיימים חשבונות בשם joe בשני דומיינים שונים, הDN שלהם שונה: cn=joe,ou=accounts,dc=child2,dc=domain,dc=local cn=joe,ou=haifa,dc=child1,dc=domain,dc=local צריך להבין שGC לא "רושם" שמות. GC מחזיק עותק חלקי (PAS-Partial Attribute Set) של כל האובייקטים בForest, כאשר כל דומיין הוא בעל namespace שונה ולכן לא יכול להווצר מצב של התנגשות במקרה של sAMAccountName. המקרה של UPN קצת יותר מסובך: UPN חייב להיות ייחודי בForest (לא ייתכן מצב של שני אובייקטים בעלי UPN זהה). הסיבה לכך היא שUPN הוא שם אוניברסלי בForest הסתייגויות/הערות: - כעקרון יש שם נוסף לחשבון וזה הimplicit Kerberos principal. (הUPN הוא explicit), אבל נדלג על זה בינתיים כיוון שלא מדובר בattribute בAD. - מעשית ניתן ליצור מצב של חשבונות בעלי upn זהה בforest, אך זהו מצב לא תקין שגורם לתקלות
המממ
קצת קשה להסביר על רגל אחת, אבל הנה שאלה שלי ברשימת תפוצה של activedir.org ששאלתי בזמנו:
קצת קשה להסביר על רגל אחת, אבל הנה שאלה שלי ברשימת תפוצה של activedir.org ששאלתי בזמנו:
Stumbled upon an issue couple of days ago and wanted to hear what you guys think about it. Suppose that your AD is called myad.com and you also configure additional UPN suffix "company.com". Now I create 2 users in child.myad.com child domain: 1) sAMAccountName: guy userPrincipalName: [email protected] 2) sAMAccountName: guy$adm userPrincipalName: [email protected] (Notice that in ADUC the userPrincipalName is constructed from 2 fields: W2K username and suffix) From AD point of view this is all nice and legit and UI will be happy to create both. But if you look at the users explicit Kerberos principals, both look the same: [email protected] (checked with klist tgt). In our environment, if you are logged on with account #1, two things happened: 1. Once in a while LAN users had XP pop up a baloon in systrey with "XP needs your user credentials" 2. The corresponding account #2 was getting locked out. Renaming UPNs of supplemental accounts fixed the issue (the name clash was not intentional from the beginning as you might guess). Still I am wondering why AD allowed creation of account with Kerberos principal that already existed in AD. If AD check for sAMAccountName collisions, is there any special reason not to check Kerberos principals ? How can I prevent this from happening ? (the implications would mean that anyone with permissions to create user accounts can do some very nasty things)
והנה הפניה לthread המלא: http://www.mail-archive.com/[email protected]/msg20106.htmlCopyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.