Phần 2. Triển khai cấu hình đăng nhập 1 lần SSO giữa Moodle và AD server ROBUSTA Distance Learning 2015


10. Cấu trúc hệ thống đăng nhập 1 lần – SSO:

1. Đăng nhập một lần (SSO – Single Sign On): Khi người dùng đăng nhập lần đầu vào một WBT, tài khoản đăng nhập đó sẽ tự động được sử dụng cho phiên làm việc của người đó trong toàn bộ hệ thống.

Hệ thống đào tạo ở đây được hiểu là tập hợp các ứng dụng khác nhau có thể được dùng thông qua giao diện Web. Cơ chế này có thể xây dựng dựa vào một điểm chứng thực trung tâm (Central Authentication Service – “CAS”), dựa vào giao thức LDAP (Lightweight Directory Access Protocol), hoặc hoặc thậm chí dựa vào cookie của trình duyệt để giữ xác thực.

image

image

 

2. Sơ đồ đăng nhập 1 lần với LMS vs LCMS:

screenshot_technologists_03 image

3. Khả năng đáp ứng đăng nhập 1 lần với các ứng dụng hiện nay:

image

image

4. Khả năng tích hợp giữa e-learning với các mô hình hệ thống dịch vụ khác:

image

Dựa trên các phân tích và thực tế triển khai, phát triển sản phẩm công nghệ đào tạo trực tuyến hiện nay, chúng ta thấy được Moodle là một trong các mô hình E-learning phát triển mạnh mẽ nhất trên thế giới.

5. Cấu trúc vận hành xác thực trong SSO:

image

Với mô hình cấu trúc xác thực SSO nói trên đã có rất nhiều các gói ứng dụng, giao thức và giải pháp xác thực, đăng nhập 1 lần khác nhau.

Nhưng tất cả đều phải tuân thủ 1 nguyên tắc cơ bản là bảo mật, quản lý và vận hành theo nguồn dữ liệu người dùng đơn giản và hiệu quả nhất.

 

6. Lý do lựa chọn giải pháp tích hợp Moodle với AD Server:

    • ROBUSTA Distance Learning 2015 đã và đang sử dụng hạ tầng quản lý người dùng trên nền Windows Active Directory (AD Server) và tích hợp các nền tảng dịch vụ Office 365 – Exchange – Lync – SharePoint Online, CRM online. Do vậy, việc lựa chọn giải pháp tích hợp đăng nhập 1 lần giữa Moodle và AD là hiển nhiên.
    • Ngoài ra, các hệ thống thực hành Labs trên Private Cloud, Hybrid Cloud, Public Cloud, VMware vSphere đều được kết nối, đồng bộ tài khoản giữa các ứng dụng đó với AD Users.
    • Đây là 1 phần quan trọng để thống nhất quản lý người dùng, đồng thời đem lại sự đơn giản hóa cho người dùng khi sử dụng hệ thống Đào tạo trực tuyến của ROBUSTA.

image

7. Các bước cấu hình đăng nhập 1 lần trên Moodle Admin:

Tham khảo link: https://docs.moodle.org/28/en/Active_Directory#Troubleshooting_AD_and_LDAP_authentication 

Tham khảo link: Tích hợp Moodle với Microsoft Office 365 thông qua AD: http://www.moodlenews.com/2013/integrate-moodle-and-microsoft-office-365-through-ad/ 

Tham khảo link:  Lỗi tích hợp xác thức trên nền IIS http://support.microsoft.com/kb/896861 

Tham khảo link: cấu hình SMTP relay gửi thư qua Office 365 trên windows server 2008 http://www.configureoffice365.com/configure-office-365-smtp-relay/ 

Tham khảo link: cấu hình phân quyền và chức năng sử dụng trong Moodle: https://docs.moodle.org/28/en/Standard_roles 

Tham khảo link: cách xóa quyền truy cập của Guest / Anonymous: https://moodle.org/mod/forum/discuss.php?d=65614

 

8. Chi tiết các bước tích hợp Moodle với AD  thông qua giao thức xác thực LDAP Authentication và NTLM SSO:

Bước 1:  chuẩn bị

– Moodle 2.8 Server đang chạy trên máy chủ Windows Server 2012 đã Join domain.

– 1 máy chủ Domain Control Center “DCC” chạy trên windows server 2008 r2.

Bước 2:  kiểm tra tình trang kết nối LDAP qua cổng 389 từ máy chủ Moodle 2.8 tới máy chủ DCC.

– Bạn nên download công cụ LDP.zip để kiểm tra các công việc trên máy chủ Moodle 2.8

