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

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

Quản trị mạng – Trong phần ba này chúng tôi sẽ giới thiệu cho các bạn về sự ủy quyền Kerberos và khi nào cần cấu hình sự ủy thác này.

Giới thiệu

Chúng tôi sẽ bắt đầu phần này bằng việc giải thích về sự ủy nhiệm Kerberos Delegation là gì và khi nào cần phải cấu hình nó. Trong các phần trước của loạt bài này, chúng tôi đã giới thiệu các bước cấu hình nhưng sự ủy nhiệm không phải lúc này cũng cần vì nó phụ thuộc vào kịch bản hay thiết kế ứng dụng và các yêu cầu bảo mật.

Kerberos Delegation có thể cho một tài khoản hợp lệ qua nhiều máy chủ bằng cách sử dụng sự nhân cách hóa. Vấn đề này thường được biết đến như việc nhảy đúp và bạn có thể cảm nhận thấy khi sử dụng một số dịch vụ chẳng hạn như Excel Calculation Services (ECS). Khi cấu hình sự tin cậy cho sự ủy nhiệm và sử dụng sự nhân cách hóa các chứng chỉ tài khoản người dùng, chúng ta phải bảo đảm rằng mức truy cập được duy trì đúng trong toàn bộ hệ thống. Một ví dụ khác có thể thấy khi người dùng yêu cầu dữ liệu từ một ứng dụng web. Ứng dụng web sẽ tạo một truy vấn đến cơ sở dữ liệu SQL trên máy chủ vật lý khác và bởi vậy phải sử dụng sự nhân cách hóa. Nếu sự ủy nhiệm và nhân cách hóa được sử dụng thì máy chủ SQL chỉ trả về dữ liệu mà người dùng truy cập đến.

Hình 22: Hai bước nhảy vật lý tạo vấn đề nhảy đúp

Chúng ta sẽ thiết lập một môi trường test cho vấn đề này và xem những kiểu lỗi gì xảy ra nếu sự ủy nhiệm không được cấu hình đúng cách. Chúng ta có một trang . aspx đang làm việc và hiển thị dữ liệu từ một cơ sở dữ liệu thông thường trên SQL server.

Hình 23: Truy vấn đến máy chủ SQL

Kerberos Delegation đã được cấu hình đúng trong môi trường demo của chúng tôi, tuy nhiên chúng hãy xem những gì xảy ra nếu remove sự tin cậy đối với một số quyền ủy nhiệm cho tài khoản các ứng dụng Application Pool; SPContentPoolAcct. Hình 24 thể hiện cấu hình hiện hành cho tài khoản này.

Hình 24: Sửa thiết lập ủy nhiệm

Chúng ta sẽ thử remove các quyền tin cậy đối với dịch vụ MSSQLSvc được đánh dấu màu vàng trong hình và thực hiện một IISRESET /NOFORCE trên máy chủ SharePoint WSS1. Khi thiếu các quyền cần thiết, tài khoản SPContentPoolAcct có thể sẽ không cá nhân hóa các tiêu chuẩn người dùng và hiển thị điều đó với SQL server. Lúc này người dùng sẽ gặp lỗi Microsoft SharePoint chuẩn như thể hiện trong hình 25.

Hình 25: Trang SharePoint đang trả về một thông báo lỗi chuẩn

Trước hết, chúng ta không thể thực hiên nhiều với thông báo lỗi này. Nếu là một quản trị viên bạn sẽ có thể vô hiệu hóa file web.config trong hệ thống file của máy chủ Microsoft SharePoint Web FrontEnd (WFE).

Vô hiệu hóa các thông báo lỗi trong Microsoft SharePoint

Lưu ý: Điều này có thể được thực hiện trên mọi máy chủ Microsoft SharePoint WFE

Lúc này chúng ta hãy qua sát lại trang này.

Hình 26: Trang SharePoint trả về các thông báo lỗi chi tiết

