Tài liệu Quản lý Receive Connector – Phần 4 pdf

Trong phần 4 này chúng tôi sẽ tiếp tục giới thiệu với các bạn về các điều khoản ở mức Receive Connector và cấu hình thẩm định TLS trong một receive connector.. Trong phần trước của loạt

Trong phần 4 này chúng tôi sẽ tiếp tục giới thiệu với các bạn về các điều khoản ở mức Receive Connector và cấu hình thẩm định TLS trong một receive connector

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn

về cách quản lý các điều khoản bằng Exchange Management Shell và AdsiEdit.msc còn trong phần này chúng tôi sẽ giúp bạn cá nhân hóa các điều khoản của receive

connector theo một cách khác mà không cần sử dụng đến nhóm Permissions mặc định

Exchange Server 2007 có một tập các nhóm Permissions được định nghĩa trước, tập các nhóm

điều khoản này giúp bạn dễ dàng quản trị bằng cách sử dụng một checkbox để định nghĩa các

điều khoản cần thiết Khi có nhiều máy chủ hoạt động trong hệ thống của bạn thì khi đó chúng ta

lại gặp phải một số vấn đề khác, lý do ở đây là một số tổ chứ cần có một receive connector mang

tính hạn chế hơn, vấn đề này có thể được thực hiện bằng thủ tục được phác thảo trong phần này

Nếu bạn không thực sự cần đến tính năng như vậy, hãy sử dụng Permissions Groups mặc định có

sẵn xuyên suốt Exchange Management Console hoặc Exchange Management Shell

Chúng ta giả sử rằng muốn có Active Directory Group có tên gọi Grp_Relay được cho phép

relay trong Exchange Server 2007 Để thực hiện điều đó, chúng ta phải khai thác hơn nữa các

cấu hình điều khoản của Receive Connector nhằm gán cho những người dùng khác ngoài danh

Nếu bạn sẽ dụng nhiều HUB Transport trong một kịch bản NLB cho receive connector thì khi đó

tất cả các thay đổi phải được thực hiện trong các nút NLB để cung cấp cùng một chế độ thẩm

định và các điều khoản

Trước hết, chúng ta cần remove tất cả các nhóm hiện đã nằm trong tab Permissions của Receive

Connector trong Exchange Management Console Để thực hiện điều đó, hãy vào trang các thuộc

tính của Internal Relay connector và bảo đảm rằng không có nhóm nào được kiểm trên tab

Permissions

Lúc này, hãy quay trở lại AdsiEdit.msc và kích chuột phải vào Internal Relay connector và kích

Properties Kích tab Security, bổ sung thêm nhóm Grp_Relay từ Active Directory Bảo đảm rằng

• Submit Messages to Server

• Submit Messages to any Recipient

• Bypass Anti-Spam

• Accept routing Headers

Hình 01

Lúc này chỉ có những người dùng nằm trong nhóm Grp_Relay mới có thể gửi thư bằng

Internal Relay Receive Connector Nếu người dùng nào đó nằm bênngoài nhóm muốn gửi thư thì họ sẽ bị yêu cầu về các chứng chỉ cần thiết (có thể đến một vài lần); bạn có thể hợp lệ hóa lỗi trong file bản ghi Receive Connectors Lỗi này sẽ gồm có các thông

Inbound authentication failed because the client DOMAIN\username doesn’t have

Nếu bạn gặp phải tình huống mà ở đó một số máy chủ phải relay trên Exchange Server không sử dụng sự thẩm định, khi đó bạn phải sử dụng cùng thủ tục giống ở trên để đồng ý điều khoản cho entry Anonymous trên tab Receive Connector Security

Hoàn toàn không tốt nếu bạn cho phép điều khoản đặc quyền relay trong một máy chủ Exchange Server Hãy bảo đảm rằng chỉ có một tập các máy chủ có thể sử dụng connector này bằng cấu hình RemoteIPRanges của receive connector

định trong một Receive Connector, giờ đây chúng ta hãy kích hoạt TLS trong Receive

Connector Trước hết, hãy vào cửa sổ các thuộc tính của Internal Relay Receive

Connector, sau đó kích tab Authentication và tích vào tùy chọn TLS như trong hình 2

Hình 02

Hãy kết nói đến receive connector này, receive connector có FQDN được định nghĩa là

relay.apatricio.local (Apatricio.local là tên FQDN của Active Directory) Sử dụng SMTP

verb trước, EHLO example.org , khi đó chúng ta sẽ thấy rằng STARTTLS không được

hiện diện, điều đó có nghĩa rằng thậm chí khi TLS được kích hoạt trên Receive

