Chữ ký Số, mã hoá file tài liệu và cách xoay khổ giấy A3/A4 sang 16:9 và xuất SCORM bằng Fliping book tránh tải xuống máy cá nhân


Phần 1. Các tài liệu sách in giấy thường là khổ A4, A3 Khổ dọc (Portrait):

  • Khi chuyển sang màn trình chiếu PowerPoint hoặc màn hình Tablet thường là màn 4:3 hoặc rộng là 16:9 thường sẽ phải xoay khổ ngang (Landscape).
  • Kích thước phông chữ, hình ảnh và các đối tượng trong trang sách gốc phải được co giãn “zoom in/out”, điều chỉnh lề “margin” phù hợp với khổ xoay ngang.

Thực tế nhu cầu này còn kèm với các yêu cầu cơ bản của việc số hoá như:

  • Bảo vệ tài liệu tránh/hạn chế bị download tài liệu.
  • Hạn chế không in giấy cứng vì học viên và giảng viên thực hiện học tập từ xa.
  • Tránh mất bản quyền, tác quyềndo việc sao chép bản in giấy cứng hoặc
  • Hạn chế/tránh sao chép các Files tài liệu mềm ví dụ: doc, docx, xls, pptx, pdf, onenote…
  • Các files PDF có thể ký chữ ký số tác quyền, tác giả thậm trí gán quyền chỉ cho đọc/xem nội dung, không cho sửa, không cho in/ cho in chất lượng phân giải thấp…
  • Nếu đưa các Files PDFs đã được ký chữ ký số và gán quyền hạn chế chỉ đọc vào SharePoint Portal, OneDrive, MS Teams còn hạn chế không cho tải xuống máy cá nhân “Download”.

Tham khảo: https://atcom.vn/digi-docs

Ví dụ về một số cấp độ sử dụng chữ ký số, cấu hình mã hoá tài liệu và gán quyền nhằm bảo vệ tài liệu chia sẻ.

Ở cấp độ 1: Nếu đã ký được chữ ký số cá nhân/ tổ chức vào File documents thì các tính năng xoay, xoá trang không có tác dụng.

Ở cấp độ 2: Bị khoá các tính năng sửa, xoá thậm trí trong mục Security của tài liệu File cũng cấm các tính năng khác như không in, không sao chép văn bản…

Ở các cấp độ cao hơn 3,4,5 thì chữ ký số còn có thể:

  • Tự điều chỉnh thời gianhết hạn chữ ký số à Chúng ta có thể thay đổi mô hình kinh doanh bán/thuê/mượn tài liệu (sách điện tử) theo ngày,tuần, tháng,năm hoặc số lần mở xem…
  • Có mật khẩu chữ ký số yêu cầu người xem phải đáp ứng hợp lệ thì có thể chuyển từ Xem sang, chèn, xoá, sửa, thêm trang, điền dữ liệu …

 

Phần 2. Cách xoay khổ giấy A4/A3 từ hướng ngang sang hướng dọc:

  • Mở file PDF bằng phần mềm Foxit Phantom Editor
  • Chọn hết các pages cần đổi hướng “Orientation Lanscape”
  • Sau đó chọn xuất ra file PPTX.


Chọn kiểu xuất ra file Office PPTX


Chọn thư mục lưu file PPTX.

Bước tiếp theo:

  • Mở file PPTX bằng MS Power Point 2016 /2019/2022/ MSO365…
  • Chọn Menu Thiết kế > Kích cỡ trang chiếu > Kích cỡ trang chiếu tuỳ chỉnh…


  • Chúng ta sẽ chọn để xoay khổ ngang hướng “Landscape” màn hình 16:9


  • Tiếp theo chọn kích thước hiển thị “Đảm bảo Vừa”


  • Sau tất cả những cấu hình trên, các Sliders trên Power Point, chúng ta chủ động chỉnh sửa tăng giảm, kích thước cỡ phông chữ, vị trí căn hình ảnh, văn bản cho tới khi mọi thứ đã đảm bảm.

 

Phần 3. Kết xuất file PPTX ra dạng Ebook tránh người dùng Download xuống máy cá nhân dùng cho dạy học LMS:

  • Dùng ispring để chuyển đổi các file PPTx sang dạng ebook “Sách lật scorm”.

Một số lợi thế nhất định của loại sách Fliping được xem xét:

  • Tránh học viên download sách về máy cá nhân.
  • Vẫn có thể chọn copy một số đoạn văn bản trong trường hợp học viên cần sao chép các đoạn code, lệnh lập trình hoặc lệnh điều khiển trong các khoá học

    ví dụ: lập trình hoặc cấu hình Ảo hoá máy ảo, k8s deploy, vRealize Automation, Cloud Foundation deploy, Certified Ethical Hacker (CEH v12) viết script test virus…

  • Tất nhiên nếu cần chia nhỏ các mô-đun thực hành trong file PPTX có thể chúng ta sẽ phải copy lưu thành nhiều file PPTX với nội dung đã được ngắt/copy theo giới hạn trang chứa các mô-đun nói trên.
  • Sau khi bấm nút Publish chúng ta sẽ có các files SCORM .zip và việc còn lại sẽ upload vào các hệ thống E-learning/ LMS/LCMS như: Moodle , blackboard …

Ví dụ: Hiển thị trên LMS

 

Chúc các bạn thành công trong công cuộc Số hoá tài liệu, mã hoá an toàn dữ liệu và Bảo vệ tài liệu cá nhân cũng như tổ chức !

Lab 1001. Sử dụng VBREM để Backup và Restore Application Items cho EXCHANGE DAG


Kịch bản thực hành:

Nhu cầu Sao lưu hệ thống cụm các máy chủ dịch vụ Email Exchange DAG gồm:

  • 2 máy chủ Exchange (viết tắt: ex1, ex2)
  • 2 máy chủ Domain Controller (viết tắt: dc1, dc2).
  • 1 máy chủ Edge Hub Transport – Firewall và Anti-Spam (viết tắt: edge).
  • 1 máy chủ Lưu trữ Quorum Share Disk – File Server Witness (viết tắt: fsw).
  • Webmail SSO ADFS 2019 (viết tắt: adfs).

Câu hỏi: làm thế nào có thể dùng Veeam Backup sao lưu, khôi phục nguyên cả hệ thống hoặc chỉ những dữ liệu bị mất hoặc bị lỗi, bị xoá nhầm hoặc cố ý bị xoá như:

  • Thư cá nhân.
  • Tài khoản hoặc mật khẩu người dùng,
  • Các Rules/Roles trong GPO/LGPO.

Phần 1. Cấu hình, cài đặt cụm EXCHANGE DAG Protection Group:











  • Thêm một sự cố và cách xử lý:


Ví dụ: bạn có thể xóa một hoặc nhiều máy tính khỏi nhóm bảo vệ nếu không muốn bảo vệ các máy tính này bằng Veeam Agent nữa mà muốn sao lưu dữ liệu của các máy tính khác trong nhóm bảo vệ. Khi bạn xóa một máy tính khỏi nhóm bảo vệ, Veeam Backup & Replication sẽ xóa các bản ghi về máy tính khỏi bảng điều khiển sao lưu Veeam và cơ sở dữ liệu cấu hình nhưng không gỡ cài đặt Veeam Agent khỏi máy tính. Bạn có thể xóa Veeam Agent khỏi máy tính trước, trước khi xóa máy tính khỏi nhóm bảo vệ. Để tìm hiểu thêm, hãy xem Gỡ cài đặt Veeam Agent.


  • Cần dùng CMD (Admin) để thực hiện lệnh xoá

Ví dụ: MsiExec.exe /X {7796202E-3320-41ED-9A2C-14613AEED3D3} /qn


  • Hệ thống tự reboot OS

Sau khi đăng nhập lại OS chúng ta kiểm tra Settings và Registry


  • Đối với trường hợp máy chủ DC1 lại cài dạng Windows Core 2019 (không giao diện)

Chúng ta phải dùng tới máy client cài Windows Center Admin để điều khiển Registry và CMD (admin) của máy chủ DC1 windows Core 2019.


  • Dùng phần Installed Apps:




Sau khi xoá hết End point backup ở 2 máy chủ DC1, DC2, ta quay lại VBR để scan Protection Group lại


  • Hệ thống VBR server tự động cài bản End point


Sau khi cài xong sẽ yêu cầu reboot:


  • Khi cài xong Agent End point cho 4 EX1, DC2, EDGE, FSW


Registry quay lại


  • Chúng ta chạy lại Rescan của Protection Group> Exchange DAG



  • Check kết nối ngay trên máy chủ VBR


Xuất hiện lỗi: System error 53 has occurred. The network path was not found.

Thực hiện lệnh: Test-NetConnection -ComputerName 172.16.0.30 -port 445


  • Sửa lỗi máy chủ FSW



 

Dùng Registry cấu hình tắt Remote UAC trên máy trạm này:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
DWORD: LocalAccountTokenFilterPolicy
Value: 1


Tham khảo: https://www.veeam.com/kb1230 (Win32 error: The network path was not found. Code 53)


Tiếp theo, cấu hình Firewall Incoming rules: mở cổng 445 TCP/IP


Kết quả sau khi enabled cổng 445:


 

Cuối cùng, sau khi mở Firewall cổng 445 của máy chủ FSW thông qua Windows Admin Center.

Chúng ta dùng lại Power Shell lệnh trên máy chủ VBR: Test-NetConnection -ComputerName fsw.adatum.com -port 445


 

Bước tiếp theo: chúng ta Rescan lại EXCHANGE DAG.



Sau khi cài Veeam_B&R_Endpoint_x64.msi cho máy chủ FSW, chúng ta dùng Windows Admin Center để khởi động lại máy chủ FSW:


 

Bước thao tác tiếp là cài Backup Repository:


 

Bước tiếp theo: Tạo Agent Backup Job cho cụm 4 máy chủ EDGE, EX1, EX2, FSW:



Lưu ý đâu tiên: Nên chọn Managed by backup server để sao chép các cụm máy chủ EXCHANGE DAG mặc dù chúng ta vừa cài các Agent Endpoint backup gián tiếp lên các máy chủ Guest OS này nhưng do có một số máy chủ lại cài HĐH kiểu Windows Core 2019 (không có giao diện).



Chọn kiểu vùng dữ liệu của các máy chủ cần sao lưu:


Chọn vùng lưu trữ theo cấu hình của máy chủ VBR


Chọn kiểu định dạng dữ liệu cần khôi phục (Cụm: AD, Exchange, SQL, Oracle, SharePoint, MS Teams, Microsoft Office 365 là những dạng được Veeam hỗ trợ kiểu Application Items)


Cấu hình Advanced tắt các chế độ đánh dấu sao lưu cả SQL Truncate, SQL Log system do cụm sao lưu EXCHANGE DAG không dùng MS-SQL/Oracle.


Bỏ dấu chọn Enable application-aware processing:


