Khắc phục sự cố các vấn đề đối với Kerberos trong SharePoint – Phần 3 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
Trang 1Khắc phục sự cố các vấn đề đối với Kerberos trong SharePoint
– Phần 3 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
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
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ố
Trang 2quyề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
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
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)
Môi trường test được định vị ở
đây: C:\inetpub\wwwroot\wss\VirtualDirectories\intranet.domain.local80
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
Tạo một copy với file web.config trước khi chỉnh sửa nó (bảo đảm trong những trường hợp xấu hơn)
Mở nó bằng một trình soạn thảo văn bản chẳng hạn như Notepad
Tìm kiếm <customErrors mode="Off" /> và thay đổi thành <customErrors
mode="On" />
Tìm kiếm CallStack="true" và thay đổi thành CallStack="false"
Trang 3 Khởi động lại Internet Information Server (IIS) với lệnh IISRESET /NORFORCE
Lúc này chúng ta hãy qua sát lại trang này
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)