Category Archives: Active Directory

Cách cấu hình đăng nhập 1 lần SSO giữa AD Server với vCenter 6.0 (Platform Service Controller– PSC)


 

Platform Service Controller– PSC là một thành phần dịch vụ mới trên vCenter 6.0 PSC có chứa tất cả các dịch vụ mà vCenter cần cho các chức năng của nó bao gồm Single Sign-On (SSO). Tôi xin mô tả làm thế nào để cấu hình xác thực AD trong vCenter Server 6.0.

Một số yêu cầu trước khi cấu hình SSO:

1. Chỉ dùng Web Sphere client để cấu hình SSO cho vCenter Server Appliance

2. Phải cấu hình NTP time để đồng bộ giữa ESXi Host 6 với NTP server local hoặc NTP Global thông qua internet.

3. Phải cấu hình các bản ghi A (host), PTR IP cho máy chủ vCenter 6.0 trên máy chủ AD – DNS Server trước khi cài vCenter Server Appliance 6 và tất nhiên là trước khi cấu hình SSO trên Web sphere client.

4. Lưu ý: vCenter Server Appliance 6.0 bắt buộc phải được cài và cấu hình trên ESXi host x64bit hoặc ESXi Host Nested x64 bit.

5. (Tùy chọn) cấu hình Join domain giữa ESXi Host 6 với AD Server thông qua Windows Authenticate (mục đích chính: kiểm tra khả năng cấu hình chính xác về mạng ảo lớp Management Nework layer).

 

Tham khảo link:

Phần 4: Triển khai đăng nhập 1 lần SSO giữa AD và VMware vCenter Appliance 5.5
Phần 5: Triển khai đăng nhập 1 lần SSO giữa AD-DS và VMware vCenter Appliance 5.5

Một số lưu ý tránh nhầm lẫn:

1. Hệ thống vCenter 5.x hoặc 6.x đều có 3 nhóm Domain quản lý các users với quyền và chức năng khác nhau:

1.1. Nhóm 1: localos (đây là nhóm users dùng quản lý HĐH của VMware, ngầm định có user: root)

– có chức năng chính dùng làm triển khai các tính năng cơ bản của ESXi hoặc vCenter, console, management network, bật /tắt ESXi Shell, SSH hoặc SSH Bash

không có quyền cấu hình SSO vcenter.

1.2.Nhóm 2: vCenter Single Sign-On users(đây là nhóm được tạo ra trong quá trình cài vCenter)

– có chức năng Administrators, quản trị tất cả nguồn tài nguyên và cấu hình vCenter SSO.

– vCenter 5.x nhóm 2 có domain name luôn là vsphere.local.

– vCenter 6.x nhóm 2 có domain name gợi ý là vsphere.local, các bạn có thể thay nó thành các tên miền của Doanh nghiệp, tổ chức, phòng ban, homelab (lưu ý: nó sẽ dùng làm từ ghép trong account để đăng nhập Web sphere client, ví dụ:  administrator@sso.vcenter)

– vCenter 6.x có thêm site name: bạn có thể nhập tên đơn vị hoặc vị trí địa lý đang hosting/vận hành hệ thống vcenter để phân biệt khi Doanh nghiệp của bạn có nhiều hệ thống vcenter khác nhau.

1.3.Nhóm 3: Users Authentication (đây là nhóm được tạo ra khi cấu hình join domain giữa vCenter với AD hoặc cấu hình kết nối LDAP/OpenLDAP với vCenter)

– có 3 phương pháp kết nối:

1.3.1.  Active Directory (Integrated Windows Authentication):

– Phương án này áp dụng từ AD server phiên bản Windows 2003 trở lên (chỉ áp dụng với hệ thống quản lý người dùng bằng WIndows Server có AD, DC).

1.3.2. Active Directory as an LDAP Server:

– Phương án này áp dụng cho AD server có mở dịch vụ, cổng LDAP TCP/IP 389 trên firewall.

1.3.3. OpenLDAP:

– Phương án này áp dụng cho các hệ thống có mở dịch vụ kết nối người dùng dạng open source, google, facebook…

 image

Các bước cấu hình SSO:

Bước 1. Mở Web Sphere client https://ip-vcenter :

Đăng nhập bằng Account: administrator@vsphere.local

image

Bước 2. Chọn menu Administration:

image

Chọn mục Configuration:

image

Bước 3. Mở tab Identity Sources:

image

Bấm vào dấu cộng màu xanh để khai báo kết nối hệ thống quản lý người dùng (LDAP)

Bước 4. chọn nguồn xác thực kiểu tích hợp Windows Authentication

Trường hợp đã join domain giữa máy chủ vCenter và AD chúng ta có thể nhận được tên domain name của AD server.

image

Trường hợp chưa join domain giữa máy chủ vCenter và AD chúng ta sẽ nhận cảnh báo lỗi:

image

Hãy bấm “Go to Active Directory Management”

image

Sau khi join domain thành công, bạn sẽ cần phải khởi động lại node > vCenter

image

Chọn System Configuration

image

Chọn Nodes> bấm chuột trái chọn tiếp tên máy chủ vCenter

image

Bấm mũi tên trỏ xuống ở mục Actions > Chọn menu bar” Reboot…

Chúng ta sẽ đợi trong vòng 5 – 10 phút cho tới khi vCenter khởi động trở lại. Ta tiếp tục quay lại bước 4 để cấu hình kết nối xác thực giữa vCenter và AD.

Bước 5. Quay lại phần Identity Sources bạn sẽ cần tạo thông tin liên quan tới cách kết nối giữa vCenter với AD để lấy được các users và groups từ active directory. Khi bạn kết nối kiểu Integrated Windows Authentication, thì các trusted domains phải có giá trị hoạt động. 

Bước 6. Chọn Active Directory và bấm vào “world with arrow” để chuyển trạng thái đăng nhập ngầm định là các tài khoản từ AD domain.

image

Bạn sẽ nhận được một cảnh báo cho bạn biết rằng “Điều này sẽ làm thay đổi tên miền mặc định hiện tại của bạn. Bạn có muốn tiếp tục? “. Điều này là không sao, vì bạn chỉ có thể có một tên miền mặc định.

 

Bước 7.Thêm user và phân quyền:

Để thay đổi cấu hình vCenter Server SSO với người dùng khác ngoài administrator@vsphere.local, bạn phải thêm chúng vào Nhóm LocalOS hoặc vSphere.local hoặc Nhóm thuộc Domain do bạn vừa cấu hình

image

Bước 8. Thêm các tài khoản lấy từ AD sang để phân quyền theo users/ group:

image

 

Cơ chế phân quyền:

Bước 1. Tạo User/ Group làm thành viên trong Nhóm 2: vCenter Single Sign-On users(đây là nhóm được tạo ra trong quá trình cài vCenter)

Bước 2. Tạo/sửa/clone quyền “Roles”

Bước 3. Điều chỉnh các hành động “privileges” trong quyền “Roles”

Bước 4. Xác định các Objects sẽ được gán quyền.

 image

 

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

created a adm file for HideNetworkInExplorer


; Use this one for hiding the network icon in your explorer.

CLASS MACHINE

CATEGORY !!Custom

CATEGORY !!ExplorerExtras

POLICY !!HideNetworkInExplorer
KEYNAME “SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\NonEnum”
EXPLAIN !!HideNetworkInExplorer_Help
VALUENAME “{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}”
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY

END CATEGORY

END CATEGORY

[strings]
Custom=”Custom Policies”
ExplorerExtras=”Windows Explorer Extra’s”
HideNetworkInExplorer=”Hide Network Icon in Explorer 2008/Vista”
HideNetworkInExplorer_Help=”Enable this one to hide the icon, disable or unconfigure to show it…”

