Exchange порти для підключення. Підключення поштових клієнтів до Microsoft Exchange Server

У цій статті ми розберемося з тим, як настроїти статичні RPC порти для служб RPC Client Access, Exchange Address Book та служби доступу до спільних папок у Exchange 2010.

Уявимо, що ми маємо складну організацію з Exchange Server 2010 SP1 (або вище), в якій у тому числі є . Сервера CAS зазвичай розташовуються в мережі, відокремленій міжмережевими екранамивід мереж, з яких передбачається доступ користувачів (мережі Outlook). Підключення клієнта Outlook до сервера CAS відбувається по RPC, а це означає, що на мережному рівні може бути задіяний будь-який порт з вільного діапазону портів. Не секрет, що в Windows Server 2008 і 2008 R2 як динамічний діапазон портів для RPC підключень використовується діапазон 49152-65535 (у попередніх версіях Windows Server використовували RPC порти в діапазоні 1025-65535).

Щоб не перетворювати брандмауери на «решето», бажано звузити діапазон портів, що використовуються RPC, в ідеалі, зробивши їх статичними на кожному сервері Client Access Server в масиві Client Access. Крім того, використання статичних RPC портів дозволяє знизити споживання пам'яті на пристроях балансування навантаження (особливо HLB) і спростити їх конфігурування (не потрібно вказувати великі діапазони портів).

У Exchange 2010 для служби RPC Client Access, а також для служби адресної книги Exchange можна встановити статичні порти. Outlook взаємодіє з цими службами через інтерфейс MAPI.

Статичний порт для служби Exchange 2010 RPC Client Access

Віртуальна служба Exchange 2010 RPC Client Access пов'язана зі службою доступу клієнтів RPC Client, до якої в Exchange 2010 підключаються клієнти Outlook MAPI. Коли клієнт Outlook підключається до Exchange, на сервері Exchange 2010 Client Access службою RPC Client Access для вхідних підключень використовується порт TCP End Point Mapper (TCP/135) та випадковий порт із динамічного діапазону портів RPC (6005-59530)

Щоб у Exchange 2010 для служби RPC Client Access встановити статичний порт, необхідно в редакторі реєстру відкрити розділ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Створіть новий ключз ім'ям ParametersSystem, всередині якого створіть параметр типу REG_DWORDз ім'ям TCP/IP Port. У TCP/IP Port задається статичний порт для служби RPC Client Access. У документації Microsoft рекомендується вибрати порт в діапазоні 59531 - 60554 і використовувати дане значенняна всіх CAS-серверах (ми вказали порт 59532, природно, він не повинен використовуватися ніяким іншим ПЗ).

Після завдання статичного порту, щоб зміни набули чинності, потрібно перезапустити службу Microsoft Exchange RPC Client Access.

Restart-Service MSExchangeRPC

Статичний порт для служби Exchange 2010 Address Book

У Exchange 2010 до виходу SP1 для завдання статичного порту служби Exchange 2010 Address Book використовувався спеціальний конфігураційний файл Microsoft.exchange.addressbook.service.exe.config. Після релізу Exchange 2010 SP1 встановити статичний порт цієї служби можна через реєстр. Для цього відкрийте редактор реєстру та перейдіть у гілку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

Створіть новий параметр RpcTcpPort(типу REG_SZ) і введіть номер порту, який необхідно зафіксувати для служби Exchange Address Book service. Рекомендовано використовувати будь-який вільний порт у діапазоні 59531-60554 і надалі використовувати його на всіх серверах Exchange 2010 Client Access у домені. Ми задаємо RpcTcpPort=59533

Після цього необхідно перезапустити службу Microsoft Exchange Address Book

Restart-Service MSExchangeAB

Важливо:При переході з Exchange 2010 RTM на SP1, цей ключ потрібно задавати вручну, автоматично він не успадковується.

Налаштування статичного порту для підключення до спільних папок

Доступ до спільних папок із клієнта Outlook здійснюється безпосередньо через службу RPC Client Access на сервері за участю Mailbox. Це налаштуваннянеобхідно провести на всіх серверах за участю Mailbox, які містять базу спільних папок(аналогічно до серверів CAS). Відкрийте редактор реєстру та перейдіть у гілку

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ MSExchangeRPC

Створіть новий ключ із ім'ям ParametersSystem, всередині якого створіть параметр типу REG_DWORD з ім'ям TCP/IP Port. Вкажіть його значення: TCP/IP Port = 59532.

Задавши статично порт для спільних папок, потрібно перезапустити службу Microsoft Exchange RPC Client Access service на кожному сервері mailbox.

Перевірка використання статичних портів між Outlook та Exchange 2010

Після внесених змін перевіримо, що Outlook підключається до заданих нами статичних портів RPC. Для цього на клієнтській машині перезапустіть Outlook, а потім у командному рядку виконайте команду:

Netstat -na

What TCP and UDP ports does my Exchange 2000/2003 Server use?

Для того, щоб configuring firewalls або для проблем з комунікаційними службами, це може бути корисним для того, щоб TCP/UDP порти Exchange 2000 Server і Exchange 2000 Conferencing Server є використання. Цей матеріал також є true for Exchange Server 2003 installations.

Protocol: LDAP

  • Port (TCP/UDP): 389 (TCP)
  • Description: Lightweight Directory Access Protocol (LDAP), використовуваний Active Directory, Active Directory Connector, та Microsoft Exchange Server 5.5 directory.

Protocol: LDAP/SSL

  • Port (TCP/UDP): 636 (TCP)
  • Description: LDAP за допомогою Secure Sockets Layer (SSL). Якщо SSL є налагодженим, LDAP data, що є переведена і отримана, є введеною.
  • Для того, щоб забезпечити SSL, ви повинні налаштовувати комп'ютер certificate на домашній контролер або Exchange Server 5.5 комп'ютера.

Protocol: LDAP

  • Port (TCP/UDP): 379 (TCP)
  • Description: Служба технічної підтримки (SRS) використовує TCP port 379.

