Tài liệu Khắc phục sự cố các vấn đề đối với Kerberos trong SharePoint – Phần 3 ppt

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ầ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ố
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.
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"
 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).