Kerberos trong môi trường Sharepoint

Jesper M. Christensen

Quản trị mạng - Microsoft Windows Sharepoint Services (WSS) 3.0 và Microsoft Office Sharepoint Server (MOSS) 2007 được thiết kế để tập trung các thông tin và giúp các thành viên trong các nhóm có thể cộng tác với nhau một cách hiệu quả. Người dùng có thể truy cập vào tất cả thông tin nằm trong các tài khoản cá nhân riêng lẻ nếu được cho phép từ website Sharepoint.

Trong bài này, chúng tôi sẽ giới thiệu cho các bạn những một số vấn đề cơ bản để sử dụng Kerberos trong môi trường Sharepoint. Bạn sẽ tìm thấy nhiều hướng dẫn cấu hình cho các kịch bản khác nhau và một số mẹo ở đây và chúng tôi hy vọng bài viết này có thể cung cấp được cho các bạn một cái nhìn tổng quan đối với môi trường của riêng mình.

Việc sử dụng Kerberos trong Sharepoint?

Kerberos là một giao thức an toàn cho phép thẩm định theo thẻ nếu yêu cầu máy khách đến Trung tâm phân phối khóa - Key Distribution Center (KDC) có các chứng chỉ người dùng hợp lệ và tên dịch vụ - Service Principal Name (SPN) hợp lệ. Kerberos là kiểu thẩm định được ưa thích trong Sharepoint vì tốc độ, sự an toàn hơn và giảm được số lượng lỗi với username và password hơn so với NTLM. Nếu website Sharepoint sử dụng dữ liệu bên ngoài (nằm trên các máy chủ khác với bản thân máy chủ Sharepoint của bạn) cho cơ sở dữ liệu SQL thông qua các webpart thì máy chủ cần có Kerberos để ủy nhiệm các chứng chỉ máy khách.

Vậy những gì xảy ra giữa máy khách và các máy chủ khi bạn truy cập một website có cho phép Kerberos? Chúng tôi đã tạo một tóm tắt mang tính tổng quan để thể hiện những gì sẽ xảy ra đằng sau kịch bản. Kịch bản được thể hiện trong hình 1 này được tạo từ Windows Sharepoint Services 3.0.

Hình 1: Kerberos trong luồng Sharepoint

1. Máy khách truy cập http://intranet.domain.local bằng các chứng chỉ nặc danh
2. WSS Server trả về lỗi IIS error 401.2 nhưng cũng trả về một WWWAuthenticate header.
3. Máy khách yêu cầu thẻ cho SPN được tạo bởi trình duyệt Internet nội bộ: HTTP/intranet.domain.local
4. KDC trả về thẻ nếu SPN được phát hiện. Điều này được mã hóa bằng khóa chủ tài khoản đã được đăng ký cho SPN (domain\spcontentpool).
5. Máy khách thẩm định với thẻ cho ứng dụng web.
6. Tài khoản Web App giải mã thẻ và hợp lệ hóa nó.
7. Tài khoản Web App yêu cầu thẻ cho SPN được tạo bởi SQL Client: MSSqlSvc/sql1.domain.local:1433.
8. KDC trả về thẻ nếu SPN được tìm thấy. Điều này được mã hóa bằng khóa chủ của tài khoản đã được đăng ký cho SPN (domain\sqlsvsacct).
9. Dịch vụ ứng dụng web thẩm định với cơ sở dữ liệu QLS bằng thẻ tài khoản ứng dụng web và đóng vai người dùng bằng các quyền ủy nhiệm.
10. Tài khoản dịch vụ SQL giải mã thẻ và hợp lệ nó.
11. SQL Server trả về dữ liệu yêu cầu cho WSS Server.
12. WSS Server trả về webpage.

Nếu Kerberos không được cấu hình để truyền thông SQL, bạn hãy nhảy từ bước 6 đến bước 12. Nhớ rằng việc cho phép thẻ chỉ xảy ra ở lần đăng nhập đầu tiên và cho đến khi timeout.