(tham khảo hướng dẫn dùng ldp.exe : https://technet.microsoft.com/en-us/library/cc794810%28v=ws.10%29.aspx )

– Giải nén file ldp.zip vào thư mục c:\LDAP trên máy chủ Moodle.

– Chạy file ldp.exe

image

 

– Chọn menu Connection sau đó bấm chọn Connect.

– Nhập tên máy chủ AD server bạn cần để kiểm tra tình trạng làm việc của LDAP. (nếu bạn không chắc chắn tên hoặc ip của máy chủ AD thì hãy nhập dòng lệnh sau:

nltest/dclist:yourdomain.name.com nó sẽ giúp bạn nhìn được danh sách các máy chủ Domain controllers trong hệ thống mạng LAN của bạn.) sau đó bấm OK.

– Nếu mọi thứ thực hiện đúng nó sẽ kết nối và nó sẽ hiển thị tất cả cấu hình LDAP server /phiên bản của máy chủ AD.

image

– Bấm menu ConnectionBind.

– Bây giờ chúng ta cần nhập username, password và domain (nhập tài khoản administrator username và mật khẩu, tên miền domain).

– Nếu thực hiện thành công sẽ thấy xuất hiện Authenticated as dn:’username’. (cần khởi tạo hoặc kiểm tra tài khoản này với quyền admin privileges).

– Chúng ta có thể bấm menu View sau đó chọn popbar  Tree.

– Một menu sổ xuống và bạn chọn BaseDN cho việc hiển thị thông tin trong domain của bạn.

image

– Bạn sẽ nhìn thấy phía bên trái domain của bạn, các thông tin về OU và CN trong máy chủ AD đang quản lý.

– Bước tiếp theo ta sẽ cần dùng các thông tin trong OU, CN và DC để khai báo vào máy chủ Moodle LDAP

 

Bước 3: kích hoạt Moodle LDAP

– Trước hết chúng ta cần kích hoạt LDAP plugin.

–  Đăng nhập vào Moodle bằng admin, bấm: Site administration, Plugins, Authentication và chọn Manage authentication.

– Trong danh sách các plug-in sẽ thấy kiểu xác thực có giá trị  “available authentication types” ta bấm tiếp vào hình “con mắt”  để kích hoạt “LDAP Server –> enable”.

image

Bước 4: Cấu hình Moodle LDAP:

– Bấm vào LDAP Server để truy cập trang cấu hình LDAP:

  • Host URL: ldap://ip (đây là tên FQDN hoặc IPv4 của máy chủ AD domain controller, nếu  có nhiều máy chủ DC bạn có thể nhập các địa chỉ phân cách nhau bằng dấu;  ví dụ: ldap://10.66.28.42;ldap://10.66.28.43 ).
  • Version: 3
  • Use TLS: No (bạn có thể nâng cấp dùng TLS sau)
  • LDAP encoding: ulf-8

Bind Settings

  • Hide password: yes (không cho lưu mật khẩu trong Moodle database.)
  • Distinguished Name: CN=LDAP,OU=Other,OU=Admin,OU=School Users,DC=***,DC=***,DC=****,DC=*** (có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).

image

  • Password: ******** (mật khẩu của account admin dùng cho Bind account)

User Lookup Settings

  • User Type: MS ActiveDirectory (đây là kiểm truy cập bằng account LDAP AD User).
  • Context: OU=school users,DC=***,DC=***,DC=***,DC=*** (nặp lại có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).
  • Search Subcontext: Yes (giúp tìm cấc tài khoản theo kiểu nặp lại OU nhiều cấp OU –> OU1 –> OU11).
  • User Attribute: samaccountname (các thuộc tính người dùng để tìm kiếu theo kiểu tên / email có trong cấu trúc cây LDAP user. Thông thường là kiểu domain\username hay còn gọi sAMAccountName hiếm khi có trường hợp đặc biệt kiểu UPN hoặc email address) , Nó thường dùng kiểu: cn (Novell eDirectory and MS-AD) , uid (RFC-2037, RFC-2037bis cho SAMBA 3.x LDAP extension), nhưng nếu bạn dùng MS-AD bạn cần nhớ rằng ta cần phải dùng theo chuẩn đăng nhập NTLM SSO nên thường dùng sAMAccountName (là kiểu đăng nhập The pre-Windows 2000 logon account name).

Force Change Password

  • Force Change Password: no (Chúng ta không nên cho user Moodle được phép thay mật khẩu, người dùng có thể thay từ AD server hoặc từ việc đăng nhập computer và dùng tổ hợp phím Ctrl+Alt+Del).

LDAP password expiration Settings

  • Expiration: no (Không nên giới hạn tuổi của mật khẩu ở Moodle LDAP vì sẽ rắc rối lớn nếu người dùng không đăng nhập được Moodle vì mật khẩu truy cập vào Moodle bị hết hạn sử dụng).
  • Grace Login: no (Nếu đã không đăng nhập được Moodle qua mạng thì hiển nhiên họ sẽ không vào được trang My Moodle cá nhân hoặc trang admin Moodle).

Enable User Creation

  • Create User Externally: no (Chúng ta muốn chỉ có những tài khoản thuộc AD mới truy cập được Moodle).

Course Creator

  • Creators: OU=Staff,OU=School Users,DC=***,DC=***,DC=***,DC=*** (nặp lại có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).

NTLM SSO (đây là cấu hình bắt buộc)

  • Enable: yes (cho phép sẽ đăng nhập tài khoản bằng Moodle single sign-on).
  • Subnet: IP/22 (đây là dải địa chỉ IP Subnet address  nhằm cho phép sử dụng truy xuất NTML SSO single sign-on, kiểm soát việc các computer có thuộc dải được phép SSO).
  • MS IE fast path: Yes, attempt NTLM other Browsers (đảm bảm mức tương thích với các phiên bản IE là tối đa).
  • Authentication Type: NTLM.
  • Remote Username Format: %domain%\%username% (default)

Data Mapping

  • First Name: givenname
  • Sure Name: sn
  • Email Address: mail

Tham khảo linK: các trường thông tin dùng trong AD  http://www.kouti.com/tables/userattributes.htm 

image

image

 

Bước 5: Lưu lại những thay đổi:

Bước 6: Cấu hình NTML trên IIS Server:

– Tìm đến file trong thư mục sau auth/ldap/ntlmsso_magic.php thông qua IIS Management Console,

Nếu dùng IIS 6.0 thì bấm phải chuột vào file và chọn properties:

    • Ở tab “file security” bấm quyền truy cập Authentication and Access control chọn nút edit.

 

  • Bỏ chọn  “Enable Anonymous Access” và bấm chọn “Integrated Windows Authentication”

Nếu dùng IIS 7.0 thì bấm phải chuột vào file và chọn properties

  • Sau mục chỉ dẫn navigating chọn thư mục ‘auth/ldap’ và bấm chuyển “switch to Content View”.
  • Bấm phải chuột trên file và chọn “Switch to Features View”.
  • Bấm vào biểu tượng Authentication icon nằm cửa sổ bên phải.
  • Chọn ‘Anonymous Authentication’ và  bấm nút ‘Disable’.
  • Chọn ‘Windows Authentication’ và bấm nút ‘Enable’.

Nếu dùng IIS 7.5  bạn sẽ cần chọn ‘Windows Authentication’ và chọn ‘Providers’. Nó sẽ hiển thị danh sách enabled providers Negotiate and NTLM. hãy chuyển đổi thứ tự để cho NTLM lên đầu danh sách.

Moodle_SSO

image

 

Bước cuối: Thử nghiệm

– Bấm chọn (Đăng nhập):

image

– Nhập domain name\username và mật khẩu của AD:

image

– Màn hình tự động đăng nhập Moodle bằng NTML:

image

– Bạn sẽ nhận được thư gửi có nội dung và link để kích hoạt tài khoản truy cập sử dụng các dịch vụ của Moodle sau khi khai báo thêm các thông tin về User Profile (đặc biệt là địa chỉ email)

image

Tham khảo: Phần 3. Triển khai cấu hình đăng nhập 1 lần SSO giữa AD server On-Premise với Microsoft Office 365 – ROBUSTA Distance Learning 2015

P.S: Rất tiếc phần 3, chỉ công bố trong chương trình đào tạo MS Office 365, Private Cloud.

Các bạn hãy đăng ký tham gia các khóa học của http://robusta.vn để được trải nghiệm, hỗ trợ và thực hành tốt hơn.

 

Chúc các bạn thành công !

 

Advertisements

Phần 9. Có những lỗi của SharePoint rất hiểm mà chỉ có IIS và ASPX.Net mới hiểu được ?


Một trong những lỗi mà dân lập trình, triển khai và quản trị MS SharePoint khó phát hiện ra cách sửa lỗi nhất đó là:

“Khi tạo ra 1 Portal site trên chính máy chủ SharePoint Farm, cài, cấu hình và khởi tạo đầy đủ các template site. Đăng nhập lại trang portal đó bằng chính account system admin của AD

đều bó tay không thể mở được, cho dù nhập rất đúng mật khẩu và kiểu account sAMAccountName hay UPN hay kiểu Email domain…” mọi thứ khác đều chạy ổn, riêng vấn đề này không ổn”.

SPS2010_not_access

Tại sao vậy ?

Nguyên nhân:

Khi bạn sử dụng tên miền đầy đủ (FQDN) hoặc một tiêu đề tùy chỉnh /IP để truy cập một trang web localhost được lưu trữ trên một máy tính đang chạy Microsoft Internet Information Services (IIS) 5.x, 6.x, 7.x, 8.x hoặc một phiên bản sau này, bạn có thể nhận được một thông báo lỗi tương tự như sau:

HTTP 401.1 – Unauthorized: Logon Failed

Vấn đề này xảy ra khi các trang web đó có sử dụng tích hợp xác thực “Integrate Windows Authentication” và có một cái tên được ánh xạ đến địa chỉ loopback localhost.

Chú ý: Bạn chỉ nhận được thông báo lỗi này nếu bạn cố gắng để duyệt qua các trang web trực tiếp trên chính máy chủ host URL đó.

Nếu bạn duyệt qua các trang web từ một máy tính khác, các trang Web đó vẫn sẽ hoạt động như bình thường.

Luận thuyết về lỗi trên SharePoint Farm:

Vấn đề này xảy ra nếu bạn cài đặt Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows Server 2003, Windows 2008 server/R2 và MS SharePoint bao gồm một tính năng bảo mật kiểm tra loopback được thiết kế để giúp ngăn chặn các cuộc tấn công ánh xạ ngay trên máy tính chủ dịch vụ của bạn.

Vì vậy, xác thực không thành công nếu FQDN hoặc header tùy chỉnh mà bạn sử dụng không phù hợp với tên máy tính localhost.

Cách xử lý:

Bạn hãy mở Registry của chính máy chủ windows server 2008 standard/r2 đang chạy

SPS2010_not_access1

Có hai phương pháp để xử lý vấn đề này, sử dụng một trong các phương pháp sau đây sao cho thích hợp với tình hình của bạn.

Phương pháp 1: Xác định tên host (phương pháp Preferred nếu NTLM xác thực được mong muốn):

Để xác định tên máy chủ được ánh xạ đến địa chỉ loopback và có thể kết nối đến các trang web trên máy chủ của bạn, hãy làm theo các bước sau:

1. Thiết lập DisableStrictNameChecking trong registry với giá trị  1.

2. Nhấp vào Bắt đầu, bấm Chạy, loại regedit, và sau đó nhấn OK.

3. Trong Registry Editor, xác định vị trí và sau đó nhấp vào khóa registry sau đây:  HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ MSV1_0

4. Kích chuột phải vào MSV1_0, chọn New, và sau đó nhấp vào Multi-String Value.

5. Gõ BackConnectionHostNames, và sau đó nhấn ENTER.

6. Kích chuột phải vào BackConnectionHostNames, và sau đó nhấp vào Modify.

7. Trong value gõ tên máy chủ hoặc các tên máy chủ cho các trang web có trên máy tính localhost, và sau đó nhấn OK.

8. Thoát khỏi Registry Editor, và sau đó khởi động lại dịch vụ IISAdmin.

Phương pháp 2: Vô hiệu hoá việc kiểm tra loopback (phương pháp ít được đề nghị – nhưng phù hợp với trường hợp của Microsoft SharePoint)

Phương pháp thứ hai là để vô hiệu hóa việc kiểm tra loopback bằng cách thiết lập các khóa registry DisableLoopbackCheck.
Để thiết lập các khóa registry DisableLoopbackCheck, hãy làm theo các bước sau:

  1. Thiết lập DisableStrictNameChecking sửa trong registry để giá trị bằng 1.
  2. Nhấp vào Bắt đầu, bấm Chạy, loại regedit, và sau đó nhấn OK.
  3. Trong Registry Editor, xác định vị trí và sau đó nhấp vào khóa registry sau đây:  HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa
  4. Kích chuột phải vào Lsa, chọn New, sau đó bấm Value DWORD.
  5. Gõ DisableLoopbackCheck, và sau đó nhấn ENTER.
  6. Kích chuột phải vào DisableLoopbackCheck, và sau đó nhấp vào Modify.
  7. Trong phần Data value nhập giá trị bằng 1, và sau đó nhấn OK.
  8. Thoát khỏi Registry Editor, và sau đó khởi động lại máy chủ của bạn.
  9. SPS2010_not_access2

Thực tế, mình sửa tới đây rồi và lưu lại register đợi sau 5 phút thì mở lại trang Portal site của Microsoft SharePoint thì đăng nhập được luôn (không khởi động lại máy chủ SharePoint).

P.S: Các bạn hãy đến học chương trình MS SharePoint tại ROBUSTA để có những kinh nghiệm thực tế, vững vàng trong công tác phát triển thông tin thông tấn tại Doanh nghiệp bạn.

Chúc các bạn yêu MS SharePoint yêu luôn cả lỗi bực mình này nhé !

Thông tin về lịch khai giảng tại Viện đào tạo và quản lý CNTT ROBUSTA Hà nội


Nếu quý khách có yêu cầu chương trình học ngoài lịch khai giảng trên xin vui lòng liên hệ với Robusta

STT

Tên khóa học

Ngày KG

Giờ học

Ngày học

Thời lượng

Học phí

Giảng viên

Các khóa đào tạo công nghệ VMware

1

 Triển khai, quản trị hạ tầng ảo hóa với VMware vSphere 5.5

05-05-2014 18h-21h Thứ 2-6 40 giờ Liên hệ Việt Nam
2
10-05-2014 09h-17h Thứ 7,CN 40 giờ Liên hệ Việt Nam
3
12-05-2014 09h-17h Trong tuần 40 giờ Liên hệ Việt Nam
4

VMware vSphere: Optimize & Scale [v5.1]

26-05-2014 09h-17h Trong tuần

40 giờ

Liên hệ Việt Nam

 

5

Ảo hóa máy trạm và ứng dụng VMware [v5.5]

 

19-05-2014

18h-21h

Trong tuần

40 giờ

Liên hệ

Việt Nam

6

09-06-2014

18h-21h

Thứ 2,4,6

40 giờ

Liên hệ

Việt Nam

 

7

VMware vCenter Configuration Manager for Virtual Infrastructure Management [V5.x]

04-06-2014

09h-17h

Trong tuần

40 giờ

Liên hệ

Nước ngoài

8

VMware vCenter Operations Manager: Analyze and Predict [V5.x]

02-06-2014

09h-17h

Trong tuần

16 giờ

Liên hệ

Nước ngoài

9

VMware vCenter Configuration Manager for Virtual Infrastructure Management [V5.x]

04-06-2014 09h-17h Trong tuần 24 giờ Liên hệ Nước ngoài

Các khóa đào tạo Microsoft

1

Office365 Tổng hợp

 

05-05-2014 09h-17h Trong tuần 24 giờ 06 triệu Việt Nam
2 05-05-2014 18h-21h Thứ 2,4,6 24 giờ 06 triệu Việt Nam
3

 

Manage Projects with Microsoft Project 2010

 

12-05-2014
18h-21h

Thứ 2,4,6

24 giờ 05 triệu Việt Nam
4

Phát triển Biztalk Server dành cho người lập trình

12-05-2014 09-17h

Trong tuần

40 giờ Liên hệ Việt Nam
5

Quản trị Biztalk Server

26-05-2014 09-17h

Trong tuần

40 giờ Liên hệ Việt Nam
6 Phát triển Biztalk trong tích hợp ứng dụng doanh nghiệp 02-06-2014 09-17h Trong tuần 40 giờ Liên hệ Việt Nam
7 02-06-2014 18h-21h Thứ 3,5,7 40 giờ Liên hệ Việt Nam
8 Thiết kế và phát triển Ứng dụng Microsoft Sharepoint 19-05-2014 18h-21h Thứ 2,4,6 40 giờ Liên hệ Việt Nam
9 Thiết kế kiến trúc hạ tầng Microsoft Sharepoint 26-05-2014 09h-17h Trong tuần 40 giờ Liên hệ Việt Nam
10

KHOÁ ĐÀO TẠO NÂNG CAO

ĐIỀU CHỈNH SHAREPOINT 2010 CHO HIỆU SUẤT CAO

23-06-2014 09h-17h Trong tuần 40 giờ Liên hệ Việt Nam
11 Thiết kế các giải pháp BI với  Microsoft SQL Server 09-06-2014 09h-17h Trong tuần 40 giờ Liên hệ Việt Nam
Các khóa đào tạo khác
1 Quản lý CNTT và An toàn thông tin 19-05-2014 09h-17h Trong tuần 40 giờ Liên hệ Việt Nam
2 19-05-2014 18h-21h Thứ 2,4,6 40 giờ Liên hệ Việt Nam
3 IT Management Skills – Các kỹ năng quản lý công nghệ thông tin 16-06-2014 09h- 17h Trong tuần 40 giờ Liên hệ Việt Nam
4 ITIL – Information Technology Infrastructure Library Foundation V3 16-06-2014 18h-21h Thứ 2,4,6
24 giờ Liên hệ Việt Nam
5
Thiết kế Website PHP và HTML5 bằng phương pháp sản xuất công nghiệp
27-4-2014
08h-12h
Chủ nhật
4 giờ
01 triệu
Việt Nam

 

Thông tin ưu đãi:

– Giảm giá đặc biệt cho các học viên đăng ký và thanh toán trước ngày khai giảng tối thiểu 02 tuần hoặc đăng ký nhóm 02 người trở lên.

 

Thông tin chi tiết vui lòng liên hệ:

Lê Trường Sơn (Mr.) – Mobile : (+84) 0904 411 933 – Email: son.le@robusta.vn

Lê Toàn Thắng (Mr.) – Mobile : (+84) 943 851 178 – Email: thang.le@robusta.vn

Xin cám ơn và mong được hợp tác và hỗ trợ Quý Anh/Chị cùng đơn vị trong thời gian tới!

Làm cách nào để tạo theme mới hoặc mẫu giao diện cho NopCommerce


1. Các bước tạo theme cho nopCommerce

Trước tiên, hãy copy bản  nopCommerce source code (hoặc phiên bản Web)  về máy chủ web Microsoft  OS.

Bây giờ bạn có thể dùng Visual Studio 2012 mở Solution.Open Solution

1. Hãy mở theme đã có sẵn, tôi thường dùng  DefaultClean theme để cài bản nopCommerce. theo địa chỉ link thư mục sau:

Bản có Source Code – Presentation\Nop.Web\Themes

Bản cho Web – Nop.Web\Themes

Theme Location

2. Chọn Theme, bấm phải chuột và  bấm COPY, sau đó bấm phải chuột chọn ‘Themes’ folder và bấm PASTE và sau đó đổi tên thư mục mới ‘NewTheme’.

Copy Theme

3. Bây giờ bạn mở thư mục theme mới vừa tạo và mở các tệp trong đó với tên gọi theme.config

Bây giờ thay đổi tất cả các tệp liên quan DefaultClean references để bạn tạo mới tên themes name (tôi ví dụ gọi là  ModernTheme)

theme.config

4. Bây giờ bạn có 1 theme mới mở  Views\Shared\Head.cshtml

Bây giờ thay đổi tất cả đường dẫn từ   ’DefaultClean’ sang ‘modernTheme’ cho đúng với trong stylesheets và  javascript liên quan.

head.cshtml

Nội dung trong tệp stylesheet sẽ có link mới  ModernTheme\Content\styles.css  và các tệp ảnh cũng sẽ có link mới là  ModernTheme\Content\images.

 

2. Cài và áp dụng 1 theme cho nopCommerce

Bạn chỉ cần downloaded a new theme which is in a zip file.

  1. Giải nén tệp zip và copy nó vào thư mục “Themes” .
  2. Truy cập trang admin (www.yourdomain.com/admin).
  3. Tới menu Configuration > Settings > General And Miscellaneous settings
  4. Chọn theme theo tên “Desktop Store theme” kéo thả và chọn sau đó bấm  SAVE.
  5. Bây giờ chuyển qua mục  public store hoặc truy cập web theo domain. Bạn sẽ nhìn được giao diện mới khi bạn đã thay theme.

Cách cấu hình SMTP Relay trên máy chủ IIS–Windows 2008 kết nối Exchange Online của Office 365


Cấu hình SMTP Relay trên máy chủ IIS 7, 7.5 Windows Server 2008

Contents

1. Mở IIS 7. 1

2. Kích hoạt SMTP Server trên máy chủ Windows 2008. 2

3. Cấu hình SMTP trên IIS 6. 3

4. Kiểm tra chạy cấu hình SMTP trên IIS 6. 9

5. Cấu hình Mail trên SharePoint Administrator Center. 10

1. Mở IIS 7

clip_image002

2. Kích hoạt SMTP Server trên máy chủ Windows 2008

clip_image004

3. Cấu hình SMTP trên IIS 6

clip_image006

clip_image008

clip_image010clip_image012

clip_image014

clip_image016clip_image018clip_image019clip_image021

Cách xác định địa chỉ máy chủ Exchange Online bằng lệnh CMD như sau:

clip_image023

Ví dụ: địa chỉ mail.cloud.edu.vn là địa chỉ bạn đã khai subdomain / DNS của webmail theo nhà cung cấp dịch vụ quản lý tên miền

Kết quả trả về là màn thông báo kết nối thành công mã 220

clip_image025

Cuối cùng, mở Start\Control Panel\Services kiểm tra dịch vụ SMTP đã started.

clip_image027

4. Kiểm tra chạy cấu hình SMTP trên IIS 6

Tạo 1 file có tên mail.txt, có nội dung sau:

From:<thang.le@hotmail.com>

To:<youremail@your_domain_office365.edu.vn>

Subject: Test mail from IIS Server via SMTP Relay Office 365

Body:

Mail Content to send SMTP Relay.

^

Hãy copy file này vào thư mục c:\inetpub\mailroot\pickup\

clip_image029

Nếu hệ thống chạy tốt, cấu hình SMTP trong IIS đúng, file đó sẽ tự động chuyển sang thư mục Queu và Send, bạn có thể kiểm tra log của IIS 6 hoặc trên hòm thư bạn đã gửi trong mục To:<> của nội dung file mail.txt.

5. Cấu hình Mail trên SharePoint Administrator Center

clip_image031

Các bước cài: WebDav cho Windows Server 2008 R2


Introduction

Microsoft released a new WebDAV extension module that was completely rewritten for Internet Information Services (IIS) 7 on Windows Server® 2008. This new WebDAV extension module incorporated many new features that enable Web authors to publish content better than before, and offers Web administrators more security and configuration options. Microsoft has released an update to the WebDAV extension module for Windows Server® 2008 that provides shared and exclusive locks support to prevent lost updates due to overwrites.

This document walks you through adding WebDAV publishing to an existing Web site by using the new WebDAV user interface and by directly editing the IIS configuration files.

Note: This walkthrough contains a series of steps in which you log on to your Web site using the local loopback address and the local administrator account. When using an administrator account, these steps should only be followed on the server itself using the loopback address or over SSL from a remote server. If you prefer to use a separate user account instead of the administrator account, you must create the appropriate folders and set the correct permissions for that user account when necessary.

In This Walkthrough

Note: This topic discusses using the WebDAV Redirector to connect to your web site. Please see the Using the WebDAV Redirector topic for more information; specifically the Troubleshooting the WebDAV Redirector section if you have trouble using the WebDAV redirector.

Installing WebDAV on IIS 7.0

Prerequisites

The following items are required to complete the procedures in this article:

  • IIS 7.0 must be installed on your server, and the following must be configured:
    • The Default Web Site that is created by the IIS 7.0 installation must still exist.
    • The Internet Information Services Manager must be installed.
    • At least one authentication method must be installed.

Note: If you choose to use Basic Authentication with the WebDAV redirector, you must connect to your server using HTTPS.

  • The WebDAV Redirector must be installed:
    • You must use Server Manager to install the Desktop Experience feature before you can use the WebDAV redirector.
Downloading the Right Version for Your Server

There are two separate downloadable packages for the new WebDAV extension module; you need to download the appropriate package for your version of Windows Server 2008:

Launching the Installation Package

You must run the installation package as an administrator. This can be accomplished by one of the following methods:

  • Logging in to your server using the actual account named “Administrator”, then browsing to the download pages listed above or double-clicking the download package if you have saved it to your server.
  • Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting “Run as administrator”, then typing the appropriate command listed below for your version of Windows to run the installation:
    • 32-bit Windows Versions:
      • msiexec /i webdav_x86_75.msi
    • 64-bit Windows Versions:
      • msiexec /i webdav_x64_75.msi
Walking Through the Installation Process
  1. When the installation package opens, you see the following screen. If you agree to the license terms, check the “I accept” box, then click Install.
  2. The progress indicator will reflect the status of the installation as it proceeds.
  3. After the installation has completed, click Finish.
  4. The WebDAV extension module is now installed.

Installing WebDAV on IIS 7.5

IIS 7.5 for Windows Server 2008 R2
  1. On the taskbar, click Start, point to Administrative Tools, and then click Server Manager.
  2. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS).
  3. In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services.
  4. On the Select Role Services page of the Add Role Services Wizard, expand Common HTTP Features, select WebDAV Publishing, and then click Next.

  5. On the Confirm Installation Selections page, click Install.
  6. On the Results page, click Close.