Như vậy, khi Sao lưu cụm EXCHANGE DAG thông qua VSS (shutdown copy volume OS sẽ chỉ copy Block Files/File System State hoặc copy files Log block (gọi tắt là Copy only transaction log).


Đặt lịch hàng ngày backup Full, số lần cố thử sao lưu theo lịch (3 lần, mỗi lần cách nhau 10 phút)


Sơ kết có 7 ngày sao lưu dạng chỉ có những thay đổi và sẽ làm lại 1 bản Full vào đúng 10:42 AM
ngày thứ 8. Gọi là bản Full Retention Point.


Kết quả của bản backup cụm EXCHANGE DAG:


Cuối cùng chúng ta kiểm tra backup job, sau khi sửa cấu hình Backup Job, chúng ta chọn Start để chạy lịch Job để backup:

Kết quả, Backup 4 máy chủ thành công:


 

Nếu bị Troubleshoot do VBR Repository thiếu dung lượng sẽ báo lỗi:


  • Cách thêm dung lượng trống cho máy chủ Veeam Backup Repository:



Chọn menu phải chuột để Extend volume:




  • Sau khi tăng kích thước trống cho VBR Repository, chúng ta có thể đợi cho Job Backup tự resume chạy lại riêng máy chủ bị lỗi thiếu dung lượng sẽ tự động backup lại.


 

Lưu ý 1: Trường hợp các cụm máy chủ cài là Windows Core thì việc chọn Job backup kiểu Agent sẽ dẫn tới không có VMs nào được backup



 

Lưu ý 2: Nếu cần điều khiển các máy vật lý, Workstation, Máy tính để bàn (Desktop/ Laptop) hoặc máy chủ Ảo thông qua Windows Admin Center thì các máy có hệ điều hành Windows cần phải cấu hình Windows Firewall mở 4 dịch vụ: Windows Remote Management


 

 

Phần 2. Khôi phục các dữ liệu sau khi đã Backup:

Giả sử cần restore dạng bị xoá dữ liệu email, user accounts email hoặc mail box user, thì chúng ta sẽ chuyển sang trạng thái Application Items cuả EX1 hoặc EX2:

Bây giờ sử dụng hệ thống Explorer Veeam (Application Items) để so sánh các thay đổi của EX1, EX2, EDGE, FSW hiện thời so với bản backup

  • Nếu ở hệ thống EX1, EX2 hiện bị xoá nhầm hoặc tạo thêm Account mail của người dùng ngay sau bản đã backup.
  • Bây giờ quay lại VBR và bấm nút Compare with Production:

Sau đó bấm tiếp nút Show Changed Objects Only

Như vậy, chúng ta chỉ thấy dữ liệu email thư đã bị xoá, user accounts email hoặc mail box user đã bị xoá còn không thấy Account mail box hoặc thư mới tạo thêm.

Tương tự, nếu chúng ta thực hiện tiếp tục các lịch backup chỉ lưu những thay đổi của EX1, EX2, EDGE, FSW. Chúng ta hoàn toàn có thể restore những dữ liệu cũ cho tới mới thay đổi.

Lab 102. Mklink với việc đọc ghi và chạy ứng dụng Office 365 trên ổ cứng khác ổ Logic boot windows


1. Yêu cầu của vấn đề:

  • Chúng ta đang có MS Outlook và các dữ liệu mail dạng file OST và NST ở ổ C, do ổ cứng này có kích thước nhỏ, cần move sang ổ D / E hoặc F cần dung lượng rộng hơn.

2. Giả sử: MS Outlook 2016 đã được cài đặt, Email thì dùng giao thức oAuth2, Exchange Connector nên thư vẫn nằm ở máy chủ Exchange On-premise hoặc Exchange Online cho dù tôi có xoá các files có trong thư mục gốc do MS Outlook cài trên ổ C:\

Ví dụ: C:\Users\<tên username>\AppData\Local\Microsoft\Outlook\email@company.vn.ost và C:\Users\<tên username>\AppData\Local\Microsoft\Outlook\email@company.vn.nst

Tham khảo: Lệnh dùng trên CMD hoặc PowerShell với lệnh cấu trúc: mklink <c:\…. đường dẫn thư mục\tên các files mail box (không có files đó tồn tại ở đây)> <D:\đường dẫn thư mục mới\tên các files mailbox tương tự.

3. Phương án 1. Chỉ move riêng các Files OST và nst:


Ở ổ D tôi sẽ phải tạo ra thư mục chứa Outlook mail trước khi thực hiện lệnh mklink cho 2 files nói trên:

D:\Outlook



Để đề phòng mất dữ liệu outlook client đang có ở ổ C: tôi sẽ move ra một thư mục ở ổ D:\backup (dự phòng)


Do MS Outlook khi cài xong luôn có thư mục này rồi do vậy nếu định mklink trường hợp này sẽ phải áp dụng cho User profile db mail chưa có

Nếu không chúng ta sẽ gặp lỗi báo là File ost ở ổ C đã có rồi.

Như vậy, ở đây mình sẽ áp dụng kiểu khai báo trước file dữ liệu outlook tên file trùng với việc hệ thống mail settting User profile của MS Outlook tạo để cấu hình lệnh:

mklink chạy trước:

mklink “C:\Users\Account\AppData\Local\Microsoft\Outlook\email@company.vn.ost” “D:\outlook\email@company.vn.ost”

mklink “C:\Users\Account\AppData\Local\Microsoft\Outlook\email@company.vn.nst” “D:\outlook\email@company.vn.nst”


Sau lệnh trên ta sẽ kiểm tra trên ổ C:


Xuất hiện 4 files shortcut ở ổ C, Sau bước thực hiện này:

Chúng ta sẽ copy các dữ liệu Outlook (đã di chuyển sang ổ D:\Backup) và sẽ copy / moved về ổ D:\outlook


Sau khi copy 4 files outlook mail về thư mục D:\outlook xong


Chúng ta mở MS Outlook client


 

Sau đó kiểm tra lại 2 thư mục chứa 4 files Outlook mail


 

3. Phương án 2. Move toàn bộ Folder có chứa toàn bộ MS Office:

Tham khảo: Lệnh dùng trên CMD hoặc PowerShell với lệnh cấu trúc: mklink /J <c:\…. đường dẫn thư mục Microsoft Office (không có dữ liệu đó tồn tại ở đây)> <D:\đường dẫn thư mục mới>

Lab 100. Dựng máy ảo CentOS 8.x và cấu hìnhVNC server cho phép điều khiển từ Cloud Edge có GUI


Cấu hình network DHCP hoặc IP static:

Cấu hình ổ cứng VD làm Boot OS

Cấu hình LVM và các phân vùng riêng cho VD0 làm boot

Tạo tiếp vùng /boot/efi

Tiếp tục tạo SWAP

Tiếp tục tạo riêng phân vùng tất cả còn lại cho /home

Toàn bộ phân vùng

 

Phần 1. Cấu hình phân vùng ổ cứng CentOS 7,8:

Mount: /

Device Type: LVM Thin Provisioning

File System Type: ext4

RAID Level: RAID5

 

  • Lựa chọn cài CentOS8 theo môi trường – Server with GUI:

Và

Tham khảo 1: https://www.tecmint.com/create-raid-5-in-linux/

Tham khảo 2: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/configuring-raid-logical-volumes_configuring-and-managing-logical-volumes#raid-allocate-faultpolicy

 

Phần 2. Cài VNC-Server cho CentOS:

Tham khảo 3: https://onet.com.vn/configuring-vnc-server-on-centos-8.html

  • Cấu hình Firewall cho phép mở cổng VNC-Server:

  • Khởi động để cập nhật cấu hình cổng vừa mở trên firewall:

  • Kiểm tra tình trạng cấu hình Network của CentOS 8:

  • Bước tiếp theo cấu hình thuộc

 

Sau khi bật các chế độ Screen Sharing và Networks

 

Chúng ta nên cấu hình có yêu cầu mật khẩu để đảm bảo tách riêng 2 trạng thái Remote VNC chỉ có quyền View hoặc trạng thái được phép điều khiển máy ảo CentOS8

 

Phần 2. Cấu hình ở Guacamole

https://guacamole.apache.org/doc/gug/installing-guacamole.html

  • Tạo 1 Connector

  • Lưu lại cấu hình kết nối trên và Share cho các user có quyền sử dụng phần kết nối này.

 

  • Truy cập trang web Cloud Edge:

     

 

Nhược điểm của cách cấu hình VNC server trên CentOS 8 này là:

  1. VM hoặc Physical phải được Login vào màn hình CentOS 8 trước.
  2. Nếu reboot lại HĐH CentOS 8 thì kết nối của Guacamole không thể tự reconnect lại Remote VNC chỉ khi Admin Console phải login trước vào HĐH CentOS 8 để HĐH start VNC-Server.

Lab 6.3. Cài và cấu hình File Share Witness – FSW trên Windows Server Core 2019


Giới thiệu về công nghệ Lưu trữ VSA áp dụng cho EXCHANGE DAG 2019:

Giờ đây, chúng ta có thể tạo FSW không sử dụng CNO, nhưng trên thực tế, chỉ cần sử dụng tài khoản người dùng cục bộ trên máy chủ mà FSW được kết nối.

Điều này có nghĩa là KHÔNG cần kerberos, KHÔNG cần bộ điều khiển miền, KHÔNG cần chứng chỉ và KHÔNG cần Đối tượng tên cụm. Trong khi chúng tôi đang ở đó, KHÔNG cần tài khoản trên các nút, không cần Join domain.

Có nhiều tình huống mà điều này có thể được sử dụng, chẳng hạn như thiết bị NAS, cài đặt Windows không tham gia miền, v.v.

Cách thức hoạt động là trên Windows Server, bạn muốn đặt FSW, tạo tài khoản người dùng cục bộ (không phải quản trị), cấp cho tài khoản cục bộ đó toàn quyền đối với chia sẻ, kết nối cụm với chia sẻ.

Ví dụ: tôi có một máy chủ tên là SERVER và một phần chia sẻ có tên SHARE mà tôi muốn sử dụng làm FSW. Để tạo loại File Share Witness này chỉ có thể được thực hiện thông qua PowerShell. Các bước để thiết lập điều này là:

Ví dụ: tôi có một máy chủ tên là SERVER và một phần chia sẻ có tên SHARE mà tôi muốn sử dụng làm FSW. Để tạo loại File Share Witness này chỉ có thể được thực hiện thông qua PowerShell. Các bước để thiết lập điều này là:

  • Đăng nhập vào MÁY CHỦ và tạo tài khoản người dùng cục bộ (tức là FSW)
  • Tạo một thư mục trên MÁY CHỦ và chia sẻ nó ra ngoài
  • Cấp cho tài khoản người dùng cục bộ (FSW) toàn quyền chia sẻ
  • Đăng nhập vào một trong các nút cụm của bạn và chạy lệnh PowerShell:

Set-ClusterQuorum -FileShareWitness SERVERSHARE -Credential $(Get-Credential)

  • Bạn sẽ được nhắc nhập tài khoản và mật khẩu mà bạn nên nhập SERVERFSW và mật khẩu.

Viola!! Bạn đã hoàn thành vì chúng tôi vừa xử lý tất cả các tình huống trên. Cụm sẽ giữ tên và mật khẩu được mã hóa và không ai có thể truy cập được.

Đối với những trường hợp không có máy chủ bổ sung, bạn có thể sử dụng ổ USB được kết nối với bộ định tuyến không? Có, chúng tôi có khả năng đó và đơn giản như việc thiết lập nó trên máy chủ.

Chỉ cần cắm ổ USB của bạn vào cổng trong bộ định tuyến và truy cập vào giao diện của bộ định tuyến. Trong đó, bạn có thể thiết lập tên chia sẻ, tên người dùng và mật khẩu để truy cập. Sử dụng lệnh PowerShell ở trên trỏ nó tới bộ định tuyến và chia sẻ, và bạn đã sẵn sàng để sử dụng. Để trả lời câu hỏi tiếp theo của bạn, điều này hoạt động với SMB 2.0 trở lên. SMB 3.0 không bắt buộc đối với loại FSW.

 

Mô hình FSW và các giao thức chuẩn như sau:


Các bước thực hành dựng hệ thống FSW trên nền Windows Core server 2019:

Với máy chủ File Server Witness (viết tắt FSW) cho Exchange 2019 chi tiết cần:

  1. Máy chủ FSW cần cài tuần tự các bước cho Windows Core 2019 (không có giao diện) là 1 hoặc nhiều máy chủ tuỳ theo mô hình Exchange 2019 là Enterprise License 1 máy, DAG là 2 – 16 máy chủ.
  2. Các bước cài Windows core Server, sẽ giúp khâu chuẩn bị cài máy chủ FSW chạy tối ưu, bảo mật và ổn định gồm:
  • Bước 1. Cấu hình tối thiểu 2 ổ cứng C, D, trong đó C: format kiểu NTFS 4K (ngầm định của Microsoft x64bit), ổ D format kiểu ReFS 64K (thao tác thủ công trên Disk manager hoặc thông qua máy client Admin có cài tool Windows Admin Center).
  • Bước 2. Dùng sconfig lệnh để Đổi tên System Name
  • Bước 3: cấu hình IPv4 tĩnh
  • Bước 4: Cấu hình bật/tắt Remote Desktop
  • Bước 5: Join Domain. (nếu FSW nằm vùng DMZ thì không cần Join Domain, chỉ chạy Workgroup).

     

Chi tiết các bước thực hiện:


Nhập lệnh: Start PowerShell

Sau đó dùng tiếp lệnh trên PS:

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon’ -Name Shell -Value ‘PowerShell.exe’


Chúng ta sẽ sử dụng lệnh sconfig để thay đổi tất cả các tên theo thiết lập của bạn:

Trình tự cấu hình máy chủ FSW có thể là:


Cấu hình network:


Đổi tên máy thành: FSW


Join domain bằng lệnh sconfig



Bấm nút “No” và hệ thống yêu cầu restart , bấm nút Yes


cuối cùng đã hoàn thành


Kiểm tra phiên bản:

Dùng lệnh: Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer


Kiểm tra nhóm Administrators của máy Local phải có thành viên Admin của Domain:

Gõ lệnh: Get-LocalGroupMember “Administrators”


Gõ lệnh: Add-LocalGroupMember -Group “Administrators” -Member “Adatum\Administrator”


 

 

Bước 1: Thiết lập Máy chủ FSW:

Để định cấu hình và thiết lập Máy chủ tệp nhân chứng (FSW), hãy triển khai máy chủ FSW là vật lý hoặc Máy chủ Ảo được Join Domain và Vai trò Active Directory. Không sử dụng Bộ điều khiển miền (DC) của bạn làm máy chủ FSW.

Các bước như sau:

Trường hợp 1. máy chủ FSW có giao diện Windows Server 2019:

  • Truy cập máy chủ FSW và mở Administrative Tools và chọn Computer Management..


  • Tìm và nhấp đúp vào Administrators Group để mở thuộc tính.
  • Chuyển đến thành viên rồi nhấp vào Add.
  • Sau đó tìm kiếm và thêm Group Exchange Trusted Subsystem và nhấp vào Apply > OK.


 

Trường hợp 2. Máy chủ FSW cài trên Windows Server Core 2019 không có giao diện:

Chúng ta sẽ gõ lệnh trên PowerShell của máy chủ FSW:

Add-LocalGroupMember -Group “Administrators” -Member “Adatum\Exchange Trusted Sybsystem”


 

Tiếp theo, chúng ta cần tạo DAG để sau đó thêm các máy chủ thành viên.

Bước 2: Tạo Nhóm cơ sở dữ liệu Email dùng chung (DAG):

Để tạo Nhóm cơ sở dữ liệu Email dùng chung (DAG), bạn có thể sử dụng Trung tâm quản trị Exchange (EAC) hoặc Exchange Management Shell (EMS). Các bước như sau:

  • Đăng nhập vào Exchange Server và mở Exchange Admin Center (EAC).
  • Chuyển đến Servers> Database Availability Groups và nhấp vào +.


  • Nhập tên DAG1, địa chỉ Máy chủ FSW và đường dẫn thư mục FSW vào các trường tương ứng. Bạn có thể nhập 255.255.255.0 hoặc để trống địa chỉ IP và nhấp vào Lưu.


  • Nhóm cơ sở dữ liệu Email dùng chung sẽ được tạo.


Để tạo DAG bằng Exchange Management Shell (EMS), bạn có thể làm theo các bước sau:

  • Mở EMS và sau đó thực hiện cấu trúc lệnh sau:

New-DatabaseAvailabilityGroup -Name “DAGNAME” -WitnessServer “WitnessServerNameOrAddress” -WitnessDirectory “PathcToWitnessServerDirectory”

“dagname” “witnessservernameoraddress” “pathctowitnessserverdirectory” “/pathctowitnessserverdirectory” “/witnessservernameoraddress” “/dagname”

Ví dụ: New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer FSW.ADATUM.COM -WitnessDirectory E:\DAG1

Để kiểm tra xem DAG có được tạo thành công hay không, bạn có thể chạy lệnh sau trong EMS hoặc đăng nhập vào EAC và điều hướng đến Servers > Database Availability Groups.

Get-DatabaseAvailabilityGroup “dagname” | Format-List “/dagname”.

Ví dụ: Get-DatabaseAvailabilityGroup “DAG1 ” | Format-List “/DAG1“.

Bước 3: Thêm máy chủ thành viên vào DAG:

Bây giờ bạn đã tạo DAG, đã đến lúc thêm thành viên Exchange Server 2019 vào DAG. Các bước như sau:

  • Trong Trung tâm quản trị Exchange (EAC), điều hướng đến Servers> Database Availability Groups và nhấp vào Manage DAG Membership.


  • Sau đó bấm vào biểu tượng +.
  • Chọn Máy chủ Exchange 2019 mà bạn muốn thêm vào DAG bằng nút add-> rồi nhấp vào OK.


  • Sau khi thêm, nhấp vào Lưu.
  • Thao tác này sẽ bắt đầu cài đặt Windows Failover Clustering trong Máy chủ Exchange 2019 thành viên đã chọn.


Nếu chúng ta gặp lỗi dừng ở đây:


Thì phải quay lại lệnh cmdlet của máy chủ EX1

check if the Windows Failover Clustering is installed on EX1.xyz.com.bd, and make sure you have reboot the server to complete the installation:

get-WindowsFeature Failover-Clustering


Install-WindowsFeature Failover-Clustering


Chú ý: không cần reboot?


Nguyên nhận: Ipv6 đang được bật ở các máy chủ EX thành viên.

Cách xử lý:

Chúng ta cần cấu hình trong Regedit của các máy chủ EX, disable IPv6 bằng cách tạo thêm tham số và giá trị kiểu: 32-bit DWORD registry value name: DisabledComponents thông qua Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters và giá trị là: ffffffff. Sau khi hoàn thành ở tất cả các máy chủ EX, ta sẽ khởi động từng máy chủ.

Máy chủ EX1:


Sau đó khởi động máy chủ EX1.

và tiếp theo máy chủ EX2:


Khởi động lại EX2.

  • Sau khi hoàn tất, Máy chủ Exchange 2019 sẽ được thêm vào DAG.


  • Nhấp vào Đóng. Bạn sẽ thấy nhóm khả dụng của cơ sở dữ liệu với tên của máy chủ FSW và máy chủ thành viên trong Trung tâm quản trị Exchange bên dưới Servers> Database Availability Groups.


Bước 4: Thêm bản sao cơ sở dữ liệu Email:

Cuối cùng, bạn có thể thêm các bản sao cơ sở dữ liệu hộp thư vào máy chủ hộp thư thành viên để cho phép sao chép liên tục và đảm bảo cơ sở dữ liệu vẫn hoạt động ngay cả khi máy chủ thành viên bị lỗi. Các bước như sau:

  • Mở EAC và điều hướng đến Servers> Databases.
  • Chọn cơ sở dữ liệu bạn muốn thêm vào máy chủ thành viên và nhấp vào biểu tượng (ba dấu chấm).
  • Chọn Thêm Add database copy.
  • Nhấp vào Duyệt, chọn Exchange Server và nhấp vào OK.
  • Nhấp vào để lưu. Thao tác này sẽ tạo cơ sở dữ liệu hộp thư và các bản sao tệp nhật ký trên máy chủ thành viên đã chọn.
  • Sau khi quá trình hoàn tất, bấm Đóng.
  • Để kiểm tra xem các bản sao cơ sở dữ liệu có được thêm vào máy chủ thành viên hay không, hãy nhấp vào biểu tượng làm mới bên dưới Servers> Databases.
  • Cột Máy chủ có bản sao sẽ hiển thị máy chủ Exchange 2019 (máy chủ thành viên) nơi các bản sao cơ sở dữ liệu được thêm vào.



Tương tự với EX2





Ở giai đoạn này, bạn đã triển khai và định cấu hình thành công Exchange 2019 DAG từ đầu.

 

Xác minh thư mục File Share Witness:

Chuyển đến ổ đĩa E:\ của máy chủ FSW và xác minh rằng thư mục DAG1 đã được tạo. Sau khi mở thư mục, bạn sẽ tìm thấy thư mục GUID và trong đó bạn sẽ thấy hai tệp có tên:

  • VerifyShareWriteAccess.txt
  • Witness.log

Có thể mất vài phút trước khi cả hai tệp hiển thị. Kích thước nhỏ, và nó sẽ giữ nguyên như vậy.

Ghi chú: Loại trừ thư mục File Share Witness khỏi sản phẩm Chống vi-rút/Bảo mật của bạn.


Tóm lại:

Trong bài Labs này, chúng ta đã chia sẻ các bước đơn giản để triển khai và định cấu hình các nhóm cơ sở dữ liệu Email dùng chung cho Exchange Server 2019 từ đầu. Mặc dù Exchange 2019 DAG cung cấp khả năng phục hồi và bảo vệ trang khỏi sự cố cơ sở dữ liệu và máy chủ nhưng chừng đó không phải là giải pháp thay thế cho sao lưu/khôi phụ hệ thống.

Bạn vẫn cần duy trì sao lưu cơ sở dữ liệu dựa trên VSS thường xuyên để tránh mất dữ liệu vĩnh viễn, bị mã hoá dữ liệu do Ransomware hoặc khi thảm họa xảy ra.

Bên cạnh đó, việc giữ một phần mềm khôi phục máy chủ Exchange, chẳng hạn như: Commvault Backup, Veeam Backup, Stellar Repair for Exchange, rất được khuyến khích. Nó rất hữu ích khi bạn cần khôi phục hộp thư từ cơ sở dữ liệu Exchange bị hỏng hoặc cả hệ thống Exchange Server bị hỏng. Nó lưu các hộp thư được trích xuất từ cơ sở dữ liệu đã sửa sang định dạng PST và cung cấp các tùy chọn để xuất chúng trực tiếp sang Office 365 hoặc Live Exchange Server khác.

Lab 6.2. Cài và Cấu hình Edge Transport Server for Exchange 2019 CU10 – DAG trên Windows Core 2019


Với máy chủ Edge Transport cho Exchange 2019 chi tiết cần:

  1. Máy chủ Edge Transport for Exchange 2019 cần cài tuần tự các bước cho Windows Core 2019 (không có giao diện) là 1 hoặc nhiều máy chủ tuỳ theo mô hình Exchange 2019 là Enterprise License 1 máy, DAG là 2 máy trở lên.
  2. Các bước cài Windows core Server, sẽ giúp khâu chuẩn bị cài máy chủ Edge Transport for Exchange 2019 gồm:
  • Bước 1. Đổi tên System Name
  • Bước 2: cấu hình IPv4 tĩnh
  • Bước 3: Cấu hình bật/tắt Remote Desktop
  • Bước 4: Join Domain.


Nhập lệnh: Start PowerShell

Sau đó dùng tiếp lệnh trên PS:

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon’ -Name Shell -Value ‘PowerShell.exe’


Chúng ta sẽ sử dụng lệnh: sconfig để thay đổi tất cả các tên theo thiết lập của bạn:


Join domain bằng lệnh sconfig


Trình tự cấu hình máy chủ Edge Transport có thể là:


Cấu hình Network


Đổi tên máy chủ: EDGE

Cấu hình lại Time Zone:


Join Domain với DC1: adatum.com



Cuối cùng đã hoàn thành


Kiểm tra phiên bản:

Dùng lệnh: Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer


Kiểm tra nhóm Administrators của máy Local phải có thành viên Admin của Domain:

Gõ lệnh: Get-LocalGroupMember “Administrators”


Gõ lệnh: Add-LocalGroupMember -Group “Administrators” -Member “Adatum\Administrator”


Bước cài thêm các tính năng Windows Core 2019 với Global Catalog và Domain Controller:

Trước khi bắt đầu cài đặt Exchange 2019, chúng ta cần chuẩn bị Domain.

  • Chúng ta sẽ sử dụng lệnh PowerShell sau để cài đặt thành phần HĐH cần thiết cho Microsoft UCMA 4.0 và thành phần HĐH cần thiết cho Chuẩn bị Active Directory.
  • Có thể kiểm tra xem bạn đang login vào máy chủ Windows Core 2019 bằng user local Admin hay Domain Admin


  • Nhập dòng lệnh trên PowerShell “viết tắt: PS” của máy chủ Windows Core 2019: Install-WindowsFeature -Name “RSAT-AD-PowerShell”


  • Nhập tiếp dòng lệnh trên PS: Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS




  • Nhập tiếp dòng lệnh PS: Import-Module ActiveDirectory
  • Nhập tiếp dòng lệnh PS: netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes


  • Nhập tiếp dòng lệnh PS: Install-WindowsFeature -Name Web-Server -IncludeManagementTools


Bước tiếp theo download 3 phần mềm cần thiết để hỗ trợ cài chuẩn bị cho Exchange server, sao chép chúng vào thư mục C:\Setup hoặc tạo gộp 1 file .iso để mount thành CDrom ISO ổ logic D:\

Nhập lệnh PS:> D:

Và tiếp theo kiểm tra ổ D bằng lệnh: PS D:\>dir

Tiếp theo nhập lệnh chạy file .net framework 4.8: PS D:\>.\ndp48-devpack-enu.exe



 

Installing Visual C++ 2013 Redistributable:

  • Nhập lệnh trên PS: D:\>.\vcredist_x64.exe


The UCMA installable is located under the “UCMARedist” folder:

  • Nhập lệnh PS: D:\>.\UCMARedist\Setup.exe


Bước chuẩn bị cài Exchange 2019

  • Mount bộ cài là file Exchange 2019 UC10 x64.ISO:


Nhập lệnh PS: D:\Setup.exe /m:install /roles:e /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents


Đợi cho tới completed hết các hạng mục cài.

Trường hợp 1: Nếu chúng ta cài máy chủ Edge Transport này là lần đầu tiên và không có tính năng này trên EX1, EX2 (Exchange Servers) thì


 

Trường hợp 2: Nếu chúng ta gặp lỗi như hình dưới là do trong quá trình cài Edge Transport này thì trước đó đã được cài đầy đủ chúng ở EX1 hoặc EX2 hoặc chính máy chủ Edge Server đã được cài ít nhất 1 lần trước ?


Do vậy sẽ phải dùng lệnh sau để uninstall và cài lại:

PS D:\>.\Setup.exe /m:uninstall /IAcceptExchangeServerLicenseTerms


Lab 6.1. Cài và cấu hình mô hình EXCHANGE SERVER DAG 2019 trên nền Windows Core 2019


Phần 1. Khái niêm “Database Availability Group viết tắt DAG “:

  • Nhóm tính khả dụng của cơ sở dữ liệu hoặc DAG là thành phần cơ bản và khối xây dựng trong Exchange Server để có tính sẵn sàng cao và khả năng phục hồi trang web mail.
  • Bạn có thể có tối đa 16 Máy chủ Exchange trong một DAG hoạt động với nhau và cung cấp khả năng khôi phục cấp cơ sở dữ liệu tự động sau khi cơ sở dữ liệu Exchange (.edb), máy chủ hộp thư bị lỗi hoặc lỗi mạng.
  • Bạn có thể thiết lập hai loại DAG khác nhau cho Exchange Server 2019:

Loại 1. DAG với Điểm truy cập quản trị cụm hoặc VIP (IP tĩnh hoặc DHCP cấp động) “DAG with Cluster Administrative Access Point or IP (static or DHCP)”:

Mô hình Lab cũ 2013/2016:


Loại 2. DAG không có Điểm truy cập quản trị cụm hoặc VIPDAG Non-Cluster Administrative Access Point or VIP.

Mô hình Lab mới 2019/2022:


  • Tuy nhiên, thiết lập DAG mặc định trong Exchange Server 2019 sẽ là Loại 2 DAG không có Điểm truy cập quản trị cụm hoặc VIP.

Trong bài Lab này, bạn sẽ tìm hiểu các bước để xây dựng và thiết lập Exchange Server 2019 DAG mà không cần “điểm truy cập quản trị cụm” từ đầu.

 

Phần 2. Các bước chuẩn bị cấu hình EXCHANGE DAG:

Các bước để định cấu hình và xây dựng Exchange Server 2019 DAG từ đầu

  • Để định cấu hình và xây dựng Exchange Server 2019 DAG, bạn cần thiết lập ít nhất hai máy chủ hoặc máy ảo vật lý khác nhau chạy cùng một phiên bản Exchange Server 2019.
  • Đảm bảo rằng cả hai máy chủ đều được cấu hình chính xác, tuần tự và giống nhau.
  • Bạn cũng cần có Máy chủ Lưu trữ Trung gian “File Server Witness – viết tắt: FSW“, điều này vô cùng quan trọng để duy trì số máy chủ Exchange dự kiến khi các máy chủ đều ở trong DAG “là 2/ 4/ 6 /8 /10/12/14/16 máy chủ Exchange là các thành viên chẵn trong DAG”.
  • Tuy nhiên, nếu bạn đang thiết lập DAG với số lượng thành viên lẻ “1/3/5/7/9/11/13/15″ máy chủ Exchange”, thì bạn không cần thiết lập Máy chủ Lưu trữ Trung gian “FSW” nói trên.

Vì chúng ta đang thiết lập hai Exchange Server 2019 trong DAG nên chúng ta sẽ thiết lập một máy chủ FSW. Các bước như sau:

Bước 1: Cài và thiết lập máy chủ EX2 trên Windows Core 2019:


 



Với máy chủ EX2 – EXCHANGE 2019 chi tiết cần:

  1. Máy chủ EX2 cần cài tuần tự các bước cho Windows Core 2019 (không có giao diện) là 1 hoặc nhiều máy chủ tuỳ theo mô hình Exchange 2019 là Enterprise License 1 máy, DAG là 2 máy trở lên.
  2. Các bước cài Windows core Server, sẽ giúp khâu chuẩn bị cài máy chủ Exchange 2019 gồm:
  • Bước 1. Đổi tên System Name
  • Bước 2: cấu hình IPv4 tĩnh
  • Bước 3: Cấu hình bật/tắt Remote Desktop
  • Bước 4: Join Domain.


Nhập lệnh: Start PowerShell

Sau đó dùng tiếp lệnh trên PS:

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon’ -Name Shell -Value ‘PowerShell.exe’


Chúng ta sẽ sử dụng lệnh sconfig để thay đổi tất cả các tên theo thiết lập của bạn:


Chúng ta sẽ sử dụng lệnh sconfig để thay đổi tất cả các tên theo thiết lập của bạn:

Trình tự cấu hình máy chủ EX2 có thể là:


Cấu hình network:


Thay đổi time zone:


Thay đổi tên máy chủ Exchange: EX2


Khởi động lại máy chủ và cấu hình Join domain bằng lệnh sconfig:



Bấm nút No không thay đổi tên máy chủ và tiếp tục bấm Yes để khởi động lại máy chủ lần 3


Khởi động lại máy chủ, đăng nhập lại bằng user AD


và cuối cùng đã hoàn thành


Kiểm tra phiên bản:

Dùng lệnh: Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer


Kiểm tra nhóm Administrators của máy Local phải có thành viên Admin của Domain:

Gõ lệnh: Get-LocalGroupMember “Administrators”


Gõ lệnh: Add-LocalGroupMember -Group “Administrators” -Member “Adatum\Administrator”


Bước cài thêm các tính năng Windows Core 2019 với Global Catalog và Domain Controller:

Trước khi bắt đầu cài đặt Exchange 2019, chúng ta cần chuẩn bị Domain.

  • Chúng ta sẽ sử dụng lệnh PowerShell sau để cài đặt thành phần HĐH cần thiết cho Microsoft UCMA 4.0 và thành phần HĐH cần thiết cho Chuẩn bị Active Directory.
  • Có thể kiểm tra xem bạn đang login vào máy chủ Windows Core 2019 bằng user local Admin hay Domain Admin


  • Nhập dòng lệnh trên PowerShell “viết tắt: PS” của máy chủ Windows Core 2019: Install-WindowsFeature -Name “RSAT-AD-PowerShell”


  • Nhập tiếp dòng lệnh trên PS: Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS




  • Nhập tiếp dòng lệnh PS: Import-Module ActiveDirectory
  • Nhập tiếp dòng lệnh PS: netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes


  • Nhập tiếp dòng lệnh PS: Install-WindowsFeature -Name Web-Server -IncludeManagementTools


Bước tiếp theo download 3 phần mềm cần thiết để hỗ trợ cài chuẩn bị cho Exchange server, sao chép chúng vào thư mục C:\Setup hoặc tạo gộp 1 file .iso để mount thành CDrom ISO ổ logic D:\


PS C:\windows\system32> gõ lệnh D:

PS D:\> gõ lệnh dir để xác định các tên phần mềm chạy:


Nhập lệnh PS:> D:

Và tiếp theo kiểm tra ổ D bằng lệnh: PS D:\>dir

Tiếp theo nhập lệnh chạy file .net framework 4.8: PS D:\>.\ndp48-devpack-enu.exe



Khởi động lại máy chủ EX2 lần 4.

Installing Visual C++ 2013 Redistributable:

  • Nhập lệnh trên PS: D:\>.\vcredist_x64.exe


The UCMA installable is located under the “UCMARedist” folder:

  • Nhập lệnh PS: D:\>.\UCMARedist\Setup.exe


Sau khi cài thành công 3 tools này, chúng ta nên khởi động lại máy chủ EX2.

Bước chuẩn bị cài Exchange 2019

  • Mount bộ cài là file Exchange 2019 UC10 x64.ISO:


Nhập lệnh PS: D:\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents


Hệ thống có thể báo lỗi dừng việc cài do đã kiểm tra xong các Role.

Bắt đầu chính thức cài Exchange Server 2019:

  • Nhập lệnh PS D:\> .\Setup.exe


Trường hợp 1: Bình thường chưa bao giờ cài EXCHANGE 2 thì sẽ cài tuần tự các bước





 


 





  • Cuối cùng đợi cho quá trình cài 14 bước hoàn thành




Trường hợp 2:

Tôi đã từng cài EX2 là bản Windows 2019 có giao diện và đang vận hành cùng với EX1 kiểu EXCHANG 2019 DAG (chưa cấu hình DAG, chưa có FSW), nên khi chúng ta bỏ và dựng mới bản EX2 trên nền Windows Core 2019 sẽ gặp lỗi:


Lúc đó sẽ bấm nút OK, và nhập lại lệnh PS D:\> .\Setup.exe /m:RecoverServer / IAcceptExchangeServerLicenseTerms /InstallWindowsComponents


Hệ thống mailbox trên con EX2 cũ (có giao diện) bắt chúng ta phải dùng lệnh Recovery để khôi phục các dữ liệu email của Admin và người dùng trước vẫn có.


 

Như vậy, tình huống phức tạp (đã từng dựng EXCHANGE DAG 2019 và có dữ liệu Email, cấu hình đang vận hành theo mô hình EX1, EX2 có giao điện

Và tôi đã cố tình/ vô tình xoá EX2 (ổ cứng cũ đang có dữ liệu Email, cấu hình) là máy chủ Exchange đang chạy trong cụm DAG đã có, và dựng mới EX2 trên Windows Core 2019 (ổ cứng hoàn toàn mới).


Sau khi khởi động lại máy chủ EX2 thành công.

Ở đây chúng ta có thể test https://ex2/owa để xem account: administrator@adatum.com đã từng có thư đến/đi có mở lại bình thường lại không (mặc dù máy chủ EX2 là bị xoá tất cả dữ liệu có trên ổ cứng và cài mới lại windows core 2019.


Bước 2: Cài và Thiết lập Máy chủ EX1 trên nền Windows Core 2019:

Trường hợp 1:

Chúng tôi đã cài EX1 chạy trên nền Windows Server 2019 (có giao diện) và chạy cùng với EX2 cũng trên nền Windows Server 2019 (có cấu hình giao diện và giống với EX1) theo nguyên tắc thông thường của Cụm máy chủ EXCHANGE DAG 2019. Đã có email, cấu hình của các hòm thư Administrator@adatum.com

 

Trường hợp 2:

Chúng ta vừa cài lại mới EX2 chạy trên nền Windows Core 2019 (không có giao diện) và mọi dữ liệu email, cấu hình được recovery từ hệ thống EX2 cũ sang EX2 được cấu hình mới thông qua lệnh: PS D:\> .\Setup.exe /m:RecoverServer / IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

 

Trường hợp 3:

Chúng ta tiếp tục phá bỏ EX1 đang chạy trên nền Windows Server 2019 và chuyển cài mới lại sang dạng Windows Core 2019 (không có giao diện) và sẽ kiểm tra xem mọi dữ liệu email, cấu hình có được recovery từ hệ thống EX1 cũ sang không.

Bắt đầu lặp lại bước cài giống EX2 core 2019 ở Bước 1.

Xoá VD của EX1 đang chạy


Và sau khi xoá hẳn ổ cứng ảo VD đó, chúng ta turn off máy chủ EX1


Sau đó settings để tạo lại ổ VD mới



 



Mount ISO bộ cài Windows Server 2019 x64


Boot lên và chọn cài Windows 2019 Datacenter







Với máy chủ EX1 – EXCHANGE 2019 chi tiết cần:

  1. Máy chủ EX1 cần cài tuần tự các bước cho Windows Core 2019 (không có giao diện) là 1 hoặc nhiều máy chủ tuỳ theo mô hình Exchange 2019 là Enterprise License 1 máy, DAG là 2 máy trở lên.
  2. Các bước cài Windows core Server, sẽ giúp khâu chuẩn bị cài máy chủ Exchange 2019 gồm:
  • Bước 1. Đổi tên System Name
  • Bước 2: cấu hình IPv4 tĩnh
  • Bước 3: Cấu hình bật/tắt Remote Desktop
  • Bước 4: Join Domain.


Nhập lệnh: Start PowerShell

Sau đó dùng tiếp lệnh trên PS:

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon’ -Name Shell -Value ‘PowerShell.exe’


Chúng ta sẽ sử dụng lệnh sconfig để thay đổi tất cả các tên theo thiết lập của bạn:


Chúng ta sẽ sử dụng lệnh sconfig để thay đổi tất cả các tên theo thiết lập của bạn:

Trình tự cấu hình máy chủ EX1 có thể là:


Cấu hình network:


Thay đổi time zone:


Thay đổi tên máy chủ Exchange: EX1


Khởi động lại máy chủ và cấu hình Join domain bằng lệnh sconfig:



Bấm nút No không thay đổi tên máy chủ và tiếp tục bấm Yes để khởi động lại máy chủ lần 3


Khởi động lại máy chủ, đăng nhập lại bằng user AD


và cuối cùng đã hoàn thành


Kiểm tra phiên bản:

Dùng lệnh: Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer


Kiểm tra nhóm Administrators của máy Local phải có thành viên Admin của Domain:

Gõ lệnh: Get-LocalGroupMember “Administrators”


Gõ lệnh: Add-LocalGroupMember -Group “Administrators” -Member “Adatum\Administrator”


Bước cài thêm các tính năng Windows Core 2019 với Global Catalog và Domain Controller:

Trước khi bắt đầu cài đặt Exchange 2019, chúng ta cần chuẩn bị Domain.

  • Chúng ta sẽ sử dụng lệnh PowerShell sau để cài đặt thành phần HĐH cần thiết cho Microsoft UCMA 4.0 và thành phần HĐH cần thiết cho Chuẩn bị Active Directory.
  • Có thể kiểm tra xem bạn đang login vào máy chủ Windows Core 2019 bằng user local Admin hay Domain Admin


  • Nhập dòng lệnh trên PowerShell “viết tắt: PS” của máy chủ Windows Core 2019: Install-WindowsFeature -Name “RSAT-AD-PowerShell”


  • Nhập tiếp dòng lệnh trên PS: Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS




  • Nhập tiếp dòng lệnh PS: Import-Module ActiveDirectory
  • Nhập tiếp dòng lệnh PS: netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes


  • Nhập tiếp dòng lệnh PS: Install-WindowsFeature -Name Web-Server -IncludeManagementTools


Bước tiếp theo download 3 phần mềm cần thiết để hỗ trợ cài chuẩn bị cho Exchange server, sao chép chúng vào thư mục C:\Setup hoặc tạo gộp 1 file .iso để mount thành CDrom ISO ổ logic D:\


PS C:\windows\system32> gõ lệnh D:

PS D:\> gõ lệnh dir để xác định các tên phần mềm chạy:


Nhập lệnh PS:> D:

Và tiếp theo kiểm tra ổ D bằng lệnh: PS D:\>dir

Tiếp theo nhập lệnh chạy file .net framework 4.8: PS D:\>.\ndp48-devpack-enu.exe



Khởi động lại máy chủ EX1 lần 4.

Installing Visual C++ 2013 Redistributable:

  • Nhập lệnh trên PS: D:\>.\vcredist_x64.exe


The UCMA installable is located under the “UCMARedist” folder:

  • Nhập lệnh PS: D:\>.\UCMARedist\Setup.exe


Sau khi cài thành công 3 tools này, chúng ta nên khởi động lại máy chủ EX2.

Bước chuẩn bị cài Exchange 2019

  • Mount bộ cài là file Exchange 2019 UC10 x64.ISO:


Nhập lệnh PS: D:\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents


Hệ thống có thể báo lỗi dừng việc cài do đã kiểm tra xong các Role.

Bắt đầu chính thức cài Exchange Server 2019:

Tôi đã từng cài EX1 là bản Windows 2019 có giao diện và đang vận hành cùng với EX2 kiểu EXCHANG 2019 DAG (chưa cấu hình DAG, chưa có FSW), nên khi chúng ta bỏ và dựng mới bản EX1 trên nền Windows Core 2019 sẽ gặp lỗi:

Chúng ta nhập lại lệnh PS D:\> .\Setup.exe /m:RecoverServer / IAcceptExchangeServerLicenseTerms /InstallWindowsComponents



Sau khi khởi động lại EX1 khi recover xong EXCHANGE 2019 core


 

Lab 7. Cách khôi phục tài khoản đã bị xoá ở AD windows Server


Câu hỏi: người quản trị đã vô tình xoá nhầm Tài khoản trên AD Windows Server, vậy có cách nào khôi phục lại tài khoản này ?

Ví dụ: tôi có 1 tài khoản trên AD User


 


  • Đã cố tình hoặc xoá nhập Account trước khi bật chế độ AD Recycle bin.

Tham khảo 1: https://www.lepide.com/how-to/restore-deleted-objects-in-active-directory.html

Tham khảo 2: https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/retore-deleted-accounts-and-groups-in-ad

Các công cụ gốc để khôi phục các đối tượng đã xóa:

Trong AD, bạn có thể sử dụng các công cụ sau để khôi phục các đối tượng đã xóa:

  1. PowerShell
  2. Tiện ích LDP
  3. Trung tâm quản trị Active Directory (áp dụng cho Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 và Windows Server 2012)

Để bất kỳ phương pháp nào ở trên hoạt động, Thùng rác “AD Recycle Bin” phải được bật. Nếu Thùng rác không được bật, hầu hết các thuộc tính đối tượng sẽ bị xóa khi các đối tượng bị xóa. Các đối tượng vẫn có thể được khôi phục, nhưng các thuộc tính bị thiếu sẽ phải được thêm lại theo cách thủ công.

Mặt khác, nếu Thùng rác được bật, các đối tượng và tất cả các thuộc tính của chúng được giữ nguyên trong thời gian tồn tại theo cấu hình mặt định của ADSI Edit là 180 ngày, có thể được đặt bằng cách thay đổi thuộc tính msDS-deletedObjectLifetime.

Những hạn chế của các công cụ khôi phục có sẵn của Windows AD:

  • Tìm kiếm các đối tượng đã xóa cụ thể bằng tiện ích PowerShell và LDP rất tốn thời gian.
  • Theo mặc định, các đối tượng máy tính và người dùng được đánh dấu không chứa mật khẩu (Unicode-pwd) và do đó, mật khẩu của tài khoản máy tính và người dùng đã khôi phục sẽ không được khôi phục.
  • Mật khẩu của tài khoản người dùng đã khôi phục phải được đặt lại và quản trị viên hệ thống phải thêm lại các đối tượng máy tính vào miền theo cách thủ công.
  • Để khôi phục mật khẩu người dùng và máy tính, giá trị của thuộc tính searchFlag trên đối tượng lược đồ Unicode-pwd phải được thay đổi từ 0 thành 8.
  • Thùng rác gốc phải được bật để thực hiện khôi phục hoàn toàn, điều này có thể làm tăng kích thước của Cây thông tin thư mục (DIT).
  • Các đối tượng đã vượt quá thời gian vòng đời của cấu hình mặc định 180 ngày sẽ không thể được khôi phục.

 

Nếu download và cài tool của hãng thứ ba:

https://www.manageengine.com/ad-recovery-manager/638563/ManageEngine_RecoveryManagerPlus_Bundle.exe

 

  • RecoveryManager Plus của ManageEngine cho phép bạn khắc phục tất cả những thiếu sót của các công cụ gốc đồng thời tăng thêm giá trị bằng việc bổ sung các khả năng khác của nó.
  • Với RecoveryManager Plus, bạn có thể khôi phục các đối tượng với tất cả các thuộc tính còn nguyên vẹn, ngay cả khi Thùng rác gốc không được bật;
  • Điều này có thể thực hiện được vì RecoveryManager Plus đi kèm với tính năng Thùng rác của riêng nó.
  • Tất cả các đối tượng AD đã bị xóa có thể được tìm thấy ở đó và thậm chí bạn có thể xem trước các thuộc tính sẽ được khôi phục cùng với đối tượng.
  • Bạn cũng có thể sử dụng các bộ lọc có sẵn để giới hạn kết quả tìm kiếm đối với loại đối tượng được yêu cầu (người dùng, OU, nhóm, v.v.) hoặc tìm kiếm đối tượng đã xóa theo tên.


RecoveryManager Plus là giải pháp thay thế tốt hơn cho các công cụ gốc: không có tập lệnh PowerShell Script;

không cần phải sàng lọc vô số mục để tìm đối tượng đã xóa, như trong tiện ích LDP.

 

Các tính năng chính khác của RecoveryManager Plus:

Bên cạnh việc khôi phục các đối tượng đã xóa, RecoveryManager Plus là một công cụ đa diện với một số khả năng khiến nó trở thành công cụ bắt buộc phải có đối với các quản trị viên hệ thống muốn có toàn quyền kiểm soát nội dung trong AD của họ.


 

Lab thực hành:

  • Tôi cài RecoveryManager Plus nên máy chủ AD-DS:



 



 



 


 


User: admin | pass ngầm định: admin


Trước khi muốn có thể khôi phục được Account vừa xoá/ đã xoá bạn cần phải Backup

Hãy nhập tài khoản thuộc nhóm Domain Admins có quyền để backup lại toàn bộ dữ liệu AD DC

Nếu ngầm định là backup All thì hệ thống đã tự chọn cho bạn


Nếu bạn muốn lựa chọn hãy bấm từng dấu + trong 2 mục để chọn riêng các mục muốn backup:



 

Khi bấm nút Backup Now, màn hình xuất hiện thông tin


Thu nhỏ màn hình Web browser có thể nhìn thấy


Chúng ta chuyển qua màn hình cấu hình Backup bằng thao tác:


 


Muốn kiểm tra thư mục chứa bản backup




Sau khi cấu hình xong backup, sẽ có hiển thị danh mục Job lịch backup


Bây giờ quay lại màn Menu Backup và chạy lệnh Backup ngay lập tức


  • Để khôi phục lại Tài khoản đã xoá nhầm



Hãy bấm chọn sang mục Recycle to:



Sau đó bám Save và kéo xuống dưới màn hình có thông tin và bấm nút Restore



 

Sau cùng chúng ta mở lại màn AD User and Computer để refresh OU nơi chứa tài khoản vừa được Restore bằng RecoveryManagerPlus để kiểm tra


Tài khoản sẽ hiện ra với chỉ thông tin Tài khoản và mật khẩu như cũ.



Các tham số cấu hình, phân quyền “member of” có trong tài khoản (Objects) sẽ mất và chúng ta sẽ phải điền bổ sung thông tin thủ công.

Lab 6. Cài và cấu hình mô hình EXCHANGE SERVER DAG 2019


Phần 1. Khái niêm “Database Availability Group viết tắt DAG “:

  • Nhóm tính khả dụng của cơ sở dữ liệu hoặc DAG là thành phần cơ bản và khối xây dựng trong Exchange Server để có tính sẵn sàng cao và khả năng phục hồi trang web mail.
  • Bạn có thể có tối đa 16 Máy chủ Exchange trong một DAG hoạt động với nhau và cung cấp khả năng khôi phục cấp cơ sở dữ liệu tự động sau khi cơ sở dữ liệu Exchange (.edb), máy chủ hộp thư bị lỗi hoặc lỗi mạng.
  • Bạn có thể thiết lập hai loại DAG khác nhau cho Exchange Server 2019:

Loại 1. DAG với Điểm truy cập quản trị cụm hoặc VIP (IP tĩnh hoặc DHCP cấp động) “DAG with Cluster Administrative Access Point or IP (static or DHCP)”:

Mô hình Lab cũ 2013/2016:


Loại 2. DAG không có Điểm truy cập quản trị cụm hoặc VIP “DAG Non-Cluster Administrative Access Point or VIP.

Mô hình Lab mới 2019/2022:


  • Tuy nhiên, thiết lập DAG mặc định trong Exchange Server 2019 sẽ là Loại 2 DAG không có Điểm truy cập quản trị cụm hoặc VIP.

Trong bài Lab này, bạn sẽ tìm hiểu các bước để xây dựng và thiết lập Exchange Server 2019 DAG mà không cần “điểm truy cập quản trị cụm” từ đầu.

Phần 2. Các bước chuẩn bị cấu hình EXCHANGE DAG:

Các bước để định cấu hình và xây dựng Exchange Server 2019 DAG từ đầu

  • Để định cấu hình và xây dựng Exchange Server 2019 DAG, bạn cần thiết lập ít nhất hai máy chủ hoặc máy ảo vật lý khác nhau chạy cùng một phiên bản Exchange Server 2019.
  • Đảm bảo rằng cả hai máy chủ đều được cấu hình chính xác, tuần tự và giống nhau.
  • Bạn cũng cần có Máy chủ Lưu trữ Trung gian “File Server Witness – viết tắt: FSW“, điều này vô cùng quan trọng để duy trì số máy chủ Exchange dự kiến khi các máy chủ đều ở trong DAG “là 2/ 4/ 6 /8 /10/12/14/16 máy chủ Exchange là các thành viên chẵn trong DAG”.
  • Tuy nhiên, nếu bạn đang thiết lập DAG với số lượng thành viên lẻ “1/3/5/7/9/11/13/15″ máy chủ Exchange”, thì bạn không cần thiết lập Máy chủ Lưu trữ Trung gian “FSW” nói trên.

Vì chúng ta đang thiết lập hai Exchange Server 2019 trong DAG nên chúng ta sẽ thiết lập một máy chủ FSW. Các bước như sau:

 

Bước 1: Thiết lập Máy chủ FSW:

Để định cấu hình và thiết lập Máy chủ tệp nhân chứng (FSW), hãy triển khai máy chủ FSW là vật lý hoặc Máy chủ Ảo được Join Domain và Vai trò Active Directory. Không sử dụng Bộ điều khiển miền (DC) của bạn làm máy chủ FSW.

Các bước như sau:

  • Truy cập máy chủ FSW và mở Administrative Tools và chọn Computer Management..


  • Tìm và nhấp đúp vào Administrators Group để mở thuộc tính.
  • Chuyển đến thành viên rồi nhấp vào Add.
  • Sau đó tìm kiếm và thêm Group Exchange Trusted Subsystem và nhấp vào Apply > OK.


Tiếp theo, chúng ta cần tạo DAG để sau đó thêm các máy chủ thành viên.

Bước 2: Tạo Nhóm cơ sở dữ liệu Email dùng chung (DAG):

Để tạo Nhóm cơ sở dữ liệu Email dùng chung (DAG), bạn có thể sử dụng Trung tâm quản trị Exchange (EAC) hoặc Exchange Management Shell (EMS). Các bước như sau:

  • Đăng nhập vào Exchange Server và mở Exchange Admin Center (EAC).
  • Chuyển đến Servers> Database Availability Groups và nhấp vào +.


  • Nhập tên DAG01, địa chỉ Máy chủ FSW và đường dẫn thư mục FSW vào các trường tương ứng. Bạn có thể nhập 255.255.255.0 hoặc để trống địa chỉ IP và nhấp vào Lưu.


  • Nhóm cơ sở dữ liệu Email dùng chung sẽ được tạo.

 

Để tạo DAG bằng Exchange Management Shell (EMS), bạn có thể làm theo các bước sau:

  • Mở EMS và sau đó thực hiện cấu trúc lệnh sau:

New-DatabaseAvailabilityGroup -Name “DAGNAME” -WitnessServer “WitnessServerNameOrAddress” -WitnessDirectory “PathcToWitnessServerDirectory”

“dagname” “witnessservernameoraddress” “pathctowitnessserverdirectory” “/pathctowitnessserverdirectory” “/witnessservernameoraddress” “/dagname”

Ví dụ: New-DatabaseAvailabilityGroup -Name DAG01 -WitnessServer HN-FSW -WitnessDirectory C:\DAG01

Để kiểm tra xem DAG có được tạo thành công hay không, bạn có thể chạy lệnh sau trong EMS hoặc đăng nhập vào EAC và điều hướng đến Servers > Database Availability Groups.

Get-DatabaseAvailabilityGroup “dagname” | Format-List “/dagname”.

Ví dụ: Get-DatabaseAvailabilityGroup “DAG01 ” | Format-List “/DAG01“.

Bước 3: Thêm máy chủ thành viên vào DAG:

Bây giờ bạn đã tạo DAG, đã đến lúc thêm thành viên Exchange Server 2019 vào DAG. Các bước như sau:

  • Trong Trung tâm quản trị Exchange (EAC), điều hướng đến Servers> Database Availability Groups và nhấp vào Manage DAG Membership.


  • Sau đó bấm vào biểu tượng +.
  • Chọn Máy chủ Exchange 2019 mà bạn muốn thêm vào DAG bằng nút add-> rồi nhấp vào OK.


  • Sau khi thêm, nhấp vào Lưu.
  • Thao tác này sẽ bắt đầu cài đặt Windows Failover Clustering trong Máy chủ Exchange 2019 thành viên đã chọn.


  • Sau khi hoàn tất, Máy chủ Exchange 2019 sẽ được thêm vào DAG.
  • Nhấp vào Đóng. Bạn sẽ thấy nhóm khả dụng của cơ sở dữ liệu với tên của máy chủ FSW và máy chủ thành viên trong Trung tâm quản trị Exchange bên dưới Servers> Database Availability Groups.

Bước 4: Thêm bản sao cơ sở dữ liệu Email:

Cuối cùng, bạn có thể thêm các bản sao cơ sở dữ liệu hộp thư vào máy chủ hộp thư thành viên để cho phép sao chép liên tục và đảm bảo cơ sở dữ liệu vẫn hoạt động ngay cả khi máy chủ thành viên bị lỗi. Các bước như sau:

  • Mở EAC và điều hướng đến Servers> Databases.
  • Chọn cơ sở dữ liệu bạn muốn thêm vào máy chủ thành viên và nhấp vào biểu tượng (ba dấu chấm).
  • Chọn Thêm Add database copy.
  • Nhấp vào Duyệt, chọn Exchange Server và nhấp vào OK.
  • Nhấp vào để lưu. Thao tác này sẽ tạo cơ sở dữ liệu hộp thư và các bản sao tệp nhật ký trên máy chủ thành viên đã chọn.
  • Sau khi quá trình hoàn tất, bấm Đóng.
  • Để kiểm tra xem các bản sao cơ sở dữ liệu có được thêm vào máy chủ thành viên hay không, hãy nhấp vào biểu tượng làm mới bên dưới Servers> Databases.
  • Cột Máy chủ có bản sao sẽ hiển thị máy chủ Exchange 2019 (máy chủ thành viên) nơi các bản sao cơ sở dữ liệu được thêm vào.

Ở giai đoạn này, bạn đã triển khai và định cấu hình thành công Exchange 2019 DAG từ đầu.

 

Xác minh thư mục File Share Witness:

Chuyển đến ổ đĩa C:\ của máy chủ tệp và xác minh rằng thư mục DAG01-2016 đã được tạo. Sau khi mở thư mục, bạn sẽ tìm thấy thư mục GUID và trong đó bạn sẽ thấy hai tệp có tên:

  • VerifyShareWriteAccess.txt
  • Witness.log

Có thể mất vài phút trước khi cả hai tệp hiển thị. Kích thước nhỏ, và nó sẽ giữ nguyên như vậy.

Ghi chú: Loại trừ thư mục File Share Witness khỏi sản phẩm Chống vi-rút/Bảo mật của bạn.


Tóm lại:

Trong bài Labs này, chúng ta đã chia sẻ các bước đơn giản để triển khai và định cấu hình các nhóm cơ sở dữ liệu Email dùng chung cho Exchange Server 2019 từ đầu. Mặc dù Exchange 2019 DAG cung cấp khả năng phục hồi và bảo vệ trang khỏi sự cố cơ sở dữ liệu và máy chủ nhưng chừng đó không phải là giải pháp thay thế cho sao lưu/khôi phụ hệ thống.

Bạn vẫn cần duy trì sao lưu cơ sở dữ liệu dựa trên VSS thường xuyên để tránh mất dữ liệu vĩnh viễn, bị mã hoá dữ liệu do Ransomware hoặc khi thảm họa xảy ra.

Bên cạnh đó, việc giữ một phần mềm khôi phục máy chủ Exchange, chẳng hạn như: Commvault Backup, Veeam Backup, Stellar Repair for Exchange, rất được khuyến khích. Nó rất hữu ích khi bạn cần khôi phục hộp thư từ cơ sở dữ liệu Exchange bị hỏng hoặc cả hệ thống Exchange Server bị hỏng. Nó lưu các hộp thư được trích xuất từ cơ sở dữ liệu đã sửa sang định dạng PST và cung cấp các tùy chọn để xuất chúng trực tiếp sang Office 365 hoặc Live Exchange Server khác.

Lab 5. Cách cấu hình Exchange Server 2019 chống thư Spoofing mail


Tuyên bố miễn trừ trách nhiệm: Bài labs thực hành này không phải là “Email giả mạo 1101”. Các ví dụ giả mạo chỉ được trình bày cho mục đích thử nghiệm và phòng ngừa.

  1. Khái niệm:

Đảm bảo bảo mật email có thể là một trong những nhiệm vụ quan trọng nhất và khó khăn nhất mà quản trị viên phải đối mặt. Mỗi ngày, các máy chủ xử lý hàng ngàn email và việc kiểm soát một luồng thư lớn như vậy là không dễ dàng. Không có gì ngạc nhiên khi tin tặc tập trung vào kênh này khi họ lên kế hoạch tấn công. Họ sử dụng nhiều thủ thuật khác nhau để khiến người dùng nghĩ rằng việc mở một tệp đính kèm đáng ngờ là một ý kiến ​​hay.

Một trong những thủ thuật họ sử dụng là giả mạo email, giả mạo cả địa chỉ email của chính người được phép gửi thư trong nội bộ của hệ thống máy chủ email, nội dung giả mạo, doạ nạt, giả thư thanh toán tiền, báo giá, hoá đơn, hợp đồng, tống tiền…


Email giả mạo “email spoofing” là gì?

Email giả mạo là một phương pháp tấn công rất phổ biến. Người gửi sửa đổi tiêu đề thư để email xuất hiện dưới dạng được gửi từ người khác. Ví dụ, tin tặc sử dụng nó để mạo danh nhân viên của một công ty nhằm lấy thông tin xác thực đăng nhập, dữ liệu cá nhân hoặc thông tin bí mật khác.

 

  1. Cách thức xử lý phổ biến:

Hai cách phổ biến nhất để bảo vệ tổ chức của bạn khỏi các cuộc tấn công giả mạo từ bên ngoài là:

  1. Bản ghi SPF – Danh sách các địa chỉ IP được phép gửi email từ một miền.
  2. Kiểm tra DKIM – Một phương thức xác thực email. Nó cho phép bạn ký và xác minh email bằng khóa chung và khóa riêng. Các khóa công khai, được xuất bản trong bản ghi DNS được sử dụng để xác minh xem thư có đến từ người gửi ban đầu hay không. Bạn không thể định cấu hình nó trên Exchange Server nguyên bản – bạn cần có plugin áp dụng cho cổng SMTP.

 

Sơ kết:

Cả hai cách đều cho kết quả tốt khi được cấu hình áp dụng chống giả mạo email bên ngoài (mạng internet).

  • Vấn đề bắt đầu khi chúng ta gặp hành vi giả mạo ở trong mạng nội bộ khi một nhân viên cố gắng mạo danh đồng nghiệp hoặc máy tính của người dùng trong công ty bị virus/ ransomware.
  • Nó có thể là một trò đùa, hoặc để đạt được một số lợi ích/mục đích – dù bằng cách nào, nó đều có thể phá hoại/gây hại một hệ thống email của công ty theo một số cách:
  1. Gây hỗn loạn, hoang mang do nội dung trong thư sai trái, thất thiệt.
  2. Gây thiệt hại vật chất, tiền tài chính.
  3. Làm hại, thất thoát tính toàn vẹn của dữ liệu.
  4. Gây tổn hại đến uy tín của cá nhân và công ty.

Tệ hơn nữa, việc chống lại các nỗ lực giả mạo nội bộ đòi hỏi một cách tiếp cận hơi khác.

Bây giờ chúng tôi sẽ trình bày cách ngăn chặn giả mạo email nội bộ trong một tổ chức sử dụng Exchange mail Server. Nhưng trước tiên, hãy mô tả nhanh về môi trường thử nghiệm:

 

 

  1. Xây dựng mô hình Exchange Server 2019 thử nghiệm:

Đối với mục đích trình bày và thử nghiệm, chúng ta sẽ sử dụng các máy sau:

  • Có 1 máy chủ Windows Server 2019 làm Domain Controller (PDC và BDC). Tên miền: adatum.com, IPv4: 172.16.0.10
  • Có 1 máy chủ Windows Server 2019 DC with Exchange 2019 CU10 cấu hình DAG, IPv4: 172.16.0.11, DAG IPv4: 172.16.0.33
  • Có 1 máy cá nhân Windows 10 with Outlook 2016, IPv4: 172.16.0.111

Bây giờ cho phần thích hợp với thực tiễn. Chúng ta sẽ chỉ ra cách các cuộc tấn công giả mạo email được thực hiện và cách ngăn chặn chúng:

  1. Kịch bản giả mạo Email nội bộ:

Trước tiên, chúng ta hãy xem cách một nhân viên có thể giả dạng người dùng khác khi gửi email. Một lệnh cmdlet “Lệnh ghép ngắn” chạy bằng PowerShell duy nhất là đủ để đạt được điều đó.


Trong ví dụ bên dưới, user1@adatum.com mạo danh user3@adatum.com và gửi email đến user2@adatum.com.

Lệnh cmdlet được user1 sử dụng như sau:

Send-MailMessage –SmtpServer 172.16.0.11 –To user2@adatum.com –From user3@adatum.com –Subject “It`s me user3” –Body “Send me your report”

Tất nhiên, email như vậy sẽ không gây hại gì. Nếu user2 trả lời tin nhắn, email sẽ được chuyển đến user3 chứ không phải kẻ tấn công.

Vấn đề là sau một số sửa đổi, Send-MailMessage có thể gửi email HTML có liên kết độc hại hoặc đính kèm tệp bị nhiễm.

Tôi sẽ không đi quá xa các ví dụ về cách giả mạo có thể được sử dụng để gây hại cho một tổ chức, nhưng hãy tin tôi đi; có nhiều thứ như vậy và chúng luôn là như vậy ở trên mạng.

 

Thủ thuật tương tự có thể đạt được bằng cách sử dụng Telnet Client. Máy khách Telnet không được cài đặt theo mặc định, nhưng bạn có thể vào Control Panel > Programs > Turn Windows features on or off của Windows và chọn Máy khách Telnet Client ở đó để bật nó.


Để kiểm tra giả mạo email nội bộ, hãy chạy cmd.exe và kết nối với máy chủ của bạn trên cổng 25 bằng cách nhập lệnh CMD:

 

Telnet 172.16.0.11 25

 

Chỉ cần nhớ thay thế địa chỉ IP bằng địa chỉ của bạn. Tiếp theo, sử dụng các lệnh SMTP, bạn có thể gửi email:

  • HELO adatum.com (connects to your domain)
  • MAIL FROM: user3@adatum.com (address of the user you want to impersonate)
  • RCPT TO: user2@adatum.com (your victim’s address)
  • DATA: it enables you to specify subject and body of your email. Enter a full stop (.) in a new line to finish data input.


 

Cả hai phương pháp kết thúc với cùng một kết quả:


 

Đối với một tình huống thực tế hơn, một cuộc tấn công tương tự được triển khai trong một môi trường khác trông như thế này:


 

Như bạn có thể thấy, email này không khác với bất kỳ thư nào khác, được gửi bằng phương tiện thông thường. Người nhận rất dễ mắc bẫy vì thư doạ nạt này.

Với tư cách là quản trị viên, bạn có thể phát hiện hành động như vậy trong nhật ký Exchange Logs, nhưng trong một tổ chức lớn công ty có nhiều hòm thư người dùng hơn và luồng thư “mail flow dày đặc, sẽ gặp rất nhiều rắc rối. Chưa kể rằng tác hại có thể được thực hiện trước khi được chúng ta phát hiện.

 

Vậy tại sao Exchange lại cho phép hành vi như vậy? Và làm thế nào để chặn nó?

Trong triển khai Exchange mặc định, một trình kết nối Nhận “Receive connector ” được tạo. Giao diện người dùng mặc định (tên máy chủ của bạn) được định cấu hình sao cho:

  • Nhận từ tất cả các địa chỉ IP.
  • Sử dụng cổng SMTP mặc định 25 để nhận email.
  • Cho phép email từ người dùng ẩn danh.

 

Điểm cuối cùng này là thứ cho phép người dùng nội bộ hoặc virus lạm dụng hệ thống gửi thư.

Thật không may, việc tắt quyền cho người dùng ẩn danh cũng sẽ chặn nhận email từ các địa chỉ email bên ngoài. Chà, chúng ta không biết trong môi trường nào thì đó sẽ là một lựa chọn hợp lý.

 

 

  1. Cách ngăn chặn giả mạo email nội bộ:

Có thể có nhiều giải pháp của bên thứ ba chống lại mối đe dọa này, nhưng trong bài viết này, chúng ta sẽ chỉ trình bày cách loại trừ giả mạo bên trong một tổ chức bằng cách sử dụng cơ chế kỹ thuật của Exchange.

 

Có hai phương pháp chúng ta sẽ chứng minh:

 

  • Cách 1. Chặn các nỗ lực giả mạo bằng bản ghi SPF.
  • Cách 2. Ngăn giả mạo nội bộ bằng đầu nối Nhận chuyên dụng.

 

Cách 1. Sử dụng bản ghi SPF:

Như đã đề cập khi mô tả các cuộc tấn công từ bên ngoài, một trong những vũ khí phổ biến nhất (và hiệu quả) chống lại các nỗ lực giả mạo là sử dụng bản ghi SPF.

Xem cú pháp của bản ghi SPF bên dưới:

 

V=spf1 ip4:your_server’s IP –all

 

Nói một cách đơn giản: các bản ghi SPF nằm trong tệp vùng DNS. Họ chỉ định địa chỉ IP của máy chủ được phép gửi email từ một miền nhất định (thêm về cách tạo bản ghi SPF).

Cơ chế này có thể được sử dụng để bảo mật thư từ chính trong nội bộ một cách tương tự như cách nó thường được sử dụng để liên lạc với bên ngoài.

Để phương pháp này hoạt động chống lại đối với giả mạo email nội bộ, bạn sẽ cần thiết lập cấu hình ba yếu tố:

  1. Bản ghi SPF có trong DNS Local mạng nội bộ,
  2. Chức năng chống thư rác trong Exchange Server,
  3. Một ID của người gửi thư.

 

Nhược điểm của cách 1:

  • Để chặn hoàn toàn giả mạo email nội bộ bằng phương pháp này, bạn phải bao gồm tất cả các địa chỉ IP được phép gửi email trong mạng của mình (bao gồm máy in, ứng dụng và các đối tượng web khác).
  • Đây không phải là giải pháp thuận tiện nhất nếu bạn có một mạng rộng lớn nhiều VLAN, PVLAN, vô số thiết bị AP, WLAN, smartphone khác nhau…
  • Nhưng nếu bạn không có cơ sở hạ tầng quá lớn đó và bạn biết nó rõ như lòng bàn tay, thì giải pháp sẽ hoạt động tốt thôi.

 

Hướng dẫn từng bước:

 

Bước 1.
Chúng ta nên tạo bản ghi txt trên máy chủ DNS của mình trong miền cục bộ như thế này:




 

v=spf1 ip4:172.16.0.11 ip4:172.16.0.33 ip4:192.168.169.51 ip4:172.16.0.111 –all

 

172.16.0.11 và 172.16.0.33 là địa chỉ IP của Máy chủ Exchange của tôi, trong khi 192.168.169.51 là địa chỉ IP của máy in web của tôi trong một mạng con khác. Máy in gửi email đến Exchange.

172.16.0.111 là máy PC tôi cài Veeam Backup và PC này gửi email báo cáo tình hình backup/restore hệ thống data đến Exchange.

 

Bước 2. Tiếp theo là cài đặt Exchange Antispam Agent. Bạn có thể sử dụng PowerShell để làm điều đó. Lệnh ghép ngắn cmdlet là:

 

  • Trường hợp máy chủ Exchange 2019 là bản cài trên Windows Core 2019 (không có giao diện) thì sẽ gặp lỗi:



Chữa lỗi khi dùng lệnh PS này cho máy chủ Windows Core 2019 / Exchange 2019 Standard, trước tiên sẽ gõ lện CMD:> Start PowerShellvà bấm phím enter:

Start PowerShell


Một cửa sổ lệnh mới của PowerShell window xuất hiện chúng ta sẽ nhập lệnh ở đây:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn


Sau đó quay lại lệnh cài AntiSpamAgents.ps1


  • Trường hợp máy chủ Exchange 2019 là bản cài trên Windows Server 2019 có giao diện đầy đủ thì chỉ nhập lệnh PowerShell:

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

Cài đặt thành công sẽ như thế này:


 

Bước 3. Bây giờ để các thay đổi được áp dụng, hãy khởi động lại dịch vụ MSExchangeTransport của bạn:

Restart-Service MSExchangeTransport


Bước 4. Cung cấp tất cả địa chỉ IP của Máy chủ Exchange:

Set-TransportConfig –InternalSMTPServers 172.16.0.11,172.16.0.33

Tôi phải cung cấp hai địa chỉ IPv4 vì Máy chủ Exchange của tôi có hai giao diện mạng.

Chúng ta đang gần hoàn tất. Bây giờ, bạn phải định cấu hình quy tắc từ chối email từ các địa chỉ không có trong bản ghi SPF của bạn. Lệnh ghép ngắn PowerShell là:

 

Set-SenderIdConfig –SpoofedDomainAction Reject

 


 

Tất cả những gì còn lại là kiểm tra xem cấu hình hiện tại có chặn thành công nỗ lực giả mạo nội bộ hay không.

Tôi sẽ sử dụng cmdlet giống như tôi đã trình bày ở đầu bài viết. Thay vì gửi email, kẻ tấn công sẽ gặp lỗi sau:


Như bạn có thể thấy, máy chủ Exchange chặn nỗ lực này và hiển thị lỗi 5.7.1 “ID người gửi <PRA> không được phép. Hiệu ứng sẽ giữ nguyên ngay cả khi người dùng nhập hộp thư của chính họ trong thuộc tính –From:


Cuối cùng, hãy để chúng tôi kiểm tra xem điều gì sẽ xảy ra nếu tôi cố giả dạng người dùng khác trên máy có địa chỉ IP 172.16.0.111 (địa chỉ tôi đã thêm vào bản ghi SPF cục bộ trước đó vào máy chủ DNS):


Và ngay sau khi DNS Server local đã thêm IP4 trong bản ghi SPF (TXT) đó thì cũng dùng lệnh PowerShell> Restart-Service MSExchangeTransport


Tôi dùng PowerShell remote có trên Windows Admin Center khi connected tới máy chủ Exchange Core 2019.


Trong khi đó nếu thư soạn và gửi bằng lệnh:

Telnet 172.16.0.11 25 thì lại thành công


 

Thư đi qua mà không có vấn đề gì:


 

  • Ví dụ này cho thấy một nhược điểm khác của phương pháp ghi SPF. Vì cơ sở xác thực dựa trên IP của người gửi, cấu hình sai hoặc chính máy trong dải ip được phép bị nhiễm virus sẽ không đảm bảo rằng công ty của bạn được bảo vệ hoàn toàn khỏi hành vi giả mạo nội bộ.
  • Việc triển khai phương pháp này không ảnh hưởng đến việc gửi email từ các ứng dụng email (Outlook, OWA hoặc ActiveSync) vì chúng sử dụng RPC hoặc MAPI qua HTTP thông qua một cổng khác (443 hoặc 80).

 

 

Cách 2. Sử dụng đầu kết nối Nhận chuyên dụng:

  • Phương pháp thứ hai là tạo một trình kết nối Nhận bổ sung trên cổng 25.
  • Trình kết nối kiểm soát mạng cục bộ và chỉ cho phép các email từ người dùng trong miền đi qua.
  • Cách tiếp cận này sử dụng một phương thức ủy quyền khác.
  • Thay vì sử dụng IP, nó sử dụng thông tin xác thực tên miền (đăng nhập và mật khẩu).
  • Việc thay đổi phương thức ủy quyền tạo ra một vấn đề – tất cả các kết nối Exchange nội bộ phải được ủy quyền. Nói cách khác, mọi thiết bị web và ứng dụng gửi email tới Exchange đều yêu cầu tài khoản miền (hoặc ít nhất chúng có thể có một tài khoản chung).
  • Đề cập trước đây, trình kết nối sẽ được đặt cho cổng TCP 25. Tuy nhiên, như bạn có biết, đã có một trình kết nối Nhận, chấp nhận các kết nối ẩn danh từ máy chủ SMTP trên cổng 25.

Vậy làm cách nào để trình kết nối này có thể cùng tồn tại với một cái bạn sắp tạo? Và làm thế nào để Exchange biết nên chọn cái nào?

  • Exchange Server khá thông minh khi nói đến điều này.
  • Máy chủ sẽ luôn chọn trình kết nối chính xác hơn cho mỗi kết nối.
  • Trình kết nối Nhận mà tôi định cấu hình được xác định cho mạng LAN, trong khi trình kết nối mặc định áp dụng cho tất cả các kết nối. Do đó, đối với các kết nối SMTP nội bộ, Exchange sẽ luôn chọn trình kết nối mới, được chỉ định cho mạng LAN.

 

 

Hướng dẫn từng bước:

 

Cách thứ hai, ngoài việc an toàn hơn, còn dễ thực hiện hơn.

Đó là bởi vì nó chỉ yêu cầu tạo một trình kết nối Nhận mới.

Bạn có thể sử dụng một lệnh cmdlet trên PowerShell cho việc đó.

Tôi sẽ sử dụng tên SMTP của Máy khách Nội bộ cho trình kết nối để sau này tôi có thể dễ dàng xác định nó. Hãy nhớ rằng, dải IP được cá nhân hóa VLAN isolate network cho môi trường của tôi:

 

New-ReceiveConnector –Name “Internal Client SMTP” –TransportRole FrontendTransport –Usage Custom –Bindings 0.0.0.0:25 –RemoteIPRanges 172.16.0.0/24,192.168.170.0/24 –AuthMechanism TLS,Integrated –PermissionGroups ExchangeUsers

 

Hoặc cũng có thể tạo nó trong Trung tâm quản trị Exchange Administration Center > Mail Flow > Receive Connectors > New: Các cài đặt tương tự với sử dụng trong lệnh cmdlet ở trên.

Trình kết nối phải là nội bộ và vai trò phải được đặt thành TransportRole FrontendTransport… Thật không may, Vai trò mặc định là Hub Transport và có vẻ như tôi không thể thay đổi nó thành tùy chọn mà tôi cần. Dù sao thì chúng ta hãy tiếp tục và xem điều gì sẽ xảy ra.


 

Trang tiếp theo rất quan trọng – đó là nơi bạn phải chỉ định tất cả các mạng LAN mà bạn có trong tổ chức của mình. Trong trường hợp của tôi, đó là 172.16.0.0/24 và 192.168.170.0/24.



Đó là nơi Exchange đưa ra lỗi.


The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector “LON-EXCH\Default Frontend LON-EXCH”. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.

 

Có vẻ như Exchange không thích có hai trình kết nối với các vai trò Vận chuyển khác nhau cùng nghe trên một cổng. Nhưng hai vai trò chỉ khác nhau vì một tùy chọn bị chuyển sang màu xám… Điều này thật đặc biệt, khi xem xét thực tế là một lệnh cmdlet không đưa ra bất kỳ lỗi nào. Bạn có thể kiểm tra xem mình có gặp phải lỗi tương tự hay không, nhưng lời khuyên của tôi là chỉ nên sử dụng cmdlet trên PowerShell.

 

Trình kết nối (bất kể bạn tạo nó như thế nào) sẽ xuất hiện trong danh sách:


 

Now for the testing. user1 will try to send a message to user2@adatum.com as user3@adatum.com.

 

The PowerShell command already used a couple of times in this article does not send an email this time. The error code is different from the one which appeared using the previous method: 5.7.60 SMTP; Client does not have permission to send as this sender.

 


 

nếu người dùng thử thủ thuật tương tự sau khi cung cấp thông tin đăng nhập của họ thì sao?


Tốt, vẫn không có may mắn. Nhưng khi cùng một người dùng ngừng cố gắng xuất hiện với tư cách người khác:


Lệnh cmdlet đã thực hiện công việc của nó. Nạn nhân của ngày hôm nay, user3@adatum.com có thể đọc tin nhắn cùng với người gửi ban đầu::

 


Nỗ lực giả mạo nội bộ cũng bị chặn nếu người dùng ác ý cố gắng sử dụng telnet:


 

Tóm tắt:

 

Là quản trị viên Exchange Server, bạn cần biết rằng việc triển khai Exchange mặc định là không đủ để bảo vệ người dùng của bạn khỏi các email độc hại.

Bạn có thể sử dụng bài Labs này để ngăn chặn việc giả mạo email nội bộ mãi mãi.

Cả hai cách trên đều dựa trên cơ chế Exchange Server, tất cả những gì bạn cần là thực hành.