Connector thì chúng ta vẫn không thể sử dụng được nó (xem trong hình 3)

Hình 03

Sau kết nối đó, chúng ta có thể vào Event Viewer của Exchange Server và EventID

12014 (hình 4) sẽ nằm ở đây, thông báo lỗi sẽ cho chúng ta biết được những gì đang xảy ra với môi trường hiện hành của mình Một câu trả lời đơn giản là không có chứng chỉ với tên đã được cấu hình trong FQDN của Receive Connector đó

Hình 04 Chúng ta hãy sửa trường hợp này Chúng tôi giả dụ rằng đang sử dụng một PKI trong

và để yêu cầu một chứng chỉ SMTP mới bằng Exchange Management Shell, hãy sử

New-ExchangeCertificate –GenerateRequest –Path c:\cert.req –SubjectName

“cn=relay.apatricio.local” –FriendlyName “Internal Relay Certificate” –

PrivateKeyExportable:$True

Lúc này hãy yêu cầu chứng chỉ đã được tạo bằng website Certification Authority:

1 Đăng nhập vào Exchange Server với đường dẫn http://<CA Server>/certsrv, ở đây

<CA Server> là máy chủ nắm giữ Certification Authority

2 Kích vào liên kết Request a Certificate

3 Kích advanced certificate request

4 Kích vào liên kết thứ hai Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS

#7 file

5 Mở file C:\cert.req, đây là file đã được tạo bởi lệnh New-ExchangeCertificate và copy nội dung

6 Paste nội dung của file đó vào trường yêu cầu chứng chỉ được mã hóa 64 trong website

7 Cũng trên trang đó, chọn Web Server trong trường Certificate Template và sau đó kích nút Submit

8 Trên trang mới, kích vào liên kết Download Certificate và lưu nó trong C:\ root của

Exchange Server

Chúng ta hãy import chứng chỉ mới, để thực hiện điều đó, hãy sử dụng lệnh sau:

Import-ExchangeCertificate –Path:C:\certnew.cer

Lưu ý:

Tên file và đường dẫn ở đây chỉ mang tính ví dụ, bạn phải sử dụng tên file và đường dẫn mà bạn sử dụng trong bước trước

Lúc này hãy kích hoạt một chứng chỉ đã được import mới để sử dụng cho dịch vụ SMTP bằng Exchange Management Shell Để kích hoạt, chúng ta cần copy Thumbprint được xuất hiện khi bạn đã import yêu cầu trong bước trước và sử dụng lệnh sau:

Enable-ExchangeCertificate –Thumbprint <Thumbprint> -Services SMTP

Bạn sẽ được nhắc nhở cần thay đổi chứng chỉ SMTP mặc định, hãy đánh vào đó N và nhấn Enter

Chúng ta hãy test những thay đổi của mình, trước tiên là việc kết nối trong Internal Relay Receive Connector và sẽ đánh vào SMTP verb, ehlo example.org trước Bạn có thấy thay đổi nào không? Lúc này bạn hiện có STARTTLS đã được cung cấp bởi

Exchange Server Chúng ta cũng có thể quay trở về Exchange Server Event Viewer và không thấy bất cứ lỗi Transport nào giống như những gì đã thấy trước đó

Hình 05

Hãy quay trở về Outlook Express để xác nhận giải pháp Trong các thuộc tính của tài khoản Outlook Express, chúng ta phải sử dụng tên FQDN trong trường Outgoing mail (SMTP) và tên này phải được phân tích và hiểu bởi máy khách và phải là tên được sử dụng bởi chứng chỉ đã được triển khai gần đây (xem trong hình 6)

Hình 06

Hình 07

Lúc này, hãy gửi một thông báo bằng Outlook Express Chúng ta sẽ không nhận trên Outlook Express client vì không thiết lập POP3 server đúng cách mà chỉ là SMTP Nếu thông báo không xuất hiện trong thư mục Outbox thì đây là một dấu hiệu tốt, tuy nhiên chúng ta cần phải hợp lệ hóa các file bản ghi và sẽ thấy thông báo cuối cùng đã được gửi bằng TLS như thể hiện trong hình 8

Hình 08

Kết luận

Trong phần này, chúng tôi đã giới thiệu cho các bạn được về cách tránh Event ID

12014 khi cấu hình một FQDN mới trong Receive Connector, cách cấu hình một nhóm chỉ định nhằm relay trong một Receive Connector nào đó, cách cấu hình một chứng chỉ

và hơp lệ hóa các file bản ghi để bảo đảm rằng cấu hình hiện làm việc đúng cách