Phần chưa được công bố: Các bạn đã chuẩn bị gì cho kế hoạch nâng cấp domain controller windows 2003 khi ngày End of Support đang đến gần ?


Hiện tại trên thị trường Doanh nghiệp đang sử dụng rất nhiều các máy chủ chạy Domain Controller bằng windows 2000, Windows 2003 Standard…

Việc Microsoft chuẩn bị đếm lùi ngày kết thúc hỗ trợ các bản vá lỗi cho Windows 2003 thật sự là điều rủi ro cao cho các Doanh nghiệp, tổ chức vẫn tiếp tục sử dụng windows server 2000/ 2003 làm hệ thống

Domain Controller cho tổ chức của mình.

Đặt vấn đề:

Để chuẩn bị cho các công việc nâng cấp, hoặc chuyển đổi hệ thống Domain Controller sang hạ tầng hoặc version cao hơn là điều vô cùng cần thiết lúc này.

Tôi xin giới thiệu một số tình huống xử lý sự cố từ domain controller windows 2003 để các bạn tham khảo và lường trước khó khăn:

  1. Tình huống sử dụng Domain controller phổ biến trong Doanh nghiệp là có ít nhất 2 –3 con Domain controller chạy Duplicate hoặc deligated nhằm backup/restore hoặc cluster Domain.
  2. Sau thời gian dài sử dụng thì các máy chủ này có vấn đề về phần mềm hoặc phần cứng dẫn tới một trong 2 máy chủ Domain controller bị lỗi / hỏng ngừng hoạt động.
  3. Có rất nhiều System Administrator hỏi tôi về việc nếu cứ để hệ thống đó chạy như vậy có sao không ? hoặc làm thế nào để xóa những máy domain controller bị lỗi đúng cách ?

Dựng Mô hình hệ thống Domain controller 2003:

– Mở phần mềm Active Direcoty Sites and Services:

image

 

– Mở phần mềm Active Direcoty Users and Computers:

image

Chú ý: Điều này chỉ được thực hiện nếu một DC đã lỗi không bao giờ hoạt động trở lại.

Biện pháp xử lý: gỡ bỏ các máy chủ Domain Controller bị lỗi:

  • Từ máy chủ Domain Controller đang hoạt động, mở một cửa sổ cmd (bấm START > RUN gõ CMD) và gõ các lệnh chính xác như hiển thị dưới đây.
  • Thay thế các từ bên trong dấu ngoặc nhọn (<>) với tên của các máy chủ phải được loại bỏ, thực hiện theo từng dòng  lệnh sau mỗi dấu :
  1. Ntdsutil
  2. Metadata cleanup
  3. Connections
  4. Connect to server  <nhập tên máy chủ đang hoạt động bình thường thuộc nhóm Primary Domain (không phải là máy chủ Domain Controller bị lỗi)>
  5. QUIT
  6. Select operation target
  7. List domains
  8. Select domain 0
  9. List sites
  10. Select site 0
  11. List servers in site
  12. Select server  <nhập số thứ tự tương ứng với tên của Chủ bị lỗi >
  13. Quit
  14. Remove selected server

ví dụ:

image

ví dụ:

image

Sau khi gõ lệnh cuối cùng để xóa máy chủ Domain controller bị lỗi, bạn sẽ thấy một hộp thoại với thông điệp sau:

“Are you sure you want to remove the server object
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx? This is not the last server for domain xxxxxxxxxxxxxx”

(Các xxx là thông tin liên quan tới máy chủ và tên miền bạn đã chọn bằng lệnh ở trên)

Hãy đọc kỹ thông báo trước khi bấm vào YES nếu bạn chắc chắn đã chọn đúng máy chủ bị lỗi và cần xóa.

image

Lệnh xóa máy chủ Domain Controller bị lỗi được thực thi:

image

 

Các bạn có thể lặp lại việc xóa các domain controller bị lỗi khác tương tự.

 

Để kết thúc:

• Bạn mở  Active Directory Sites and Services và loại bỏ các đối tượng máy chủ đã bị xóa

image

 

• Tiếp tục mở Active Directory Users and Computers và loại bỏ các đối tượng máy chủ bị xóa (nếu vẫn còn hiện hữu)

image

 

• Tiếp tục mở DNS Server và loại bỏ các hồ sơ đối tượng máy chủ bị xóa

image

 

Tóm lại, sau khi xóa xong các máy chủ Domain Controller windows 2003 bị lỗi,

Bạn hoàn toàn dễ dàng nâng cấp Domain Controller lên windows 2008, R2 Enterprise hoăc windows 2012.

ví dụ: nâng cấp từ Forest Level 2000 lên 2003 thành công sau khi xóa hết các máy chủ domain controller lỗi.

image

 

P.S: Những nội dung xử lý troubleshoot kỹ thuật trên càng ngày càng rắc rối,

các bạn nên đăng ký tham gia các khóa học của ROBUSTA để được luyện tập, trải nghiệm qua các khóa học

và phương pháp học thực hành chuyên sâu.

vững Trí vững Nghề !

Phần 7: cấu hình giao thức LDAPS cho việc Change password của AD từ các hệ thống VPN / SharePoint / .Net / PHP / Apache dùng SSL/TLS


1. Tại sao lại cần SSL/TLS cho LDAP (port default: 389):

Theo mặc định, truyền thông LDAP giữa máy chủ AD và máy chủ ứng dụng không được mã hóa. Thiết bị hoặc phần mềm và xem các thông tin liên lạc đi lại giữa client và máy tính LDAP server.

Điều này đặc biệt có vấn đề khi một LDAP đơn giản được sử dụng bởi vì các thông tin (tên người dùng và mật khẩu) được truyền tải qua mạng được mã hóa, thậm trí có nhu cầu thay đổi mật khẩu.

Lưu ý: chỉ LDAP chuyển dữ liệu được tiếp xúc. Xác nhận hoặc ủy quyền dữ liệu khác sử dụng Kerberos, SASL, và thậm chí NTLM có hệ thống mã hóa.

Tham khảo: Windows 2000 SP4 sử dụng LDAP  hoặc

chứng thực đơn giản theo chuẩn Layer (SASL)

bản sao giữa các domain controller được mã hóa bằng cách sử dụng Kerberos .

Lý do cho phép Lightweight Directory Access Protocol (LDAP) trên Secure Sockets Layer (SSL) / Transport Layer Security (TLS) cũng được gọi là LDAPS bao gồm:

  • Một số ứng dụng xác thực với Active Directory Domain Services (AD DS) thông qua BIND đơn giản. Như BIND đơn giản cho thấy nhiều thông tin quan trọng của người sử dụng trong văn bản rõ ràng, sử dụng Kerberos được ưa thích. Nếu BIND đơn giản là cần thiết, sử dụng SSL / TLS để mã hóa các phiên xác thực được khuyến khích mạnh mẽ.
  • Sử dụng các ràng buộc proxy hoặc thay đổi mật khẩu trên LDAP, mà đòi hỏi LDAPS. (Ví dụ: Bind một AD LDS instance Thông qua một đối tượng Proxy )
  • Một số ứng dụng tích hợp với các máy chủ LDAP (như Active Directory hoặc Active Directory Domain Controller) yêu cầu thông tin liên lạc được mã hóa. Để mã hóa truyền thông LDAP trong một mạng Windows, bạn có thể bật LDAP trên SSL (LDAPS).

Cảnh báo Trước khi bạn cài đặt một hệ thống cấp chứng nhận (CA Server), bạn nên biết rằng bạn đang tạo hoặc mở rộng một cơ sở hạ tầng khóa công khai (PKI). Hãy chắc chắn để thiết kế một PKI đó là thích hợp cho tổ chức của bạn. Xem PKI Thiết kế Tổng quan Giới thiệu tóm tắt để biết thêm thông tin.

 

