Kerberos- قسمت دوم: Active Directory

در محیط Active Directory وظیفه KDC ها بر عهده ی Domain Controller ها است همچنین از Domain برای Realm استفاده می شود. در اینجا قصد داریم، فرآیند ذکر شده برای Kerberos v5 را در محیط Active Directory مرور کنیم.

بخش یک

 

image_thumb[57]

در Windows Vista/7/2008 ابتدا kerberos Authentication توسط LSA فراخوانی می شود. زمانی که یک user قصد دارد Logon کند، لازم است username و password خود را وارد کند. password او توسط یک الگوریتم hash یک طرفه رمزنگاری شده و در محل امنی از حافظه نگه داری می شود. hash یک طرفه به این معنی است که کلمه عبور از عبارت hash شده قابل استخراج نمی باشد. این عبارت hash ثابت است به این معنی که هر زمان که عملیات hashبرای همان password انجام شود خروجی ثابت است.

۱) ابتدا Kerberos SSP روی Client یک پیام درخواست برای DC ارسال می کند. این پیام حاوی مواری همچون، Username، TGT و Domain مربوطه است. همچنین Pre-Authentication Data نیز در این درخواست ارسال می شود که با استفاده از کلیدی که از روی عبارت password تولید می شود رمز شده است.

۲)زمانی که پیام درخواست به DC می رسد. پروسه ی AS ابتدا نام کاربری را در data store خود چک می کند و سپس با توجه به آنکه در زمان تعیین password، به AS نیز اطلاع رسانی شده است و دارای یک کپی از کلید است می تواند رمز شده در پیام را رمزگشایی کند و Time Stamp را باز بینی کند. چنانچه رمزگشایی موفقیت آمیز باشد و Time Stamp در بازه زمانی ۵ دقیقه ای زمان فعلی DC باشد، DC برای Authenticate کردن آن کاربر آماده می شود. حداکثر زمان اختلاف که به صورت پیش فرض ۵ دقیقه است، در تنظیمات سیاست دامین قابل ویرایش است.

۳) زمانی که مرحله دو موفقیت آمیز بود، DC یک پیام برای Client ارسال می کند که حاوی یک Session Key (کلید جلسه) برای TGS یا Ticket-Granting Service است. همچنین حاوی یک TGT یا Ticket-Granting Ticket خواهد بود که برای درخواست های به TGS نیاز خواهد بود. در تمام lifetime (عمر) TGT کلاینت دیگر نیاز به دریافت TGT نخواهد داشت. در TGT تمام Access Token های کاربر همانند SID خود User و SID گروه هایی که در آن عضو است وجود دارند. توجه داشته باشید تنها SID مربوط به Security Groups در TGT اضافه می شود و از این رو است که دسترسی های امنیتی با استفاده از این نوع گروه تخصیص می یابند. به این اطلاعات در اصطلاح Privilege Attribute Certificate یا PAC می گوییم. کلید TGS با استفاده از کلید کاربر رمزنگاری شده و TGT با استفاده از یک کلید بلند مدت مخصوص DC که به آن krbgt می گوییم. بنابراین محتوای آن برای کلاینت نا مفهوم است.

۴) زمانی که packet ها به Client می رسند، کلید کاربر که از روی password آن ساخته شده بود برای بازگشایی کلید TGS مورد استفاده قرار خواهد گرفت. چنانچه رمزگشایی موفق باشد و Time Stamp معتبر باشد، کامپیوتر Client تصور می کند که Authentication موفقیت آمیز بوده است. همچنین کلید TGS روی کامپیوتر تا زمانی که کاربر logoff کند و یا عمر آن (LifeTime)تمام شود Cache می شود. از کلید TGS برای رمزنگاری تمام ارتباطات آینده با DC استفاده خواهد شد و این به معنی آن است که Client دیگر نیازی با کلید کاربر ندارد و حذف می شود. TGT به صورت رمزنگاری شده روی Cache نگه رای می شود.

– پروتکل Kerberos دارای یک زیر پروتکل به نام ASE یا Authentication Service Exchange است که فرآیند توضیح داده شده بر اساس آن صورت گرفته است. در RFC پیام اول با KRB_AS_REQ و پیام دوم با KRB_AS_REP شناسایی می شوند.

