Kerberos разпознаване в активна директория, конфигуриране на прозорци и Linux сървъри
Проверете Kerberos разпознаване на Active Directory
Проверете Kerberos разпознаване на Active Directory
Здравейте скъпи читатели, не толкова отдавна работех върху задачата по конфигуриране на SQL Наличност групи на клъстера на Windows, в които клиентите правят хубави уеб-базирани инструменти, всичко е наред, клиентът чака за следващото развитие на ситуацията в момента, а именно създаването и прилагането на механизма на Single Sign- на (SSO) или руски една точка на удостоверяване, ние вече са запознати с него при създаването на Vmware vCenter Server. Този механизъм работи на криптиране Kerberos протокол, който ще говорим. Ние разглеждаме как Kerberos разпознаване се проверява в Active Directory. като разбирането на принципите, които ще ви помогнат при реализирането на една точка на удостоверяване.
Идентификация и достъп до Active Directory
Домейн Услуги Active Directory (Active Directory Domain Services, AD DS) осигурява автентикация и достъп (идентичност и достъп, IDA) за корпоративни мрежи. Нека да видим как на изискванията и критериите трябва да съответстват на структурата на IDA:
- Тя трябва да съхранява информация за всички обекти на Active Directory, като например: потребители, групи за сигурност, компютри, принтери и други идентифициращи обекти. Идентифициране обект (идентичност) предполага някаква идея по същество има за задача да извърши всички действия на корпоративната мрежа. Един прост пример е потребител Боб и той работи с документи в споделена папка на сървъра. Тези документи са защитени достъп, който определя списъка за контрол на достъпа (Access Contro Списък л, ACL). Достъпът в желан от вас файл, управляван от сигурността на подсистемата на сървъра, който е в папка, когато осъществявате достъп, той сравнява идентификация на потребителя на обекта с обектите, които се намират в нея на ACL, и вече въз основа на това, той взема решение за даване или отказ на потребителя достъп , Тъй като услугата, компютри, групи, както и други предмети, да направят определени неща в локалната мрежа, като всеки от тях има своя собствена идентификация на обекта. Този обект съдържа много информация, която е уникална за всеки един от тях, като например името на потребителя, СИД (идентификатор за сигурност, SID), парола. Така, че идентифицирането на магазина обект, е неразделна част от идентичността и достъпа. Всички данни в Active Directory, се намират в директорията АД, който управлява домейн контролера.
- Authentication идентификация обект. Тук общия принцип на тази, когато потребителят получава достъп до документа, сървърът няма да го покаже на него, докато той не потвърди автентичността на идентификацията на обекта, който се появява в заявката. За да направите всичко това, потребителят има някаква тайна информация, която е известна с него и IDA инфраструктура, така че тези данни са само в сравнение с тези, които съществуват в идентифицирането на магазина обект по време на удостоверяване.
Kerberos протокол за удостоверяване
Операционната система Windows е добро, това е фактът, че тя е много стандартизиран, поради интерфейс SSPI (Support Provider сигурност интерфейс). SSPI - механизъм за операционната система Windows, чиято задача е осигуряването на приложения не зависи от различни удостоверяване протоколи, решения, което ви позволява да се работи изцяло с някоя от тях, за да перифразираме, че всяка молба да използвате всеки протокол за удостоверяване. Друг много голям плюс SSPI интерфейс е, че тя позволява да се изолира мрежов трафик от протокол за удостоверяване, ако просто, тези протоколи са независими от мрежовите протоколи за пренос на данни, както и прилагането на обща към крушката, кой да използвате.
То се осъществява чрез доставчиците на доставчик на услуги за поддръжка на сигурността (SSP), направен механизъм за удостоверяване. Операционната система Windows вече има вградени модули, но нищо не пречи на програмистите да вземе и напишете и да го свържете към SSPI
Ключът за персонализирано - когато администраторът на системата започва нов потребител, неговата стойност парола сметка се използва при създаването на ключа, тя се съхранява в непосредствена близост до самия обект потребителя АД. И, както е описано по-горе, най-важното знам домейн контролера и потребителят, двете страни.
ключ система - в момента на въвеждане на компютър в домейн на Active Directory, той също получава уникална парола въз основа на тях, и създава ключ, всички като потребител. Все пак, аз се отбележи, че тази парола е променено автоматично всеки месец, така че старите компютри, които отдавна не са включени, не могат да се удостоверяват в областта, тъй като връзката се губи доверие.
Ключови услуга (ключова услуга) - всичко е просто, често на системните администратори да управляват услугата за създаване на отделен домейн на потребителя, в следствие на тази услуга ще получи ключа си, но ако тя се управлява в рамките на системата на сметката (LocalSystem), а след това да получат ключова компютър.
Ключови между домейни (между сфера ключ). Този бутон позволява удостоверяване между домейни и се използва за осигуряване на връзка на доверие в Astive Directory среда.
- Нека разгледаме как удостоверяване Kerberos в домейна Active Directory. И така, на потребителя или на компютъра, като се опитва да влезе в мрежата локален домейн е протокол Kerberos да удостовери автентичността на тези данни, в резултат на което се получава пакет от данни, или по-скоро на билет или билет (билет), в дясно се нарича TGT (Ticket Предоставяне на билета).
Билет (билет) е закодиран пакети данни, която е издадена от доверен удостоверяване, от гледна точка на протокола Kerberos - Key Distribution Center (KDC, Key Distribution Center). TGT се криптира с помощта на ключ общи за услугата KDC, което означава, че клиентът не може да чете информация от вашия билет. Този билет е използван от клиента да получи други билети.
- Сега, когато даден потребител или компютър има TGT, тя може да му предостави всяка услуга или ресурс. В бъдеще, когато се отнася до специфични мрежови ресурси, потребители, представяйки TGT, получава от удостоверението KDC за достъп до дадена мрежа ресурс - билетен център (TGS). Този билет ще идентифицира заверено потребител на сървъра. Потребителят ще предостави TGS билет за достъп до сървъра, той ще го приеме и да потвърди преминаването на удостоверяване. Тук Kerberos и показва всички свои предимства, то е само се изисква една мрежа за влизане и след получаване на TGT на билета той е идентифициран за целия домейн като цяло, което му дава възможност да получите идентификационни билети за достъп до услуги, без да се влиза в публични пълномощията, всички тези операции се извършват поради вградените клиенти и Kerberos услуги в Kerberos.
Сам Ticket-Предоставянето на услуги се състои от две неща, първото е копие на ключа за достъп и информация на клиентите. Всички тези данни се криптира с ключ поделя между услугите, за които е налице лечение и KDC. Това означава, че потребителят не може да види данните, но услугата или сървърът, на който жалбата е да.
Благодарение на високото ниво на сигурност на протокола Kerberos, данните се прехвърлят няма да видите пароли или хеш стойност в ясен. Друго изискване за работа в съответствие с този протокол, изпълнява времето система, която не може да се отклони от времето на домейн контролер с повече от 5 минути
Друг много важен момент е факторът, че услугата KDC трябва да знае точно за какво точно услугата се осъществява достъп и как процеса на производство на ключ за шифроване. За да направите това, има механизъм, като например услуги Основни имена, всъщност уникален идентификатор на услуга, която ще се регистрира в базата данни Active Directory. На изискванията за това, тя трябва да бъде уникален в рамките на гората. Всяка услуга, която използва Kerberos, трябва да сте регистриран SPN. Без идентификатор конфигуриран правилно протокол за услугата или сървърът няма да работи.
Самата SPN се съхранява в атрибут Service-главен име, от една сметка в който той е свързан, и при която започва на услугата. По този начин, SPN свързва заедно всички части на процеса. Клиентът знае, за които услугата той иска достъп. И когато то се натрупва искане ключ низ SPN, например, с помощта на функцията DsMakeSpn. Сървърът KDC, получаване на данни, може да се намери на сметката, при които услугата ще започне и, с помощта на ключ от този потребител акаунт в Active, създаване на достъп билетни услуги и да го криптирате с този ключ.
Как е моят SPN конфигурация е описан в една статия.
Щателна митническа проверка Kerberos от началото сеч
Нека на снимките ще кажа по-подробно как удостоверяване Kerberos, от момента, потребителят въведе паролата. И така:
- Човек вижда областта на потребителско име и парола на компютъра си
- Компютърно генерирани на първични данни на потребителя изпраща заявка на домейн контролер, и по-специално да обслужва Key Distribution Center, който предава KDC потребителско име в ясна, името на домейна и текущото време на работната станция, за пореден път ти напомням, че не трябва да се различава от времето, домейн контролер за повече от 5 минути. Времето се предава в шифрован вид, и ще действа като удостоверяващ. Напомням ви, че кодът за шифроване (User ключ) се генерира от паролата на потребителя, в резултат на хеша.
- KDC услуга вижда обработката на компютъра и започва да търси за потребителя в Active Directory, потребителят проверява ключа и декриптира Удостоверител, ако това стане по време на руската заминаването на искането. Тогава Key Distribution Center създава два билета. Първият е ключа за достъп, той е необходим, за да кодира данни между клиента и KDC. Второ билет, билет билет-даване (Ticket-Предоставяне на билети (TGT)), веднага след като той се появи на потребителя, той ще бъде в състояние да поиска билети за услуги и сървъри. Самата TGT се състои от такива части: копие от ключа за достъп, времето за край на живота на билета и името на потребителя. TGT се криптира с помощта на главния ключ на услугата за разпределение център, така че потребителят не може да го разшифровате.
- След като тези билети са генерирани Key Distribution Center криптира потребителския Удостоверител (време печат) и ключ за достъп с ключ на потребителя и тихо ги прехвърля на потребителя.
- Тъй като потребителят има, ключът на потребителя, той спокойно декриптира билети от Key Разпределение център и проверява Удостоверител. В резултат на това той вече притежава ключа за достъп, а ключът TGT сега приключи първата фаза на Kerberos и потребителите вече не е необходимо в тази сесия, за да поръчате тези билети.
- Клиентът иска достъп до услугата, тъй като тя вече има ключ към други клавиши (TGT), за достъп до услугата, тя осигурява на KDC, продажба на билети за продажба на билети, Предоставяне и щемпел на времето, което криптира ключа за достъп.
- KDC получава това искане и билети, декриптира го използвате ключа си. Контролерът на домейн потвърждава, че заявката е от правилния потребител.
- Следващата стъпка Key център за разпределение генерира два билета (билетен център (TGS)), един е подал молба за клиента и един за услугата, за която клиентът има достъп. Всеки от билета ще съдържа името на потребителя, който иска достъп до който трябва да получи искането, печатът на времето, което казва кога е създаден на билета, както и периода на живота си, както и нов ключ KCS. KCS - е ключът за услугата и клиента, чиято задача е да се осигури безопасното взаимодействие между тях. Следваща KDC услуга криптира билета, използвайки ключовата сървърна система и поставя на билета в билет на клиента, който също има ключова KCS.
- Сега всичко е криптиран ключ на сесия и се изпраща на клиента.
- Клиентът получава билет, да го разкодира с помощта на ключа за достъп и TGS вижда своя билет и KCS услуга, клиентът не може да чете KCS предназначен за обслужване
- клиент сега генерира клеймото и го криптира KCS ключ, тя изпраща заедно с билета, на TGS, предназначен за него.
- Когато сървъра услуга получи тази информация, той веднага се вижда от опаковката KDC, предназначена за него, за да TGS ключ (KCS). Той ги декриптира печата време от клиента.
- Тъй като и двете страни имат TGS ключ, те могат да бъдат сигурни за които клиентът правилно идентифицирани, т.е.. А. За кодирате маркер време е бил използван KCS. Ако е необходимо, отговора от сървъра към клиента, сървърът ще използва ключовата KCS. Клиентът знае, че сървърът е правилно определена, защото сървърът трябва да използвате, за да получите KCS.