1.1. Việc kích hoạt LDAPS cho domain controller sử dụng một hệ thống phân cấp CA single-tier:
1.2. Việc kích hoạt LDAPS cho domain controller sử dụng một hệ thống phân cấp CA multi-tier:

Khi bạn có một-đa lớp (chẳng hạn như một hai tầng, ba tầng) CA ​​phân cấp, bạn sẽ không tự động có các chứng chỉ thích hợp để xác thực LDAPS trên Domain Controller. Để kích hoạt LDAPS trong một hệ thống phân cấp CA multi-tier, bạn phải yêu cầu một giấy chứng nhận đáp ứng các yêu cầu sau:

 

2. Cách cấu hình LDAPS (default port: 636)

  1. Trên máy chủ AD cần mở Certification Authority, mở Certificates console hoặc certsrv console. Để mở certsrv, bấm Start > certsrv.msc và sau đó nhấp OK .
  2. Đảm bảo rằng Certification Authority.
  3. Kích chuột phải vào Certificate Templates > Manage.

image

4.  Trong Certificate Templates control, nhấp chuột phải Domain Controller Authentication và sau đó chọn Duplicate Template . Bạn không cần phải sử dụng các mẫu Kerberos. Bạn có thể tạo riêng của bạn hoặc sử dụng một trong những mẫu hiện có Server Authentication như một Target, chẳng hạn như Domain Controller Authentication, Domain Controller , Web Server , và Computer .

Quan trọng: Bạn nên kế hoạch trên có giấy chứng nhận trên mỗi máy chủ LDAP (tức là Domain controller hoặc AD LDS server) với target: Server Authentication . image

5. Trên Duplicate Template , để mặc định chọn Windows Server 2003 Enterprise chọn và sau đó nhấn OK .

6. Các thuộc tính của New Template xuất hiện. Đảm bảo rằng các thiết lập như bạn muốn họ được cho mẫu chứng chỉ này. Hãy chú ý để đảm bảo rằng các tên Template hiển thị được thiết lập để một cái tên thích hợp cùng với các cài đặt sau:

  • Thời gian hiệu lực và gia hạn được quy định theo chính sách bảo mật của tổ chức.
  • Chiều dài khóa phù hợp.
  • Chọn nếu bạn muốn đặt chứng chỉ trong Active Directory.
  • Tên tab Subject: Tên DNS và Dịch vụ tên chính (SPN) được lựa chọn.
  • Nếu bạn có kế hoạch để nhập chứng chỉ vào lưu trữ chứng chỉ Active Directory Domain Services, sau đó cũng nên đánh dấu các khóa riêng như xuất khẩu.

image

 

image

 

7.  Nhấn OK .

8. Quay trở lại Giấy chứng nhận hoặc certsrv console và trong panel chi tiết của Certificate Templates , kích chuột phải vào một khu vực mở của giao diện, kích New , và sau đó nhấp vào Certificate Template để export

image

image

image

image

 

3. Yêu cầu một chứng chỉ cho Server Authentication

Để yêu cầu một chứng chỉ từ máy chủ LDAPS của bạn, hãy làm như sau trên mỗi Domain Controller đòi hỏi kết nối LDAPS:

  1. Mở Certificates console. Bấm vào Bắt đầu , loại MMC , và sau đó nhấn ENTER. Nếu được nhắc nhở bởi User Account Control, đảm bảo nó sẽ hiển thị các hành động mà bạn muốn và sau đó bấm Yes .
  2. Trong giao diện điều khiển MMC được mở ra (thường Console1), nhấp vào file và sau đó nhấp vào Add / Remove Snap-in.
  3. Trong Add or Remove Snap-ins dưới Snap-ins , nhấp Certificates, và sau đó nhấp vào Add.
  4. Trong Certificates snap-in , chọn Computer Account và sau đó nhấp vào Next.
  5. Trong Select Computer , nếu bạn đang quản lý các máy chủ LDAP yêu cầu chứng chỉ, chọn Local . Nếu không, hãy chọn Another Computer và nhấn Browse để xác định vị trí máy chủ LDAP yêu cầu giấy chứng nhận.
  6. Một khi bạn có máy tính đúng được chọn, nhấn OK và sau đó nhấp vào Finish.
  7. Trong Add or Remove Snap-in , click OK .
  8. Trong cây giao diện điều khiển, mở rộng Certificates (<Computer>).
  9. kích chuột phải vào Certificates , nhấn All Tasks , và sau đó nhấp vào Yêu cầu chứng chỉ mới .

image

image

image

 

image

image

image

 

image

10.  Trong Certificate Enrollment , bấm Next.

11.  Trong Select Certificate Types, thông thường bạn sẽ để mặc định của Active Directory Enrollment Policy . Nếu bạn có một chính sách khác nhau mà bạn nên làm theo, sau đó chọn một trong đó và nhấp vào Next.

12.  Chọn một chứng chỉ cho phép để xác thực server, Kerberos làm việc, nhưng bạn có thể sử dụng chứng chỉ tùy chỉnh như mô tả trong Công bố Giấy chứng nhận rằng Hỗ trợ Server Authentication. Nhấn vào Enroll .

image

image

 

image

image

image

 

image

(1.3.6.1.5.5.7.3.1) .

Đối với từng bước ví dụ khác yêu cầu một chứng chỉ để xác thực máy chủ và thực hiện LDAP trên SSL (LDAPS), xem các bài viết sau đây:

 
4. Các dịch vụ Active Directory Domain Certificate lưu trữ 

Khi một chứng chỉ được lựa chọn từ các máy tính local (như trong CertEnumCertificatesInStore ) Giấy chứng nhận hợp lệ đầu tiên mà có thể được sử dụng để xác thực máy chủ (OID: 1.3.6.1.5.5.7.3.1) được trả về để sử dụng. Trong trường hợp khách hàng có nhiều giấy chứng nhận hợp lệ cho Server Authentication trong (ví dụ như các máy chủ LDAP của AD DS bộ điều khiển miền , AD LDS , hoặc ADAM server) lưu trữ chứng chỉ máy tính local, có thể thấy rằng một chứng chỉ khác so với cái mà họ muốn được sử dụng cho LDAPS.

Độ mã hóa tốt nhất cho một vấn đề như vậy là để loại bỏ tất cả các chứng chỉ không cần thiết từ các máy tính local chứng nhận và chỉ có một giấy chứng nhận là hợp lệ để xác thực máy chủ. Tuy nhiên, nếu có một lý do chính đáng mà hai hay nhiều chứng chỉ của một máy khách sử dụng ít nhất Windows Server 2008 máy chủ,  máy chủ LDAP, Directory Domain Services (NTDS \ Personal) lưu trữ chứng chỉ mới có thể được sử dụng cho giao thức LDAPS .

Chú ý: Có một số chi tiết quan trọng cần biết trước khi bạn thực hiện việc sử dụng của các kho lưu trữ chứng thực Active Directory Domain Services (AD DS):

  1. Giấy chứng nhận đăng ký tự động (auto-enroll) không thể được sử dụng với các chứng chỉ trong kho chứng chỉ cá nhân NTDS \.
  2. Các công cụ dòng lệnh hiện hành không cho phép quản lý giấy chứng nhận lưu trữ chứng chỉ cá nhân NTDS \.
  3. Chứng chỉ nên được nhập khẩu vào các cửa hàng, và không di chuyển (bằng cách kéo và thả) thông qua giao diện điều khiển Certificates (MMC)
  4. Mỗi máy chủ LDAP sẽ yêu cầu giấy chứng nhận của riêng mình để sử dụng tùy chọn này, nhưng nó chỉ là cần thiết để sử dụng tùy chọn này trên một máy chủ có nhiều chứng chỉ với mục đích Server Authentication trong Giấy chứng nhận cửa hàng địa phương. Giải pháp tốt nhất là để chỉ có một giấy chứng nhận trong giấy chứng nhận cá nhân của máy tính.

 