بخش دو

 

image

۵) تا اینجا کاربر تشخیص هویت شده است، اما دسترسی به منابع ندارد. برای دسترسی به منابع لازم است Ticket مخصوصی را از TGS دریافت کند. با استفاده از TGT کاربر می تواند هویت خود را برای TGS معین کند. برای این منظور علاوه بر TGT در یک پیام نام و Domain کامپیوتر مقصد که کاربر قصد دارد روی آن به منابعی دست پیدا کند را به TGS ارسال می کند. همچنین SPN یا Service Principal Name ای که UPN یا User Prinicipal Name می خواهد به آن متصل شود و TimeStamp با استفاده از TGS Session Key که در بخش قبل به دست آمده بود رمز شده برای DC ارسال می گردد.

۶) DC اکنون TGT را با استفاده از long-term Key خود می تواند رمز گشایی کند. سپس با رمزگشایی timestamp مشخص می گردد که کلاینت از کلید مناسب برای رمزنگاری آن استفاده کرده یا به عبارت دیگر هویت جعل نشده کلاینت تایید می شود. همچنین TimeStamp بررسی می شود که معتبر باشد. سپس DC یک LDAP Query برای یافتن اکانتی که SPN روی آن register شده است می گیرد. پس از آن، DC آماده صورت Service Ticket است.

۷) پاسخ شامل دو کپی از Service Session Key است. کلید اول با استفاده کلید TGS Session Key رمز نگاری شده است و کپی دوم در Service Ticket وجود دارد که برای دسترسی به Service کلاینت آن را به Server ارائه می دهد. Service Ticket توسط یک کلید بین Server و DC رمز شده است و بنابراین محتوای ticket برای کلاینت نامفهوم است.

۸) کلاینت Session Ticket را دریافت می کند و به همراه سایر اطلاعات دریافتی Cache می کند.

– پیام ها در این مرحله به ترتیب با نام های KRB_TGS_REQ و KRB_TGS_REP شناسایی می شوند.

بخش سه

 

image

۹) کلاینت برای دسترسی به Service لازم است Ticket را برای برقراری Session به Server ارائه دهد.

۱۰) Server با استفاده از کلید خود Service Ticket را رمزگشایی می کند و سپس با استفاده از Session Key به دست آمده می تواند TimeStamp را رمزگشایی کند. اگر TimeStamp معتبر باشد (در بازه ۵ دقیقه ای زمان خود Server باشد به صورت پیش فرض) سرور می تواند به اطلاعات دریافت شده اعتماد کند. اکنون Server بررسی می کند که اگر کلاینت درخواست تشخیص هویت متقابل کرده باشد، سرور یک واحد به TimeStamp اضافه می کند و آن را با استفاده از Session Key رمزنگاری می کند و به کلاینت بر می گرداند.

۱۱) اگر کلاینت درخواست تشخیص هویت متقابل (mutual Authentication) کرده باشد، پیام ارسال شده از طرف Server را دریافت می کند و سپس آن را با استفاده از Session Key رمز گشایی می کند اگر مقدر TimeStamp مقدار مورد انتظار باشد، کلاینت می تواند هویت سرور را بپذیرد.

– پیام های در این قسمت به ترتیب با نام های KRB_APP_REQ و KRB_APP_REP شناسایی می شوند.

پس از آنکه عملیات Authentication انجام شد، سرور، Service Ticket دریافت شده را به LSA تحویل می دهد. LSA سپس اطلاعاتی که برای Authorization (تایید صلاحیت) کاربر نیاز است را استخراج می کند. این اطلاعات شامل SID های User و Security Group هایی که عضو آن است می باشد. LSA از این اطلاعات برای ساخت یک Access Token استفاده می کند که برای دسترسی به هر منبع (Resource) موجود روی Server لازم است توسط کلاینت ارائه شود.

