Công nghệ Kiến thức cơ bản

Khắc phục sự cố các vấn đề đối với Kerberos trong SharePoint – Phần 2

Khắc phục sự cố các vấn đề đối với Kerberos trong SharePoint – Phần 1

Jesper M. Christensen

Quản trị mạng – Trong phần 2 này chúng tôi sẽ giới thiệu cho các bạn về cấu hình SPN, Duplicate Service Principal Names và sự không ăn khớp trong cấu hình DNS.

Trong phần đầu của loạt bài này chúng tôi đã giới thiệu cho các bạn các vấn đề về ngày và thời gian, tài khoản ứng dụng và cấu hình cơ bản của Service Principal Name (SPN). Trong phần này, chúng tôi sẽ giới thiệu các chủ đề dưới đây:

  • Cấu hình SPN - cho IIS 7
  • Duplicate Service Principal Names
  • Sự không tương xứng DNS Configuration

Cấu hình SPN – cho IIS 7

Trong phần trước của bài này, có một số vấn đề đã được chúng tôi đề cập không thể sử dụng các website làm việc với Kerberos nếu chúng sử dụng Internet Information Server 7 trên Windows Server 2008. Tài khoản ứng dụng và đăng ký SPN được cấu hình đúng, tuy nhiên thông báo lỗi này vẫn xuất hiện trong bản ghi sự kiện của hệ thống - Windows System Event Log: KRB_AP_ERR_MODIFIED.

Vấn đề này xuất hiện vì sự thẩm định chế độ Kernel được kích hoạt một cách mặc định. Thông thường các bạn nên sử dụng một máy chủ SharePoint và đăng ký SPN vào các máy chủ NETBIOS. Tuy nhiên, trong cả một hệ thống web, bạn cần vô hiệu hóa sự thẩm định ở chế độ Kernel hoặc cấu hình ứng dụng để có thể sử dụng các điều khoản từ ứng dụng.

Chúng ta hãy đi xem xét tỉ mỉ môi trường của mình từ phần 1 được sử dụng làm ví dụ.

Thông tin về địa chỉ IP:

172.16.189.11 là domain controller (và KDC) DC1
172.16.189.15 là SQL Server (và KDC) SQL1
172.16.189.là website http://intranet.domain.local
172.16.189.21 là SharePoint Server WSS1
172.16.189.22 là SharePoint Server WSS2
172.16.189.101 là computer PC1 đang truy cập website

Chúng tôi đã vô hiệu hóa chế độ thẩm định Kernel trong môi trường của mình cho test này, bạn có thể kích hoạt nó trở lại (như chế độ mặc định của nó) trong Internet Information Manager 7:

  1. Trong IIS 7 Manager, chọn “Sites/<tên của SharePoint website>” và chọn “Authentication”.

Hình 7
  1. Chọn “Windows Authentication” và kích vào “Advanced Settings”

Hình 8
  1. Tích vào hộp kiểm “Enable Kernel-mode authentication”, đây cũng là thiết lập mặc định

Hình 9
  1. Sau đó thiết lập lại IIS bằng lệnh: IISRESET /NOFORCE

Chúng ta muốn thấy được nhiều chi tiết về gói hơn, chính vì vậy, trước khi thực hiện truy cập vào website, bạn cần khởi chạy Wireshark, đây là một phân tích giao thức mạng trên DC1 và PC1 để chúng ta có thể nghiên cứu các lỗi Kerberos trên. Chúng tôi khuyên bạn nên thiết lập một bộ lọc để chỉ hiển thị các gói Kerberos:


Hình 10

Lúc này chúng ta sẽ truy cập vào website: http://intranet.domain.local – ở đây, chúng ta sẽ thấy một hộp đăng ký vì có gắng đăng nhập đã bị thất bại. Bước đầu tiên là kiểm tra bản ghi sự kiện trên máy tính đang truy cập website. Đây là sự kiện từ Windows System Event Log trên máy tính truy cập website đã được kiểm tra trên PC1:


Hình 11

Nếu quan sát vào các gói và các lỗi được capture trên máy PC1 bằng Wireshark, chúng ta sẽ thấy các lỗi giống nhau:


Hình 12