Lưu ý: Các bước trên đây là kết thúc việc cấu hình SSL cho LDAP trên phiên bản máy chủ windows 2000 và Windows 2003 Enteprise.

4.1 Kiểm tra kết nối tới giao thức LDAPS connection:
  1. Mở chính máy chủ Windows 2000 /2003 AD vừa cài LDAPS:

netstat -n -p tcp  server returns that 636 is listening:

image

2. Mở máy chủ liên quan tới SharePoint Server / .NET / PHP Server / VPN SSL cần kết nối với máy chủ Windows 2003/ 2000 vừa cài LDAPS:

image

3. Xem cách sửa lỗi này ở mục 6:

 

4.2.  Xuất file pfx chứng nhận LDAPS và Nhập file pfx để sử dụng với AD DS (áp dụng cho AD Server 2008 / 2008 R2 Enterprise):

Các bước sau chứng minh làm thế nào để xuất ra một giấy chứng nhận LDAPS kích hoạt từ kho lưu trữ chứng thực Enterprise từ một Domain Controller để Directory Domain Services lưu trữ chứng chỉ dịch vụ Active Directory (NTDS \ Personal).

Bạn sẽ phải thực hiện bước này cho mỗi Domain Controller khi có nhiều giấy chứng nhận với việc sử dụng kích hoạt kiểu Server Authentication.

Giấy chứng nhận này sẽ phải được gia hạn sử dụng và chỉ thực hiện được bắt đầu với Windows Server 2008 domain controller, vì đó là Windows Server Active Directory Domain service  (AD DS) đầu tiên, trong đó NTDS được tách ra như là dịch vụ riêng của chính hệ thống.

  1. Bấm vào Start, gõ mmc và sau đó nhấn OK .
  2. Nhấn vào File Add / Remove Snap-in .
  3. Nhấn vào Certificate và sau đó nhấp vào Add.
  4. Trong Certificates snap-in, chọn Computer Account và sau đó nhấp vào Next.
  5. Trong Select Computer , nếu bạn đang làm việc tại các máy chủ LDAP yêu cầu chứng chỉ, chọn Local . Nếu không, hãy chọn Another Computer và nhấn Browse để xác định vị trí máy chủ LDAP yêu cầu giấy chứng nhận.
  6. Một khi bạn có máy tính đúng được chọn, nhấn OK và sau đó nhấp vào Finish . Trong Add or Remove Snap-in , click OK .
  7. Trong cây giao diện điều khiển, mở rộng Certificates (<Computer>)
  8. Trong giấy chứng nhận giao diện điều khiển của một máy tính có một chứng chỉ có thể được sử dụng để xác thực máy chủ, kích chuột phải vào chứng chỉ, nhấn All Tasks , và sau đó nhấp vào Export.

image

image

 

9. Trên Certificate Export Wizard màn hình chào mừng, nhấn Next.

10. Trên export the Key Private màn hình, chọn Yes, export the private key và sau đó nhấp vào Next. Nếu bạn không có tùy chọn để xuất khẩu các khóa riêng, sau đó các mẫu chứng chỉ không cho phép xuất khẩu của khóa riêng

Tham khảo:  Xuất bản chứng chỉ hỗ trợ Server Authentication.

image

Trên Export File Format màn hình, bạn nên chọn Export tất cả các thuộc tính mở rộng . Các lựa chọn khác là:

image

image

11. Trên màn hình Password, nhập mật khẩu mà bạn muốn được sử dụng khi các chứng chỉ được nhập khẩu. Bạn sẽ phải nhập mật khẩu hai lần: một lần trong Mật khẩu hộp và sau đó một lần nữa trong các Loại và mật khẩu xác nhận . Sau đó, nhấp vào Next.

12. Trên File to Export màn hình, nhập vào đường dẫn, tên file, và mở rộng tập tin .pfx và

image

image

 

sau đó nhấp vào Next.

13. Xác nhận các thiết lập trên màn hình hoàn thành và sau đó nhấp vào Finish. Bạn sẽ thấy một thông báo pop-up chỉ ra rằng việc xuất khẩu là thành công. Nhấn OK .

14. Nhấn vào File và sau đó nhấp vào Add / Remove Snap-in .

15. Nhấn vào Certificates và sau đó nhấp vào Add.

image

image

Chọn Service account và sau đó nhấp vào Next.

image

16. Chọn Local Computer, đảm bảo rằng bạn nhắm mục tiêu các máy tính thích hợp. Nếu bạn đang chạy Microsoft Management Console (MMC) và muốn nhắm tới các máy tính địa phương, bạn có thể để lại các lựa chọn mặc định của Local Computer. Nếu không, hãy chọn nother computer và sau đó sử dụng các Browse để chọn các máy tính thích hợp. Sau đó nhấp vào Next.

17. Chọn Active Directory Domain Services và sau đó nhấp vào Finish.

image

image

18. Trên Add or Remove Snap-ins hộp thoại bấm OK .

19. Mở rộng Certificates (Active Directory Domain Services) và sau đó nhấp vào NTDS \ Personal.

20. Kích chuột phải vào NTDS \ Personal, nhấn All Tasks , và sau đó nhấn Import .

image

21. Trên Certificate Import Wizard màn hình chào mừng, nhấn Tiếp theo .

22. Trên File to Import , nhấn chuột vào Browse , và sau đó xác định vị trí các tập tin chứng chỉ mà bạn đã xuất trước đó.

23. Trên mở màn hình, đảm bảo rằng Personal Information Exchange (* PFX, *. p12) được lựa chọn là các loại tập tin và sau đó di chuyển các tập tin hệ thống để xác định vị trí các chứng chỉ mà bạn đã xuất trước đó và sau đó nhấp vào giấy chứng nhận đó.

image

24. Nhấn Open và sau đó nhấp vào Next.

25. Trên Password màn hình nhập mật khẩu bạn đặt cho các tập tin và sau đó nhấp vào Next.

image

Trên trang Certificate, đảm bảo rằng tất cả các chứng chỉ hợp lệ được chọn và đọc vào vị trí Certificate store : NTDS \ Personal và sau đó nhấp vào Next.

image

26. Trên Certificate Import Wizard màn hình hoàn thành, bấm Finish. Sau đó bạn sẽ thấy một thông báo rằng nhập đã thành công. Nhấn OK .

27. Trong khung Navigation, dưới NTDS \ Personal, nhấp Certificates

28. Trong cửa sổ chi tiết, kích chuột phải vào chứng chỉ mà bạn nhập khẩu và sau đó nhấp vào Browser.

image

Click vào Detail và sau đó nhấp vào Enhanced Key Usage, bạn sẽ thấy rằng Authentication Server (1.3.6.1.5.5.7.3.1) là một trong những Target của các giấy chứng nhận và sau đó nhấp OK .

image

5. Kiểm tra kết nối LDAPS:

Sau khi một chứng chỉ được cài đặt, hãy làm theo các bước sau để xác minh rằng LDAPS được kích hoạt:

5.1 Bắt đầu công cụ mới Administration Directory (Ldp.exe)

image

  1. Trên kết nối đơn, nhấp vào Connect .

image

2. Nhập tên của máy chủ LDAP (ví dụ như Domain Controller  hoặc AD LDS / ADAM server) mà bạn muốn kết nối.

3. Đổi số cổng sang 636 .