Cấu hình Kerberos cho Sharepoint

Đầu tiên chúng tôi khuyên các bạn tạo một cài đặt thử nghiệm trước khi cấu hình lại môi trường sản xuất. Biết vấn đề này sẽ rất khó cho bạn nhưng nếu có các máy chủ ảo, bạn hoàn toàn có thể xây dựng các máy chủ test một cách nhanh chóng và dễ dàng. Điều này cũng cho phép bạn so sánh cấu hình cuối cùng nếu có vấn đề gì đó không làm việc như mong đợi.

Chính vì vậy chúng tôi cần phải tách bỏ NTLM trên các ứng dụng web của mình và cấu hình để sử dụng Kerberos. Đầu tiên bạn vô hiệu hóa giao thức truyền thông này giữa các máy chủ frontend và backend. Sau đó kích hoạt Kerberos giữa các máy khách và các ứng dụng web riêng biệt để quản lý sự thẩm định thông qua máy chủ Sharepoint (có thể gọi nó là sự thẩm định dual- hoặc double-hop).

Hãy xem xét danh sách cần phải thực hiện cho các thiết lập này.

• Thu thập các thông tin cần thiết và tạo người dùng Sharepoint
• Kích hoạt Kerberos để truyền thông SQL
• Cấu hình Service Principal Names (SPNs) trong Active Directory
• Cấu hình “sự tin tưởng về ủy nhiệm” đối với các tài khoảng computer và user
• Cấu hình Component Services trên các máy chủ Sharepoint
• Kích hoạt Kerberos cho các ứng dụng web và Shared Service Provider (SSP)
• Test môi trường Sharepoint

Thu thập các thông tin cần thiết

Để thực hiện một cách dễ dàng và không gây hại cho các hệ thống đang hoạt động, chúng ta cần phải có tất cả các block đã sẵn sàng. Giả sử môi trường của bạn đang chạy Active Directory và mỗi máy chủ đều có một địa chỉ IP duy nhất. Điều này phải được đăng ký trong máy chủ DNS và không có sự nhân bản tồn tại trong các vùng tra cứu thuận và ngược để Kerberos làm việc. Thêm vào đó tất cả các máy chủ và máy khách phải được đặt thời gian đúng như Kerberos sử dụng để hợp lệ hóa các thẻ và sự truy cập cho máy chủ DNS bên trong.

Trước khi cài đặt, Sharepoint sẽ tạo những người dùng thích hợp trong Active Directory. Nếu bạn đã tạo các tài khoản cần thiết này, hãy đọc các phần tiếp sau nó.

Đây là một danh sách các thông tin cần thiết cho việc thiết lập Kerberos trong môi trường Sharepoint.

• Lớp dịch vụ của SPN
• (HTTP cho các ứng dụng web WSS/MOSS. MSSQLSvc cho SQL Server mặc định)
• Tên host của SPN
• Fully Qualified Domain Name (FQDN) cho tất cả các ứng dụng wen và máy chủ
• Số cổng hoặc SPN của bạn (không có cổng nào cho các ứng dụng web WSS và MOSS. 1433 cho SQL).
• Các tài khoản Active Directory cho SPN (dịch vụ và các tài khoản ứng dụng)

Kích hoạt Kerberos trong truyền thông SQL

Microsoft khuyên nên thực hiện bước này trước khi cài đặt Microsoft Sharepoint để bảo đảm rằng sự truyền thông SQL sẽ làm việc. Cơ sở dữ liệu cấu hình được định vị trong máy chủ SQL và nếu kết nối bị đứt thì bạn cần sửa nó trước khi các site Sharepoint được thiết lập và chạy trở lại. Nếu bạn thay đổi sự thẩm định sau khi cài đặt ban đầu, phải tắt các dịch vụ Sharepoint để tránh mất dữ liệu.

