AD автентикацията използва два основни протокола: Kerberos и NTLM
NTLM
Процесът на сертифициране е следният:
- Клиентът генерира NTLM хеш локално, а стойността е хеш стойността на паролата на потребителя.
- Клиентът изпраща потребителското име към сървъра на приложението.
- Сървърът на приложението генерира случайна стойност за клиента, която обикновено се нарича nonce или challenge.
- Клиентът криптира NONCE с NTLM хеш и го изпраща към сървъра на приложението.
- След като го получи, сървърът на приложението го изпраща към AD сървъра заедно с потребителското име и nonce.
- AD генерира NTLM хеш въз основа на паролата на потребителя, криптира nonce и след това сравнява съобщението на клиента.
- Ако стойностите са еднакви, автентикацията преминава, а ако са различни, автентикацията се проваля.
Керберос
Ключови термини:
- KDC: Център за разпределение на ключове, който предоставя две услуги: услуга за автентикация (AS) и услуга за издаване на билети (TGS). Домейнът генерира домейн акаунт, наречен krbtgt за KDC, а TGT използва паролата за криптиране и декриптиране. Когато потребител на домейн достъпва за първи път, той иска AS да се удостовери, а след преминаването AS иска от TGS да предостави билет (TGT) на домейна потребителя.
- SPN:Service Principal Name。 Освен потребителските акаунти, AD акаунтите имат и сервизни акаунти. Приложението ще има и свързан сервизен акаунт, който ще улесни достъпа до сървърни ресурси като exchange, SQL, IIS и др. SPN е услуга, използвана за свързване на услугата, активирана от приложението, със служебния акаунт в AD.
Процес на сертифициране:
1. Когато потребител на домейн влезе, към DC се изпраща AS заявка (AS_REQ), която съдържа криптиран времеви печат, криптиран с паролата и потребителското име на потребителя.
2. След получаване на заявката, DC използва хэша на потребителското име и паролата на потребителя, за да я декриптира. DC отговаря с AS отговор (AS_REP) на клиента, който включва сесийен ключ и TGT (билет за предоставяне на билет). Сесийният ключ се криптира с хеша на паролата на потребителя. TGT съдържа членството в групата, домейна, времевия печат, IP адреса на клиента и сесийния ключ. TGT също е криптиран, криптиран с паролата на KDC Service акаунта и клиентът не може да я декриптира. (TGT е валиден по подразбиране 10 часа, а актуализациите, които се случват след това, не изискват потребителят да въвежда паролата отново)
3. Когато потребител поиска ресурс в домейна, се изпраща заявка за услуга за предоставяне на билети (TGS_REQ), включваща потребителското име, времевия печат, TGT и SPN. Времевите печати и потребителските имена се криптират с сесиен ключ.
4. След получаване на заявката, KDC първо определя дали има SPN в заявката, след това декриптира TGT, извлича сесийния ключ и времевия печат в TGT и използва сесийния ключ в TGT, за да декриптира криптираното потребителско име и времеви печат. Направете няколко проверки:
(1) Времевият печат, декриптиран от TGT, трябва да е валиден. (Ако възникне повторна атака, времевият печат е невалиден.) ）
(2) Дали потребителското име в TGT съответства на потребителското име в заявката.
(3) Дали IP адресът в TGT е същият като IP адреса в заявката.
Проверката ще отговаря на TicketGranting ServiceReply(TGS_REP) на клиента, който съдържа упълномощения достъп от SPN, новия сесийен ключ, използван за достъп между клиента и SPN, и новия Service Ticket Service Ticket (включително новия сесийен ключ, потребителско име и потребителска група). Както упълномощеният SPN ключ, така и сесийният ключ, който достъпва SPN, са криптирани със сесийния ключ в TGT. Заявката за услуга се криптира с паролата на съответния SPN акаунт.
1. След горния процес, потребителят е получил сесийния ключ и служебния билет, свързани с услугата на приложението. Потребителят изпраща заявка за приложение (AP_REQ) към приложната услуга, която съдържа потребителското име и времеви печат и е криптирана със сесийен ключ.
2. Приложната услуга използва хеша на паролата на служебния акаунт, за да декриптира заявката и да извлече потребителя, потребителската група и сесийния ключ. Декриптирайте потребителското име и времевия печат в AP_REQ с декриптирания сесийен ключ. AP_REQ Ако е така, заявката се приема и услугата за приложение присвоява права въз основа на информацията от потребителската група в заявката, след което потребителят може да получи достъп до поисканата услуга.
Оригинален адрес:Входът към хиперлинк е видим.
|
Публикувано в 22.08.2023 г. 19:16:28 ч.
|
|
|
|