IIS 7.5 for Windows 7
  1. On the taskbar, click Start, and then click Control Panel.
  2. In Control Panel, click Programs and Features, and then click Turn Windows Features on or off.
  3. Expand Internet Information Services, then World Wide Web Services, then Common HTTP Features.
  4. Select WebDAV Publishing, and then click OK.

Enabling WebDAV Publishing by Using IIS Manager

The new WebDAV extension module makes it easy to add WebDAV publishing to existing sites by providing you with a wizard that walks you through all of the required steps.

Step 1: Enabling WebDAV and Adding an Authoring Rule

In this first step, we add WebDAV publishing to the Default Web site, and add the required settings to allow the local administrator account to edit the content.

  1. In IIS Manager, in the Connections pane, expand the Sites node in the tree, then click the Default Web Site.
  2. As shown in the image below, double-click the WebDAV Authoring Rules feature.
  3. When the WebDAV Authoring Rules page is displayed, click the Enable WebDAV task in the Actions page.
  4. Once WebDAV has been enabled, click the Add Authoring Rule task in the Actions pane.
  5. When the Add Authoring Rule dialog appears:
    1. Click All content to specify that the rule applies to all content types.
    2. Choose “Specified users” and type “administrator” for the user name.
    3. Select Read, Source, and Write for the permissions.
    4. When you have completed these items, click OK.