Chúng ta có thể thấy những gì, trong cả bản ghi sự kiện và các gói đã capture, là chỉ thị mã lỗi KRB_AP_ERR_MODIFIED và tài khoản đang đáp trả là wss1$. Biết rằng máy chủ WSS1 báo cáo lỗi này khi chúng ta truy cập website. Chúng ta cũng có thể thấy được điều đó từ địa chỉ IP nếu chúng ta quan sát thông tin địa chỉ IP nguồn và đích trong Wireshark. Hãy quan sát trên máy chủ này. KRB_AP_ERR_MODIFIED có nghĩa rằng máy tính cho rằng gói trao đổi Client/Service dường như được thay đổi và các tham số được kiểm tra là ngày tháng, địa chỉ IP, hostname và khóa giải mã có làm việc hay không. Kiểm tra nhanh chóng date/time, IP addresses và hostname (xem phần cấu hình DNS) và giả sử sự thật là đúng. Khóa mã hóa và giải mã được xác định bởi việc mapping tài khoản SPN. Tài khoản này phải là tài khoản IIS website trên máy chủ WSS1 đang sử dụng.
Chúng ta sẽ kiểm tra vấn đề đó bằng lệnh sau:


Hình 13

Service Principal Name bản đồ hóa tài khoản miền SPContentPoolAcct và cho phép chúng ta kiểm tra IIS Application Pool mà website sử dụng. Trong IIS manager, tìm đến Application Pool được sử dụng trong IIS Website. Sau đó kiểm tra Advanced Settings –hình 14 thể hiện tài khoản đã được cấu hình đúng.


Hình 14

Vì cấu trúc mới trong IIS 7 trên Windows Server 2008 nên vấn đề này chỉ được sử dụng nếu thẩm định chế độ Kernel bị vô hiệu hóa hoặc cấu hình chủ được thay đổi.
Chúng ta kiểm ra và sửa file cấu hình bằng phương pháp này:

  1. Đầu tiên mở file cấu hình trên máy chủ SharePoint: %WinDir%\System32\inetsrv\config\ApplicationHost.config
  2. Sau đó kiểm tra rằng thiết lập useAppPoolCredentials đã hiện diện. Nếu không chúng ta cần bổ sung thuộc tính giống như trong ví dụ được đánh dấu bởi màu xanh bên dưới.
    <system.webServer>
    <security>
    <authentication>
    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
    </authentication>
    </security>
    </system.webServer>
  3. Cuối cùng, thiết lập lại Internet Information Server từ nhắc lệnh:
    IISRESET /NOFORCE

Lúc này chúng ta có thể truy cập vào website một lần nữa không có nhắc nhở đăng nhập hoặc các lỗi bản ghi sự kiện. Với bản ghi, chúng ta chỉ gộp các thông tin chi tiết về giao thức đã được capture từ máy khách PC1:


Hình 15

Kiểm tra sự nhân bản Service Principal Names

Hoàn toàn dễ dàng tạo một SPN nhân bản trong Active Directory trừ khi bạn sử dụng lệnh setspn.exe với tiếp lệnh “-S” hoặc “–F” (chỉ áp dụng cho setspn.exe trong Windows Server 2008 hoặc phiên bản cao hơn). Để hiểu tốt hơn về cách Service Principal Names được lưu như thế nào và cách KDC khóa chặn tài khoản dựa trên SPN. Chúng tôi đã thể hiện bằng sơ đồ trong hình 16. Ví dụ về một SPN nhân bản đăng ký trong SPWrongAcct được đánh dấu màu đỏ.


Hình 16

Việc nhân bản SPN có thể làm cho các thông báo lỗi không liên tục chỉ thị KRB_AP_ERR_MODIFIED, vì KDC có thể mã hóa thẻ dịch vụ bằng khóa công của tài khoản SPN – có thể là tài khoản khác mà ứng dụng sử dụng để giải mã gói dữ liệu. Việc kiểm tra các SPN nhân bản được khuyến khích thực hiện trong bất cứ môi trường nào và có thể thực hiện theo một vài cách.

  • ldifde – trích rút SPN trực tiếp và được lọc từ Active Directory.

    Getting accounts where the HTTP SPNs is defined:
    ldifde -d "dc=domain,dc=local" -r "servicePrincipalName=http*" -p subtree -l "dn,servicePrincipalName" -f output.txt

    Getting accounts where the MSSQLSvc SPNs is defined:
    ldifde -d "dc=domain,dc=local" -r "servicePrincipalName=mssqlsvc*" -p subtree -l "dn,servicePrincipalName" -f output.txt
  • setspn.exe – trên Windows Server 2008 có thể kiểm tra các nhân bản

    Getting the account where a HTTP SPN is defined:
    setspn.exe –Q http/intranet.domain.local

    Checking for a HTTP SPN registered on multiple accounts (duplicate SPNs):
    setspn.exe –X http/intranet.domain.local
  • ADSIEdit – thường vào thông qua tài khoản người dùng và máy tính một cách lần lượt và kiểm tra rằng giá trị không tồn tại trên nhiều tài khoản. Phương pháp này khó vì vậy chúng ta chọn một trong những phương pháp khác.