Protocol: LDAP

  • Port (TCP/UDP): 390 (TCP)
  • Description: Коли не існує стандартний LDAP port, TCP port 390 є відповідним іншим портом для налаштування Exchange Server 5.5 LDAP protocol при Exchange Server 5.5 is running on a Microsoft Windows 2000 Active Directory domain controller.

Protocol: LDAP

  • Port (TCP/UDP): 3268 (TCP)
  • Description: Global catalog. Windows 2000 Active Directory Global Catalog (який є справжнім домашнім контролером “роля”) повідомлень на TCP port 3268. Якщо ви рекомендуєте,використовувати питання, які можуть бути віднесені до Global Catalog, connect to port 3268 in LDP.

Protocol: LDAP/SSL

  • Port (TCP/UDP): 3269 (TCP)
  • Description: Global catalog over SSL. Applications that connect to TCP port 3269 of Global Catalog Server може transmit and receive SSL завантажені дані. Натисніть на глобальний каталог для підтримки SSL, ви повинні налаштувати комп'ютер certificate на глобальному каталогу.

Protocol: IMAP4

  • Port (TCP/UDP): 143 (TCP)
  • Description: Internet Message Access Protocol version 4, може бути використаний як “standards-based” clients such as Microsoft Outlook Express або Netscape Communicator для доступу до електронної пошти. IMAP4 runs on top of Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe), і достатній клієнт access to the Exchange 2000 information store.

Protocol: IMAP4/SSL

  • Port (TCP/UDP): 993 (TCP)
  • Description: IMAP4 за допомогою SSL використовує TCP port 993. Перед сервером Exchange 2000 support IMAP4 (або будь-який інший протокол) за допомогою SSL, ви повинні налаштовувати на комп'ютері certificate на сервері Exchange 2000.

Protocol: POP3

  • Port (TCP/UDP): 110 (TCP)
  • Description: Post Office Protocol 3 version, enables “standards-based” clients such as Outlook Expressабо Netscape Communicator для доступу до електронної пошти. Як з IMAP4, POP3 відправляються на верхню службу IIS Admin Service, і достатні клієнтські послуги до Exchange 2000 інформаційний центр.

Protocol: POP3/SSL

  • Port (TCP/UDP): 995 (TCP)
  • Опис: POP3 over SSL. Для забезпечення POP3 over SSL, ви повинні налаштовувати комп'ютерний certificate на сервері Exchange 2000.

Protocol: NNTP

  • Port (TCP/UDP): 119 (TCP)
  • Description: Network News Transport Protocol, деякими названими Usenet protocol, належним чином “standards-based” client access to public folders in the information store. Як з IMAP4 і POP3, NNTP залежить від IIS Admin Service.

Protocol: NNTP/SSL

Port (TCP/UDP): 563 (TCP)

Description: NNTP over SSL. Для забезпечення NNTP over SSL, ви повинні налаштовувати комп'ютер certificate на Exchange 2000 Server.

Protocol: HTTP

  • Port (TCP/UDP): 80 (TCP)
  • Description: Hyper-Text Transfer Protocol використовується в протоколі, в основному з Microsoft Outlook Web Access (OWA), але також здатні деякі адміністративні рішення в Exchange System Manager. HTTP є здійснений через World Wide Web Publishing Service (W3Svc), і керує на верхній частині IIS Admin Service.

Protocol: HTTP/SSL

  • Port (TCP/UDP): 443 (TCP)
  • Description: HTTP over SSL. Для забезпечення HTTP over SSL, ви повинні налаштовувати комп'ютер certificate на сервері Exchange 2000.

Protocol: SMTP

  • Port (TCP/UDP): 25 (TCP)
  • Description: Simple Mail Transfer Protocol, є повідомлення для всіх електронної пошти в Exchange 2000. SMTP Service (SMTPSvc) runs on top of IIS Admin Service. Unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 не може використовувати окремий port для захисту комунікацій (SSL), але інші, які працюють у "засобі захисту суб-системи" названі Transport Layer Security (TLS).

Protocol: SMTP/SSL

  • Port (TCP/UDP): 465 (TCP)
  • Description: SMTP over SSL. TCP port 465 is reserved common industry practice for secure SMTP communication using the SSL protocol. Одначе, unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 не може використовувати окремий port для захисту комунікацій (SSL), але інші, трудяться "в-засобі захисту субсистеми" називається Transport Layer Security (TLS) . Для забезпечення TLS працює на Exchange 2000, ви повинні install на комп'ютері certificate на сервері Exchange 2000.

Protocol: SMTP/LSA

  • Port (TCP/UDP): 691 (TCP)
  • Description: У Microsoft Exchange Routing Engine (як відомо, як RESvc) літери для повідомлень електронної пошти стану інформації на TCP port 691. Exchange 2000 використовується routing link state information для повідомлень електронної пошти та routing table is constantly updated. The Link State Algorithm (LSA) propagates outing status information між Exchange 2000 servers. Цей algoritm базується на Open Shortest Path First (OSPF) протоколі з мережевої технології, і transfers link state information між routing groups з використанням X-LSA-2 комбінаційної версії через SMTP і з використанням Transmission Control Protocol (TCP) з'єднання port 691 в routing group.

Protocol: RVP

  • Port (TCP/UDP): 80 (TCP)
  • Description: RVP є підготовкою до Instant Messaging в Exchange 2000. У той час як RVP з'єднується з TCP port 80, сервер підключається до нового підключення до клієнта на епеморальний TCP port до 1024. Тому цей порт є issues exist when you enable Instant Messaging через firewall.

Protocol: IRC/IRCX

  • Port (TCP/UDP): 6667 (TCP)
  • Description: Internet Relay Chat (IRC) - це chat protocol. IRCX is the extended version offered by Microsoft. Коли TCP port 6667 є найбільшим спільним port для IRC, TCP port 7000 є також дуже frequently used.

Protocol: IRC/SSL

  • Port (TCP/UDP): 994 (TCP)
  • Description: IRC або з SSL. IRC або IRCX над SSL не підтримується в Exchange 2000.

Protocol: X.400

  • Port (TCP/UDP): 102 (TCP)
  • Description: ITU-T Recommendation X.400 є реально series recomendations for what electronic message handling system (MHS) should look like. TCP port 102 є визначеним в IETF RFC-1006, який описує OSI Communications over a TCP/IP network. В brief, TCP port 102 is the port that the Exchange message transfer agent (MTA) використовується для комунікації з іншими X.400-capable MTAs.