Summary

Task completed. You have enabled WebDAV authoring on an existing Web site.

To recap the items that you completed in this step, we added WebDAV publishing to the “Default Web Site” by:

  • Enabling WebDAV for the Web site.
  • Adding an Authoring Rule for the local administrator account for Read, Source, and Write access.

Note: As mentioned earlier, your default request filtering settings may block several file types from WebDAV authoring. If you do not modify your request filtering settings, you may see various errors when you try to publish files that are blocked. For example, if you attempt to upload or download a web.config file you will see errors in your WebDAV client. For more information about configuring your request filtering settings, see the How to Configure WebDAV with Request Filtering walkthrough.

Step 2: Logging in to Your WebDAV Site

In Step 1 above, you enabled WebDAV publishing for your Default Web Site and added an Authoring Rule for the local administrator account for Read, Source, and Write access to your Web site’s content. In this step, you log in using your administrator account.

Ensuring that you have Authorization and Authentication configured

  1. In IIS Manager, in the Connections pane, expand the Sites node in the tree, then click the Default Web Site.
  2. Double-click the Authentication feature.
  3. When the Authentication feature opens, make sure that Windows Authentication is enabled. (Note: You can use Basic Authentication with WebDAV, but the WebDAV redirector will only use Basic authentication with SSL connections.)
  4. In IIS Manager, click the Default Web Site under the Sites node in the tree.
  5. Double-click the Authorization feature.
  6. When the Authorization feature opens, make sure that an Allow rule is defined that includes the administrator account. (For example, the default rule for IIS allowing access to All Users will include the administrator account.)

