Đó không phải là về tệp 'hosts' - nó phá vỡ các lượt chia sẻ được truy cập thông qua tên máy chủ khác với tên "thực" của máy chủ. Kết quả của bạn là bình thường, vì đó thực sự là toàn bộ mục đích của GPO.
GPO được đề cập rất giống với việc thực thi TLS SNI được tìm thấy trong một số máy chủ web: máy khách nói "Tôi ở đây để nói chuyện với máy chủ SRV01.EXAMPLE.COM" và nếu máy chủ không nhận ra tên đó là một trong các vhost nó phục vụ, nó từ chối khách hàng hoàn toàn. Vì vậy, ở đây nếu máy khách nói rằng nó muốn nói chuyện với một trong các bí danh /etc/hosts của bạn, nhưng máy chủ không biết bí danh đó, thì nó sẽ từ chối máy khách.
Kerberos đã có sẵn tính năng thực thi tương tự (đó là lý do tại sao bạn cần đăng ký SPN cho bí danh bằng cách sử dụng tập hợp), nhưng GPO làm cho nó chặt chẽ hơn và cũng mở rộng khả năng bảo vệ tương tự đối với NTLM.
(Như đã đề cập trong trang Tài liệu, điều này được cho là để ngăn chặn các cuộc tấn công chuyển tiếp NTLM, trong đó máy chủ độc hại A chấp nhận xác thực NTLM sau đó chuyển tiếp chính xác các gói NTLM đó đến máy chủ thực B – cuộc tấn công sẽ bị ngăn chặn vì máy chủ B sẽ xem "Tôi muốn nói chuyện với máy chủ A" từ máy khách.)
Nó Là vẫn có thể sử dụng bí danh máy chủ, nhưng nó yêu cầu số lượng nút đăng ký ngày càng tăng. Phương pháp chính thức là sử dụng tên máy tính netdom REALHOST /add: THEALIAS như trong bài đăng TechNet nàyvà tôi đã tìm thấy các bài đăng trên blog tuyên bố rằng nó đủ để làm cho các bí danh có thể sử dụng được ngay cả khi xác thực SPN nghiêm ngặt, nhưng thực sự có vẻ như đó là không phải khá đủ – có ít nhất một nếu không muốn nói là hai giá trị sổ đăng ký mà nó quên chạm vào.
thanh ghi NETDOM Kerberos SPN cho bí danh trong AD, cho phép nhận vé Kerberos cho chúng, tương tự như thực hiện hai lệnh sau theo cách thủ công:
setspn -S HOST/THEALIAS REALHOST$
setspn -S HOST/thealias.example.com REALHOST$
Điều này là bắt buộc đối với Kerberos và không có lý do gì để không sử dụng Kerberos trong môi trường AD, vì vậy, cho dù bạn chọn sử dụng NETDOM hay thực hiện thủ công, thì bạn vẫn nên đăng ký SPN bí danh.
(Về mặt kỹ thuật, SMB sử dụng các nguyên tắc gốc "cifs/", nhưng trong AD, chúng hiện diện hoàn toàn bất cứ khi nào SPN "host/" được đăng ký.)
Sau đó, NETDOM thêm bí danh vào hai vị trí sổ đăng ký của máy chủ, khiến máy chủ đăng ký tên bổ sung của nó trong AD DNS cũng như thông báo chúng qua Trình duyệt NetBIOS:
Con đường: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Tên: Tên máy tính thay thế
Loại: REG_MULTI_SZ
Dữ liệu: {thealias.example.com}
Con đường: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Tên: Tên tùy chọn
Loại: REG_MULTI_SZ
Dữ liệu: {THEALIAS}
Chúng dường như không có bất kỳ ảnh hưởng nào đối với xác thực (thậm chí không phải Kerberos), vì vậy tôi tin rằng cả hai thứ đó là hoàn toàn tùy chọn nếu bạn sử dụng/etc/hosts hoặc tạo bản ghi CNAME thủ công trong DNS.
Một tham số bổ sung mà NETDOM không tạo, nhưng tôi thấy cần thiết để truy cập các bí danh từ bên trong máy chủ, là:
- Con đường:
HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Tên: BackConnectionHostNames
Loại: REG_MULTI_SZ
Dữ liệu: {thealias.example.com}
Cái này chỉ cần thiết cho các kết nối "loopback", vì vậy có lẽ không thực sự cần thiết nói chung, nhưng ít nhất trong trường hợp của tôi, máy chủ đã làm cần kết nối với bí danh của chính nó để cài đặt được yêu cầu.
Cuối cùng, tôi thấy rằng tính năng "Xác thực tên mục tiêu SPN" có của riêng mình danh sách các tên được phép phải được cập nhật theo cách thủ công – nếu không, các bí danh sẽ bị từ chối do xác thực SPN nghiêm ngặt ngay cả khi có tất cả các cài đặt ở trên:
- Con đường:
HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Tên: SrvAllowedServerNames
Loại: REG_MULTI_SZ
Dữ liệu: {THEALIAS, thealias.example.com}
Bạn sẽ muốn liệt kê cả hai tên ngắn và FQDN của mọi bí danh â từ các thử nghiệm của tôi, việc liệt kê một bí danh không tự động ngụ ý bí danh kia.
Với Kerberos SPN đã đăng ký và SrvAllowedServerNames giá trị sổ đăng ký được đặt, các bí danh cuối cùng sẽ hoạt động bình thường ngay cả khi xác thực mục tiêu nghiêm ngặt.