Thông báo lỗi này cho chúng ta rất nhiều thông tin về vấn đề và trang đã chỉ thị rõ ràng rằng vấn đề nằm ở lỗi đăng nhập SQL client với thông báo: System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Đăng nhập nặc danh đã được thực hiện bằng mã .NET và vì vậy tài khoản của người dùng (DOMAIN\Administrator đã đăng nhập vào máy trạm và cố gắng load trang) không được sử dụng trong quá trình này. Để có thêm thông tin về vấn đề này, bạn có thể quan sát trong bản ghi sự kiện ứng dụng tại máy chủ SharePoint (Chúng ta chỉ có một kịch bản này, nhưng nếu bạn có nhiều máy chủ WFE trong Network Load balanced Network (NLB) thì bạn cần phải kiểm tra từng máy chủ một để tìm ra các thông báo lỗi của mình).

Trong Event Viewer trên WSS1 chúng ta sẽ tìm thấy sự kiện cảnh báo:

Warning, ASP.NET 2.0.50727.0, Event ID: 1039, Category:Web Event
Event code: 3005
Event message: An unhandled exception has occurred
…
…
User: DOMAIN\Administrator
Is authenticated: True
Authentication Type: Negotiate
Thread account name: DOMAIN\spcontentpoolacct

Thread information:
Thread ID: 4
Thread account name: DOMAIN\spcontentpoolacct
Is impersonating: False
…

Hình 27: Cảnh báo từ bản ghi sự kiện trên WSS1 SharePoint WFE

Thông tin trong event viewer hiển thị cho chúng ta rằng mã .NET đã sinh ra sự kiện cảnh báo web. Người dùng đã tạo ra điều đó là người dùng xác thực (DOMAIN\Administrator) còn tài khoản gây lỗi là DOMAIN\spcontentpoolacct. Nó cũng thể hiện cho chúng ta thấy được rằng người dùng gây ra lỗi đang không cá nhân hóa tài khoản người dùng thực. Chính vì vậy sự cá nhân hóa không được sử dụng cho đoạn mã .NET và điều này đã gây ra vấn đề.

Cấu hình ủy nhiệm Kerberos sẽ gồm có:

Lưu ý: Lưu ý rằng chúng tôi đã bỏ sót cấu hình ủy nhiệm trong DOMAIN\SPContentPoolAcct. Tuy nhiên rất đơn giản, bạn có thể thêm các thông tin và khởi động các dịch vụ IIS trên máy chủ SharePoint WFE.

Kerberos cho Shared Service Provider (SSP)

Trước khi Infrastructure Update (tháng 7 năm 2008) cho các máy chủ Microsoft Office Servers được phát hành thì sự thẩm định Kerberos không được hỗ trợ đầy đủ cho SSH. Điều này đã gây ra một số vấn đề với nhiều SSP và chức năng tìm kiếm. Chính vì vậy chúng tôi khuyên bạn nên cài đặt nâng cấp trên các hệ thống nếu chưa thực hiện điều đó. Microsoft đã công bố một số nâng cấp về sau có trong đó cả nâng cấp về cơ sở hạ tầng này, chính vì vậy các bạn hãy kiểm tra website của Microsoft để có được đường dẫn nâng cấp mới nhất. Bạn có thể tìm thấy liên kết đến các phần liên kết đó ở cuối phần này.

Trong Infrastructure Update, Microsoft đã bổ sung thêm định dạng Service Principal Name (SPN): MSSP/<host:port>/<SSP name>.

Để có được các thông tin chi tiết của cấu hình cho SSP đang sử dụng định dạng SSP mới này, bạn hãy vào website TechNet được đề cập đến trong phần liên kết của phần này. Chúng tôi đã tóm tắt ngắn gọn về các bước cấu hình Kerberos như được đề cập đến trong một bài viết của TechNet về Shared Services Provider.

Shared Services Provider (SSP)

Hình 28: Đăng ký tên dịch vụ cho SSP

Thêm một số vấn đề và các lưu ý

Người dùng và các tài khoản dịch vụ SharePoint

Kiểm tra xem người dùng hoặc tài khoản SharePoint có bị khóa trong miền hoặc có một mật khẩu đã hết hạn sử dụng hay không. Một chính sách công ty có thể được thực thi trong môi trường của bạn trong trường hợp này.

Kết nối an toàn tài khoản máy tính

Một số máy khách và máy chủ thất bại trong việc thiết lập một kết nối an toàn với miền nhưng Kerberos được xây dựng trên kiểu cơ sở hạ tầng bảo mật này. Nếu xảy ra điều đó, bạn cần thiết lập lạu và xây dựng lại mối quan hệ này.