Logging in to your WebDAV site using your administrator account

  1. On your WebDAV server, open a command prompt session.
  2. Type the following command to connect to your WebDAV server:
    net use * http://localhost/

You now have a drive mapped to your WebDAV-enabled web site using the local administrator account, and based on the authorization rule that we added in Step 1, you have Read, Write, and Source access to the content folder.

Summary

To recap the items that you completed in this step:

  • You verified that your Web site had sufficient Authentication and Authorization settings.
  • You logged in to your WebDAV site as the local administrator.

Enabling WebDAV Publishing by Editing the IIS Configuration Files

You can also add WebDAV publishing to an existing Web site by editing the IIS configuration files.

Note: Editing your applicationHost.config file requires full administrative permissions. This is best accomplished using one of two methods:

  • Log in to your computer using the local “administrator” account.
  • If you are logged in using an account with administrative permissions that is not the local “administrator” account, open Notepad using the “Run as Administrator” option.

Note: The above steps are required because the User Account Control (UAC) security component in Windows Server 2008 will prevent access to your applicationHost.config file. For more information about UAC, please see the following documentation:

The following steps will walk you through all of the required settings to add WebDAV publishing for the Default Web Site.

  1. Using a text editor such as Windows Notepad, open your applicationHost.config file, which is located in your %SystemRoot%\System32\inetsrv\config folder by default.
  2. Scroll to the bottom of your applicationHost.config file and locate the <location> section for your Default Web Site that contains your authentication settings. If this section does not exist, you must add it. This should resemble the following example:
    <location path=”Default Web Site”>
    <system.webServer>
    <security>
    <authentication>
    <anonymousAuthentication enabled=”true” />
    <basicAuthentication enabled=”false” />
    <digestAuthentication enabled=”false” />
    <windowsAuthentication enabled=”true” />
    </authentication>
    </security>
    </system.webServer>
    </location>
  3. Make sure that you have Windows authentication method enabled.
  4. Add a <webdav> section beneath the closing </authentication> tag that will contain your WebDAV settings.
  5. Add an <authoring enabled=”true” /> element to the <webdav> element
  6. And add and <authoringRules> collection with a single entry for <add users=”administrator” path=”*” access=”Read, Write, Source” />.
  7. Your Default Web Site’s settings should now resemble the following example:
    <location path=”Default Web Site”>
    <system.webServer>
    <security>
    <authentication>
    <windowsAuthentication enabled=”true” />
    <anonymousAuthentication enabled=”false” />
    <digestAuthentication enabled=”false” />
    <basicAuthentication enabled=”false” />
    </authentication>
    </security>
    <webdav>
    <authoring enabled=”true” />
    <authoringRules>
    <add users=”administrator” path=”*”
    access=”Read, Write, Source” />
    </authoringRules>
    </webdav>
    </system.webServer>
    </location>
  8. Save your applicationHost.config file.