Kích hoạt Kerberos giữa các máy chủ frontend Sharepoint cho máy chủ SQL của bạn bởi:

• Cấu hình SPN
• Cấu hình sự tin cậy cho việc ủy nhiệm nếu bạn cần đóng vai người dùng trong các dịch vụ khác.

Không cần thiết kích hoạt Kerberos trong việc truyền thông SQL nếu bạn chỉ cần thẩm định các máy khách cho frontend Sharepoint, không cần các dịch vụ khác như kết nối dữ liệu, Excel Services/SQL Reporting.

Cấu hình Service Principal Names (SPNs) trong Active Directory

Việc bản đồ hóa Service Principal Name được sử dụng bởi Kerberos để cho phép sự ủy nhiệm của một dịch vụ nhằm thủ vai một tài khoản dịch vụ của người dùng nào đó. Một SPN gồm có Service Class, hostname và đôi khi một số cổng. Một số ví dụ ở đây là HTTP/intranet.domain.local và MSSqlSvc/sql1.domain.local:1433. Bạn nên đăng ký cả hai hostname và FQDN cho các ứng dụng web của mình mặc dù thường chỉ sử dụng một trong chúng.

Để cấu hình Service Principal Name, bạn có thể sử dụng một vài công cụ. Chúng tôi sử dụng thành phần SetSPN-tool được cài đặt trong Windows Server 2008 mặc định. Với Windows Server 2003, thành phần này có thể tìm thấy trong phần các công cụ hỗ trợ trên cài đặt CD-ROM hoặc trong phần resource kit có thể download từ Microsoft. Bạn cũng có thế sử dụng ADSIedit để cấu hình SPN, tuy nhiên thao tác này khiến bạn mất đôi chút công việc để điều hướng thông qua Active Directory, việc edit các hạng mục và thay đổi ServicePrincipalName của chúng.

Lệnh đăng ký một SPN: setspn.exe –A HTTP/intranet.domain.local DOMAIN\Account
Lệnh liệt kê SPN cho một tài khoản: setspn.exe –L DOMAIN\Account
Lệnh xóa một SPN: setspn.exe –D HTTP/intranet.domain.local DOMAIN\Account

Sử dụng các bảng trong hình 2 và 3 để xem các đăng ký cần thiết cho SQL trong kịch bản MOSS và WSS

Hình 2: Sự ủy nhiệm và SPN cho MOSS

Hình 3: Sự ủy nhiệm và SPN cho WSS

Cấu hình sự tin cậy cho các ủy nhiệm trên các tài khoản computer và user

Lúc này bạn cần quản lý được các quyền ủy nhiệm trong Active Directory. Điều này có thể được thực hiện cho các tài khoản máy tính và người dùng như những gì bạn có thể xem trong bảng trên. Trong Active Directory Users and Computers, kích chuột phải vào tài khoản, chọn thuộc tính và kiểm tra phần tin cậy của sự ủy nhiệm (xem các thông tin trong hình 4 và 5 bên dưới). Văn bản hay thủ tục có thể khác trong các phiên bản của Windows Server.

Hình 4: Ủy nhiệm cho tài khoản máy tính

Hình 5: Ủy nhiệm các tài khoản người dùng

Xem trong hình 2 và 3 về các tài khoản để cấu hình sự ủy nhiệm trong kịch bản.

Cấu hình các dịch vụ thành phần trên máy chủ Sharepoint

Các tài khoản ứng dụng web cần phải có các quyền hợp pháp bằng không bạn sẽ nhận được một lỗi DCOM với mã sự kiện là 10017 trong bản ghi sự kiện của mình và được môt tả trong Microsoft KB920783:

“The application-specific permissions settings do not grant Local Activation permission for the COM Server application with CLSID {CLSID} to the user DomainName\UserName SID {SID}. This security permission can be modified using the Component Services administration tool.”

