کربروس Kerberos دو نوع نام اصلی Principal Names مختلف را تعیین یا مشخص میکند. این دو نام اصلی مختلف، یکی User Principal Name – UPN است و دیگری Service Principal Name – SPN میباشد.
فقط اکانت یوزر User account دارای یک User Principal Name – UPN است که در اکانت آن یوزر معین یا مشخص شده است. وقتی شما اکانت یک یوزر را نگاه کنید، در تب اکانت Account، متوجه میشوید که UPN از ترکیب دو قسمت Field که در قسمت User logon name قرار دارند تشکیل شده است. یک UPN باید در کل Forest منحصر بفرد unique باشد، در غیر این صورت زمانی که KDC به اکانت یوزرها با استفاده از UPN نگاه میکند، اگر چند یوزر دارای یک UPN باشند، احراز هویت Authentication برای تمام آن یوزرها که دارای UPN یکسان هستند با شکست یا عدم موفقیت failures مواجه خواهد شد. UPN در object اکتیو دایرکتوری یک صفت attribute است که فقط میتواند یک مقدار تک یا واحد را در خود داشته باشد. اسم این صفت attribute که این مقدار واحد یا تک را در خود دارد userPrincipalName میباشد. به طور مثال UPN به این صورت است : Administrator@GEEKBOY.IR
Service Principal Names باید در Forest منحصر بفرد باشد و میتواند به اکانت یوزر User account یا اکانت کامپیوتر Computer account اختصاص داده شود. فقط برای اکانت کامپیوتر Computer account است که به صورت اتوماتیک SPN معین یا مشخص میشود.
SPN مشخص میکند که کدام سرویس Service در چهار چوب اکانت های امنیتی اجرا شود. بطور مثال برخی از سرویس هایی که یک کامپیوتر میتواند داشته باشد File Server یا CIFS – Common Internet File System میباشد. اگر این کامپیوتر یک دومین کنترولر باشد، یک LDAP SPN و Active Directory Replication SPN و FRS SPN دارد. SPN ها میتوانند برای اکانت یوزر معین یا مشخص شوند که چه زمانی یک سرویس یا برنامه در چهار چوب امنیت یوزرها اجرا شود. بطور معمول این نوع از اکانت های یوزر به نام Service Accounts نامیده میشوند. این خیلی مهم است که بفهمید Service Principal Names باید به صورت منحصر بفرد در Forest اکتیو دایرکتوری باشد.
در زیر چند نمونه از این اکانت یوزرها که به آنها معین میشود را نگاه میکنیم:
وقتی یک سرویس سرور SQL بجای استفاده بصورت استاندارد از LocalSystem، از یک اکانت یوزر یا Service Account استفاده میکند. مثال MSSQLSvc/sqlsrvr.geekboy.pro:1433
وقتی یک مخزن برنامه وب Web Application Pool در IIS، در حال اجرا با استفاده از اکانت یک یوزر میباشد، بجای اینکه از Network Service بصورت استداندارد استفاده کند. مثل http/websrvr.geekboy.pro
مجوزها یا بلیط های کربروس Kerberos tickets
مرکز توزیع کلید Key Distribution Center – KDC
KDC یک سرویس Service است که فقط و باید بر روی دومین کنترولر Domain Controller در حال کار یا اجرا باشد. اسم این سرویس مرکز توزیع کلید کربروس Kerberos Key Distribution Center است. در واقع KDC یک سرویس است که مسئول تصدیق هویت یوزرها در زمانی که از کربروس استفاده میشود، میباشد. KDC دو جزء component سرور را پیاده سازی میکند. یکی سرور احراز هویت یا تائید Authentication Server – AS است و دیگری سرور اعطای مجوز Ticket Granting Server – TGS میباشد .
سرور احراز هویت یا تائید Authentication Server – AS
نقش KDC این است که هویت را شناسایی میکند که principal باشد و سپس درخواست اعطای بلیط یا مجوز Ticket Granting Ticket – TGT را برای اصل بودن principal صادر میکند تا ابراز هویت Authentication با موفقیت انجام شود. داشتن یک TGT معتبر سبب میشود که principal بتواند یک درخواست بلیط یا مجوز سرویس Service ticket از سرور اعطای مجوز Ticket Granting Server – TGS کند. این سبب میشود که یک TGT در کش اعتبار نامهCredentials Cache هر دومین Domain برای principal باشد.
برای بهتر فهمیدن یک مثال میزنیم: یک یوزر در دومین geekboy.pro میخواهد به یک فایل سرور File Server در دومین Emea.geekboy.pro دسترسی داشته باشد. این یوزر باید یک TGT برای geekboy.pro و Emea.geekboy.pro داشته باشد.
سرور اعطای مجوز Ticket Granting Server – TGS
نقش دیگر KDC این است که یک بلیط یا مجوز سرویس Service ticket در زمانی که یک principal درخواست اتصال به یک سرویس کربروس را میکند را صادر میکند .توجه کنید که قبل از آنکه یک بلیط یا مجوز سرویس Service ticket برای دومین اکتیو دایرکتوری صادر شود، شما باید یک درخواست اعطای بلیط یا مجوز Ticket Granting Ticket – TGT برای دومین اکتیو دایرکتوری داشته باشید، هر چند که KDC برای صادر کردن بلیط یا مجوز سرویس Service ticket بطور مستقیم با آن سرویسی که principal برای آن درخواست بلیط یا مجوز کرده است، صحبت نمیکند.
زمانی که یک بلیط یا مجوز سرویس Service ticket توسط سرور اعطای مجوز Ticket Granting Server – TGS صادر میشود، این بلیط یا مجوز سرویس Service ticket در داخل کش اعتبار نامه Credentials Cache مربوط به principal ها برای استفاده های بعدی قرار میگیرد. وقتی principal احتیاج به اتصال به سرویس درخواست شده را دارد، بلیط یا مجوز سرویس Service ticket از کش اعتبار نامه Credentials Cache مورد استفاده قرار میگیرد و آن را به آن سرویسی که میخواهد متصل شود ارسال میکند.
این را هم باید بدانیم که KDC فقط دو نوع مختلف مجوز یا بلیط ticket صادر میکند:
- درخواست اعطای بلیط یا مجوز Ticket Granting Ticket – TGT
- بلیط یا مجوز سرویس Service ticket از طرف سرور اعطای مجوز Ticket Granting Server – TGS
مراحل مجوز یا بلیط کربروس Kerberos Ticketing Process
چگونه کربروس کار میکند، بسیار سخت قابل شرح دادن است، چون در این عملیات بسیار زیاد رمز گشایی Decrypting و رمز نگاری Encrypting برای احراز هویت Authentication دیتا وجود دارد. اگر میخواهید فقط به صورت ساده مراحل را متوجه شوید، فقط توضیحاتی را که با شماره نوشته شده بخوانید، ولی اگر میخواهید کمی عمیق تر مطلب را متوجه شوید، برای هر شماره زیر آن توضیحاتی داده میشود که آن را نیز بخوانید.
1- کلاینت یک KRB_AS_REQ به سمت Key Distribution Center – KDC میفرستد و بیشتر و بطور خاص سرور احراز هویت Authentication Server تا یک Ticket Granting Ticket – TGT درخواست کند. AS_REQ در خود کلاینت و از ترکیب ساعت در حال حاضر کامپیوتر Current Computer Time و رمز نگاری پسورد هش یوزر User Password Hash ساخته میشود. در آن AS_REQ همچنین اطلاعات دیگری که شامل UPN مربوط به Principal میباشد نیز وجود دارد. این اطلاعات به نام Authentication Data معروف است.
KDC -2 هنگامی که یوزر Authentication Data را بررسی و تائید کرد، به کلاینت با یک KRB_AS_REP جواب میدهد که در آن یک TGT و یک Session Key برای TGT وجود دارد. KDC میتواند AS_REQ را رمز گشایی کند، چون پسوردهای هش مربوط به تمام Principalها در اکتیو دایرکتوری ذخیره شده است. سپس از روی برچسب یا مهر زمان Timestamp روی AS_REQ مطمئن میشود که سیستم ها Systems از زمان با تلرانس 5 دقیقه خارج نشده اند. این مکانیزم یوزر و پسورد آن Principal را تصدیق و احراز هویت میکند. Session Key که برای TGT داده میشود، برای درخواست بلیط یا مجوز سرویس Service ticket استفاده میشود.
3- حالا کلاینت از زمانی که دارای TGT معتبر را برای اکتیو دایرکتوری در دومین میباشد، میتواند درخواست بلیط یا مجوز سرویس Service ticket کند. در این مرحله کلاینت یک KRB_TGS_REQ به سمت KDC که بیشتر و بطور خاص Ticket Granting Server – TGS میباشد را ارسال میکند و درخواست یک بلیط یا مجوز سرویس Service ticket را میکند. یادتان نرود که کلاینت فقط یک درخواست بلیط یا مجوز سرویس Service ticket ارسال نمیکند، بلکه یک کپی از TGT که در مرحله 2 در خود دارد را نیز با آن ارسال میکند. Principal در حال ساخت تائید کننده که با رمز گزاری Session key مربوط TGT به میباشد. این دیتای تائید کننده User Principal Name – UPN میباشد و همچنین مهر یا برچسب زمان Timestamp حال TGS_REQ دارای این اطلاعات میباشد، User Principal Name – UPNکه آن میخواهد دسترسی داشته باشد و TGT که از مرحله گرفته شده است.
KDC -4 زمانی که TGT که داخل آن نیز درخواست بلیط یا مجوز سرویس Service ticket میباشد را بررسی و تائید کرد، در جواب به سمت کلاینت یک KRB_TGS_REP ارسال میکند که داخل آن بلیط یا مجوز سرویس Service ticket و یک Service Session Key میباشد. KDC پس از رمزگشایی موفق TGT، سرور Ticket Granting Server میتواند به TGS Session key و دیتا تائید کننده که با آن رمز گزاری شده، دسترسی پیدا کند. رمز گشایی دیتا تائید کننده کمک یا مشخص میکند که چه Principal یوزری برایش TGT صادر شده و چه کسی تقاضای بلیط یا مجوز سرویس Service ticket را ارسال کرده است. همچنین KDC با استفاده از مهر یا برچسب زمان Timestamp مشخص میکند که ساعت سیستم در همان تلرانس 5 دقیقه میباشد و از آن خارج نشده و تشخیص میدهد که یک نفوذ یا حمله Attack نمیباشد.
پرسش LDAP برای Service Principal Name – SPN انجام میشود که مجوز یا بلیط Ticket از طرف این اطلاعات بلیط یا مجوز تقاضا شده است. جستجوی LDAP با یک سوال از صفت attribute مربوط به servicePrincipalName که در اکتیو دایرکتوری ذخیره شده انجام میشود.
TGS یک Unique Service Session Key تولید میکند. این Session Key برای Principal و سرویس Service مورد استفاده قرار میگیرد.
سپس KDC بلیط یا مجوز سرویس Service ticket را با اطلاعات زیر که درون است تولید میکند:
- یک کپی از Unique Session Key
- دیتا مجوزها که آن از TGT مربوط به Principal کپی شده که درخواست داده بود. این دیتا مجوزها دارای SID مربوط به Principal و اطللاعات تمام گروه ها All Groupsمیباشد. این اطللاعات به نام Privileged Attribute Certificate – PAC نامیده میشود.
- هنگامی که Service ticket کامپایل میشود، کل یا تمام Service ticket به همراهServices User Key رمزگزاری میشود – پسورد هش Password Hash
- اطللاعات مجوز و کپی Service Session Key مربوط به Principal با Ticket Granting Server session key رمز گزاری میشوند.
5- سپس کلاینت این Service Ticket را به سمت سرویس یا برنامه به عنوان یک KRB_AP_REQ ارسال میکند. شما بطور معمول نوع آن پکت Packet را بصورت سرویسی که در آن جاسازی شده و استفاده میشود، خواهید دید. بطور مثال اشتراک فایل File Share از SMB استفاده میکند.
اطلاعات درون KRB_AP_REQ در حقیقت Service ticket میباشد که از TGS بدست می آید وauthenticator با Session Key برای سرویس رمز گزاری شده است.
6- بعد از آنکه احراز هویت Authentication با موفقیت انجام شد، سرویس مربوطه جواب کلاینت را با یک KRB_AP_REP میدهد.
وقتی کلاینت KRB_AP_REP را دریافت میکند، Service’s authenticator را با Service Session Key که با سرویس به اشتراک میباشد رمزگشایی کرده و زمان برگشت توسط سرویس را نیز با زمان داخل کلاینت اصلی مقایسه میکند. اگر زمان تطابق کند، کلاینت میفهمد که سرویس حقیقی یا واقعی است.
بعد از آنکه سرور کلاینت را با استفاده از احراز هویت کربروس تائید کرد، Privilege Attribute Certificate – PAC از Service ticket گرفته میشود و برای تولید یا ایجاد User Access Token استفاده میشود. این Privilege Attribute Certificate – PACدوباره دومین کنترولر را از طریق یک NetLogon بررسی میکند تا PAC Signature را بررسی کند.
این 6 مرحله، مراحل مجوز یا بلیط کربروس بود.
حال برای درک بهتر، ویدیوی زیر را تماشا کنید:
توجه:
- دسترسی یوزر به منابع به مدت عمر یا اعتبار مجوز یا بلیط Lifetime of ticket بستگی دارد.
- مجوز یا بلیط ticket قابل تجدید شدن renewable است.
- زمان Lifetime به صورت استاندارد 10 ساعت است که از طریق گروه پالسی Group Policy تنظیم میشود (لطفا در صورتی که اطلاعات کافی ندارید، با این زمان بازی نکنید)