نکته: با استفاده از ابزار هایی همانند KList.exe می توانید Ticket ها و اطلاعات Cache شده روی کلاینت را مشاهده کنید و یا آن ها را حذف کنید. این ابزار در Windows Server 2008 در دسترس است و از CLI (محیط متنی) استفاده می کند. همچنین با استفاده از ابزار Kerbtray.exe که یک محیط گرافیکی دارد می توانید Ticket های Cache شده را مشاهده کنید. این ابزار به عنوان یکی از ابزار های Windows Server 2003 Resource Kit Tools در آن قرار دارد.

Flagها

پرچم ها مولفه هایی هستند که برای تعیین محدودیت یا مقصود (هدف) Ticket به کار گرفته می شوند. برخی از Flag ها عبارت اند از:

– Forwarded
– Forwardable
– Proxy
– Proxiable
– Invalid
– Renewable
– PostDated
– hw-AUTHENT
-PRe-AUTHENT

Delegation Of Authentication

یکی از چالش هایی که می تواند دسترسی به شبکه را پیچیده کند، آن است که سرویس های تحت شبکه معمولا به صورت توزیع شده (Distributed) کار می کنند. به عنوان مثال ممکن است برای دریافت سرویسی مشخص، لازم باشد که به یک Front-End Server متصل شویم که آن Server از Database روی یک back-End Server استفاده می کند. در چنین شرایطی لازم است user علاوه بر Front-End Server اطلاعات کاربر در Back-End Server نیز Authorize شود. در Windows Server 2000 امکانی در kerberos ایجاد شده است که سبب می شود این قابلیت از دو روش به وجود آید. این روش ها عبارت اند از Proxy Ticket و Forwarded Ticket.

اگر امکان استفاده از Proxy Ticket فعال باشد. کلاینت یک درخواست Session Ticket به KDC برای back-End Server ارسال می کند و سپس یک Proxiable Flag روی آن می زند. سپس کلاینت Session Ticket دریافت شده را به Front-End Server تحویل می دهد که از آن برای ارتباط با Back-End Server استفاده می کند. بزرگترین ایراد وارد بر این روش آن است که لازم است کلاینت اطلاعات هویت Back-End Server را بداند.

روش دیگر استفاده از Forwarded Ticket است. در این حالت اگر امکان استفاده از این نوع Ticket ها موجود باشد، Client یک درخواست AS Exchange به KDC (یا در واقع DC) ارسال می کند. این درخواست، یک درخواست TGT است که Front-End Server بتواند با آن به Back-End Server دسترسی پیدا کند. اکنون، AS یک TGT برای Client ارسال می کند که Client آن را به Front-End Server می فرستند. Front-End Server یک Session Ticket برای Back-End Ticket دریافت می کند که با استفاده از آن Session Ticket به Back-End Serverدسترسی پیدا می کند. مسئله ای که اینجا ایجاد می شود آن است که پس از آنکه Front-End Server یک TGT از Client دریافت می کند، می تواند از آن TGT برای دسترسی به هر Resource دیگری که Client به آن دسترسی داشته است استفاده کند. برای حل این مشکل در Windows Server 2003 راهکاری در نظر گرفته شد که به آن Consstrain Delegation گفته می شود. با استفاده از ایم ویژگی TGTها با استفاده از SPN ها فقط مخصوص همان سرویس خواهد شد.

برای جلوگیری از آنکه Kerberos Delegation در خصوص یک Userصورت بگیرد، در کنسول Active Directory Users and Computers رفته و روی User Account مورد نظر Right Click کنید و گزینه Properties را بزنید. در TAB (زبانه) Account گزینه This account is sensitive and Cannot be Delegated را چک بزنید.

برای جلوگیری از آنکه Kerberos Delegation در خصوص یک Service صورت بگیرد، ابتدا لازم است نوع Account ای که آن سرویس از آن استفاده می کند را بیابید. اگر از یک اکانت localsystem استفاده می کند، تنظیمات باید روی Computer Account انجام شود. اگر از یک User Account استفاده می کند مشابه قبل عمل کنید. فراموش نکنید لازم است آن اکانت دارای یک SPN مناسب باشد.

image

 

در قسمت بعدی: پیکربندی  Kerberos

یک دیدگاه در “Kerberos- قسمت دوم: Active Directory

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *