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

Quản lý Receive Connector – Phần 4 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:///certsrv, ở đây 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 -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.