Với việc thiết lập bảo mật thích hợp cho các tài khoản, bạn chỉ cần vào Control Panel, Component Services, Computers, My Computer, DCOM Config và chỉnh sửa các thuộc tính của “IIS WAMReg Admin Service”. Chỉnh sửa “Launch and Activate” trong tab Security và trao quyền “Local Activation” cho các tài khoản ứng dụng (xem trong hình 2 và 3).

Khi bạn ở trong Component Services, thiết lập “Default Impersonation Level” là “Delegate” bằng cách chỉnh sửa thuộc tính của “My Computer”.

Kích hoạt Kerberos cho các ứng dụng web và Shared Service Provider (SSP)

Cấu hình cơ bản của bạn sẽ được thực hiện lúc này. Để sử dụng Kerberos bạn phải kích hoạt thông qua Central Administration cho các ứng dụng web của bạn. Chúng ta có thể chọn giữa NTLM và Kerberos cho các ứng dụng web riêng biệt trên trang Authentication Providers mà bạn sẽ tìm thấy trong panel Application Management. Theo đường dẫn này để cấu hình:

• Central Administration, Application Management, Authentication providers
• Chọn ứng dụng web của bạn cần sử dụng Kerberos cho, ví dụ:

• Kích “Default”
• Chọn hay tích vào tùy chọn Kerberos

Hãy khởi động lại IIS với iisreset /noforce trong nhắc lệnh trên các máy chủ front end của bạn.
Trong MOSS, Shared Service Provider của bạn cũng phải được cấu hình và bạn thực hiện trong một nhắc lệnh. Lệnh SetSharedWebServiceAuthn không tồn tại trong WSS. Điều hướng đến thư mục 12-hive (thường nằm trong C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin) và chạy lệnh: stsadm.exe -o SetSharedWebServiceAuthn –negotiate

Test môi trường Sharepoint

Lúc này vào phần đang tồn tại của hoạt động: Bảo đảm rằng mọi thứ đều làm việc như mong đợi.

Kiểm tra bản ghi đăng nhập bảo mật cho các sự kiện đăng nhập của Kerberos. Kiểm tra tài khoản miền đã được sử dụng. Nếu tài khoản có một đăng nhập lỗi, hãy kiểm tra những thứ dưới đây:

• Ngày và thời gian có được thiết lập đúng trên tất cả máy chủ
• Tài khoản không bị khóa trong miền
• Dịch vụ hoặc ứng dụng đang hoạt động với đúng tài khoản
• Ủy nhiệm được cấu hình đúng trên các tài khoản máy tính và người dùng
• SPN được cấu hình đúng trong Active Directory
• Không có sự nhân bản trên các máy chủ tồn tại trong vùng DNS thuận và ngược
• Các máy chủ DNS được chỉ định đúng trên tất cả các máy chủ

Các vấn đề về phiên bản đối với Internet Explorer

Nếu bạn sử dụng các cổng không phải mặc định trên máy chủ IIS Virtual của mình, hãy bảo phiên bản Internet Explorer mà bạn đang sử dụng là Internet Explorer 6 hoặc đã được vá và được cấu hình để có các cổng trong SPN. Central Administration sẽ gồm một số cổng không mặc định. Lưu ý ở đây là bạn sẽ không thấy thông báo lỗi nói rằng lỗi này là do sử dụng một phiên bản không thích hợp của Internet Explorer

Kết luận

Microsoft Windows Sharepoint có thể được sử dụng trong các môi trường phức tạp, nơi sự thẩm định bảo mật với Kerberos cần thiết. Bài viết này được cung cấp cho các bạn với hy vọng giải thích một số vấn đề về bức trang lớn của Kerberos trong cài đặt Sharepoint. Các công cụ và các cấu hình cơ bản đều có sẵn để bạn có thể bắt đầu việc sử dụng các tính năng tuyệt vời của Sharepoint với thẩm định dual-hop.