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.
Nguồn: MSexchange
3Cdotcom “Dịch vụ hosting tốt nhất cho dữ liệu" www.hosting.net.vn