4. Check ô SSL

5. Nhấn OK .

 

6. Tham khảo các lỗi vs Xử lý sự cố LDAP qua SSL:

Khi bạn có vấn đề với LDAPS, có những điều khác nhau mà có thể là sai.

Các bạn nên tham khảo: Khắc phục sự cố LDAP qua SSL .

Chỉ có một sự kiện ID đó là liên quan trực tiếp đến LDAP trên SSL, đó là các mã lỗi có ký hiệu số:

  • Error event ID 1220 – LDAP trên SSL
  • Error event ID 2886 – LDAP ký : đăng nhập mỗi lần một bộ điều khiển miền được bắt đầu, nếu bạn không có yêu cầu ký kích hoạt trên bộ điều khiển tên miền của bạn.
  • Error event ID 2887 – Nếu ký kết yêu cầu không được bật, sự kiện này còn giữ một số bao nhiêu với phím unsigned xảy ra trong 24 giờ. Các sự kiện được đăng nhập mỗi 24 giờ.
  • Error event ID 2888 – Nếu ký cần được kích hoạt, sau đó điều này thậm chí giữ một đếm bao nhiêu với phím LDAP unsigned xảy ra trong 24 giờ. Kể từ khi ký LDAP là cần thiết, với phím sẽ bị từ chối. Đây là thông báo cho người quản trị để điều tra các máy tính khách hàng đang cố gắng để ràng buộc mà không ký.
  • Error event ID 2889- quản trị có thể cho phép sự kiện này để giúp xác định các máy tính khách hàng đang cố gắng để ràng buộc mà không ký. Sự kiện này được đăng nhập với địa chỉ IP và danh tính ràng buộc của khách hàng mỗi khi một ràng buộc unsigned được thực hiện hoặc cố gắng.
 

Lỗi Error <0x51>: Fail to connect to

image

Đây là lỗi do bạn chưa ký chữ ký số của máy chủ windows 2000/2003 /2008 AD vừa dựng LDAPS sang máy chủ liên quan mà bạn cần truy cập kết nối sử dụng dịch vụ LDAPS:

ví dụ: bạn mở máy chủ SharePoint Server / máy chủ .NET framework hoặc / Apache Server / PHP server …

image

image

image

image

image

image

image

 

image

image

image

image

image

 

image

 

Như vậy, có 2 bước triển khai:

1. cấu hình CA trên AD DS và Export ra file pfx.

2. Cấu hình import file pfx vào máy VPN/ SharePoint /.Net / PHP/ Apache server cần kết nối LDAPS.

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

 

P.S: Những nội dung triển khai giải pháp kỹ thuật trên càng ngày càng phức tạp,

các bạn nên đăng ký tham gia các khóa học của ROBUSTA để được luyện tập, trải nghiệm qua các môn học,

phương pháp học thực hành chuyên sâu, vững Trí vững Nghề !

Phần 6: Triển khai đăng nhập 1 lần SSO theo cơ chế Multi-site trên VMware vCenter Appliance 5.5


I. Mô hình tổ chức quản lý tên miền AD-DC:

Xuất phát từ quan điểm tổ chức tên miền nhiều cấp, nhiều vùng, nhiều phòng ban, thậm trí nhiều vùng / thị trường của Doanh nghiệp (tập đoàn, tổng công ty…)

các Doanh nghiệp sẽ tổ chức hệ thống quản trị tên miền theo nhiều máy chủ AD server.

Tham khảo link: https://letonphat.wordpress.com/2010/10/03/active-directory-windows-server-2008/

Trees:

– Trees là một nhóm các domain được tổ chức theo cấu trúc hình cây với mô hình parent-child ánh xạ từ thực tế tổ chức của doanh nghiệp, tổ chức. Một domain có 1 họăc nhiều child domain nhưng 1 child domain chỉ có 1 parent-domain mà thôi.

image

Forests:

– Forest là một thuật ngữ được đặt ra nhằm định nghĩa 1 mô hình tổ chức của AD, 1 forest gồm nhiều domain trees có quan hệ với nhau, các domain trees trong forest là độc lập với nhau về tổ chức, nghe ra có vẻ mâu thuẫn trong mối quan hệ nhưng ta sẽ dễ hiểu hơn khi mối quan hệ giữa các domain trees là quan hệ Trust 2 chiều như các partners với nhau.

– Một forest phải đảm bảo thoả các đặc tính sau:

· Toàn bộ domain trong forest phải có 1 schema chia sẻ chung

· Các domain trong forest phải có 1 global catalog chia sẻ chung

· Các domain trong forest phải có mối quan hệ trust 2 chiều với nhau

· Các tree trong 1 forest phải có cấu trúc tên(domain name) khác nhau

· Các domain trong forest hoạt động độc lập với nhau, tuy nhiên hoạt động của forest là hoạt động của toàn bộ hệ thống tổ chức doanh nghiệp.

image

 

II. Cơ chế hoạt động vật lý của AD cho vấn đề Multi-site / Multi Domain:

(Kerberos Authentication Process Over Forest Trusts)

image

Google translate dịch kinh khủng đọc không hiểu phiền các bạn bỏ qua, chỉ cần hiểu concept thôi.

  1. User1 đăng nhập vào Workstation1 bằng các thông tin từ các miền europe.corp.tailspintoys.com. Sau đó người dùng cố gắng truy cập vào một nguồn tài nguyên chia sẻ trên FileServer1 nằm trong forests usa.corp.wingtiptoys.com.
  2. Liên lạc Workstation1 Trung tâm phân phối khóa Kerberos (KDC) trên một bộ điều khiển miền trong phạm vi của nó (ChildDC1) và yêu cầu thẻ dịch vụ cho FileServer1 SPN.
  3. ChildDC1 không tìm thấy trong cơ sở dữ liệu SPN phạm vi của nó và truy vấn các tên miền global để xem nếu bất kỳ lĩnh vực trong tailspintoys.com chứa SPN này.Bởi vì một danh mục global được giới hạn ở forests riêng của nó, là SPN không được tìm thấy. Các tên miền global sau đó sẽ kiểm tra cơ sở dữ liệu của nó cho thông tin về bất kỳ tín thác forests được thành lập với forests của mình, và nếu tìm thấy, nó sẽ so sánh các hậu tố tên được liệt kê trong các đối tượng tin tưởng forests miền tin cậy (TDO) để các hậu tố của mục tiêu SPN tìm một trận đấu. Khi một hợp được tìm thấy, các tên miền global cung cấp một gợi ý định tuyến trỏ tới ChildDC1. Gợi ý giúp định tuyến yêu cầu chứng thực trực tiếp đối với các khu forests đích, và chỉ được sử dụng khi tất cả các kênh truyền thống xác thực (bộ điều khiển miền địa phương và sau đó tên miền toàn cầu) không để định vị một SPN.
  4. ChildDC1 gửi giấy giới thiệu cho miền cha của nó trở lại Workstation1.
  5. Liên lạc Workstation1 một bộ điều khiển miền trong ForestRootDC1 (domain cha của nó) được giới thiệu đến một bộ điều khiển miền (ForestRootDC2) trong tên miền gốc forests của forests wingtiptoys.com.
  6. Liên lạc Workstation1 ForestRootDC2 trong forests của wingtiptoys.com cho một token dịch vụ đáp ứng các dịch vụ yêu cầu.
  7. ForestRootDC2 liên hệ Global của nó để tìm ra SPN, và các Global tìm thấy một trận đấu cho SPN và gửi nó trở lại ForestRootDC2.
  8. ForestRootDC2 sau đó gửi giấy giới thiệu để usa.corp.wingtiptoys.com lại Workstation1.
  9. Liên lạc Workstation1 các KDC trên ChildDC2 và thương lượng vé cho User1 để đạt được quyền truy cập vào FileServer1.
  10. Khi Workstation1 có một vé dịch vụ, nó sẽ gửi thẻ dịch vụ để FileServer1, mà đọc thông tin bảo mật của User1 và xây dựng một access token cho phù hợp.

 