Hình 17

Thứ để tìm kiếm trong đầu ra của bất cứ thủ tục nào ở trên là SPN (chẳng hạn như HTTP/intranet.domain.local) không được liệt kê trên các tài khoản khác (chỉ một tài khoản duy nhất). Tài khoản tự bản thân nó có thể có nhiều SPN được liệt kê mà không có vấn đề gì (xem trong hình 17).

Chúng tôi khuyên các bạn nên sử dụng các lệnh dưới đây nếu chạy Windows Server 2008:

  • “setspn.exe –S” cho việc đăng ký một SPN trên một tài khoản và kiểm tra nhân bản trong miền
  • “setspn.exe –F –S” cho việc đăng ký SPN trên một tài khoản và kiểm tra các nhân bản trong forest.

Chúng tôi có sử dụng các hình trong tiến trình kiểm tra các nhân bản và cấu hình Service Principal Name (hình 18) cho tài khoản DOMAIN\SPContentPoolAcct


Hình 18

Hình tiếp theo thể hiện một hành động tạo một SPN nhân bản. setspn.exe trong nhân bản này được thể hiện trong hình 19 và nó còn mách bảo cho bạn biết đối tượng Active Directory nào mà nó xung đột với.


Hình 19

Cấu hình DNS

Một cấu hình DNS vững chắc phải thích hợp với mọi domain ngày nay và khi sử dụng Kerberos thì điều này cũng không phải là một ngoại lệ. Tất cả các hostname phải được tạo trong các vùng tra cứu thuận vào ngược và không có các nhân bản nào trên hostname hoặc IP address được thừa nhận. Trong vùng tra cứu thuận, các bản ghhi cần phải được tạo như A-records – cũng tên các host header trỏ tới các máy chủ. Nếu CNAME đôi khi được sử dụng thì Kerberos sẽ dựng lên các thẻ sử dụng hostname sai – về cơ bản đó là một rule để thực hành trong cấu hình DNS để bảo đảm nó làm việc.

Các thông tin gửi và nhận sẽ được kiểm tra theo cả hai vùng tra cứu thuận và ngược. Chúng ta sẽ test cấu hình của mình trước để xem DNS có đáp trả đúng hostname của mình hay không.


Hình 20

Cả hai lệnh cần phải trả về đúng host-name và IP address – tuy nhiên ý tưởng tốt nhất là tự kiểm tra cấu hình DNS. Bạn cần bảo đảm rằng tất cả các hostname trong cài đặt (các máy chủ DC1, SQL1, WSS1 và máy tính PC1) và các host-header đã được sử dụng (intranet.domain.local) được tạo và mang tính duy nhất. Bên dưới là các hình từ quá trình cấu hình DNS được thể hiện trong hình 21 và 22.
Vùng tra cứu thuận cho domain.local:


Hình 21

Vùng tra cứu ngược cho domain.local:


Hình 22

Kết luận

Cho đến đây, chúng tôi đã giới thiệu cho các bạn hầu hết các thành phần của các lỗi điển hình trong SharePoint và Kerberos như cấu hình DNS, nhân bản SPN và IIS 7 trên Windows Server 2008. Trong phần thứ ba của loạt bài này, chúng tôi sẽ giới thiệu kỹ hơn về các thẻ và xem các thông tin gì chúng ta có thể sử dụng từ đó. Chúng tôi cũng giới thiệu sự ủy nhiệm và Shared Service Provider theo cách xem nó làm việc, tạo lỗi và phân tích sau đó khắc phục lỗi.

Thứ Sáu, 20/02/2009 14:24
3 ★ 1 👨 1.092

Bạn nên đọc

0 Bình luận
Sắp xếp theo
❖
Xóa Đăng nhập để Gửi

    Có thể bạn quan tâm

    ❖ Kiến thức cơ bản