Quản lý Receive Connector – Phần 4 docx

Quản lý Receive Connector – Phần 4
Quản Trị Mạng - 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 sách mặc định.

Lưu ý:
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 nhóm có tối thiểu các điều
khoản dưới đây (Hình 1):

• 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 tin dưới đây:

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

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.

Lưu ý:
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.

Cấu hình TLS trên Receive Connector

Các bạn đã thấy được cách cấu hình các phương pháp thẩm định và các nhóm
thẩm đị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ử dụng lệnh dưới đây:

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
Bước thứ hai cần phải thực hiện ở đây là tên tab Advanced, bạn phải tích vào
tùy chọn This server requires a secure connection (SSL), xem thể hiện trong
hình 7.

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.

Văn Linh (Theo MS Exchange)