DN چیست؟ بررسی مفهوم Distinguished Name در اکتیودایرکتوری
Distinguished Name چیست؟ DN چیست؟ RDN چیست؟ در این مقاله به مبانی نامگذاری اشیاء در اکتیودایرکتوری خواهیم پرداخت . در قسمت معرفی روش ذخیره اطلاعات در اکتیودایرکتوری از این مقالات به این نکته اشاره کردیم که پروتکل LDAP یک پروتکل مرجع برای اشیاء در اکتیودایرکتوری محسوب میشود که هر شیء را با یک اسم منحصر به فرد به نام Distinguished Name می شناسد . در این مقاله میخواهیم به شما دقیقا کاری که Distinguished Name ها در اکتیودایرکتوری انجام میدهند را نشان بدهیم .قبل از اینکه به سراغ مقوله اصلی بروم باید بگویم که مسئله Distinguished Name ها صرفا متعلق به اکتیودایرکتوری نیست . مایکروسافت سرویس اکتیودایرکتوری را برای رقابت با دایرکتوری سرویس های شرکت ناول و IBM و بر اساس یک استاندارد مشترک ایجاد کرد . اگر با ساختار نامگذاری Distinguished Name در اکتیودایرکتوری به خوبی آشنا بشوید خواهید دید که ضمن اینکه براحتی میتوانید با سرویس اکتیودایرکتوری و سیستم های نامگذاری آن کار کنید ، براحتی میتوانید با دایرکتوری سرویس های غیر مایکروسافتی که از استاندارد مشترک x.500 استفاده می کنند نیز استفاده کنید . در دوره آموزش نتورک پلاس شما با مفاهیم اولیه در دایرکتوری سرویس نیز آشنا می شوید.
قوانین پایه نامگذاری در Distinguished Name
Distinguished Name ها که در اینجا به اختصار به آنها DN میگوییم ، از مجموعه ای از خاصیت ها درست شده اند که هر کدام دارای یک مقدار هستند . یک DN به تنهایی دارای چندین جفت خاصیت یا بهتر بگوییم Attribute میباشد . برای اینکه این مطلب بیشتر برای شما جا بیافتد به مثال زیر توجه کنید :
CN=User1, CN=Users, DC=tosinso, DC=com
در مثال فوق این DN از چهار Attribute مختلف یا 2 جفت Attribute مختلف تشکلیل شده است که هر کدام از این attribute ها با کاما از همدیگر جداسازی شده اند . اولین جفت از attribute ها به شکل CN=USER1 نمایش داده شده است . در این قسمت CN که مخفف کلمه Common Name میباشد به عنوان خاصیت و User1 به عنوان مقدار این خاصیت معرفی میشود . Attribute ها و مقدارهای آنها همیشه توسط علامت مساوی از یکدیگر مجزا می شوند .
RDN چیست؟ بررسی مفهوم Relative Distinguished Name
وقتی یه یک DN مثل CN=User1, CN=Users, DC=tosinso, DC=comنگاه میکنیم ، یک نکته بلافاصله تو ذهنمون میاد ( البته باید بیاد ، خوب شایدم دوست داشته باشه و نیاد ) DN ها میتونن خیلی خیلی بزرگ و طولانی بشن !!! اگر نگاه دقیقتری به DN بیاندازید میبینید که ساختار سلسله مراتبی چنین وضعیتی را پیش خواهد آورد . در این مثال خاص DC=com بالاترین سطح این سلسله مراتب را نمایش میدهد . DC=tosinso دومین مرحله از سلسله مراتب را نمایش میدهد .
شما در اینجا میتوانید com و tosinso را به عنوان دامین در نظر بگیرید همانطور که برای معرفی آنها از DC استفاده شده است . سلسله مراتب دامین در حقیقت تقلیدی از سلسله مراتبی است که ساختار DNS از آن بهره میگیرد.درک اینکه سلسه مراتب در DN ها چگونه کار میکنند به دو دلیل مهم است . در دوره آموزش لینوکس اسنشیالز و البته در دوره های آموزش لینوکس سطح بالاتر شما با سرویسی به نام OpenLDAP سرو کار دارید که ساختار DN را نیز عینا در آن مشاهده می کنید.
اولین نکته این است که باد درک کردن درست شیوه سلسله مراتبی نامگذاری اشیاء در اکتیودایرکتوری شما میتوانید محل دقیق قرارگیری این شیء در ساختار اکتیودایرکتوری را بیابید . دلیل دیگری که درک طبیعت DN ها به ما مکم میکند که کار ما راحتتر شود این است که شما برخی اوقات نیاز دارید که از اشیاء خود بصورت Shortcut در مکان های دیگر استفاده کنید که در اینجا هم DN ها و ساختارشان به شما کمک خواهند کرد .
خوب برای اینکه مفهوم بالا را به درستی درک کنید بیاید با همان مثلا قبلی جلو برویم : CN=User1, CN=Users, DC=tosinso, DC=com . در این مثال خاص DN بصورت مشخص به کاربری به نام User1 ( که در حقیقت به نام شیء کاربر هم آنرا میشناسیم ) اشاره شده است . در نهایت این خط و مثال به شما میگوید که این شیء درکجای ساختار سلسله مراتبی اکتیودایرکتوری شما قرار گرفته است .
خوب اگر بخواهید به شخص دیگری در خصوص این شیء اطلاعاتی بدهید صرفا به گفتن User1 به آن شخص کفایت خواهید کرد . بعضی اوقات LDAP همینکار را برای ما انجام میدهد . این کار براحتی ممکن است چون شما وقتی مکان یک شیء را میدانید دیگر نیازی نیست که در ساختار سلسله مراتبی به دنبال آن بگردید .
برای مثال اگر ما بخواهیم یک سری عملیات بر روی کاربرانی که در Container به نام Users قرار گرفته اند انجام دهید که در دامین tosinso.com قرار دارد ، خوب آیا مهم است که همیشه نام tosinso.com را برای مشخص کردن محل آن ذکر کنید در حالی که میدانید غیر از آن دامینی در کار نیست ؟
در اینگونه موارد برای راحتی کار ما نام دامین را از ساختار DN حذف میکنیم و در حقیقت آنرا خلاصه میکنیم ، برای مثال همان نمونه بالا در قالب این ساختار به جای نوشتن CN=User1, CN=Users, DC=tosinso, DC=comبصورت CN=User1 نوشته میشود و به این حالا Relative Distinguished Name یا DN خلاصه شده اطلاق میشود .
RDN همیشه از مشخص ترین شناسه شیء استفاده میکند ، این یعنی سمت چپ ترین خاصیت یا جفت اطلاعات ( value pacom) در یک DN ، ادامه باقیمانده از ساختار نامگذاری DN به نام DN والد یا Parent DN شناخته میشود . ( والد همون بابا و مامانش میشن ) ، در مثلال بالا DN والد بصورت CN=Users, DC=tosinso, DC=comخواهد بود .
قبل از اینکه ادامه بدهیم بایستی به این نکته اشاره کنم که مایکروسافت از سیستم نامگذاری DN ای استفاده میکند که تا حدودی با سیستم های نامگذاری سایر سیستم های عامل سایر تولید کنندگان نرم افزار متفاوت است. همانطور که در مثال های بالا مشاهده کردید DN هایی که در ساختار اکتیودایرکتوری مایکروسافت وجود دارند بر اساس Container ها و دامین ها هستند . در این نوع قالب بندی هیچ مشکلی وجود ندارد زیرا مایکروسافت ساختار نامگذاری DN های خود را بر اساس RFC 2253 ایجاد کرده است که در حقیقت استاندارد ایجاد نامگذاری DN را مشخص میکند .
بعضی از سیستم های عامل غیر مایکروسافتی ساختار DN خود را به جای اینکه بر اساس دامین و Container ایجاد کنند ، بر اساس شرکت ها و کشورها ایجاد کرده اند. در اینگونه DN ها مثلا خاصیت یا Attribute با حرف O نشان دهنده Organization یا سازمانی است که شیء در آن ایجاد شده است ، و همچنین حرف C نشان دهنده کلمه Country یا کشوری است که شیء در آن قرار گرفته است . بر همین اساس مثالی که در قبل ذکر کردیم میتواند به شکل زیر بکار برود ، شکل اولیه CN=User1, CN=Users, DC=tosinso, DC=comبوده است که با ساختار جدید به شکل پایین تبدیل خواهد شد :
CN=User1, O=tosinso, C=comAN
به یاد داشته باشید که هر دوی این ساختار های نامگذاری DN با RFC 2253 مطابقت دارند اما نکته در اینجاست که ایندو قابلیت تبدیل و تغییر به همدیگر را ندارند . همیشه به یاد داشته باشید که وظیفه اصلی DN مشخص کردن مکان قرار گیری اشیاء در ساختارهای دایرکتوری سرویس هست و همچنین ارائه توضیحاتی در خصوص نوع شیء نیز بر عهده DN ها میباشد . دلیل این تقاوت در نامگذاری DN ها این است که مایکروسافت همیشه تافته جدا بافته است و استاندارد های خاصی را برای محصولات استفاده میکند که از دیگران متفاوت باشد .
استفاده از کاراکترهای خاص در Distinguished Name ها
خوب در اوایل همین مقاله به این موضوع اشاره کردیم که علامت کاما و مساوی معانی خاصی در ساختار نامگذاری DN ها دارد . چندین کاراکتر خاص نیز در این میان وجود دارند که معانی خاصی برای خود دارند . این علامت ها به ترتیب علامت مثبت ، علامت منفی ، علامت # ، علامت بک اسلش و علامت کوتیشن یا , است .
من قصد ندارم که کلیه این علامت ها رو و کاربردشون در ساختار DN رو به شما نشون بدم اما شما بایستی بعد ها یاد بگیرید که چگونه از آنها در جهان واقعی استفاده کنید . اما میخام حتما در مورد بک اسلش براتون صحبت کنم ، علامت بک اسلش به LDAP میگوید که از سایر کاراکترهای موجود صرف نظر کند . برای یادگیری کامل و جامع اکتیودایرکتوری می توانید به دوره آموزش MCSA مراجعه کنید.
این به شما اجازه میدهد که کاراکتر های مخفی را نیز در دایرکتوری شما ذخیره شوند . برای اینکه درک بهتری از این مسئله داشته باشید فرض کنید در ساختار LDAP شما اگر نام و نام خانوادگی را با کاما از هم متمایز کنید ، این برای LDAP قابل قبول نیست ، چرا که کاما را برای وارد کردن خاصیت بعدی در نظر خواهد گرفت
برای اینکه بتوانیم کاری کنیم که همزمان بتوانیم پس از نام ، نام خانوادگی را وارد کنیم بایستی از ساختار زیر و از بک اسلش استفاده کنیم یعنی در ساختار عادی CN=Nascomi,Mohammad که در این مورد LDAP منتظر ورود مقدار برای Mohammad میماند ، اما با استفاده از بک اسلش ساختار به شکل زیر در می آید :
CN=Nascomi,Mohammad
در این حالت علامت بک اسلش به LDAP میگوید که علامت کاما را به عنوان داده برای مقدار ورودی در نظر بگیرد . در روش دیگر میتوانید به جای کلیه مکانهایی که میبایست داده وارد کنید از علامت کاما استفاده کنید ، LDAP به علامت کاما به عنوان داده ورودی در نظر میگیرد .همیشه یک قانون برای استفاده از بک اسلش و کاما در کنار هم وجود دارد .
همیشه علامت بک اسلش برای این استفاده میشود که به LDAP بگوید که علامت بک اسلش بعدی را در نظر نگیرد ، برای اینکه درک بهتری از این موضوع داشته باشید فرض کنید که با آوردن دو عدد بک اسلش در دستور ، LDAP بک اسلش دوم را به عنوان داده ورودی در نظر میگیرد. اگر تعداد بیشتری بک اسلش در این میان استفاده شود ساختار دستوری اشتباه خواهد بود .
نتیجه : همانطوری که مشاهده کردید ساختار نامگذاری LDAP تا حدودی تخصصی به نظر میرسد . اما داشتن یک دانش نسبی به آن تا حدودی به ما درک بهتری از ساختار ذخیره سازی در دایرکتوری سرویس ها را میدهد که در حل مشائل کمک شایانی به ما میکند.