کربروس چیست - What is Kerberos? (fa-IR)

کربروس چیست - What is Kerberos? (fa-IR)


در این مقاله تلاش میکنیم که کوتاه و مفید در مورد کربروس  Kerberosصحبت کنیم.

نام های اصلی    Principal Names

کربروس Kerberos دو نوع نام اصلی Principal Names مختلف different را تعیین یا مشخص میکند. این دو نام اصلی مختلف، یکی 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  دیتا وجود دارد. اگر میخواهید فقط به صورت ساده مراحل را متوجه شوید، فقط توضیحاتی را که با شماره نوشته شده بخوانید، ولی اگر میخواهید کمی عمیق تر مطلب را متوجه شوید، برای هر شماره زیر آن توضیحاتی داده میشود که آن را نیز بخوانید .



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 که در مرحله ۲ در خود دارد را نیز با آن ارسال میکند .
 
 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 را بررسی کند .

این ۶ مرحله، مراحل مجوز یا بلیط کربروس بود .

حال برای درک بهتر، در زیر به صورت عکس یکبار دیگر مراحل را میبینیم
.

مرحله 1



مرحله 2



مرحله 3



مرحله 4



مرحله 5



مرحله 6




توجه :
دسترسی یوزر به منابع به مدت عمر یا اعتبار مجوز یا بلیطLifetime of ticket  بستگی دارد
.
مجوز یا بلیط ticket قابل تجدید شدن renewable است
.
زمان Lifetime به صورت استاندارد 10 ساعت است که از طریق گروه پالسی Group Policy تنظیم میشود (لطفا در صورتی که اطلاعات کافی ندارید، با این زمان بازی نکنید .(





ابزاری که برای دیدن View و رفع ایراد Troubleshooting کربروس Kerberos استفاده میشود :

Kerbtray.exe

 

این وسیله گرافیکی GUI Tool به شما این امکان را میدهد که تمام مجوزها یا بلیط های کربروس Kerberos tickets را نشان View میدهد و همچنین به شما این امکان را میدهد که آنها پاک Purge کنید. قابلیت پاک کردن به این شیوه است که بر روی مجوز یا بلیط سبز رنگ Green Ticket در System tray با موس کلیک سمت راست کرده و سپس Purge Tickets را کلیک میکنیم. بعد از این عمل، تمام مجوزها یا بلیط های کربروس Kerberos tickets پاک میشوند .

Klist.exe

این وسیله خط فرمان 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 استفاده کنید.


How the Kerberos Version 5 Authentication Protocol Works
 Kerberos Authentication Technical Reference
 The Kerberos Consortium
 Kerberos: The Network Authentication Protocol
 Kerberos Survival Guide
RFC1510
RFC4120

 

Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Patris_70 edited Revision 5. Comment: completed

  • Patris_70 edited Revision 3. Comment: not completed

  • Patris_70 edited Revision 2. Comment: not completed

  • Patris_70 edited Revision 1. Comment: not completed

Page 1 of 1 (4 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Patris_70 edited Revision 1. Comment: not completed

  • Patris_70 edited Revision 2. Comment: not completed

  • Patris_70 edited Revision 3. Comment: not completed

  • Patris_70 edited Revision 5. Comment: completed

  • Very helpful

  • Thanks

Page 1 of 1 (6 items)