You should now be able to log in to your WebDAV-enabled site using a WebDAV client using the administrator account, but no other users should be able to access the content using WebDAV.

Summary

In this task you added WebDAV publishing to your Default Web Site by editing the IIS configuration files. To recap the items that you completed in this task:

  1. You enabled Windows Authentication for the Default Web Site.
  2. You enabled WebDAV for the Default Web Site.
  3. You added a WebDAV authoring rule for the administrator account with Read, Write, and Source access the Default Web Site.

1 máy PC đã join domain sau khi đăng nhập máy bằng Ctrl + Alt + Delete thì truy cập vào website trong mạng Intranet IIS 7.x theo kiểu Windows Authenticate sẽ phải tự động truy cập vào được bằng Domain User ?


Vấn đề 1: 1 máy PC đã join domain sau khi đăng nhập máy bằng Ctrl + Alt + Delete thì truy cập vào website trong mạng Intranet IIS 7.x theo kiểu Windows Authenticate sẽ phải tự động truy cập vào được bằng Domain User ?

Vấn đề 2: Máy chủ hosting website đó là IIS7.5 / Windows Server 2008 R2 SP1. Máy chủ chạy website ASP.NET có cả SharePoint 2007 vậy khi triển khai gói MS Live@edu SSO Kit thì cấu hình SSO như thế nào để máy PC trong Domain Local (đang join domain) sẽ có thể truy cập tự động (không hỏi user/password) khi truy cập site:SSO ?

Hãy tham khảo bài viết dưới đây:

IIS and Kerberos. Part 1 – What is Kerberos and how does it work?

Edit: I’ve created a list of all the parts in this series here, which will be updated as I add more parts.

Configuring Kerberos and Delegation is one of the more common problems I see in the communities and even within Avanade. Since Kerberos isn’t a simple topic, I’m going to write a quick series explaining how Kerberos works, common scenarios and problems and some troubleshooting tips.

Kerberos is an open authentication protocol developed at MIT, and implemented in Windows 2000/2003 Active Directory domains (amongst other places). Authentication is the process of proving your identity to a remote system. Your identity is who you are, and authentication is the process of proving that. In many systems your identity is your username, and you use a secret shared between you and the remote system (a password) to prove that your identity.

The problem with simplistic shared secret systems is two-fold:
a) there is a scalability problem. If every user needs to maintain a shared secret with every individual server (or every service on every server!) then that results in poor passwords. Users can not be expected to remember dozens, hundreds or thousands of unique passwords and so end up repeating them regardless of whether the server is a low security or high security resource
b) there is an issue in securely transmitting the shared secret from the user to the server. Various technologies (like TLS/SSL) exist for securing the transport of data between machines, however it is incumbent upon each service to utilise services lower down in the network stack.

Kerberos is designed to overcome these limitations. In this part we look at how a simple Kerberos implementation works. In this scenario we have a user using a client machine that wishes to connect to a remote service (the user here is a person or application, the client is the OS or machine). Remember that we want a system that allows us to store shared secrets centrally, and to securely transmit user credentials between client and service. Lastly we should look to prevent replay attacks (where someone who is sniffing the wire can replay captured packets to impersonate a legitimate user, even if they do not know how to create the authentication packets themselves).

To begin with we introduce the Kerberos KDC – Key Distribution Centre. In the Windows Active Directory world, the KDC lives on Domain Controllers (DCs). The client connects to the Authorisation Service (AS) that runs on the KDC and asks the AS to authenticate the user to the remote service. Technically, the client doesn’t need to authenticate itself to the Domain Controller. However in the Active Directory world, something called pre-authentication is used to ensure that the user (or client application) is actually who they say they are.

Simple Kerberos implementation

The AS on the KDC generates a session key that will be used by the client and the remote service. It encrypts the session key with the user’s password (this is why the user doesn’t need to authenticate – if the user isn’t who they say they are, they won’t be able to decrypt the session key because they don’t know the user’s password). The KDC also prepares a second piece of data – it again encrypts the session key as well as the user’s username (known as a Kerberos principal), but using the service’s password this time to encrypt the data. Only the remote service will be able to decrypt this second piece of data. This second piece of data is known as the Service Ticket (or just Ticket).

The KDC now sends both pieces of data back to the client. The user, knowing their own password, is able to decrypt the first piece of data, and extract the session key. The user however does not know the service’s password, so is unable to decrypt the second piece of data. The client uses the session key to encrypt the current time (amongst other things, but they aren’t so important right now). This piece of data is known as the Authenticator. The client sends the Authenticator it just generated, along with the Service Ticket received from the KDC to the remote service.

The remote service is able to decrypt the Service Ticket using its own password. It is thus able to get access to the session key, and the Principal (user) attempting to connect. It now uses the session key to decrypt the Authenticator, and extract the time. It compares the time to the current system time on the server to ensure a match. Since only the service, the KDC and the user, know the session key then the service can assume that user must be who they say they are.

If an imposter sent a Service Ticket to the service (e.g. by replaying captured packets) they wouldn’t know the correct session key necessary to encrypt the timestamp correctly. Alternatively, if the imposter attempts to use captured Authenticator packets (which contain a timestamp), thus bypassing the need to know the session key, then the times will not match when the Authenticator is decrypted by the service and the service will refuse to authenticate the remote user.

If this was the extent of the Kerberos, then each and every time the client received an encrypted session key from the KDC, the user would need to enter their password to allow the client machine access to it. That could rapidly become a productivity sinkhole (imagine having to enter your password for each and every HTTP request you made!). To get around this, the client machine could cache the user’s password, but that isn’t a particulary secure system. What Kerberos does is introduce the concept of a Ticket Granting Ticket (TGT).

Ticket Granting Tickets are issued by the AS running on the KDC in the same way that a normal service ticket is issued. However the TGT is valid for the Ticket Granting Service, rather than a remote HTTP server (or any other type of server). Whenever the user wishes to connect to a remote service, it can use the TGT that it has already received to connect to the TGS. The TGS, after authenticating the user via the TGT, issues a Service Ticket to the remote service. However instead of encrypting anything using the user’s password, it encrypts using the session key originally generated by the AS. Since the client machine aleady knows this from when the TGT was received in the first place, there is no need to bother the user for their password. The TGT typically has a short lifespan – around 8 hours or so.

IIS and Kerberos. Part 2 – Service Principal Names

Apologies for the delay in posting Part 2 – I’ve been on holidays so it’s been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs).

In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn’t cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?

In an Active Directory domain, all computer and user objects have a password. This password is used as the basis of the shared secret between the AS and the remote service. If the remote service is running under an inbuilt principal such as LocalSystem or Network Service then the computer account’s password is used as the basis of the shared secret. If the remote service is running under a custom user account, then the user account’s password is used as the basis of the shared secret.

So how does the AS know which user or computer account’s password should be used? When a user wishes to connect to a remote service, it tells the Domain Controller what Kerberos service it wishes to connect to. The AS searches through Active Directory to find a matching Service Principal Name (SPN). SPNs are attributes of user and computer objects in the directory. For example, for the computer w03-svr-sql we can see the following SPNs (using ADSIEdit):

Service Principal Name (SPN)

Service Principal Names (SPN)

SPNs can be viewed, added and removed using a GUI tool like ADSIEdit, or you can do the same using a command line tool such as SetSPN (part of the Windows 2000 Resource Kit).

Using SetSPN

Generally, when installing a product such as SQL Server or IIS that supports Kerberos, SPNs are registered for you for the accounts that those products are configured to use. However you later change the user account that the services are running under, you may need to set a new SPN for that Kerberos authentication continues working.

This method of determining the shared secret to be used between the AS and remote service raising a couple of gotchas which can break Kerberos Authentication:

1) The missing SPN
When installing IIS (and a lot of other common services) the installer will register a set of default SPNs in the Directory. However if you change the way that your service runs after installation, you may need to update the SPNs that are registered.

