نحوه کار Kerberos (پارت دوم)
دوستان من در این مقاله به ادامه مبحث مقاله قبل میپردازم و سعی میکنم اطلاعات کاربردی درمورد این پروتکل جذاب ارائه دهم. تو این مقاله من درمورد Ticket Flags، TGT/TGS Lifetime، Renewable Ticket و.. توضیح میدم.
خُب بریم سراغ اصل داستان و ادامه مقاله قبل !!
ادامه بحث مربوط به Ticket ها
چطور KDC قادر به محدود کردن Lifetime تیکت ها است؟
– هر تیکت باید Start time و End time داشته باشد
– کلاینت میتونه Start time رو خودش مشخص کنه.
– اگر start time رو خود کلاینت معلوم نکرد، KDC تایمی که اون تیکت رو ایجاد میکنه به عنوان Start time در نظر میگیره.
– حالا KDC با استفاده از Start time و پالیسی دامین، End time رو بدست میاره.
– که فاصله زمانی بین start time و End time میشه = Life time
چه اتفاقی میوفته اگر Ticket، Expire بشه؟
– خود KDC متوجه Expire شدن تیکت ها نمیشه، چون اطلاعات مربوط به تیکت ها رو تو خودش نگهداری نمیکنه.
– زمانی که کلاینت بخواد از تیکت استفاده بکنه، میفهمه که Expire شده.
– البته اگر به یه تیکت ما وصل شده باشیم به یک سرویسی و بعد اون تیکت Expire بشه، اون کانکشن ما همچنان پابرجا میمونه.
– ولی اگر بخوایم برای بار بعد به اون سرویس وصل بشیم، متوجه Expire شدن اون میشیم.
اگر TGT، Expire بشه چی میشه؟
– خُب واضحه که باید درخواست TGT بده.
– اما برای این کار نیاز به User long term key داره.
– اگر خود کلاینت این User long term key رو cache نکرده باشه، امکان داره کادر Username/Password براش بیاد تا Password خودش رو دوباره وارد کنه.
اما Renewable TGT چیه؟
– وقتی تیکت ها Renewable باشند، بجای اینکه KDC تیکت جدید ایجاد بکنه، برای اون تیکت Session key ها رو در هر بازه زمانی مشخص تغییر میده.
– اگر پالیسی Renewable Ticket فعال باشه :
– تو قسمت End time، اون زمانی هست که این Instance از TGT منقضی میشه. مثلا ۱۰ ساعت. یعنی کلاینت ۱۰ ساعت وقت داره تا Renew کنه.
– و قبل از اینکه End time تموم بشه، کلاینت باید یه Authenticator جدید درست کنه بفرسته به KDC تا TGT خودش رو Renew کنه.
– یه زمان دیگه وجود داره به اسم Renew Till. یعنی تا کِی این تیکت میتونه Renew بشه. مثلا میتونه ۱ روز باشه.
– یعنی تا ۱ روز این تیکت میتونه Renew بشه.
قسمت Credential Cache
– تیکت هایی که گرفته میشه، در Credential Cache نگهداری میشه. که بر روی Volatile Memory(حافظه فرار) ذخیره میشه و امنیت این قسمت بر عهده LSA(Local Security Authority) است.
– خود Credential Cache هم توسط Kerberos SSP مدیریت می شه.
– هر وقت تیکت بخواد استفاده بشه یا Renew بشه از این قسمت فراخوانی میشه.
– همه دیتا ها در Credential Cache زمانی که Log off و یا Shutdown رخ میدهد، از بین میروند.
KDC in-depth
خب در این بخش همونطور که از اسمش معلوم هست، میخوام درمورد خود سرویس Kerberos، اجزای اون، دیتابیس و نحوه کارش توضیحات بیشتری به شما ارائه بدم.
چند نکته ریز درمورد KDC :
– مایکروسافت KDC رو به عنوان یک سرویس ارائه و راه اندازی کرده.
– از Active directory های درون دامین به عنوان Account databse خودش استفاده میکنه.
– بعضی مواقع هم اطلاعاتی از GC یا همون Global Catalog میگیره.
– KDC در همه DC وجود داره، دقیقا مثل Directory Service.
– KDC توسط LSA هنگام بوت اجرا میشه. غیرقابل Stop هم هست.
– اکانتی که KDC برای دسترسی استفاده میکند، krbtgt است.
توضیحات اضافه درمورد KDC Account Databse :
– درواقع Active Directory به عنوان Account databse برای KDC عمل میکنه.
– و اون Encryption key که مخصوص هر Principal object در دامین هست نیز، در Attribute اون Principal object ها وجود داره.
– دیتابیس KDC توسط Directory System Agent کنترل میشه که این DSA هم با LSA در سیستم عامل بصورت یکپارچه کنار هم کار میکنند.
– اگر یک کلاینت بخواد اطلاعات خودش یا بقیه یوزر ها رو در این دیتابیس پیدا بکنه باید به Active Directory Service Interfaces(ADSI) وصل بشه.
– مثل File و Folder، تمامیه Object های این دیتابیس توسط Access Control List(LSA) کنترل و پرمیشن دهی میشه.
– بر خلاف File و Folder، در این دیتابیس نه تنها Object ها بلکه Attribute های اون ها هم با ACL کنترل و پرمیشن دهی میشن.
– از اونجایی که پسورد بسیار دیتای مهمی هست، در Attribute به اسم account’s object password فقط Encryption key را نگهداری میکند نه خود پسورد رو.
ویژگی های اکانت Krbtgt چیه؟
– درواقع SPN سرویس KDC همین krbtgt است. (در ادامه درمورد SPN گفته می شود)
– وقتی دامین ساخته می شود این اکانت بوجود می آید.
– این اکانت پاک نمیشه و حتی rename هم نمیشه.
– یک پسورد بصورت خودکار به krbtgt داده می شود.
– پسورد krbtgt که درون یک encryption key قرار میگیرد و در نهایت یک KDC Long term key بوجود میاد.
– این KDC long term key استفاده میشه برای encrypt, decrypt کردن TGT ها در دامین.
– پسورد این اکانت برای Domain trust هم بصورت خودکار داده میشود. که همان inter realm key از آن بدست می آید.
– پسورد این اکانت چه برای داخل دامین و چه برای domain trust بصورت اتوماتیک عوض می شود.
توضیح وظایف سرویس های KDC :
۱- Authentication Service(AS) :
– وظیفه این قسمت ارائه دادن TGT به کلاینت هست.
– تا کلاینت با TGT بتونه Service ticket مورد نظرش رو دریافت کنه بدون اینکه هر بار Username/Password را وارد کنه.
۲- Ticket-granting Service(TGT)
– وقتی کلاینت میخواد به یک سرویس در شبکه وصل بشه، باید درخواست Service ticket بده.
– باید حتما Authenticator و TGT هم به همراه درخواستش ارائه بده.
– اگر کلاینت بخواد وصل بشه به سرویسی تو یک دامین دیگه، باید از Referral Process این Service ticket رو بگیره. (Referral process در مقالات بعدی گفته میشود)
وظیفه ای مهم به اسم Session Key Distribution
شما فکر کنید که هر کلاینت در شبکه برای وصل شدن به هر سرویسی باید یک Session key جداگانه و Unique داشته باشد. که این به این معناست که اگر ما ۱۰۰ اکانت در یک دامین داشته باشیم در نهایت به ۴,۹۵۰ عدد Session key نیاز پیدا میکنیم.
فرمولش میشه : n(n-1)/2 —-> n = number of accounts
حالا Kerberos چجوری این مشکل رو حل میکنه؟
– ما گفتیم کربروس ۳ سر داره : Client, Server(Application), KDC
– تنها کاری که میکنه این هست که، ۲ تا کپی از Session key رو میده به کلاینت.
– Session key کلاینت با user long term key خودش انکریپت میشه. یعنی فقط خود یوزر میتونه با long term key خودش اون رو دیکریپت کنه.
– و Session key که برای Server هست هم با Long term key اون سرویس درون Session ticket قرار میگیره و انکریپت میشه تا فقط اون سرویس بتونه Session ticket رو دیکریپت کنه و محتواش رو ببینه.
– پس دیگه این مشکل حل شد، چون KDC دیتاهای مورد نیاز رو در اختیار خود کلاینت قرار میده، تا هرموقع کلاینت خواست از اون ها استفاده کنه.
حالا KDC key version numbers چیه؟
– یوزر ها میتونن Password خودشون رو عوش بکنن.
– حالا این میتونه برای ticket هایی که با User long term key قبلی انکریپت شدن مشکل ساز بشه.
– برای حل این مشکل، یوزر یه مدتی کپی Long term key قدیمی رو نگه میدارن.
چه زمانی KDC key version number ساخته میشه؟
– زمانی که پسورد جدید set میشه این قسمت ساخته میشه.
– حالا این KDC key version number فقط برای Long term key ها هستند، مثل User long term key, inter realm key, Computer long term key
این KDC key version numbers چجوری ساخته میشه؟
– از طریق یک Attribute به اسم Update logon Timestamp ساخته میشن. که این Attribute در SAM قرار داره.
نکته آخر درمورد KDC key version number :
به نظر شما کلاینت از کجا میتونه بفهمه که باید از کلید قدیمی استفاده بکنه یا کلید جدید؟ نکته اینجاست که یک header اضافه میکنه خود KDC و در اون Serial number که استفاده کرده تا این مکالمه رو انکریپت بکنه رو می نویسه. با این کار کلاینت متوجه میشه که باید از چه کلیدی برای دیکریپت این مکالمه استفاده بکنه.
Kerberos Ticket Flags
اول از همه باید بگم که ما به تعداد ۲ به توان ۵ عدد یعنی ۳۲ تا Ticket flag در کربروس داریم. یعنی از بیت ۰ تا ۳۱ که میشه ۳۲ تا. اما من فقط مهمترین اون ها و یا کاربردی ترین شون رو به برای شما نام میبرم. در ادامه مقالات درمورد بعضی این Flag ها توضیح می دهم.
۱- Forwardable
۲- Proxiable
۳- Initial
۴- Postdated
۵- Renewable
۶- Invalid
۷- Pre-authenticated
دوستان امیدوارم از این مقاله لذت برده باشید.
یه سری نکات ریز دیگه مونده، که به امید خدا تو چند روز آینده آماده میشه.
