موضوع مدیریت دامین های چند تایی به مدیریت روابط Trust بسیار گره خورده، به عبارت دیگر دامین های چند تایی در سایه روابط Trust امکان پذیر می شوند.

ارتباطات Trust در یک دامین

در زمان عضویت کامپیوتر در دامین، زمانی که کامپیوتر هنوز عضو شبکه Workgroup است، کامپیوتر اطلاعات مربوط به کاربران را در پایگاه داده SAM یا Security Account Manager نگه داری می کند. در زمان تشخیص هویت تنها با استفاده از پایگاه داده SAM اطلاعات را کنترل می کند. زمانی که کامپیوتر عضو دامین می شود یک رابطهTrust داخل دامینی بین کامپیوتر و دامین برقرار می شود. نتیجه این رابطه آن است که کامپیوتر اجازه می دهد تا هویت کاربر توسط AD DS تایید شود. همچنین با استفاده از این رابطه، AD DS قادر می شود تا روی دسترسی به منابع نیز مدیریت داشته باشد.

ارتباطات Trust بین دامینی

با همان بنیان، می توان مفهوم Trust را گسترش داد و آن را بین دو دامین مطرح کرد. رابطه Trust بین دو دامین باعث می شود که یک دامین به تشخیص هویت دامین دیگر اعتماد داشته باشد و برای دسترسی به منابع نیز بتواند از آن تشخیص هویت استفاده کند. به عبارت دیگر یک ارتباط Trust بین دو دامین یک اتصال منطقی است بین دو دامین که باعث می شوند از مرحله تشخیص هویت گذر کنند.

در هر رابطه دو دامین نقش دارند:
1. دامین اعتماد کننده
2. دامین اعتماد شده

دامین اعتماد شده، دامینی است که هویت ها را در اطلاعات ذخیره شده خود ذخیره می کند و تشخیص هویت را انجام می دهد.

دامین اعتماد کننده، دامینی است که نمی تواند کاربر را تشخیص هویت کند زیرا اطلاعات را در اطلاعات ذخیره شده خود ندارد بنابراین به تشخیص هویت دامین اعتماد شد اعتماد می کند.

کاربران در دامین اعتماد شده می تواند به منابع در صورد داشتن مجوز دسترسی، دسترسی داشته باشند. همچنین می توانند حقوقی داشته باشند همانند اجازه Logon کردن روی کامپیوتر های دامین اعتماد کننده.

لغات ها در مبحث Trust شاید کمی گیج کننده باشند. درک رابطه trust با استفاده از دیاگرام بسیار ساده تر است. در دیاگرام زیر دامین A به دامین B اعتماد می کند. بنابراین دامین A دامین اعتماد کننده است و دامین B دامین اعتماد شده. اگر یک کاربر در دامین B بخواهد از دامین A استفاده کند، دامین A تشخیص هویت را با استفاده از رابطه Trust به دامین B واگذار می کند. همچنین دامین A می تواند از کاربران یا گروه های دامین B استفاده کند مثلا در دادن مجوز های دسترسی به منابع.

یک رابطه Trust بین دو دامین با سه مشخصه زیر می تواند معین شود:

1. transitivity (خاصیت تعدی) : برخی از روابط Trust دارای خاصیت تعدی هستند البته همه رابطه ها دارای این خاصیت نیستند. با توجه به دیاگرام زیر خاصیت تعدی به این شکل تعریف می گردد. دامین A به دامین B اعتماد دارد. دامین B دامین C اعتماد دارد بنابراین دامین A به دامین C نیز اعتماد دارد. اگر Trust دارای خاصیت تعدی نباشد آنگاه دامین A به دامین C اعتماد ندارد. معمولا برای ایجاد اعتماد بین A و C از یک رابطه Trust جداگانه استفاده می گردد اما اگر Trust دارای خاصیت تعدی باشد این Trust جداگانه لازم نیست.

2. جهت (direction) : یک رابطه Trust می تواند یک طرفه یا دو طرفه باشد. در Trust به صورت یک طرفه یا one way کاربران در دامین اعتماد شده می توانند در دامین اعتماد کننده تشخیص هویت شوند اما عکس آن امکان پذیر نیست. در مثال فوق کاربران دامین B در دامین A تشخیص هویت می شوند اما کاربران دامین A در دامین B تشخیص هویت نمی شوند. در بسیاری از سناریو برای رسیدن به هدف رابطه دو طرفه (Two Way) می توان یک Trust دیگر با یک جهت متصاد Trust موجود ایجاد کرد.

3. اتوماتیک یا دستی: برخی از روابط Trust خودکار ساخته می شوند و برخی دیگر لازم است تا به صورت دستی ساخته شوند. در یک جنگل (Forest) تمام دامین ها به یک دیگر اعتماد دارند. به این دلیل که دامین هر Root Domain به Forest Root اعتماد دارد و هر Child Domain به parent Domain خود اعتماد دارد. این Trust ها به صورت خودکار ساخته می شوند و لازم نیست خاصیت تعدی یا جهت در آن ها در نظر گرفته شود.

پروتکل های تشخیص هویت و روابط Trust

ویندوز سرور 2003 با استفاده از دو پروتکل می تواند تشخیص هویت می کند: Kerberos V5 یا NT LAN Manager به اختصار NTLM و Kerberos V5 پروتکل پیش فرض در ویندوز های سرور 2008، 2003 و ویندوز های 7، Vista و XP است. اگر کامپیوتری در شبکه موجود باشد که از Kerberos V5 پشتیبانی نمی کند به جای Kerberos V5 از NTLM استفاده می شود.

تشخیص هویت Kerberos در یک دامین

