با جستجویی که در گوگل انجام دادم متوجه شدم مقاله کامل و جامعی درباره کربروس (Kerberos) وجود ندارد بنابر این این مقاله را جهت اطلاعات بیشتر کاربران داتیس نتورک آماده کرده ام .
کربروس 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@contoso.com
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.contoso.com:1433
وقتی یک مخزن برنامه وب Web Application Pool در IIS ، در حال اجرا با استفاده از اکانت یک یوزر میباشد، بجای اینکه از Network Service بصورت استداندارد استفاده کند. مثل http/websrvr.contoso.com
مجوزها یا بلیط های کربروس 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 باشد . .
برای بهتر فهمیدن یک مثال میزنیم: یک یوزر در دومین Contoso.com میخواهد به یک فایل سرور File Server در دومین Emea.Contoso.com دسترسی داشته باشد .این یوزر باید یکTGT برای Contoso.com و Emea.Contoso.com داشته باشد .
سرور اعطای مجوز 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 دیتا وجود دارد. اگر میخواهید فقط به صورت ساده مراحل را متوجه شوید، فقط توضیحاتی را که با شماره نوشته شده بخوانید، ولی اگر میخواهید کمی عمیق تر مطلب را متوجه شوید، برای هر شماره زیر آن توضیحاتی داده میشود که آن را نیز بخوانید
۱- کلاینت یک 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 از زمان با تلرانس ۵ دقیقه خارج نشده اند. این مکانیزم یوزر و پسورد آن Principal را تصدیق و احراز هویت میکند .
Session Key -که برای TGT داده میشود، برای درخواست بلیط یا مجوز سرویس Service ticket استفاده میشود .
۳- حالا کلاینت از زمانی که دارای TGT معتبر را برای اکتیو دایرکتوری در دومین میباشد، میتواند درخواست بلیط یا مجوز سرویس Service ticket کند. در این مرحله کلاینت یک KRB_TGS_REQ به سمت KDC که بیشتر و بطور خاص Ticket Granting Server – TGSمیباشد را ارسال میکند و درخواست یک بلیط یا مجوز سرویس Service ticket را میکند. یادتان نرود که کلاینت فقط یک درخواست بلیط یا مجوز سرویس Service ticket ارسال نمیکند، بلکه یک کپی از TGT که در مرحله ۲ در خود دارد را نیز با آن ارسال میکند .
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 مشخص میکند که ساعت سیستم در همان تلرانس ۵ دقیقه میباشد و از آن خارج نشده و تشخیص میدهد که یک نفوذ یا حمله 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 رمز گزاری میشوند .
۵- سپس کلاینت این Service Ticket را به سمت سرویس یا برنامه به عنوان یک KRB_AP_REQارسال میکند. شما بطور معمول نوع آن پکت Packet را بصورت سرویسی که در آن جاسازی شده و استفاده میشود، خواهید دید. بطور مثال اشتراک فایل File Share از SMBاستفاده میکند .
– اطلاعات درون KRB_AP_REQ در حقیقت Service ticket میباشد که از TGS بدست می آید وauthenticator با Session Key برای سرویس رمز گزاری شده است .
۶- بعد از آنکه احراز هویت 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 را بررسی کند .
این ۶ مرحله، مراحل مجوز یا بلیط کربروس بود .
حال برای درک بهتر، در زیر به صورت عکس یکبار دیگر مراحل را میبینیم .
مرحله ۱
مرحله ۲
مرحله ۳
مرحله ۴
مرحله ۵
مرحله ۶
توجه :
دسترسی یوزر به منابع به مدت عمر یا اعتبار مجوز یا بلیطLifetime of ticket بستگی دارد .
مجوز یا بلیط ticket قابل تجدید شدن renewable است .
زمان Lifetime به صورت استاندارد ۱۰ ساعت است که از طریق گروه پالسی Group Policyتنظیم میشود (لطفا در صورتی که اطلاعات کافی ندارید، با این زمان بازی نکنید
ابزاری که برای دیدن View و رفع ایراد Troubleshooting کربروس Kerberos استفاده میشود :
این وسیله گرافیکی GUI Tool به شما این امکان را میدهد که تمام مجوزها یا بلیط های کربروس Kerberos tickets را نشان View میدهد و همچنین به شما این امکان را میدهد که آنها پاک Purge کنید. قابلیت پاک کردن به این شیوه است که بر روی مجوز یا بلیط سبز رنگ Green Ticket در System tray با موس کلیک سمت راست کرده و سپس Purge Tickets را کلیک میکنیم. بعد از این عمل، تمام مجوزها یا بلیط های کربروس Kerberos tickets پاک میشوند .
این وسیله خط فرمان Command line به شما این امکان را میدهد که تمام مجوزها یا بلیط های کربروس Kerberos tickets را نشان View میدهد و همچنین به شما این امکان را میدهد که آنها پاک Purge کنید. مزیت Klist نسبت به Kerbtray در این است که شما باKlist میتوانید مجوزها یا بلیط های کربروسKerberos tickets مورد نظر را انتحاب کرده و پاک کنید، در حالیکه با Kerbtrayمیتوانید فقط همه را پاک کنید .
Kerberos Event logging
How to enable Kerberos event logging
به صورت استاندارد، سیستم Operating System برای اتفاقات یا رویدادهای Events احراز هویت کربروس Kerberos authentication لاگ Log ثبت نمیکند. اما شما با لینکی که در بالا قرار داده شده، میتوانید آن را فعال کنید .
Network Captures
Network Monitor 3.4
WireShark
Ethereal
برای دیدن یا لاگ کردن Kerberos authentication در زمان مشکل میتوانید از ابزار مانیتورینگ مانند Network Monitor یا WireShark یا Ethereal استفاده کنید .
امیدوارم این مقاله برای شما مفید باشد – datisnetwork.com
مقاله ای که نوشتین خیلی خوب و مفید بود البته مطالب سنگین هستش باید چندین بار مطالعه بشه.
من یه سوالی برام پیش اومد که کربروس چه محدودیت هایی داره دنبالش گشتم اما چیز درست و حسابی پیدا نکردم گفتم اینجا مطرح کنم شاید کسی چیزی بدونه و بتونه جوابم رو بده.
ممنون