Điểm:0

Lỗi xác thực SSSD Ubuntu với miền AD con/phụ

lá cờ in

Cần trợ giúp xác thực máy chủ linux (Ubuntu) được kết nối với miền con. Tôi có thể thấy tên máy chủ trên Bộ điều khiển miền và có thể chạy kiểm tra xác thực thành công tuy nhiên tôi không thể đăng nhập bằng tài khoản miền của mình. Có vẻ như cài đặt cấu hình ở đâu đó cho cấu hình SSSD hoặc KRB5 cần chỉ định miền con. Ngoài ra, đây không phải là sự cố về độ tin cậy của miền do các máy chủ Windows được kết nối với miền con đang chấp nhận thông tin đăng nhập từ tài khoản mẹ.

kinit -V [email protected]
Đã xác thực với Kerberos v5

root@SERVER:/var/log/sssd# systemctl status sssd

Ngày 22 tháng 10 17:55:09 MÁY CHỦ [sssd[ldap_child[27928]: Không thể khởi tạo thông tin xác thực bằng keytab [MEMORY:/etc/krb5.keytab]: Không tìm thấy ứng dụng khách '[email protected]' trong cơ sở dữ liệu Kerberos. Không thể tạo kết nối LDAP được mã hóa GSSAPI.

LỖI trong tệp nhật ký SSSD

Thứ Sáu ngày 22 tháng 10 17:32:51 năm 2021) [sssd[be[DOMAIN.SYS]]] [confdb_get_domain_internal] (0x0010): Miền không xác định [CHILD.DOMAIN.SYS]
(Thứ Sáu ngày 22 tháng 10 17:32:51 năm 2021) [sssd[be[DOMAIN.SYS]]] [confdb_get_domains] (0x0010): Lỗi (2 [Không có tệp hoặc thư mục như vậy]) khi truy xuất miền [CHILD.DOMAIN.SYS], bỏ qua!

CẤU HÌNH SSSD

root@SERVER:cat /etc/sssd/sssd.conf
[sssd]
dịch vụ = nss, pam
config_file_version = 2
tên miền = DOMAIN.SYS, CON.DOMAIN.SYS

[nss]
default_shell = /bin/bash

[miền/MIỀN.SYS]
id_provider = quảng cáo
access_provider = quảng cáo
override_homedir = /home/%d/%u

ad_hostname = server.child.domain.sys
#ad_server = dc.child.domain.sys
#ad_domain = DOMAIN.SYS

CẤU HÌNH KRB5

root@SERVER: mèo /etc/krb5.conf
[libdefaults]
        default_realm = DOMAIN.SYS
        ticket_lifetime = 24h #
        refresh_lifetime = 7d
        rdns = sai

Các biến krb5.conf sau chỉ dành cho MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        có thể chuyển tiếp = đúng
        có thể thay thế = đúng
LeeM avatar
lá cờ cn
Vui lòng sử dụng định dạng để thông tin cấu hình ít khó đọc hơn.
Điểm:0
lá cờ cn

Bạn đã thiết lập SSSD như thế nào? Bạn đã làm khám phá vương quốc và sau đó vương quốc tham gia? Nếu bạn không, đó là phương pháp được khuyến nghị. Tôi thực sự khuyên bạn chỉ cần làm điều đó.

Bạn đã thử xác thực là người dùng trong miền con chưa? *getent passwd [email protected]

Từ những gì tôi có thể nói trong thông tin định dạng sai mà bạn đã cung cấp, bạn có hai miền trong sssd.conf

[sssd] 
dịch vụ = nss, pam 
config_file_version = 2 

tên miền = DOMAIN.SYS, CON.DOMAIN.SYS

[nss] 
default_shell = /bin/bash

[miền/MIỀN.SYS] 
id_provider = quảng cáo 
access_provider = quảng cáo 

Bạn có một phần cho [miền/CHILD.DOMAIN.SYS]. Điều gì xảy ra nếu bạn làm danh sách cõi? Điều đó sẽ cho bạn thấy những gì được cấu hình đúng trong sssd.conf của bạn.

Tôi không chắc liệu bạn có cần liệt kê cả hai miền trong tình huống miền cha-con hay không, nhưng có lẽ trước tiên hãy thử chỉ định cấu hình miền con. Hoặc ít nhất là đặt đứa trẻ đầu tiên trong lĩnh vực danh sách.

tên miền = CHILD.DOMAIN.SYS
...
[miền/CHILD.DOMAIN.SYS] 
id_provider = quảng cáo 
access_provider = quảng cáo

Bạn đang cố gắng xác thực người dùng miền mẹ như thế nào? Bạn đang cố gắng SSH hay bạn đang thử một nhận được cục bộ trên máy chủ? Bạn có đang sử dụng tên đủ điều kiện để xác thực người dùng miền mẹ không? ví dụ. getent passwd [email protected]

Lỗi này cho biết nó đang cố sử dụng keytab với tên máy tính sai Máy khách '[email protected]' . Nó nên được sử dụng MÁY CHỦ[email protected] nếu nó được nối với miền con. Keytab của máy chủ có thực sự chứa tên máy chủ chính xác cho miền con không?

Đó là lý do tại sao tôi khuyên bạn nên đơn giản hóa vấn đề bằng cách đảm bảo trước tiên bạn có thể đăng nhập bằng thông tin xác thực miền con.Mặc dù tôi thực sự nghĩ rằng bạn nên bắt đầu lại với vương quốc tham gia nếu bạn không sử dụng phương pháp này.

Hãy thử làm theo các bước khắc phục sự cố tại đây, đặc biệt là phần Cơ bản, Phần phụ trợ và Nhà cung cấp AD chung: https://sssd.io/troubleshooting/basics.html

(nhân tiện, tôi thực sự hy vọng hậu tố tên miền của bạn không thực sự là .SYS)

AAABL avatar
lá cờ in
Cảm ơn bạn rất nhiều vì câu trả lời của bạn!
AAABL avatar
lá cờ in
vâng, tôi có thể đăng nhập bằng tài khoản người dùng từ miền con và tôi đã sửa đổi sssd.conf bằng cách xóa DOMAIN.SYS và chỉ để lại CHILD.DOMAIN.SYS để không có lỗi. Tôi có thể đăng nhập bằng [email protected] nhưng không thể đăng nhập bằng [email protected] (Quyền truy cập bị từ chối) ban đầu chúng tôi sử dụng 'net ads join k' khi tôi chạy phát hiện lĩnh vực Tôi nhận được: Không phát hiện thấy lĩnh vực mặc định nào. Tôi có cần hủy kết nối máy chủ khỏi miền và tham gia bằng cách sử dụng tham gia lĩnh vực không?
AAABL avatar
lá cờ in
Khi tôi chạy lĩnh vực khám phá -v domain.sys * Đang giải quyết: _ldap._tcp.domain.sys * Đã khám phá thành công: DOMAIN.SYS loại: kerberos tên miền: DOMAIN.SYS tên miền: domain.sys đã định cấu hình: thành viên kerberos phần mềm máy chủ: active-directory phần mềm máy khách: win-bind gói yêu cầu: winbind gói bắt buộc: libpam-winbind gói bắt buộc: samba-common-bin định dạng đăng nhập: TEST\%U chính sách đăng nhập: cho phép-bất kỳ-đăng nhập tên miền.sys loại: kerberos tên miền: DOMAIN.SYS tên miền: domain.sys cấu hình: không
LeeM avatar
lá cờ cn
Ít nhất bạn đã tham gia vào miền, vì vậy tôi sẽ không thử lại lần nữa - nhưng `tham gia lĩnh vực` tốt hơn nhiều, để tham khảo trong tương lai. Và `khám phá lĩnh vực` cho thấy nó sẽ đến được miền mẹ. Vì vậy, bây giờ có thể thử sửa đổi `domains = CHILD.DOMAIN.SYS, DOMAIN.SYS` và thêm một phần mới cho `[domain/DOMAIN.SYS]` với `id_provider` và `access_provider`. Sau đó chạy `realm list` để kiểm tra `sssd.conf` và giải quyết các miền. Sử dụng các lệnh `getent` để kiểm tra xem người dùng có thể được giải quyết trên DC trước khi thử đăng nhập hay không.
LeeM avatar
lá cờ cn
Nếu không thể phân giải người dùng trong miền mẹ bằng `getent`, bạn có thể cần kiểm tra độ phân giải DNS và xác định `ad_server` nếu máy chủ lưu trữ không thể kết nối với tất cả các DC. Quay lại vấn đề cơ bản với tất cả các bước khắc phục sự cố đó trên sssd.io. Hoặc hủy tham gia và xem việc tham gia lại bằng `realm join` có tạo ra sự khác biệt hay không. Ngoài ra, nếu bạn có bất kỳ máy *nix nào khác đã tham gia SSSD trong miền con, hãy kiểm tra cấu hình của chúng. Nhưng tôi nghĩ nếu bạn đảm bảo rằng cả hai miền đều có phần cấu hình trong `sssd.conf`, điều đó có thể khắc phục được.
LeeM avatar
lá cờ cn
ồ, vừa thấy bạn đã cố gắng rời đi và tham gia lại. Xin lỗi, tôi không biết làm cách nào để thoát khỏi mớ hỗn độn đó, ngoài việc xóa sạch (hoặc sao lưu) keytab, hoàn nguyên tất cả các tệp conf về mặc định và yêu cầu quản trị viên AD đảm bảo tài khoản máy tính trong miền là thực sự đã biến mất.
AAABL avatar
lá cờ in
tham gia lĩnh vực -v [email protected] child.domain.sys ! Không thể xác thực với thư mục hoạt động: SASL(-1): lỗi chung: Lỗi GSSAPI: Lỗi GSS không xác định. Mã phụ có thể cung cấp thêm thông tin (Không tìm thấy máy chủ trong cơ sở dữ liệu Kerberos) adcli: không thể kết nối với miền con.DOMAIN.SYS: Không thể xác thực với thư mục hoạt động: SASL(-1): lỗi chung: Lỗi GSSAPI: Lỗi GSS không xác định. Mã phụ có thể cung cấp thêm thông tin (Không tìm thấy máy chủ trong cơ sở dữ liệu Kerberos) ! Không đủ quyền để tham gia miền
AAABL avatar
lá cờ in
Tôi nghĩ rằng tôi cần phải định cấu hình miền con và miền mẹ trong tệp krb5.conf. Không chắc định dạng phù hợp hiện tại là gì. Tôi chỉ có miền mẹ

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.