به صورت بسیار مختصر؛ زمانی که کاربر به یک کلاینت تحت دامین و با پشتیبانی Kerberos تلاش می کند که Logon کند، درخواست تشخیص هویت برای Domain Controller ارسال می شود. هر Domain Controller همانند یک Key Distribution Center یا با اختصار KDC عمل می کند. پس از تایید هویت کاربر، KDC به کاربر های تایید شده یک Ticket-Granting Ticket یا به اختصار TGT می دهد. زمانی که کاربر نیاز دارد از یک منبع در همان دامین استفاده کند، ابتدا کاربر باید دارای یک Session Ticket معتبر برای آن کامپیوتری که منبع روی آن است داشته باشد. Session Ticket توسط KDC در Domain Controller فراهم می شوند. بنابراین کاربر درخواست Session Ticket خود را به Domain Controller می دهد. از آنجا که کاربر قبلا تشخیص هویت شده است دارای TGT است و TGT خود را برای نشانه ای این امر نمایش می دهد. این امر باعص می شود تا KDC بدون آنکه دوباره عمل تشخیص هویت را انجام دهد Session Ticket را به کاربر بدهد. Session Ticket احتیاج دارد تا سرور و سرویس مورد نظر معین شده باشد. KDC می تواند با استفاده از Service Principal Name یا SPN سرور درخواست شده در همان دامین سرویس را معین کند.

سپس کاربر می تواند با استفاده از Session Ticket خود به سرویس مطلوب متصل شود. سرور قادر است تا Session Ticket را بررسی کند و کنترل کند که کاربر تشخیص هویت شده است. این اتفاق با استفاده از Private Key انجام می شود. در هر صورت در اینجا قصد بررسی kerberos V5 را نداریم و در نهایت سرور با توجه به Trust داخل دامینی تشخیص هویت دامین که توسط دامین کنترلر انجام می شود را قبول دارد.

تشخیص هویت Kerberos در یک جنگل

هر Child Domain به Parent Domain خود Trust دارد و هر Tree Root به Forest Root نیز Trust دارد. این دو Trust از نوع Transitive و Two Way و اتوماتیک است. به Trust اول Parent-Child Trust و به Trust دوم Tree-Root Trust گفته می شود. درک Trust در یک جنگل از روی دیاگرام بسیار ساده تر از نوشتن این روابط است از این رو با توجه به دیاگرام زیر مطالب زیر را در نظر بگیرد.

به روابط Trust ساخته شده از روی Tree-Root Trust و Parent-Child Trust در اصطلاح Trust Path یا Trust Flow گفته می شود. در دیاگرام اول نمایی از DNS و در دیاگرام دوم نمایی از Trust Path به نمایش در آمده است. Tailspintoys.com در اینجا Forest Root است و Forest شامل دو Tree می باشد. اگر یک کاربر در USA.Windtiptoys.com بخواند یک Shared Folder روی EUROPE.Tailspintoys.com را ببیند تراکنش های زیر اتفاق می افتد.

1. کاربر روی کامپیوتر در USA.wingtiptoys.com ابتدا Logon می کند و توسط دامین کنترلر در دامین خود یعنی usa.wingtiptoys.com تشخیص هویت می شود. مراحل تشخیص هویت مشابه آن است که پیش تر گفته شد و کاربر یک TGT دریافت می کند.

کاربر می خواهد Shared Folder روی Europe.tailspintoys.com را ببیند.

2. کاربر به KDC روی دامین کنتر USA.wingtiptoy.com متصل می شود و درخواست Session Ticket می کند.

3. بر اساس SPN دامین کنترلر در USA.wingtiptoy.com متوجه می شود که سرویس مورد نظر روی دامین خود نیست. وظیفه KDC یک واسط بین کلاینت و سرویس است. از آنجا که سرویس Trust است اما در دامین خود نیست، KDC برای کمک به دسترسی به سرویس یک referral صادر می کند تا کاربر بتواند به Session Ticket مورد نظر خود دست پیدا کند.

KDC برای این کار یک الگوریتم ابتدایی دارد. اگر دامین KDC به صورت مستقیم با دامین سرویس Trust باشد، KDC به صورت مستقیم یک referral به دامین سرویس می دهد. اگر به صورت مستقیم Trust نباشد، Trust به صورت Transitive است بنابراین KDC یک Referral برای دامین بعدی در TRUST PATH صادر می کند.

4. از آنجا که usa.wingtiptoy.com مستقیما به europe.tailspintoy.com دارای Trust نیست، KDC یک referral برای دامین بعدی یعنی wingtiptoy.com صادر می کند.

5. کلاینت با KDC دامین ارجاع شده یعنی wingtiptoy.com ارتباط برقرار می کند.

6. بار دیگر KDC در wingtiptoy.com یک referral برای tailspintoy.com صادر می کند.

7. کلاینت با KDC در tailspintpy.com ارتباط بر قرار می کند و به europe.tailspintoys.com ارجاع داده می شود.

8. کلاینت به KDC در Europe.tailspintoys.com ارتباط برقرار می کند و از آنجا که Europe.tailspintoys.com به usa.wingtiptoys.com اعتماد دارد یک Session Ticket برای کاربر صادر می کند.

9. با توجه به Session Ticket کاربر می تواند با توجه به مجوز های دسترسی خود به Shared Folder دسترسی داشته باشد.

فرآیند فوق ممکن است پیچیده و زمان گیر به نظر آید اما تمام فرآیند در پشت صحنه صورت می گیرد و کاربر با این مسائل درگیر نمی شود. آنچه در اینجا به عنوان ارتباط Kerberos V5 و روابط Trust بحث شد ساده شده و مختصر شده است.