For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server’s computer account in Active Directory. These SPNs will allow Kerberos authentication to work when using the following built-in service principles: LocalSystem, Network Service or Local Service as the identity for your worker processes.

However if you change the process identity of your web application pool, and assign its worker process a custom domain user acccount as a process identity, then you will need to create SPNs for servername and servername.domain.tld under this custom user account. This allows the KDC to encrypt the service ticket with the password of the user account rather than the computer account.

2) The duplicate SPN
In the event that an SPN for the same service is registered under multiple accounts in Active Directory (e.g. under a computer account and a user account), then the KDC will not know which password should be used to encrypt the service ticket, and Kerberos Authentication will fail.

In the above scenario, once you change the identity of your web application pool, and add the new SPNs for servername and servername.domain.tld, you may need to remove the existing SPNs from under the computer account. Likewise, if you change the process identity from one user account, to another user account, you would most likely need to remove the SPNs from the first user account, and add them to the second user account.

3) Load-balanced IIS solutions
In this situation, the user’s request might be routed to either of the two (or more) nodes in your cluster. In this case, you can not run your web application pools under an inbuilt principal (such as Network Service), because the KDC can not know which computer account’s password should be used (it does not know which node in the cluster the request will be routed to). In this situation you must use a common domain user account as the process identity of your worker processes.

4) Multiple web applications hosted at a single domain name
Because SPNs are organised by name (either NetBIOS or fully qualified domain name), all web applications hosted at that domain name must be running in worker processes utilising the same, common, identity. This is so that the KDC can generate a service ticket using that identity, no matter what web application is being accessed at the FQDN. You can still run the web applications in separate web application pools, but each pool must be running under the same, common, identity.

IIS and Kerberos. Part 3 – A simple scenario

In Part 3 of this series we look at setting up Kerberos Authentication in the simplest possible scenario. If you missed Parts 1 (What is Kerberos and how does it work) and 2 (Service Principal Names) they may be worth reading first. In this scenario, we have a client, a DC and a single IIS server. As we progress through the series, we will progressively add more elements into the mix.

In this very simplistic example a client wishes to authenticate to a website hosted on the webserver. The sequence of events is illustrated in the diagram:

IIS and Kerberos - a simple scenario

1) The client makes a HTTP Request
2) The server denies the request with a 401 Authorization Required. It includes the WWW-Authenticate: Negotiate header and/or the WWW-Authenticate: Kerberos header indicating that it supports Kerberos authentication
3) The client requests a Service Ticket from the KDC hosted on the Domain Controller
4) The Domain Controller returns the Service Ticket
5) The Client generates the Authenticator, and sends this plus the Service Ticket in a new HTTP request to the web server
6) The webserver determines the identity of the client, checks the ACL on the resource and either permits or denies access to the resource.

In order for this sequence of events to work the following need to be configured.

The Browser
For Internet Explorer to use Kerberos to authenticate to IIS the following must be configured correctly:

  1. Under Tools -> Internet Options -> Advanced the option “Enable Integrated Windows Authentication (Requires Restart)” must be checked. Whilst technically IWA encompasses both NTLm and Kerberos, IE will use NTLM only if this option is not checked whilst it can use both Kerberos or NTLM if this option is checked.
  2. The website you are connecting to must be located in the “Intranet” Security zone. You can see what zone IE thinks the website is in by looking at the icon in the bottom right-hand side of IE’s status bar. If the website is located in the “Internet” zone, IE will not even attempt Kerberos authentication. This is because, in most Internet scenarios, a connection with a domain controller can not be established. The simple rule is that any website that contains full stops (periods for Americans) such as an IP address or Fully Qualified Domain Name (FQDN) is in the Internet zone. If you are connecting to an IP address or FQDN then use IE’s settings or Group Policy to add this site to the Intranet security zone. For more information on how IE determines what zone the website is in please see KB 258063

The Domain Controller
For the Domain Controller to generate the appropriate tickets to give to the client an appropriate Service Principal Name (SPN) must be registered in Active Directory. When a Windows Server 2003 machine is added to a domain, a HOST SPN for both the NetBIOS name and the FQDN of the server is automatically added to Active Directory. If your website is accessible at http://servername or http://servername.domain.tld (tld = Top Level Domain, such .com or .local) and the web application pool is running as Network Service, Local Service or Local System, you do not need to change any SPNs.

If the web application pool hosting the site is running under a custom account, the SPN HTTP/servername or HTTP/servername.domain.tld needs to be registered under that custom user account. If those HTTP SPNs exist under any other account, they need to be removed.

And lastly, if the website is accessible at an arbitrary hostname that is unrelated to the actual server’s name (e.g. http://www.domain.tld) then a SPN needs to be registered for that hostname. If the web application pool hosting the website is running as Network Service, Local Service or LocalSystem, then the SPN needs to be registered under the server’s computer account. If the web app pool is running under a custom user account, then the SPN needs to be registered under that user account in Active Directory.

SPNs can be added using a GUI-based tool such as ADSIEdit. Or can be added programmatically using an interface to AD (such as ADSI), or can be added using the SetSPN.exe command line tool (SetSPN is discussed in Part 2 of IIS and Kerberos listed earlier). To add an SPN using SetSPN for:

  1. a servername under a custom user account:
    setspn –A HTTP/servername Domain\Username
  2. an arbitrary hostname under a computer account:
    setspn –A HTTP/hostname.domain.tld Domain\MachineName
  3. an arbitrary hostname under a custom user account:
    setspn –A HTTP/hostname.domain.tld Domain\UserName

The IIS Server
There isn’t a lot to configure on the IIS Server. Firstly Integrated Windows Authentication (IWA) should be enabled for the website or application you are seeking to protect. By default this enabled both the Negotiate and NTLM Authentication Providers in the IIS metabase. If you have edited the metabase to remove the Negotiate provider, you will need to add it back in. The installation of some products (e.g. Sharepoint Portal Server 2001) removes the Negotiate provider – you may need to manually add it back in. See Microsoft KB Article 832769 for your options.

Secondly, all web applications hosted at the DNS name in question need to be running in one or more web application pools that are all running under the same user account. It’s easiest if all the web applications at that DNS name are running in a single web app pool. However if you do need to split web applications into multiple pools, those pools need to be running under the same user account.

Summary
And that should be all that is required for your Internet Explorer browser to authenticate to IIS using Kerberos. To verify whether this is occuring, you can use the tools described in my previous post on determining whether the browser is using NTLM or Kerberos to authenticate to IIS.