Конфигурации за поддръжка на Kerberos armoring

Предупреждение!

За да се използва механизмът Kerberos armoring, акаунтите на администраторите трябва да бъдат поставени в групата Protected Users.
Това налага използването на протокола за удостоверяване Kerberos вместо NTLM. Компонентът Edge Gateway трябва предварително да бъде конфигуриран да поддържа удостоверяване с Kerberos.

Конфигуриране на компонента Edge Gateway за поддръжка на удостоверяване с Kerberos за акаунти, поставени в Protected Users

Механизмът Kerberos armoring осигурява допълнително шифроване на първоначалния обмен между клиента и KDC (Kerberos Domain Controller) с помощта на информация, свързана с компютърен акаунт.

CyberElements Bastion работи за предпочитане на компютри с Debian, които не са присъединени към домейн на AD, което означава, че те нямат информация за компютърен акаунт в AD.
Конфигурацията за поддръжка на Kerberos armoring се състои от две стъпки:

• Създаване на компютърен акаунт за услуга в AD
• Конфигуриране на Kerberos armoring в компонента Edge Gateway въз основа на създадения преди това акаунт

Създаване на компютърен акаунт за услуга

Информация

На тази страница като пример ще се използва акаунт за услуга с име svc_cyberelements. Адаптирайте следващите команди според името на вашия акаунт за услуга.

Предупреждение!

Ако искате да използвате работни станции PAW, поставете този акаунт за услуга в същия силоз като целевите работни станции PAW.

От контролера на домейна започнете със създаването на компютърен акаунт с парола, използвана за генериране на билети на Kerberos.

За да създадете този акаунт, можете да използвате следната команда на Powershell от контролер на домейна (адаптирайте името на акаунта за услуга, в примера svc_cyberelements, и желаната OU, в примера OU=Service_accounts,DC=domain,DC=local, за да създадете акаунта за услуга):

New-ADComputer -Name svc_cyberelements -SAMAccountName 'svc_cyberelements$' -AccountPassword $Null -Path 'OU=Service_accounts,DC=domain,DC=local'-KerberosEncryptionType AES256 -PasswordNeverExpires $True -Enabled $True

Използвайте следната команда, за да проверите дали компютърният акаунт е създаден (заменете svc_cyberelements с името на създадения преди това акаунт):

Get-ADComputer -Identity svc_cyberelements -Properties Enabled

След това използвайте инструмента ktpass на Windows, за да експортирате файл keytab, който ще съдържа ключовете за шифроване, позволяващи на шлюза да извлече TGT.

Пример

Пример за създаване на файл svc_cyberelements.keytab с компютърния акаунт:

ktpass /princ 'svc_cyberelements$@DOMAIN.LOCAL' /mapuser 'svc_cyberelements$@DOMAIN.LOCAL' +rndPass /out svc_cyberelements.keytab /crypto AES256-SHA1 /ptype KRB5_NT_SRV_HST /mapop set

Не забравяйте да включите символите $ в края на имената на акаунтите и да изпишете името на домейна с главни букви (задължително).

Приемете всички подкани за потвърждение, които може да се появят, като въведете y.

След това задайте отново стойността на атрибута UserPrincipalName със следната команда на PowerShell:

Set-ADComputer 'svc_cyberelements$' -UserPrincipalName 'svc_cyberelements$@DOMAIN.LOCAL'

Конфигуриране на Kerberos armoring в компонента Edge Gateway

Извлечете генерирания преди това файл keytab и го копирайте на сървъра Edge Gateway.
В контекст, в който са генерирани няколко файла keytab, които трябва да се използват в един и същ компонент Edge Gateway, обединете файловете keytab в един файл.

Предупреждение

Файлът keytab съдържа ключове за шифроване. Ако нападател се сдобие с него, той може да се представи за свързания компютърен акаунт и така да намали сигурността на инфраструктурата.
Затова този файл не трябва да се съхранява никъде другаде освен в компонента Edge Gateway.

Поставете файла в директорията /etc/ipdiva/cleanroom/.