Protocol: MS-RPC

  • Port (TCP/UDP): 135 (TCP)
  • Description: Microsoft Remote procedure Call є Microsoft implementation of remote procedure calls (RPCs). TCP port 135 є фактично тільки RPC Locator Service, який є як реєстратор для всіх RPC-обслуговуваних послуг, які використовуються на окремому сервері. В Exchange 2000, Routing Group Connector використовує RPC додаток до SMTP, коли target bridgehead server is running Exchange 5.5. Також, деякі адміністративні операції потрібні RPC. Щоб configure a firewall to enable RPC traffic, багато mores ports than just 135 must be enabled.

Для додаткової інформації, клацніть сторінки номерів для перегляду статей в Microsoft Knowledge Base:

XADM: Setting TCP/IP Port Numbers for Internet Firewalls

XCON: Налаштування MTA TCP/IP Port # for X.400 and RPC Listens

Protocol: T.120

  • Port (TCP/UDP): 1503 (TCP)
  • Description: ITU-T Recommendation T.120 є основою відповідей, що define data conferencing. Data conferencing є здійснена на сервері сторони як Conferencing Technology Provider (CTP) в Multipoint Control Unit (MCU), який є одним з компонентів Exchange Conferencing Services (ECS). Data conferencing є здійснений на клієнта, як Chat, Application Sharing, Whiteboard, і File Transferring в Microsoft NetMeeting.

Protocol: ULS

  • Port (TCP/UDP): 522 (TCP)
  • Description: User Locator Service є типом Інтернет-ресурсів для конференційних клієнтів, так як NetMeeting. Exchange 2000 Server і Exchange 2000 Конференція Server не може реалізовувати ULS, але згодом приймає додаток до служб Active Directory (Directory Services TCP 389).

Protocol: H.323 (Video)

  • Port (TCP/UDP): 1720 (TCP)
  • Description: ITU-T Recommendation H.323 defines multimedia conferencing. TCP port 1720 є H.323 (video) call setup port. Після клієнта підключення, H.323 сервер невідповідає новий, динамічний UDP port буде використовуватися для streaming data.

Protocol: Audio

  • Port (TCP/UDP): 1731 (TCP)
  • Description: Audio conferencing is enabled in much the same way as H.323 video conferencing is enabled in Exchange 2000 Server. Після клієнтів підключення до TCP port 1731, новий динамічний port is negotiated for further streaming data.

Www.microsoft.com

Стаття Служба Exchange 2013 FrontEnd Transportє першою в циклі статей, що оповідають про принцип роботи служб транспорту Exchange Server 2013. У цій статті мова піде про Транспортна служба переднього плануна серверах клієнтського доступу.

У 2013 версії сервера Exchange відбулися досить сильні зміни в архітектурі і тепер існує лише дві основні ролі – сервер поштових скриньок (Mailbox Server або скорочено MBX) та сервер клієнтського доступу (Client Access Server – CAS). Особливо стоїть роль прикордонного транспортного сервера (Edge Transport). Служба Exchange 2013 FrontEnd Transportрозташовується на серверах CAS та виконує функції проксі.

Це перша стаття із серії, присвяченої принципам роботи служб транспортного конвеєра Exchange 2013, а ось повний список:

А також статті з управління логуванням цих служб:

Не забувайте про офіційну документацію.

Знайти більше інформаціїз налаштування та адміністрування Exchange 2013 на моєму блозі ви зможете в основній статті тематики - .