Nếu máy chủ và máy khách bị nhân bản, khi đó bạn cần phải tạo một ID bảo mật mới (SID) và cách được khuyên dùng để thực hiện là chạy tiện ích sysprep. Một cách khác cũng có thể thực hiện được là sử dụng Sysinternals, NewSID.

Các vấn đề với kích thước của MTU

Các gói dữ liệu mạng được gửi thông qua hệ thống dây dẫn thường đều có một độ dài nhất định. Nếu một tài khoản là thành viên của một số nhóm lớn thì điều này có thể dễ nhận thấy. Một cách khác để xử lý vấn đề MTU là thực thi Kerberos sử dụng TCP. Bạn có thể tìm thấy các thông tin về vấn đề này trong bài KB244474 của Microsoft.

Các ứng dụng web với các phương pháp thẩm định khác nhau

Vô hiệu hóa thỏa thuận trên các ứng dụng web nếu chúng không cần thiết hoặc sử dụng thẩm định Kerberos. Nếu bạn có nhiều ứng dụng web trên cùng một máy chủ và sử dụng Kerberos trên một số ứng dụng web và NTLM thì bạn có thể cảm nhận được vấn đề này. Đặc biệt nếu các ứng dụng web sử dụng cùng một tên máy chủ và sử dụng các tài khoản ứng dụng khác thì bạn thường phải tốn đến một vài giờ cho công việc khắc phục sự cố các hệ thống.

Chúng tôi giới thiệu một số hướng dẫn cho các ứng dụng web.

Kiểm tra xem Kerberos có được cấu hình cho ứng dụng web

Khởi động nhắc lệnh.

cd c:\inetpub\adminscripts
cscript adsutil.vbs get w3svc/<id of your website>/root/NTAuthenticationProviders
(bạn sẽ tìm thấy I.D cho website thông qua IIS Management trong bộ nhận dạng)

Với Kerberos kết quả sẽ là: NTAuthenticationProviders : (STRING) "Negotiate,NTLM"
Với NTLM kết quả sẽ là: NTAuthenticationProviders : (STRING) “NTLM"
Cấu hình IIS website với phương pháp khác (trong ví dụ này với Kerberos) sử dụng lệnh dưới đây:
cd c:\inetpub\adminscripts
cscript adsutil.vbs set w3svc/<id of your website>/root/NTAuthenticationProviders “Negotiate,NTLM”

Điều này cần thiết trên mọi máy chủ SharePoint frontend

Kịch bản SQL Server 2005 để kiểm tra

Chúng tôi giới thiệu một đoạn kịch bản SQL để kiểm tra kiểu của phương pháp thẩm định được sử dụng cho cơ sở dữ liệu là gì. Điều này rất hữu dụng khi bạn cần bảo đảm mọi thứ làm việc như mong đợi.

SELECT DB_NAME(dbid) AS DatabaseName, loginame AS LoginName, sys.dm_exec_connections.auth_scheme as AuthMethod
FROM sys.sysprocesses
JOIN sys.dm_exec_connections
ON sys.sysprocesses.spid=sys.dm_exec_connections.session_id
WHERE dbid > 0
GROUP BY dbid, loginame, spid,sys.dm_exec_connections.auth_scheme

Đầu ra của kịch bản trong môi trường test của chúng tôi (có ví dụ CompanyDatabase ở trên) được thể hiện trong hình 29 bên dưới.

Hình 29: Đầu ra của kịch bản trong SQL Management Studio

Kết luận

Trong phần này, chúng tôi đã giới thiệu cho các bạn về sự ủy nhiệm trong Kerberos, sự cá nhân hóa và cấu hình Shared Service Provider (SSP). Bên cạnh đó chúng tôi còn giới thiệu thêm những lưu ý và các kịch bản để kiểm tra phương pháp thẩm định đã được dùng – điều này có thể được sử dụng với SharePoint cũng như các cấu hình khác.

Cấu hình Kerberos và đặc biệt việc khắc phục sự cố các vấn đề khác nhau có thể sẽ rất phức tạp. Tuy nhiên nhiệm vụ của chúng tôi trong loạt bài này chỉ là cung cấp cho các bạn một số thông tin quan trọng trong các công nghệ để từ đó tìm ra các lý do cho các vấn đề rồi từ đó giải quyết chúng. Chúng tôi hy vọng bạn sẽ tìm thấy sự thành công sau loạt bài này.