Променете собствениците на файла keytab на ipdivacareuser за потребителя и carerecord за групата, след което променете разрешенията за файла (адаптирайте файла keytab според името на вашия собствен файл):

chown ipdivacareuser:carerecord /etc/ipdiva/cleanroom/svc_cyberelements.keytab
chmod 640 /etc/ipdiva/cleanroom/svc_cyberelements.keytab

Променете конфигурационния файл /etc/ipdiva/cleanroom/xrdprecord.ini на компонента Edge Gateway, за да посочите чрез параметъра keytab= пътя до подготвения преди това файл keytab.

Пример

keytab=/etc/ipdiva/cleanroom/svc_cyberelements.keytab

На този етап свързването с привилегировани RDP приложения в режим без агент (HTML5 или друг) би трябвало да работи с потребителски акаунти, принадлежащи към Protected Users и следователно изискващи силно удостоверяване с Kerberos. Конфигурацията на RDP приложението трябва да отговаря на определени предварителни изисквания.

Тестване на конфигурацията на Kerberos

Отстраняване на грешки

Следните команди kinit могат да предоставят повече дневници след изпълнение на следната команда (валидна до прекъсване на SSH или конзолната сесия):

export KRB5_TRACE=/dev/stdout

Започнете с извличане на билет на Kerberos с команда, подобна на следната:

kinit -k -t /etc/ipdiva/cleanroom/svc_cyberelements.keytab 'svc_cyberelements$@DOMAIN.LOCAL' -c /tmp/test_kerberos

Не забравяйте да замените местоположението на файла keytab, името на създадения акаунт за услуга и свързания с него домейн.

Ако извличането на билета на Kerberos е успешно, следната команда трябва да покаже наличието на билет за акаунта за услуга:

klist -c /tmp/test_kerberos

Ако извличането е успешно, трябва да опитате да извлечете билет за потребител с команда, подобна на следната:

kinit -T /tmp/test_kerberos user@DOMAIN.LOCAL

Заменете user@DOMAIN.LOCAL с потребител, който е вероятно да се свързва чрез RDP и Kerberos armoring. Имайте предвид, че ще бъде поискана паролата на този потребител.
Ако извличането на билета е успешно, следната команда ще го покаже:

klist -c

Ако се покаже грешка KDC policy rejects request while getting initial credentials, това означава, че KDC е отказал заявката за билет. Възможни причини:

• kinit не е успял да използва билета /tmp/test_kerberos (ако kinit не може да го използва, той продължава без съобщение за грешка с основна заявка за билет)
• Акаунтът за услуга не присъства в силоза на тествания потребител. Това се случва, когато AD е разделена на силози, и изисква компютърният акаунт за услуга да бъде поставен в съответния силоз.

Допълнителна информация може да се намери в дневниците на събитията Security на използвания контролер на домейн (KDC).

След тестването се препоръчва да изтриете генерираните билети:

kdestroy
kdestroy -c /tmp/test_kerberos

Обединяване на няколко файла keytab в един файл

Ако архитектурата на CyberElements Bastion се основава на един сървър Edge Gateway, който ще позволява достъп на множество трети страни, е необходимо всички файлове keytab, генерирани за различните акаунти на услуги, да се обединят в един файл keytab.

Забележка

В тази част ще приемем, че са налични следните файлове keytab: /root/t0.keytab, /root/t1.keytab и /root/t2.keytab. Тези файлове трябва предварително да са изпратени до компонента Edge Gateway.

За да обедините файловете keytab, влезте в компонента Edge Gateway като root, след което използвайте следните команди:

ktutil
rkt /root/t0.keytab
rkt /root/t1.keytab
rkt /root/t2.keytab
wkt /root/unified.keytab

Командите rkt позволяват да заредите толкова файлове keytab, колкото е необходимо, а командата wkt генерира нов файл keytab.
Променете пътищата до файловете според тези, с които разполагате.

Натиснете клавиша q, за да излезете от помощната програма ktutil.

Извлечете файла unified.keytab и следвайте частта Configuring Kerberos shielding on the Edge Gateway.