Так уже вийшло, що тепер у сервері Exchange 2013 існує досить багато служб транспорту, які мають схожі назву, але фундаментально відрізняються за призначенням та принципом роботи. Ось усі ці служби:

  • Транспортна служба переднього плануна серверах клієнтського доступу (Відображуване ім'я - Microsoft Exchange FrontEnd Transport, скорочене - MSExchangeFrontEndTransport);
  • Транспортна службана серверах поштових скриньок (Відображуване ім'я - Microsoft Exchange Transport, скорочене - MSExchangeTransport);
  • Транспортна служба поштових скриньокна серверах поштових скриньок (Реально включає дві служби — Microsoft Exchange Mailbox Transport Delivery і Microsoft Exchange Mailbox Transport Submission, скорочені імена — MSExchangeDelivery і MSExchangeSubmission відповідно);
  • Транспортна служба на прикордонних транспортних серверах (Ім'я, що відображається - Microsoft Exchange Transport, скорочене - MSExchangeTransport).

У цьому зіставний функціонал виконують лише друга і четверта служба, інші відрізняються принципово. Разом усі вони утворюють транспортний конвеєр, який є серцем поштового сервера.

Транспортний конвеєр

У загальному плані транспортний конвеєр виглядає так:

У контексті цієї статті нас цікавить саме верхня частина ілюстрації, на якій зображено Сервер клієнтського доступу:

У цій схемі криється один аспект. Справа в тому, що за замовчуванням сервери MBX можуть самостійно надсилати пошту назовні через порт 25 SMTP. Щоб з'єднувач відправки завжди відправляв пошту в інтернет через сервери клієнтського доступу, потрібно в явному вигляді встановити цей з'єднувач параметр FrontendProxyEnabledна значення $true(або в EAC поставити галочку на Проксі через сервер клієнтського доступуу властивостях з'єднувача відправлення). Саме від такої конфігурації я і відштовхуватимуся надалі.

Нижче я постараюся внести деякі ясності в принцип роботи серверів Exchange 2013 за участю CAS.

Принцип роботи

FrontEnd Transport(у термінології Microsoft - Служба транспорту переднього плану) не займається обробкою вмісту повідомлень, не використовує чергу повідомлень та не взаємодіє з транспортною службою поштових скриньок. Іншими словами, сервери Exchange 2013 тільки за участю CAS не зберігають у себе дані ні на постійній основі (використовуючи БД), ні на тимчасовій (у черзі обробки повідомлень).

Тим не менш, служба транспорту переднього плану має власних агентів транспорту (див. рисунок - Агенти протоколу). Агенти дозволяють розширювати функціонал поштового сервера Exchange шляхом додавання до логіки обробки повідомлень власного коду. Виклик агентів відбувається у разі виникнення подій SMTP. Ці події, у свою чергу, генеруються на тій чи іншій стадії обробки повідомлень у міру їхнього проходження через транспортний конвеєр. Варто зазначити, що більшість присутніх за умовчанням агентів приховані або їх налаштування не можна керувати. Функціонал агентів на CAS-серверах досить сильно обмежений і присутня тільки у ролей MBX і Edge.

З'єднувачі відправлення та отримання

На схемі (див. вище) Транспортної служби переднього планусервера клієнтського доступу позначимо на кожному вхідному та вихідному з'єднанні відповідний порт, отримавши в результаті таке уявлення:

За прослуховування підключень кожного порту, позначеного на схемі, відповідає окремий з'єднувач отримання, яких за умовчанням при встановленні ролі CAS створюється три штуки:

Крім видимих ​​та доступних адміністратору з'єднувачів, існують також приховані системні з'єднувачі відправки:

  • Inbound Proxy Internal Send Connector (SMTP 25/2525 )
  • Client Proxy Send Connector (SMTP, прийняті на 587 порту в Транспортну службу на серверах поштових скриньокна порт 465)

До речі, перший з'єднувач у російськомовній версії Exchange Server 2013 матиме ім'я Внутрішній з'єднувач надсилання для входу. підкл. проксі-сервера, а другий - З'єднувач відправки проксі клієнта. Це про всяк випадок, щоб не прийти в ступор при першій зустрічі з цими конекторами.

У результаті отримуємо таку повну таблицю:

Назва Призначення Порт Напрям
Default Frontend Прийом 25 Від зовнішніх серверів
Outbound Proxy Frontend Прийом 717 Від серверів MBX
Client Frontend Прийом 587 Від зовнішніх клієнтів, захищене підключення
Client Proxy Send Connector Надсилання 465 На сервери MBX
Inbound Proxy Internal Send Connector Надсилання 25/2525 На сервери MBX. Тільки підключення, прийняті на 587 порту
Створений вручну з'єднувач відправки Надсилання 25 На зовнішні сервери

Перенесемо назви з'єднувачів на схему Транспортної служби переднього плану.

Застосовується до: Exchange Server 2010 SP1

Остання зміна розділу: 2011-04-22

У цьому розділі наведено відомості про порти, автентифікацію та шифрування для всіх шляхів до даних, які використовуються в Microsoft Exchange Server 2010. Розділ «Примітки» після кожної таблиці уточнює або визначає нестандартні способи автентифікації або шифрування.

Транспортні сервери

У системі Exchange 2010 є дві ролі сервера, які виконують функції транспортування повідомлень: транспортний сервер-концентратор та прикордонний транспортний сервер.

У наступній таблиці наведено відомості про порти, автентифікацію та шифрування шляхів до даних між цими транспортними серверами та іншими серверами та службами Exchange 2010.

Шляхи даних для транспортних серверів

Шлях даних Необхідні порти Підтримка шифрування

Між двома транспортними серверами-концентраторами

Так, за допомогою TLS (Transport Layer Security)

З транспортного сервера-концентратора на прикордонний транспортний сервер

Пряма довіра

Пряма довіра

Так, з використанням TLS

З прикордонного транспортного сервера на транспортний сервер-концентратор

Пряма довіра

Пряма довіра

Так, з використанням TLS

Між двома прикордонними транспортними серверами

Анонімно, автентифікація за допомогою сертифіката

Анонімно за допомогою сертифіката

Так, з використанням TLS

З сервера поштових скриньок через службу відправки пошти Microsoft Exchange

NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок виконуються на одному сервері, використовується протокол Kerberos.

Так, за допомогою шифрування RPC

З транспортного сервера-концентратора на сервер поштових скриньок через MAPI

NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок встановлені на одному сервері, використовується протокол Kerberos.

Так, за допомогою шифрування RPC

Так, з використанням TLS

Служба Microsoft Exchange EdgeSync із транспортного сервера-концентратора на прикордонний транспортний сервер

Так, за допомогою LDAP через SSL (LDAPS)

Доступ Служба каталогів Active Directory із транспортного сервера-концентратора

Доступ до служби керування правами Служба каталогів Active Directory (AD RMS) з транспортного сервера-концентратора

Так, за допомогою SSL

Клієнти SMTP на транспортний сервер-концентратор (наприклад, кінцеві користувачі за допомогою пошти Windows Live)

Так, з використанням TLS

Примітки для транспортних серверів

  • Весь трафік між транспортними серверами-концентраторами шифрується за допомогою протоколу TLS і сертифікатів, що самозавіряють, встановлених програмою установки Exchange 2010.
  • Весь трафік між прикордонними транспортними серверами та транспортними серверами-концентраторами проходить автентифікацію та шифрується. Як механізм автентифікації та шифрування використовується Mutual TLS. Замість перевірки X.509 у Exchange 2010 для автентифікації сертифікатів використовується пряма довіра. Пряма довіра означає, що наявність сертифіката в службах Служба каталогів Active Directory або в службах Active Directory полегшеного доступу до каталогів (AD LDS) підтверджує дійсність сертифіката. Служба каталогів Active Directory вважається довіреним механізмом зберігання. Коли використовується пряма довіра, не має значення, чи застосовується сертифікат, що самозавірює, або сертифікат, підписаний центром сертифікації. При підписці прикордонного транспортного сервера на організацію Exchange прикордонна підписка публікує сертифікат прикордонного транспортного сервера в службі каталогів Active Directory, щоб транспортні сервери-концентратори могли його перевіряти. Служба Microsoft Exchange EdgeSync додає до служб Active Directory полегшеного доступу до каталогів (AD LDS) набір сертифікатів транспортного сервера-концентратора, щоб прикордонний транспортний сервер перевірив їх.
  • EdgeSync використовує безпечне підключення LDAP транспортного сервера-концентратора до підписаних прикордонних транспортних серверів через порт TCP 50636. Служби Active Directory полегшеного доступу до каталогів також здійснюють прослуховування порту TCP 50389. Підключення до цього порту не використовує протокол SSL. Для підключення до цього порту та перевірки даних служб Active Directory полегшеного доступу до каталогів можна використовувати службові програми LDAP.
  • За промовчанням трафік між прикордонними транспортними серверами, розташованими у двох різних організаціях, шифрується. Програма установки Exchange 2010 створює сертифікат, що самозавіряє, і за замовчуванням включає TLS. Це дозволяє будь-якій відправляючій системі шифрувати сеанс SMTP, що входить в Exchange. За промовчанням, сервер Exchange 2010 також намагається використовувати протокол TLS для всіх віддалених підключень.
  • Способи автентифікації для трафіку між транспортними серверами-концентраторами та серверами поштових скриньок відрізняються, якщо ролі транспортного сервера-концентратора та сервера поштових скриньок встановлені на одному комп'ютері. При локальній передачі пошти використовується автентифікація Kerberos. Під час віддаленої передачі пошти використовується автентифікація NTLM.
  • Exchange 2010 також підтримує безпеку домену. Безпека домену – це набір функцій Exchange 2010 та Microsoft Outlook 2010, які є недорогою альтернативою S/MIME та іншим рішенням для забезпечення безпеки передачі повідомлень через Інтернет. Безпека домену забезпечує спосіб керування безпечними шляхами надсилання повідомлень між доменами в Інтернеті. Після налаштування таких безпечних шляхів успішно передані по них повідомлення від відправника, що пройшов автентифікацію, відображаються для користувачів Outlook і Outlook Web Access як повідомлення, «захищені на рівні домену». Щоб отримати додаткові відомості, див. Загальні відомості про безпеку домену.
  • Багато агентів можуть виконуватися як у транспортних серверах-концентраторах, і на прикордонних транспортних серверах. Як правило, агенти захисту від небажаної пошти використовують відомості локального комп'ютера, на якому вони виконуються. Таким чином, практично не потрібна взаємодія з віддаленими комп'ютерами. Винятком є ​​фільтрація одержувачів. Для фільтрації одержувачів потрібний виклик AD LDS або Служба каталогів Active Directory. Фільтрацію одержувачів рекомендується виконувати на прикордонному транспортному сервері. У цьому випадку каталог AD LDS знаходиться на тому ж комп'ютері, на якому встановлено роль прикордонного транспортного сервера, тому віддалене підключенняне вимагається. Якщо функція фільтрації одержувачів встановлена ​​та налаштована на транспортному сервері-концентраторі, необхідний доступ до служби каталогів Active Directory.
  • Агент аналізу протоколу використовується функцією репутації відправника Exchange 2010. Цей агент також підключається до різних зовнішніх проксі-серверів, щоб визначити шляхи вхідних повідомлень для підозрілих підключень.
  • Всі інші функції захисту від небажаної пошти використовують дані, які збираються, зберігаються та доступні лише на локальному комп'ютері. Зазвичай такі дані, як об'єднаний список надійних відправників або дані одержувачів для фільтрації одержувачів, примусово надсилаються до локального каталогу AD LDS за допомогою служби Microsoft Exchange EdgeSync.
  • Агенти управління правами на доступ до даних (IRM) на транспортних серверах-концентраторах виконують підключення до серверів служб управління правами Active Directory (AD RMS) в організації. Служба керування правами Active Directory (AD RMS) – це веб-служба, яку рекомендується захищати за допомогою SSL. Підключення до серверів служб керування правами Active Directory виконується за допомогою HTTPS, а для автентифікації використовується Kerberos або NTLM залежно від конфігурації сервера служб керування правами Active Directory.
  • Правила журналів, правила транспорту та класифікації повідомлень зберігаються у службах Служба каталогів Active Directory, і доступ до них здійснює агент ведення журналу та агент правил транспорту на транспортних серверах-концентраторах.

    Сервери поштових скриньок

    На серверах поштових скриньок використання автентифікації NTLM або Kerberos залежить від контексту користувача або процесу, в рамках якого працює споживач рівня бізнес-логіки Exchange. У такому контексті споживачами є будь-які програми чи процеси, які використовують рівень бізнес-логіки Exchange. В результаті в стовпці Стандартна автентифікаціятаблиці Шляхи до даних для серверів поштових скриньокдля багатьох рядків вказано значення NTLM/Kerberos.

    Рівень бізнес-логіки Exchange використовується для доступу до сховища Exchange та взаємодії з ним. Рівень бізнес-логіки Exchange також викликається зі сховища Exchange для взаємодії із зовнішніми програмами та процесами.

    Якщо споживач рівня бізнес-логіки Exchange виконується в контексті локальної системи, способом автентифікації при доступі споживача до сховища Exchange завжди є Kerberos. Спосіб автентифікації Kerberos використовується через те, що справжність одержувача необхідно перевіряти з використанням облікового записукомп'ютера "Локальна система", а також потрібна двостороння довіра з автентифікацією.

    Якщо одержувач рівня бізнес-логіки Exchange виконується не в контексті локальної системи, способом автентифікації є NTLM. Наприклад, коли адміністратор запускає командлет командної консолі Exchange, який використовує рівень бізнес-логіки Exchange, застосовує автентифікацію NTLM.

    Трафік RPC завжди шифрується.

    У наступній таблиці наведено відомості про порти, автентифікацію та шифрування шляхів даних для серверів поштових скриньок.

    Шляхи даних для серверів поштових скриньок

    Шлях до даних Необхідні порти Стандартна автентифікація Підтримуваний спосіб автентифікації Підтримка шифрування Шифрування даних за замовчуванням

    389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мережевий вхід до системи RPC)

    Так, за допомогою шифрування Kerberos

    Адміністративний віддалений доступ (віддалений реєстр)

    Так, за допомогою IPsec

    Адміністративний віддалений доступ (SMB, файли)

    Так, за допомогою IPsec

    Веб-служба доступності (клієнтський доступ до поштової скриньки)

    Так, за допомогою шифрування RPC

    Кластеризація

    Так, за допомогою шифрування RPC

    Між серверами клієнтського доступу (Exchange ActiveSync)

    80/TCP, 443/TCP (SSL)

    Kerberos, автентифікація за допомогою сертифіката

    Так, за допомогою HTTPS

    Так, з використанням самозавірювального сертифіката

    Між серверами клієнтського доступу (Outlook Web Access)

    80/TCP, 443/TCP (HTTPS)

    Так, за допомогою SSL

    Сервер клієнтського доступу до сервера клієнтського доступу (Веб-служби Exchange)

    Так, за допомогою SSL

    Сервер клієнтського доступу до сервера клієнтського доступу (POP3)

    Так, за допомогою SSL

    Сервер клієнтського доступу до сервера клієнтського доступу (IMAP4)

    Так, за допомогою SSL

    Сервер Office Communications Server до сервера клієнтського доступу (коли включена інтеграція Office Communications Server та Outlook Web App)

    5075-5077/TCP (ВХІД), 5061/TCP (ВИХІД)

    mTLS (обов'язково)

    mTLS (обов'язково)

    Так, за допомогою SSL

    Примітки для серверів клієнтського доступу

    Сервери єдиної системиобміну повідомленнями

    Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують лише автентифікацію за допомогою сертифіката, при якій використовується автентифікація Mutual TLS для шифрування трафіку SIP та автентифікація на основі IP-адреси для підключень за протоколами SIP або TCP. Шлюзи IP не підтримують автентифікацію NTLM і Kerberos. Таким чином, при використанні автентифікації на основі IP-адреси в якості механізму автентифікації для незашифрованих підключень (TCP) використовуються IP-адреси підключень. При використанні в єдиній системі обміну повідомленнями автентифікації на основі IP-адрес перевіряє, чи дозволено цій IP-адресі підключатися. IP-адреса настроюється на шлюзі IP або IP PBX.

    Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують Mutual TLS для шифрування трафіку SIP. Після успішного імпорту та експорту необхідних довірених сертифікатів шлюз IP або УВАТС, що працює за протоколом IP, запитуватиме сертифікат у сервера єдиної системи обміну повідомленнями, а потім запитуватиме сертифікат у шлюзу IP або УВАТС, що працює за протоколом IP. Обмін довіреними сертифікатами між шлюзом IP або УВАТС, що працює за протоколом IP, та сервером єдиної системи обміну повідомленнями дозволяє обом пристроям взаємодіяти безпечним каналом за допомогою Mutual TLS.

    У наступній таблиці наведено відомості про порти, автентифікацію та шифрування для шляхів даних між серверами єдиної системи обміну повідомленнями та іншими серверами.

    Шляхи даних для серверів єдиної системи обміну повідомленнями

    Шлях до даних Необхідні порти Стандартна автентифікація Підтримуваний спосіб автентифікації Підтримка шифрування Шифрування даних за замовчуванням

    Доступ до служби каталогів Active Directory

    389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мережевий вхід до системи RPC)

    Так, за допомогою шифрування Kerberos

    Телефонна взаємодія єдиної системи обміну повідомленнями (шлюз IP PBX/VoIP)

    5060/TCP , 5065/TCP, 5067/TCP (у незахищеному режимі), 5061/TCP, 5066/TCP, 5068/TCP (у захищеному режимі), динамічний порт з діапазону 16000-17000/TCP (управління) з діапазону 1024-65535/UDP (RTP)

    IP-адресою

    За IP-адресою, MTLS

    Так, за допомогою SIP/TLS, SRTP

    Веб-служба єдиної системи обміну повідомленнями

    80/TCP, 443/TCP (SSL)

    Інтегрована перевірка автентичності Windows(Negotiate)

    Так, за допомогою SSL

    Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу

    5075, 5076, 5077 (TCP)

    Вбудована автентифікація Windows (узгодження)

    Звичайна, дайджест-автентифікація, NTLM, узгодження (Kerberos)

    Так, за допомогою SSL

    Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу (відтворення на телефоні)

    Динамічний RPC

    Так, за допомогою шифрування RPC

    Із сервера єдиної системи обміну повідомленнями на транспортний сервер-концентратор

    Так, з використанням TLS

    З сервера єдиної системи обміну повідомленнями на сервер поштових скриньок

    Так, за допомогою шифрування RPC

    Примітки для серверів єдиної системи обміну повідомленнями

    • При створенні об'єкта шлюзу IP єдиної системи обміну повідомленнями в Службі каталогів Active Directory необхідно визначити IP-адресу фізичного шлюзу IP або УВАТС, що працює за протоколом IP. При визначенні IP-адреси об'єкта шлюзу IP єдиної системи обміну повідомленнями IP-адреса додається до списку допустимих шлюзів IP або УВАТС, що працюють за протоколом IP (також званими учасниками SIP-сеансу), з якими можна взаємодіяти серверу єдиної системи обміну повідомленнями. Після створення шлюзу IP єдиної системи обміну повідомленнями, можна зв'язати його з абонентською групою цієї системи. Зіставлення шлюзу IP єдиної системи обміну повідомленнями з абонентською групою дозволяє серверам єдиної системи обміну повідомленнями, зіставленим з абонентською групою, використовувати автентифікацію на основі IP-адреси для взаємодії зі шлюзом IP. Якщо шлюз IP єдиної системи обміну повідомленнями не був створений або не був налаштований на використання правильної IP-адреси, то відбудеться збій автентифікації, і сервери єдиної системи обміну повідомленнями не прийматимуть підключення з IP-адреси даного шлюзу IP. Крім того, при реалізації Mutual TLS, шлюзу IP або УВАТС, що працює за протоколом IP, та серверів єдиної системи обміну повідомленнями, шлюз IP єдиної системи обміну повідомленнями необхідно налаштувати на використання повного доменного імені (FQDN). Після налаштування шлюзу IP єдиної системи обміну повідомленнями з використанням повного доменне ім'я необхідно також додати до зони прямого пошуку DNS запис вузла для цього шлюзу.
    • У версії Exchange 2010 сервер єдиної системи обміну повідомленнями може взаємодіяти через порт 5060/TCP (незахищений) або через порт 5061/TCP (захищений), і можна налаштувати для використання обох портів.

    Щоб отримати додаткові відомості, див. Загальні відомості про безпеку VoIP єдиної системи обміну повідомленнями та Загальні відомості про протоколи, порти та служби в єдиній системі обміну повідомленнями .

    Правила брандмауера Windows, створені програмою інсталяції Exchange 2010

    Брандмауер Windows у режимі підвищеної безпеки- це брандмауер з відстеженням стану на основі комп'ютера, який здійснює фільтрацію вхідного та вихідного трафіку на основі правил брандмауера. Програма інсталяції Exchange 2010 створює правила брандмауера Windows для відкриття портів, необхідних для взаємодії сервера та клієнта, у кожній ролі сервера. Таким чином, більше не потрібно використовувати майстер налаштування безпеки для налаштування цих параметрів. Додаткові відомості про брандмауер Windows у режимі підвищеної безпеки див. у статті Брандмауер Windows у режимі підвищеної безпеки та IPsec (сторінка може бути англійською мовою).

    У наступній таблиці наведено правила брандмауера Windows, створювані програмоюінсталяції Exchange, включаючи порти, відкриті в кожній ролі сервера. Ці правила можна переглянути за допомогою оснащення консолі MMC брандмауера Windows у режимі підвищеної безпеки.

    Ім'я правила Ролі сервера Порт Програма

    MSExchangeADTopology - RPC (вхідний TCP)

    Динамічний RPC

    Bin\MSExchangeADTopologyService.exe

    MSExchangeMonitoring - RPC (вхідний TCP)

    Сервер клієнтського доступу, транспортний сервер-концентратор, прикордонний транспортний сервер, сервер єдиної системи обміну повідомленнями

    Динамічний RPC

    Bin\Microsoft.Exchange.Management.Monitoring.exe

    MSExchangeServiceHost - RPC (вхідний TCP)

    Динамічний RPC

    Bin\Microsoft.Exchange.ServiceHost.exe

    MSExchangeServiceHost - RPCEPMap (вхідний TCP)

    Bin\Microsoft.Exchange.Service.Host

    MSExchangeRPCEPMap (GFW) (вхідний TCP)

    MSExchangeRPC (GFW) (вхідний TCP)

    Сервер клієнтського доступу, транспортний сервер-концентратор, сервер поштових скриньок, сервер єдиної системи обміну повідомленнями

    Динамічний RPC

    MSExchange - IMAP4 (GFW) (вхідний TCP)

    Сервер клієнтського доступу

    MSExchangeIMAP4 (вхідний TCP)

    Сервер клієнтського доступу

    ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe

    MSExchange - POP3 (FGW) (вхідний TCP)

    Сервер клієнтського доступу

    MSExchange - POP3 (вхідний TCP)

    Сервер клієнтського доступу

    ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe

    MSExchange - OWA (GFW) (вхідний TCP)

    Сервер клієнтського доступу

    5075, 5076, 5077 (TCP)

    MSExchangeOWAAppPool (вхідний TCP)

    Сервер клієнтського доступу

    5075, 5076, 5077 (TCP)

    Inetsrv\w3wp.exe

    MSExchangeAB RPC (вхідний TCP)

    Сервер клієнтського доступу

    Динамічний RPC

    MSExchangeAB-RPCEPMap (вхідний TCP)

    Сервер клієнтського доступу

    Bin\Microsoft.Exchange.AddressBook.Service.exe

    MSExchangeAB-RpcHttp (вхідний TCP)

    Сервер клієнтського доступу

    6002, 6004 (TCP)

    Bin\Microsoft.Exchange.AddressBook.Service.exe

    RpcHttpLBS (вхідний TCP)

    Сервер клієнтського доступу

    Динамічний RPC

    System32\Svchost.exe

    MSExchangeRPC - RPC (вхідний TCP)

    Динамічний RPC

    MSExchangeRPC - PRCEPMap (вхідний TCP)

    Сервер клієнтського доступу, сервер поштових скриньок

    Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

    MSExchangeRPC (вхідний TCP)

    Сервер клієнтського доступу, сервер поштових скриньок

    Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

    MSExchangeMailboxReplication (GFW) (вхідний TCP)

    Сервер клієнтського доступу

    MSExchangeMailboxReplication (вхідний TCP)

    Сервер клієнтського доступу

    Bin\MSExchangeMailboxReplication.exe

    MSExchangeIS - RPC (TCP-вхідний)

    Сервер поштових скриньок

    Динамічний RPC

    MSExchangeIS RPCEPMap (вхідний TCP)

    Сервер поштових скриньок

    MSExchangeIS (GFW) (вхідний TCP)

    Сервер поштових скриньок

    6001, 6002, 6003, 6004 (TCP)

    MSExchangeIS (вхідний TCP)

    Сервер поштових скриньок

    MSExchangeMailboxAssistants - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    MSExchangeMailboxAssistants - RPCEPMap (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeMailboxAssistants.exe

    MSExchangeMailSubmission - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    MSExchangeMailSubmission - RPCEPMap (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeMailSubmission.exe

    MSExchangeMigration - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    Bin\MSExchangeMigration.exe

    MSExchangeMigration - RPCEPMap (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeMigration.exe

    MSExchangerepl - Log Copier (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeRepl.exe

    MSExchangerepl - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    Bin\MSExchangeRepl.exe

    MSExchangerepl - RPC-EPMap (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeRepl.exe

    MSExchangeSearch - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    Bin\Microsoft.Exchange.Search.ExSearch.exe

    MSExchangeThrottling - RPC (вхідний TCP)

    Сервер поштових скриньок

    Динамічний RPC

    Bin\MSExchangeThrottling.exe

    MSExchangeThrottling - RPCEPMap (вхідний TCP)

    Сервер поштових скриньок

    Bin\MSExchangeThrottling.exe

    MSFTED - RPC (TCP-вхідний)

    Сервер поштових скриньок

    Динамічний RPC

    MSFTED - RPCEPMap (TCP-вхідний)

    Сервер поштових скриньок

    MSExchangeEdgeSync - RPC (вхідний TCP)

    Транспортний сервер-концентратор

    Динамічний RPC

    MSExchangeEdgeSync RPCEPMap (вхідний TCP)

    Транспортний сервер-концентратор

    Bin\Microsoft.Exchange.EdgeSyncSvc.exe

    MSExchangeTransportWorker - RPC (вхідний TCP)

    Транспортний сервер-концентратор

    Динамічний RPC

    Bin\edgetransport.exe

    MSExchangeTransportWorker - RPCEPMap (вхідний TCP)

    Транспортний сервер-концентратор

    Bin\edgetransport.exe

    MSExchangeTransportWorker (GFW) (вхідний TCP)

    Транспортний сервер-концентратор

    MSExchangeTransportWorker (вхідний TCP)

    Транспортний сервер-концентратор

    Bin\edgetransport.exe

    MSExchangeTransportLogSearch - RPC (вхідний TCP)

    Динамічний RPC

    MSExchangeTransportLogSearch - RPCEPMap (вхідний TCP)

    Транспортний сервер-концентратор, прикордонний транспортний сервер, сервер поштових скриньок

    Bin\MSExchangeTransportLogSearch.exe

    SESWorker (GFW) (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    SESWorker (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    UnifiedMessaging\SESWorker.exe

    UMService (GFW) (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    UMService (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    Bin\UMService.exe

    UMWorkerProcess (GFW) (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    5065, 5066, 5067, 5068

    UMWorkerProcess (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    5065, 5066, 5067, 5068

    Bin\UMWorkerProcess.exe

    UMWorkerProcess - RPC (вхідний TCP)

    Сервер єдиної системи обміну повідомленнями

    Динамічний RPC

    Bin\UMWorkerProcess.exe

    Примітки до правил брандмауера Windows, створених програмою інсталяції Exchange 2010

    • На серверах із встановленими службами IIS Windows відкриває порти HTTP (порт 80, TCP) та HTTPS (порт 443, TCP). Програма інсталяції Exchange 2010 не відкриває ці порти. Отже, ці порти не наведено у попередній таблиці.
    • У Windows Server 2008 та Windows Server 2008 R2 брандмауер Windows у режимі підвищеної безпеки дозволяє вказати процес або службу, для яких відкритий порт. Це безпечніше, оскільки порт може використовуватися лише процесом чи службою, зазначеної у правилі. Програма інсталяції Exchange створює правила брандмауера із зазначеним ім'ям процесу. У деяких випадках з метою сумісності також створюється додаткове правило, не обмежене цим процесом. Можна вимкнути або видалити правила, не обмежені процесами, та зберегти відповідні правила, обмежені процесами, якщо поточне середовище розгортання підтримує їх. Правила, не обмежені процесами, можна відрізнити за словом (GFW)у імені правила.
    • Багато служб Exchange використовують для взаємодії віддалені дзвінки процедур (RPC). Серверні процеси, що використовують віддалені виклики процедур, підключаються до співставника кінцевих точок RPC для отримання динамічних кінцевих точокта реєстрації їх у базі даних порівняча кінцевих точок. Клієнти RPC взаємодіють із співставником кінцевих точок RPC для визначення кінцевих точок, що використовуються серверним процесом. За промовчанням співставник кінцевих точок RPC прослуховує порт 135 (TCP). При налаштуванні брандмауера Windows для процесу, що використовує віддалені дзвінки процедур, програма інсталяції Exchange 2010 створює для цього процесу два правила брандмауера. Одне правило дозволяє взаємодію із співставником кінцевих точок RPC, а друге дозволяє взаємодію з динамічно призначеною кінцевою точкою. Для отримання додаткових відомостей про віддалені дзвінки процедур див. статтю . Для отримання додаткових відомостей про створення правил брандмауера Windows для динамічного віддаленого виклику процедур див.

      Додаткові відомості див. у статті 179442 бази знань Microsoft

Нещодавно довелося пиляти сервер Microsoft Exchange, а потім прописувати правила на фаєрволлі для портів. Так перед цим довго довелося з'ясовувати — які порти використовує Microsoft Exchange для роботи. Щось вдалося дізнатися на форумах, а щось довелося перевіряти і з'ясовувати самому, тож якщо якийсь порт ексчендж, що використовується, я випустив — пишіть у коментарях.

SMTP TCP: 25
SMTP Services використовує TCP port 25.

DNS TCP/UDP: 53
DNS listens on port 53. Домашні контролери використовують цей port.

HTTP TCP: 80
HTTP Server Port.

POP3 TCP: 110
Post Office Protocol Version 3 (POP3).

NNTP TCP: 119
Network News Transfer Protocol (NNTP).

MSRPC TCP/UDP: 135
Microsoft RPC and Locator service — LOC-SRV

IMAP4 TCP: 143
Internet Message Access Protocol (IMAP).

LDAP TCP/UDP: 379
The Site Replication Service (SRS).

LDAP TCP/UPD: 389
Lightweight directory access protocol (LDAP), використовуваний Microsoft Active Directory® directory service, Active Directory Connector, та Microsoft Exchange Server 5.5 directory.

LDAP TCP/UDP: 390
Це є сумісний альтернативний port для налаштування Exchange Server 5.5 LDAP protocol, коли Exchange Server 5.5 є керування на Active Directory домашній контролер.

HTTP/SSL TCP: 443
HTTP over SSL.

SMTP/SSL:465
SMTP over SSL. TCP port 465 is reserved common industry practice for secure SMTP communication using the SSL protocol.

NNTP/SSL TCP: 563
NNTP over SSL.

LDAP/SSL TCP/UDP: 636
LDAP over Secure Sockets Layer (SSL).

LSA TCP: 691
Microsoft Exchange Routing Engine Service (RESvc) повідомлень для routing link state information on this port.

IMAP4/SSL TCP: 993
IMAP4 over SSL.

POP3/SSL TCP: 995
POP3 over SSL.

LDAP TCP: 3268
Global catalog. Windows 2000 і Windows Server 2003 Active Directory Global Catalog (на домашній контролер «Роля») на TCP port 3268.

LDAP/SSLPort TCP: 3269
Global catalog over SSL. Applications that connect to TCP port 3269 of Global Catalog Server може transmit and receive SSL завантажені дані.