Cổng cần thiết cho Trusts

Công việc Cổng Outbound Cổng Inbound Từ-To

Thiết lập các quỹ trên cả hai bên từ rừng nội

LDAP (389 UDP và TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint độ phân giải – portmapper (135 TCP) cổng Net Logon cố định

N / A

Internal miền domain controller-External domain controller miền (tất cả các cổng)

Xác nhận sự tin tưởng từ các bộ điều khiển miền rừng bên trong đến các bộ điều khiển miền rừng bên ngoài (tin tưởng đi chỉ)

LDAP (389 UDP)

Microsoft SMB (445 TCP)

Endpoint độ phân giải – portmapper (135 TCP) cổng Net Logon cố định

N / A

Internal miền domain controller-External domain controller miền (tất cả các cổng)

Sử dụng Object chọn vào rừng bên ngoài để thêm các đối tượng đó đang ở trong một rừng các nhóm nội bộ và DACLs

N / A

LDAP (389 UDP và TCP)

Cổng Windows NT Server 4.0 dịch vụ thư mục cố định

Net Logon cổng cố định

Kerberos (88 UDP)

Endpoint độ phân giải portmapper (135 TCP)

PDC miền máy chủ nội bộ bên ngoài (Kerberos)

Miền domain controller-Internal External miền domain controller (Logon Net)

Thiết lập sự tin tưởng vào rừng bên ngoài từ rừng bên ngoài

N / A

LDAP (389 UDP và TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Miền domain controller-Internal External miền domain controller (tất cả các cổng)

Sử dụng Kerberos xác thực (client rừng bên rừng bên ngoài)

Kerberos (88 UDP)

N / A

Client-External bộ điều khiển miền domain nội bộ (tất cả các cổng)

Sử dụng xác thực NTLM (khách hàng nội bộ rừng để rừng bên ngoài)

N / A

Endpoint độ phân giải – portmapper (135 TCP) cổng Net Logon cố định

Miền domain controller-Internal External miền domain controller (tất cả các cổng)

Tham gia một tên miền từ một máy tính trong mạng nội bộ đến một miền ngoài

LDAP (389 UDP và TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint độ phân giải – portmapper (135 TCP) cổng Net Logon cố định

Cổng Windows NT Server 4.0 dịch vụ thư mục cố định

N / A

Client-External bộ điều khiển miền domain nội bộ (tất cả các cổng)

chú ýChú ý
Cổng 445 và có khả năng TCP port 139 là cần thiết cho khả năng tương thích ngược.

 

III. Cấu hình Domain Forests và Trusts:

Bước 1:

image

Bước 2: mở DNS Server và cấu hình

image

Bước 3: Cấu hình DNS Fordward

image

 

Bước 4: Tương tự trên con máy chủ AD2

image

Bước 5: Tiếp theo vẫn trên máy chủ AD2  mở Active Directory Domain and Trusts

image

Bước 6: Nhập tên miền của AD1 vào

image

Bước 7: Chọn Forest trust

image

Bước 8: Chọn Two-way

image

Bước 8: Chọn Both this domain and the specified domain

image

Bước 9: Nhập user name và mật khẩu domain admin của AD1

image

Bước 10: Chọn xác thực Forest-wide cho Outgoing

image

Bước 11: Chọn xác thực Forest-wide

image

image

image

image

image

image

Bước 12: Kiểm tra kết quả cấu hình Forest trust

image

 

Sau khi cấu hình cả 2 máy chủ phần AD Domain and trust:

image

 

V. Các bước thử nghiệm sử dụng Forest Domain Trusts trên RDP:

Để sử dụng được 1 dịch vụ như RDP mà khi đăng nhập bạn có thể dùng tài khoản từ AD1 hoặc AD2 đều truy xuất được hệ thống RDP/RDSH …

  1. Tạo một nhóm bảo mật mới trên DomainA (Domain với RDS)
  2. Thay đổi Nhóm Phạm vi  Group scope thành “Domain local”
  3. Thêm các thành viên từ DomainB đến nhóm kiểu bảo mật “Group type = Security” mới trong DomainA
  4. RDS Mở trên DomainA và thêm các nhóm bảo mật mới để Phân quyền truy cập RemoteApp.

image

Sau đó hãy thêm nhóm đó vào RDP configuration:

image

Bây giờ bạn có thể thử nghiệm đăng nhập từ tài khoản thuộc nhóm thành viên trên.

 

VI. Cấu hình SSO trên VMware vCenter Appliance:

Các bạn vẫn thực hiện các phương pháp SSO như phần 4,5:

Tham khảo link:

Phần 4: Triển khai đăng nhập 1 lần SSO giữa AD và VMware vCenter Appliance 5.5

Phần 5: Triển khai đăng nhập 1 lần SSO giữa AD-DS và VMware vCenter Appliance 5.5

 

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

Phần 5: Triển khai đăng nhập 1 lần SSO giữa AD-DS và VMware vCenter Appliance 5.5


2. Phương án Active Directory as a LDAP Server:

Các phương pháp thể hiện trong bài viết này cho phép bạn quản lý người dùng và nhóm trong thư mục trung tâm của bạn. Điều này làm cho cả hai, vCenter Server 5.5 được cài đặt trên Windows Server và các dụng vCenter Server (VCSA).

  1. Mở vSphere Web Client (https: // <ĐỊA CHỈ IP hoặc tên máy chủ vCenter>: 9443 / vSphere-client)
  2. Đăng nhập như là administrator@vsphere.local
    Mật khẩu (VCSA): ngầm định ban đầu là  VMware
  3. Điều hướng đến Administration > Single Sign-On  > Configuration

image

4. Nhấn vào dấu + màu xanh lá cây để thêm một nguồn bản sắc
image

5. Hãy chọn loại nhận dạng Source: A) dựa trên Windows vCenter Server 5.5: Active Directory (Integrated Windows Authentication)

 B) vCenter Server Appliance 5.5 (VCSA):

image

6. Bấm OK

7. Quay lại phần Identity Sources bạn sẽ cần tạo thông tin liên quan tới cách kết nối giữa vCenter với AD để lấy được các users và groups từ active directory. Khi bạn kết nối kiểu Integrated Windows Authentication, thì các trusted domains phải có giá trị hoạt động. 

8. Chọn Active Directory và bấm vào “world with arrow” để chuyển trạng thái đăng nhập ngầm định là các tài khoản từ AD domain.

image

9. Bạn sẽ nhận được một cảnh báo cho bạn biết rằng “Điều này sẽ làm thay đổi tên miền mặc định hiện tại của bạn. Bạn có muốn tiếp tục? “. Điều này là không sao, vì bạn chỉ có thể có một tên miền mặc định.

Có vậy thôi, bây giờ bạn có thể thiết lập quyền truy cập và xác thực đối với hoạt động giữa AD với vCenter Server 5.5 gọi là SSO.

Để thay đổi cấu hình vCenter Server SSO với người dùng khác ngoài administrator@vsphere.local, bạn phải thêm chúng vào Nhóm LocalOS hoặc vSphere.local hoặc Nhóm thuộc Domain do bạn vừa cấu hình

image

 

10. Thêm các tài khoản lấy từ AD sang để phân quyền theo users/ group:

image

Tham khảo: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058942 

 

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

Phần 4: Triển khai đăng nhập 1 lần SSO giữa AD và VMware vCenter Appliance 5.5


Hệ thống đăng nhập SSO đều phụ thuộc vào 5 bước chuẩn :

image

Lưu ý:

  1. Bước 1 và 2 luôn cần được vẽ sơ đồ và thông tin về cấu hình mạng trước như:  IPv4, IP gateway, IP DNS local, AD Server name, vcenter server name, A, CNAME, Reverse lookup zone và PTR.
  2. Công cụ chuẩn bị cho kiểm thử cần chuẩn bị trước (tham khảo: https://technet.microsoft.com/en-us/library/cc794810%28v=ws.10%29.aspx )
  3. Các bước chạy kiểm thử LDAP/ LDAPS các bạn cần biết qua (tham khảo: https://thangletoan.wordpress.com/2015/03/01/phan-2-trien-khai-cau-hnh-dang-nhap-1-lan-sso-giua-moodle-v-ad-server-robusta-distance-learning-2015/ )

 

Hệ thống đăng nhập 1 lần SSO thường có 4 phương pháp kết nối giữa AD với vCcenter:

image

1. Phương án Active Directory (integrated Windows Authentication):

Bước 1: chuẩn bị trên DNS Server các thông số A, CNAME:

image

và PTR

image

 

Bước 2: Join domain từ vCenter Appliance đến AD Server:

image

Bước 3: Giờ là lúc cấu hình SSO lấy account từ AD sang cho VMware vCenter:

image

Lưu ý: nếu không chuẩn kỹ, chính xác các bước 1,2 các bạn sẽ gặp khá nhiều lỗi bực mình sau:

Lỗi 1: Giá trị bí danh không nên để trống  ‘alias’ value should not be empty :

image

 

Lỗi 2: cannot load the users for the selected domain

image

– Không cập nhật bản ghi PTR hoặc khi thay máy chủ vCenter, AD, Domain Controler quên không cập nhật bản ghi PTR đều là hậu quả của các lỗi trên.

Tham khảo: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033742 

 

Chúc các bạn tránh được sai lầm và thành công !

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 !

    Làm thế nào có thể thay đổi tên miền trong tổ chức doanh nghiệp trên Windows Server 2012?


    Bài toán đặt ra:

    Hệ thống domain của tổ chức Doanh nghiệp thông thường được tạo theo cấu trúc nội bộ, không liên quan tới hệ thống dịch vụ trên Internet. Nhưng vì một số lý do rất cơ bản, tổ chức doanh nghiệp lớn, nằm dải khắp các quốc gia khác nhau.

    Khi dùng chung cấu trúc và tên 1 domain,

    Ví dụ:  Robusta.org , các đơn vị, tổ chức thành viên sẽ dùng lại đúng domain này cho hệ thống nội bộ tại quốc gia thành viên, đây là cách truyền thống, đơn giản, tiết kiệm thời gian.

    Robusta_Org_old

    Sau khi xây dựng các hạ tầng mới tài chi nhánh hoặc các tổ chức doanh nghiệp tại các quốc gia thành viên như: Ảo hóa VMware vCenter, Private Cloud…

    Các chi nhánh và tổ chức danh nghiệp thành viên sẽ nảy sinh vấn đề mới đó là:

    1. Không thể copy sao chép giống y nguyên domain name của Head quarter do vấn đề conflic về tên miền, quản lý tên miền khi các chi nhánh có nhu cầu Public các dịch vụ Web Portal, Intranet, Private Cloud, Mobile Application cần có chữ ký số thuê của các hãng Cert Sign, Godaddy…
    2. Tên miền quản lý do Head quarter quản lý do vậy, khi đăng ký SSL/TLS sẽ phải do Admin IT của Head quarter control rất mất thời gian hoặc không chủ động điều khiển được từ phía chi nhánh, tổ chức thành viên.
    3. Các chi nhánh, tổ chức thành viên khi có đầu tư hạ tầng thường sẽ có các cơ cấu nhân sự, quản lý tài nguyên chủ động, độc lập thậm chí cấu trúc kỹ thuật CNTT khác đi so với cấu trúc ở trên:

     

    Robusta_Org_new

    Theo như mô hình trên đây thì chúng ta sẽ:

    – Dễ dàng quản lý từng domain name cho các chi nhánh hoặc tổ chức doanh nghiệp thành viên mà không bị phụ thuộc vào việc xét duyệt

    đợi điều khiển từ phía Head quarter mỗi lần có phát sinh từ đơn vị chi nhánh.

    – Chủ động quản lý các tên miền, máy chủ, máy trạm, tài khoản người dùng, phân nhóm và đặc biệt là các dịch vụ SSL/TLS đăng ký để public intranet/extranet/internet.

     

    Các phương án thay đổi:

    1. Phương án 1: Xóa Domain tại các chi nhánh hoặc tổ chức Doanh nghiệp thành viên  ( demote AD-DC, sau đó restart và dcpromo lại AD-DC với tên mới)

    • Phương án này đơn giản lặp lại các bước đã làm, mất thời gian làm lại, nhưng có thể sẽ không phù hợp với các máy chủ dịch vụ đã cài và đang vận hành như: UC Voice Lync Conferencing, Exchange Server 2013 on-primise, MS SQL server enterprise, MS SharePoint farm, MS BizTalk Server Enterprise…
    • Do tất cả các máy chủ trên được cài, cấu hình trên nền tảng Windows Authentication, cần Join Domain với tên domain chuẩn ban đầu có sẵn. Nếu hủy domain hiện thời sẽ dẫn tới mất Windows Authentication và WFC Platform cho phép các máy chủ dịch vụ chạy.
    • Phương án này có thể gây sự cố không dùng lại được do các dịch vụ, cấu hình của những ứng dụng phức tạp, ứng dụng đã cấu hình theo tên miền cũ không tương thích, không phù hợp với cấu hình mới.

    2. Phương án 2: Thay đổi tên miền (rename domain, sau đó join domain lại ở các máy chủ, máy trạm)

    – Phương án này đơn giản trải qua hơn 28 bước thay đổi tên miền và join lại cho các máy trong tên miền của chi nhánh.

    – Phương án này sẽ mất thời gian join domain lại các máy chủ dịch vụ, máy trạm với tên miền và tài khoản join domain admin mới.

    – Phương án này sẽ không phải cấu hình lại toàn bộ các ứng dụng dịch vụ đang có, chỉ lưu ý các thông số của các trường hợp sau:

    1. UC Server sẽ phải kiểm tra lại các tài khoản login dịch vụ theo kiểu UPN@domain và sau đó kiểm tra dịch vụ có dùng account domain\username.

    Chứng chỉ CTL sẽ phải xóa bớt chứng chỉ gốc hoặc renew lại chứng thư số mới

    2. MS SQL Server enterprise phải cấu hình quyền access login server và có thể cả quyền DB Admin theo dạng Mixed mode (cho phép account SQL Local “sa”) được phép truy cập MS SQL

    khi gặp sự cố về Domain Controller hoặc thay đổi Domain name dẫn tới các account của domain name cũ điều khiển được MS SQL Server…

    3. MS Exchange server sẽ phải chạy lại Exchange Configuration Wizard để re-buil lại cấu hình domain mới cho Mail Server re-configure

    4. MS SharePoint server sẻ phải chạy lại SharePoint Server Configuration Wizard để re-buil Farm Server và một số cấu hình khác.

    5. Phải backup các GPO của máy chủ AD-DC trước khi rename domain

     

    3. Phương án 3: Không thay đổi tên miền, chỉ thêm các bí danh cho tên miền trên DNS Server (thêm các DNS Zone, bản ghi A (Host), CNAME, PTR, TXT, SRV)

    – Phương án này đơn giản trải qua hơn 3 bước thay đổi các thông số tên máy chủ dịch vụ, mapping IP nội bộ các máy của chi nhánh.

    – Phương án này sẽ mất ít thời gian kiểm tra máy trạm , máy chủ dịch vụ từ ngoài truy cập và hệ thống nội bộ để xác định các hạng mục có chạy ổn định hay không ?

    – Phương án này có thể không phù hợp với toàn bộ hạ tầng ứng dụng của chi nhánh khi có nhiều chuẩn HĐH khác nhau, nhiều chuẩn kết nối dữ liệu người dùng khác nhau, ứng dụng đã fix code gọi LDAP/ADFS…

    – Phương án này chỉ phù hợp với hạ tầng đã hoặc đang triển khai Private Cloud, giúp các các web portal intranet, các ứng dụng Windows Form… có thể kết nối và truy cập qua Internet bằng các trình duyệt web HTML5 smartphone, mobile device mà không cần thiết lập VPN kết nối Site – to – site.

     

    Tóm lại, phương án 2 là hợp lý nhất.

     

    Chi tiết các bước, các bạn nên tham khảo:

    Các bước thay đổi tên miềnhttps://mizitechinfo.wordpress.com/2013/06/10/simple-guide-how-to-rename-domain-name-in-windows-server-2012/ 

    Tham khảo các ghi chú về kỹ thuật thay đổi tên miền: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx

    Tham khảo support tình huống đăng ký lại chữ ký số mới cho UC: http://support.microsoft.com/kb/2464556/ 

    Tham khảo cách đăng ký chữ ký số cho IIS8, IIS8.5:  https://www.digicert.com/ssl-support/ssl-host-headers-iis-8.htm

    Tham khảo cách đăng ký chữ ký số cho Exchange 2013: http://exchangeserverpro.com/exchange-server-2013-ssl-certificates/

    SharePoint nâng cao: Phần 7 – Bổ sung cấu trúc hệ thống MySite trong SharePoint


    Tại sao có rất nhiều hệ thống Cổng thông tin Doanh nghiệp lại được gọi là “Facebook cho Doanh nghiệp”

    và bộ sưu tập trang web cá nhân cung cấp cho mỗi người sử dụng với khả năng lưu trữ thông tin cá nhân và công cộng như văn bản, hình ảnh, cập nhật trạng thái, v.v. dễ dàng và hiệu quả. Các trang web của cá nhân trong SharePoint 2010 đều được thiết kế theo mô hình mạng xã hội thu nhỏ trong hoạt động của Doanh nghiệp. Microsoft đã nhìn thấy sự cần thiết phải tiếp tục đầu tư và tăng cường khả năng kết nối mạng xã hội trong SharePoint, và như công nghệ web 2.0 tiếp tục ngổn ngang trên tất cả các trang web đang vận hành trên thế giới, Microsoft đã một lần nữa thiết lập thành công các nhãn hiệu, thẻ văn bản, meta data chuẩn bị trong Sharepoint Enterprise bằng cách giới thiệu một loạt các tính năng mạng xã hội để tăng cường sự hợp tác, lầm việc tương tác giữa những người dùng trong SharePoint 2010.

    Tôi xin giới thiệu cấu hình ứng dụng dịch vụ Xã hội cho SharePoint 2010 triển khai tại Labs của chúng tôi, hồ sơ người dùng, trong đó cung cấp cho chúng ta một vị trí trung tâm để lưu trữ các chi tiết thông tin người dùng mà sau này sẽ được nhập từ một nguồn nội dung như Active Directory vào.

    image

     

    My Site host là gì ?
    Bạn chỉ có thể sử dụng My Site host Template từ khu vực dành cho người quản trị bởi vì nó tạo ra
    một nơi cho phép lưu trữ tất cả các Site cá nhân khác. Bạn chỉ nên sử dụng Template này cho mổi
    User Profile Service Application khi cần.
    Một khi bạn tạo ra My Site host thì người dùng cá nhân có thể tạo ra các trang chủ My Site dành cho
    họ để theo dõi các tin tức mới trong Site mà họ quan tâm, tạo ra các trang nội dung và thư viện tài
    liệu cá nhân. Dĩ nhiên một trong những lợi thế quan trong khác của việc lưu trữ các tập tin trên thư
    viện My Site hơn là lưu trữ trên ổ cứng cá nhân là các dữ liệu của My Site sẽ được sao lưu một cách
    thường xuyên.

     

    Các bước tạo My Site Web Application

    Mở Central Administration / Application Management / Web Applications bấm nút New

    image

    Authentication: chọn kiểu Claims hoặc Classic  (tôi sẽ chọn “Classic”).

    IIS Web Site: Tạo 1 IIS web site mới (nhập tên theo ý của mình).

    image

    Authentication Provider: chọn phương thức xác thực.

    Public URL: nhập địa chỉ web làm địa chỉ URL truy cập My Sites của tôi.

    image

    Application Pool: Tạo thêm mới  Application Pool.

    Thông thường ở chế độ bảo mật, chúng ta nên tạo 1 account domain user trên AD server và cấp quyền duy nhất để có thể start/stop 1 web application pool (ví dụ: được quyền điều khiển  My Site Application Pool ).  Lưu ý: Account này phải được khởi tạo trong Active Directory trước và chỉ thuộc quyền Domain Users (DOMAIN\sp_mysite).

    image

    Click OK

    image

    Database Name and Authentication: tên máy chủ Database SQL sẽ chứa dữ liệu Site Content Collection DB.

    Failover Server: Tên máy chủ SQL cái ở chế độ failover server (nếu bạn có cấu hình và sử dụng SQL Server database mirroring).

    image

    bấm “OK”.

    image

    Bước tiếp theo:

    Tạo “SharePoint – My Site” Web Application và click  General Settings. 

    Ta chỉnh lại Default Time Zone.

    image

    Tạo My site theo “My Site Host Site Collection”:

    image

    Ta sẽ nhận được thông báo xác nhận việc tạo My Site:

    image

    Thiết lập cấu hình My Site:

    Mở Central Administration / Application Management / Manage service applications.

    Bấm User Profiles, bấm chọn Setup My Sites located trong mục My Site Settings

    image

    image

    image

    bấm “OK”.

    Thêm Managed Path:

    Mở Central Administration / Application Management / Manage Web Applications.

    bấm vào My Site Web Application và bấm chọn “Managed Paths” có trên bộ nút “Ribbon”

    image

    Nhập thêm “personal” chọn kiểu “Wildcard inclusion”, sau đó bấm “Add Path” và bấm “OK”

    image

    Cấu hình cho phép người dụng đăng ký có thể tự tạo Mysite page:

    Mở Central Administration / Application Management / Manage Web Applications.

    bấm “My Site Web Application” và bấm chọn “Self-Service Site Creation”

    image

    Chọn On và bấm “OK”.

    image

    Bây giờ thì chúng ta có thể truy cập MySite

    image

    Lần đầu tiên khởi tạo MySite Content hệ thống SharePoint sẽ cần thời gian xử lý:

    image

    Và sau ít phút chúng ta đã có My Site của từng cá nhân đăng nhập vào Mysite

    image

     

    Các nhà Quản trị hệ thống SharePoint hoặc các nhóm lập trình development có thể tiếp tục công việc

    cấu hình phần quyền, đẩy các Web Part, Web Application Solution hoặc SharePoint Solution cho từng người hoặc nhóm, hoặc vào các Sites

    để người dùng có thể dễ dàng sử dụng các tính năng, chức năng mở rộng, mới trong công việc hàng ngày.

     

    Chúc các bạn thành công trong công cuộc tái cấu trúc lại hệ thống Cổng thông tin Doanh nghiệp bằng SharePoint !

    %d bloggers like this: