Tôi có Red Hat IdM trên RHEL8 với sự tin cậy hai chiều đối với AD trên Windows 2019.
Những gì hiện đang hoạt động:
- Ủy quyền hạn chế cho khách hàng NFS. Máy khách NFS có thể mạo danh người dùng từ lĩnh vực IdM (gssproxy).
- Người dùng từ miền AD có thể đăng nhập vào máy chủ trong lĩnh vực IdM (sự tin cậy hoạt động).
Điều gì không hoạt động là ứng dụng khách NFS đang cố mạo danh người dùng AD. Nhận vé s4u2proxy dường như chỉ hoạt động đối với người dùng trong miền IdM:
$ knit -k
$ kvno -I [email protected] -P nfs/nfs.idm.example.com
nfs/[email protected]: kvno = 1
$ danh sách
Bộ đệm vé: KCM:0
Hiệu trưởng mặc định: host/[email protected]
Bắt đầu hợp lệ Hết hạn Dịch vụ chính
26/05/2022 15:15:22 27/05/2022 14:24:21 host/[email protected]
dành cho khách hàng [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]
dành cho khách hàng [email protected]
Sau đó, cố gắng mạo danh người dùng AD:
$khủy
$ knit -k
$ kvno -I [email protected] -P nfs/nfs.idm.example.com
kvno: TGT đã bị thu hồi trong khi lấy thông tin xác thực cho nfs/[email protected]
$ danh sách
Bộ đệm vé: KCM:0
Hiệu trưởng mặc định: host/[email protected]
Bắt đầu hợp lệ Hết hạn Dịch vụ chính
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 có lẽ có một gợi ý. Khi mạo danh người dùng trong vương quốc của chính KDC (s4u2self):
Ngày 27 tháng 5 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), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168. 1.42: SỰ CỐ: 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] cho máy chủ/[email protected]
Ngày 27 tháng 5 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): ... CHUYỂN GIAO GIAO THỨC [email protected]
Ngày 27 tháng 5 12:34:23 kerberos.idm.example.com krb5kdc[1732](thông tin): đóng fd 12
Khi cố gắng mạo danh người dùng từ vương quốc "đáng tin cậy" từ xa (s4u2self):
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192( 20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168. 1.42: SỰ CỐ: 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] cho krbtgt/[email protected]
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](thông tin): đóng fd 12
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](Lỗi): Sự cố PAC: PAC có SID khác với những gì người yêu cầu PAC tuyên bố. PAC [S-1-5-21-2772319413-1696261159-756038808-1602] so với người yêu cầu PAC [S-1-5-21-956857513-2416212418-705989587-515]
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](thông tin): TGS_REQ : handle_authdata (-1765328364)
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192( 20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168. 1.42: HANDLE_AUTHDATA: authtime 1653647627, etypes {rep=UNSUPPORTED:(0)} host/[email protected] cho host/[email protected], TGT đã bị thu hồi
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): ... CHUYỂN GIAO GIAO THỨC [email protected]
Ngày 27 tháng 5 12:34:47 kerberos.idm.example.com krb5kdc[1732](thông tin): đóng fd 12
knvo hiển thị điều này trong chế độ gỡ lỗi:
[root@client ~]# kvno -I [email protected] host/client.idm.example.com
[8389] 1653672526.395590: Nhận thông tin đăng nhập [email protected] -> host/[email protected] bằng ccache KCM:0
[8389] 1653672526.395591: Đang truy xuất máy chủ/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: từ KCM:0 với kết quả: -1765328243/Không tìm thấy thông tin xác thực phù hợp
[8389] 1653672526.395592: Đang truy xuất [email protected] -> host/[email protected] từ KCM:0 với kết quả: -1765328243/Không tìm thấy thông tin xác thực phù hợp
[8389] 1653672526.395593: Nhận thông tin đăng nhập host/[email protected] -> krbtgt/[email protected] bằng ccache KCM:0
[8389] 1653672526.395594: Đang truy xuất máy chủ/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: từ KCM:0 với kết quả: -1765328243/Không tìm thấy thông tin đăng nhập phù hợp
[8389] 1653672526.395595: Đang truy xuất máy chủ/[email protected] -> krbtgt/[email protected] từ KCM:0 với kết quả: -1765328243/Không tìm thấy thông tin xác thực phù hợp
[8389] 1653672526.395596: Đang truy xuất máy chủ/[email protected] -> krbtgt/[email protected] từ KCM:0 với kết quả: 0/Thành công
[8389] 1653672526.395597: Bắt đầu với TGT cho lĩnh vực máy khách: host/[email protected] -> krbtgt/[email protected]
[8389] 1653672526.395598: Yêu cầu vé cho krbtgt/[email protected], giới thiệu trên
[8389] 1653672526.395599: Đã tạo khóa con cho yêu cầu TGS: aes256-cts/4F09
[8389] 1653672526.395600: etypes được yêu cầu trong yêu cầu TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395602: Mã hóa phần thân và dữ liệu yêu cầu thành yêu cầu NHANH CHÓNG
[8389] 1653672526.395603: Đang gửi yêu cầu (1941 byte) tới IDM.EXAMPLE.COM
[8389] 1653672526.395604: Bắt đầu kết nối TCP với luồng 192.168.1.40:88
[8389] 1653672526.395605: Gửi yêu cầu TCP tới luồng 192.168.1.40:88
[8389] 1653672526.395606: Đã nhận câu trả lời (1860 byte) từ luồng 192.168.1.40:88
[8389] 1653672526.395607: Chấm dứt kết nối TCP với luồng 192.168.1.40:88
[8389] 1653672526.395608: Phản hồi từ master KDC
[8389] 1653672526.395609: Giải mã phản hồi NHANH CHÓNG
[8389] 1653672526.395610: Phím trả lời NHANH: aes256-cts/7017
[8389] 1653672526.395611: Trả lời TGS dành cho máy chủ/[email protected] -> krbtgt/[email protected] với khóa phiên aes256-cts/D9C7
[8389] 1653672526.395612: Kết quả yêu cầu TGS: 0/Thành công
[8389] 1653672526.395613: Đã nhận tín dụng cho dịch vụ mong muốn krbtgt/[email protected]
[8389] 1653672526.395614: Lưu trữ máy chủ/[email protected] -> krbtgt/[email protected] trong KCM:0
[8389] 1653672526.395615: Nhận tín dụng qua TGT krbtgt/[email protected] sau khi yêu cầu máy chủ\/client.idm.example.com\@[email protected] (chuẩn hóa trên )
[8389] 1653672526.395616: Đã tạo khóa con cho yêu cầu TGS: aes256-cts/4CB0
[8389] 1653672526.395617: etypes được yêu cầu trong yêu cầu TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395619: Mã hóa phần thân và dữ liệu yêu cầu thành yêu cầu NHANH CHÓNG
[8389] 1653672526.395620: Đang gửi yêu cầu (2303 byte) tới AD.EXAMPLE.COM
[8389] 1653672526.395621: Đang gửi truy vấn URI DNS cho _kerberos.AD.EXAMPLE.COM.
[8389] 1653672526.395622: URI trả lời: 0 100 "krb5srv:m:udp:belfast.ad.home."
[8389] 1653672526.395623: URI trả lời: 0 100 "krb5srv:m:tcp:belfast.ad.home."
[8389] 1653672526.395624: Đang phân giải tên máy chủ belfast.ad.home.
[8389] 1653672526.395625: Đang phân giải tên máy chủ belfast.ad.home.
[8389] 1653672526.395626: Bắt đầu kết nối TCP với luồng 192.168.1.50:88
[8389] 1653672526.395627: Gửi yêu cầu TCP tới luồng 192.168.1.50:88
[8389] 1653672526.395628: Đã nhận được câu trả lời (1852 byte) từ luồng 192.168.1.50:88
[8389] 1653672526.395629: Chấm dứt kết nối TCP với luồng 192.168.1.50:88
[8389] 1653672526.395630: Phản hồi từ master KDC
[8389] 1653672526.395631: Giải mã phản hồi NHANH CHÓNG
[8389] 1653672526.395632: Phím trả lời NHANH: aes256-cts/9CCA
[8389] 1653672526.395633: Máy chủ trả lời krbtgt/[email protected] khác với máy chủ được yêu cầu\/client.idm.example.com\@[email protected]
[8389] 1653672526.395634: Trả lời TGS dành cho máy chủ/[email protected] -> krbtgt/[email protected] với khóa phiên aes256-cts/F05E
[8389] 1653672526.395635: Got tín dụng; 0/Thành công
[8389] 1653672526.395636: Nhận tín dụng qua TGT krbtgt/[email protected] sau khi yêu cầu host/[email protected] (bật chuẩn hóa)
[8389] 1653672526.395637: Đã tạo khóa con cho yêu cầu TGS: aes256-cts/3CAC
[8389] 1653672526.395638: etypes được yêu cầu trong yêu cầu TGS: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395640: Mã hóa phần thân và dữ liệu yêu cầu thành yêu cầu NHANH CHÓNG
[8389] 1653672526.395641: Đang gửi yêu cầu (2128 byte) tới IDM.EXAMPLE.COM
[8389] 1653672526.395642: Bắt đầu kết nối TCP với luồng 192.168.1.40:88
[8389] 1653672526.395643: Gửi yêu cầu TCP tới luồng 192.168.1.40:88
[8389] 1653672526.395644: Đã nhận được câu trả lời (432 byte) từ luồng 192.168.1.40:88
[8389] 1653672526.395645: Chấm dứt kết nối TCP với luồng 192.168.1.40:88
[8389] 1653672526.395646: Phản hồi từ master KDC
[8389] 1653672526.395647: Giải mã phản hồi NHANH CHÓNG
[8389] 1653672526.395648: Giải mã phản hồi NHANH CHÓNG
[8389] 1653672526.395649: Got tín dụng; -1765328364/TGT đã bị thu hồi
kvno: TGT đã bị thu hồi trong khi lấy thông tin đăng nhập cho host/[email protected]
Bất kỳ ai biết liệu Red Hat IdM có thể mạo danh người dùng từ vương quốc "khác" không? Tôi thực sự không chắc liệu đây có phải là một tính năng được hỗ trợ hay không. Nếu nó được hỗ trợ, nó có yêu cầu gì ngoài sự tin tưởng hai chiều không?
