У меня есть Red Hat IdM на RHEL8 с двусторонним доверием к AD в Windows 2019.
Что работает на данный момент:
- Ограниченное делегирование для клиентов NFS. Клиенты NFS могут олицетворять пользователей из области IdM (gssproxy).
- Пользователи из домена AD могут регистрироваться на хостах в области IdM (доверие работает).
Что не работает, так это то, что клиент NFS пытается выдать себя за пользователей AD. Получение билетов s4u2proxy работает только для пользователей в домене IdM:
$ кинит -k
$ kvno -I [email protected] -P nfs/nfs.idm.example.com
nfs/[email protected]: kvno = 1
$ клист
Кэш билетов: KCM:0
Принципал по умолчанию: host/[email protected]
Действительный начальный срок действия субъекта-службы
26.05.2022 15:15:22 27.05.2022 14:24:21 host/[email protected]
для клиента [email protected]
26.05.2022 15:14:54 27.05.2022 14:24:21 krbtgt/[email protected]
26.05.2022 15:15:22 27.05.2022 14:24:21 nfs/[email protected]
для клиента [email protected]
Затем пытаемся выдать себя за пользователя AD:
$ kdestroy
$ кинит -k
$ kvno -I [email protected] -P nfs/nfs.idm.example.com
kvno: TGT был отозван при получении учетных данных для nfs/[email protected]
$ клист
Кэш билетов: KCM:0
Принципал по умолчанию: host/[email protected]
Действительный начальный срок действия субъекта-службы
26.05.2022 15:15:37 27.05.2022 15:10:07 krbtgt/[email protected]
26.05.2022 15:15:50 27.05.2022 15:10:07 krbtgt/[email protected]
Возможно, в krb5kdc.log есть подсказка. При выдаче себя за пользователя в сфере самого KDC (s4u2self):
27 мая 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192( 20), камелия256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), камелия128-cts-cmac(25)}) 192.168. 1.42: ВЫПУСК: authtime 1653647627, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96 (18)}, host/[email protected] для host/[email protected]
27 мая, 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): ... ПЕРЕХОД ПРОТОКОЛА [email protected]
27 мая, 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): закрытие fd 12
При попытке выдать себя за пользователя из удаленной «доверенной» области (s4u2self):
27 мая, 12:34:47. 20), камелия256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), камелия128-cts-cmac(25)}) 192.168. 1.42: ВЫПУСК: authtime 1653647627, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96 (18)}, host/[email protected] для krbtgt/[email protected]
27 мая, 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): закрытие fd 12
27 мая, 12:34:47 kerberos.idm.example.com krb5kdc[1732](ошибка): проблема с PAC: PAC имеет SID, отличный от заявленного запросчиком PAC. PAC [S-1-5-21-2772319413-1696261159-756038808-1602] и запрашивающий PAC [S-1-5-21-956857513-2416212418-705989587-515]
27 мая, 12:34:47 kerberos.idm.example.com krb5kdc[1732](информация): TGS_REQ : handle_authdata (-1765328364)
27 мая, 12:34:47. 20), камелия256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), камелия128-cts-cmac(25)}) 192.168. 1.42: HANDLE_AUTHDATA: authtime 1653647627, etypes {rep=UNSUPPORTED:(0)} host/[email protected] для host/[email protected], TGT был отозван
27 мая, 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): ... ПЕРЕХОД ПРОТОКОЛА [email protected]
27 мая, 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): закрытие fd 12
knvo показывает это в режиме отладки:
[root@client ~]# kvno -I [email protected] host/client.idm.example.com
[8389] 1653672526.395590: получение учетных данных [email protected] -> host/[email protected] с помощью ccache KCM:0
[8389] 1653672526.395591: Получение host/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: из KCM:0 с результатом: -1765328243/Соответствующие учетные данные не найдены
[8389] 1653672526.395592: Получение [email protected] -> host/[email protected] из KCM:0 с результатом: -1765328243/Соответствующие учетные данные не найдены
[8389] 1653672526.395593: Получение учетных данных host/[email protected] -> krbtgt/[email protected] с помощью ccache KCM:0
[8389] 1653672526.395594: Получение host/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: из KCM:0 с результатом: -1765328243/Соответствующие учетные данные не найдены
[8389] 1653672526.395595: Получение host/[email protected] -> krbtgt/[email protected] из KCM:0 с результатом: -1765328243/Соответствующие учетные данные не найдены
[8389] 1653672526.395596: Получение host/[email protected] -> krbtgt/[email protected] из KCM:0 с результатом: 0/Успех
[8389] 1653672526.395597: Начиная с TGT для области клиента: host/[email protected] -> krbtgt/[email protected]
[8389] 1653672526.395598: Запрос билетов на krbtgt/[email protected], рефералы на
[8389] 1653672526.395599: сгенерированный подраздел для запроса TGS: aes256-cts/4F09
[8389] 1653672526.395600: etypes, запрошенные в запросе TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395602: кодирование тела запроса и дополнительных данных в запрос FAST.
[8389] 1653672526.395603: Отправка запроса (1941 байт) на IDM.EXAMPLE.COM
[8389] 1653672526.395604: инициирование TCP-подключения к потоку 192.168.1.40:88.
[8389] 1653672526.395605: Отправка TCP-запроса в поток 192.168.1.40:88
[8389] 1653672526.395606: получен ответ (1860 байт) из потока 192.168.1.40:88.
[8389] 1653672526.395607: завершение TCP-соединения с потоком 192.168.1.40:88.
[8389] 1653672526.395608: ответ был от главного KDC
[8389] 1653672526.395609: Расшифровка ответа FAST
[8389] 1653672526.395610: ключ быстрого ответа: aes256-cts/7017
[8389] 1653672526.395611: ответ TGS для host/[email protected] -> krbtgt/[email protected] с ключом сеанса aes256-cts/D9C7
[8389] 1653672526.395612: результат запроса TGS: 0/успешно
[8389] 1653672526.395613: получены кредиты для желаемой службы krbtgt/[email protected]
[8389] 1653672526.395614: Сохранение host/[email protected] -> krbtgt/[email protected] в KCM:0
[8389] 1653672526.395615: получить кредит через TGT krbtgt/[email protected] после запроса host\/client.idm.example.com\@[email protected] (канонизировать на )
[8389] 1653672526.395616: сгенерированный подраздел для запроса TGS: aes256-cts/4CB0
[8389] 1653672526.395617: etypes, запрошенные в запросе TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395619: кодирование тела запроса и дополнительных данных в запрос FAST.
[8389] 1653672526.395620: Отправка запроса (2303 байта) на AD.EXAMPLE.COM
[8389] 1653672526.395621: Отправка DNS-запроса URI для _kerberos.AD.EXAMPLE.COM.
[8389] 1653672526.395622: ответ URI: 0 100 "krb5srv:m:udp:belfast.ad.home."
[8389] 1653672526.395623: ответ URI: 0 100 "krb5srv:m:tcp:belfast.ad.home."
[8389] 1653672526.395624: Разрешение имени хоста belfast.ad.home.
[8389] 1653672526.395625: Разрешение имени хоста belfast.ad.home.
[8389] 1653672526.395626: инициирование TCP-подключения к потоку 192.168.1.50:88.
[8389] 1653672526.395627: Отправка TCP-запроса в поток 192.168.1.50:88
[8389] 1653672526.395628: получен ответ (1852 байта) из потока 192.168.1.50:88.
[8389] 1653672526.395629: завершение TCP-соединения с потоком 192.168.1.50:88.
[8389] 1653672526.395630: ответ был от главного KDC
[8389] 1653672526.395631: Расшифровка ответа FAST
[8389] 1653672526.395632: ключ быстрого ответа: aes256-cts/9CCA
[8389] 1653672526.395633: сервер ответов krbtgt/[email protected] отличается от запрошенного хоста\/client.idm.example.com\@[email protected]
[8389] 1653672526.395634: ответ TGS для host/[email protected] -> krbtgt/[email protected] с ключом сеанса aes256-cts/F05E
[8389] 1653672526.395635: получил кредит; 0/Успех
[8389] 1653672526.395636: получить кредит через TGT krbtgt/[email protected] после запроса host/[email protected] (канонизация включена)
[8389] 1653672526.395637: сгенерированный подраздел для запроса TGS: aes256-cts/3CAC
[8389] 1653672526.395638: etypes, запрошенные в запросе TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395640: кодирование тела запроса и дополнительных данных в запрос FAST.
[8389] 1653672526.395641: Отправка запроса (2128 байт) на IDM.EXAMPLE.COM
[8389] 1653672526.395642: инициирование TCP-подключения к потоку 192.168.1.40:88.
[8389] 1653672526.395643: Отправка TCP-запроса в поток 192.168.1.40:88
[8389] 1653672526.395644: получен ответ (432 байта) из потока 192.168.1.40:88.
[8389] 1653672526.395645: завершение TCP-подключения к потоку 192.168.1.40:88.
[8389] 1653672526.395646: ответ был от главного KDC
[8389] 1653672526.395647: Расшифровка ответа FAST
[8389] 1653672526.395648: Декодирование ответа FAST
[8389] 1653672526.395649: Получил кредит; -1765328364/TGT был отозван
kvno: TGT был отозван при получении учетных данных для host/[email protected]
Кто-нибудь знает, возможно ли с помощью Red Hat IdM выдавать себя за пользователей из «другой» области? На самом деле я не уверен, поддерживается ли эта функция. Если он поддерживается, требует ли он чего-либо помимо двустороннего доверия?
