De la Rosalab Wiki

Programare

Acest ghid descrie cum să conectați diferiți clienți de e-mail la serverul Microsoft Exchange. Scopul este de a obține un sistem care se potrivește cu funcționalitatea Microsoft Outlook.

Date de intrare

Exemplele utilizează Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Testarea este efectuată în rețeaua corporativă. Adresele de e-mail externe pentru serverul de e-mail sunt specificate pe serverele DNS. Următoarele ar trebui să ruleze pe serverul Exchange:

1. OWA (Outlook Web Access) - un client web pentru accesarea Microsoft Exchange Community Server
2. OAB (Offline Address Book) - agenda offline
3. EWS (Servicii Web Exchange) este un serviciu care oferă acces la datele cutiei poștale stocate în Exchange Online (ca parte a Office 365) și Exchange local (începând cu Exchange Server 2007)

Setări Exchange Server

Autentificarea este esențială pentru succesul clienților non-Microsoft pe Exchange 2010. Puteți vizualiza parametrii acestuia pe serverul Exchange cu rolul CAS (Server de acces la client). Porniți snap-in Manager IIS și faceți clic pe fila Site-uri / Site web implicit. Acordați atenție autentificării în trei componente:

• OWA - Stat " Pornit" pentru " Autentificare de bază" și " Autentificare Windows»:

• OAB - stat " Pornit" pentru " Autentificare de bază" și " Autentificare Windows»:

• EWS - Stare " Pornit" pentru " Autentificare anonimă», « Autentificare de bază" și " Autentificare Windows»:

Interstraturi (intermediari) și utilități auxiliare

DavMail

Unii clienți de e-mail nu se pot conecta direct la Microsoft Exchange și necesită utilizarea unui strat intermediar (intermediar). În acest exemplu, un server proxy este folosit ca intermediar DavMail.

• Instalare DavMail prin obținerea drepturilor de administrator cu su sau sudo:

sudo urpmi davmail

• Alerga DavMail:

• În fila „Principal” din „ URL OWA (Exchange).„Introduceți adresa serverului dumneavoastră în formatul” https: // /EWS/Exchange.asmx „sau un link către OWA

în formatul „https: // / owa ".

• Amintiți-vă numerele portului „ Port IMAP local" și " Port SMTP local". În acest exemplu, acestea sunt 1143 și, respectiv, 1025.

Pentru a nu porni manual serverul de fiecare dată DavMail, trebuie să adăugați apelul său la pornire.

• Accesați meniul " Setări sistem -> Pornire și oprire -> Pornire automată", Apasă pe [ Adăugați aplicația] și introduceți „davmail” în bara de căutare, apoi faceți clic pe [ O.K]:

Acum proxy local DavMail va porni automat la pornirea sistemului. Dacă pictograma sa din „Tava de sistem” vă deranjează, o puteți ascunde. Pentru a face acest lucru, în fișierul .davmail.properties editați linia davmail.server = false, schimbând false în adevărat:

Sudo mcedit / home /<имя_пользователя>/.davmail.properties

Clienți de e-mail pentru a se conecta la Exchange

Acum puteți începe să vă configurați clienții de e-mail.

Thunderbird

Mozilla Thunderbird este principalul client de e-mail pentru distribuțiile ROSA Linux și cel mai probabil este deja instalat pe sistemul dvs. și gata de funcționare. Dacă nu, îl puteți instala din depozitele ROSA. Acest exemplu folosește versiunea 52.2.1.

• Instalare Thunderbird:

sudo urpmi mozilla-thunderbird

• Adăugați o interfață în limba rusă:

sudo urpmi mozilla-thunderbird-ru

• Instalați suplimentul Lightning pentru a utiliza calendare:

sudo urpmi mozilla-thunderbird-fulger

• Alerga Thunderbird.

• la capitolul " Conturi„în punct” Creați un cont"Selectați" E-mail". Va apărea o fereastră de bun venit.

• În fereastra care se deschide, faceți clic pe [ Omite acest lucru și folosește e-mailul meu existent].

• La fereastră " Configurarea unui cont de e-mail"Intra in campuri" Numele dumneavoastră», « Adresa de email Poștă" și " Parola»Acreditările dvs.

• Faceți clic pe [ Continua]. Programul va încerca să găsească conexiuni (fără succes) și va apărea un mesaj de eroare:

Aici veți avea nevoie de numerele de porturi pe care le-ați amintit la configurare DavMail.

• Pentru categorii " Sosire" și " De ieșire„Schimbați numele serverului în” localhost”.
• Indicați pentru " IMAP„Port 1143 și pentru” SMTP"- portul 1025.
• In camp " Nume de utilizator„Specificați UPN (Nume principal de utilizator) - numele de domeniu al utilizatorului în formatul „[email protected]”.
• Faceți clic pe [ Retestați].

Dacă introduceți acreditările corecte, nu vor exista erori. Este posibil ca sistemul să vă solicite să acceptați certificatul Exchange Server. Dacă acest lucru nu se întâmplă, este posibil să fi dezactivat interfața prea devreme. DavMail.

Creați un calendar al utilizatorului

• In categoria " Conturi„Selectați elementul” Creați un calendar nou».
• În fereastra care apare, selectați valoarea „ Pe net" și apăsați [ Mai departe].
• Selectați formatul " CalDAV„Și pe câmp” Adresa„Introduceți” http: // localhost: 1080 / utilizatori / / calendar ":

Crearea unei agende de adrese

Agenda de adrese Thunderbird nu acceptă CardDAV și poate fi conectat numai la directorul LDAP Exchange Server.

• Deschideți agendele de adrese existente făcând clic pe [ Agenda de adrese] și selectând elementul " Fișier -> Nou -> Director LDAP».

• Specificați următorii parametri în fereastra expertului:
  • Nume- orice nume potrivit
  • Numele serverului- gazdă locală
  • Element rădăcină (DN de bază)- ou = oameni
  • Port- 1389 (de la Davmail)
  • Nume de utilizator (Bind DN)- Nume de utilizator UPN

• Faceți clic pe [ O.K]. Programul vă va cere să introduceți o parolă.

• Accesați meniul de opțiuni Thunderbird... In categoria " Redactarea„Selectați fila” Adresarea„Și sub text” Când introduceți o adresă, căutați adrese poștale potrivite în „bifați caseta” Directory Server„Alegând numele agendei dvs. de adrese.

Evoluţie

Un client de e-mail este, de asemenea, disponibil în depozitele ROSA Evoluţie(Acest exemplu folosește versiunea 3.16.4).

• Instalare Evoluţie:

sudo urpmi evolution

• Instalați conectorul schimb valutar compatibil cu versiunea 2007 și ulterioară:

sudo urpmi evolution-ews

• Alerga Evoluţie.

• În fereastra expertului, faceți clic pe [ Următorul] până când ajungeți la „ Cont».
• Completați câmpurile „ Numele complet" și " E-mail».
• Pe fila „ Primirea corespondenței"În listă" Tip server„Selectați” Servicii web Exchange”.
• Pentru nume, specificați numele UPN al utilizatorului în formatul „[email protected]”.
• In camp " Adresa URL a gazdei„Enter” https: // MailServerNameExchange/EWS/Exchange.asmx .
• In camp " URL OAB»Introduceți adresa URL a agendei offline.
• Selectați „De bază” ca tip de autentificare.

După configurarea cu succes, programul va cere o parolă:

După introducerea parolei Evoluţie va avea acces la căsuța poștală, agenda și calendarele dvs.

Pentru orice întrebări legate de acest articol, vă rugăm să contactați [email protected]

Dacă încercați să adăugați contul Outlook.com la o altă aplicație de e-mail, este posibil să aveți nevoie de setări POP, IMAP sau SMTP pentru Outlook.com. Le puteți găsi mai jos sau urmând linkul Configurați POP și IMAP pe Outlook.com.

Dacă doriți să adăugați contul Outlook.com la un dispozitiv inteligent, cum ar fi o cameră pentru a securiza computerele de acasă, aveți nevoie de o parolă pentru aplicație. Pentru mai multe informații, consultați Adăugarea contului Outlook.com la o altă aplicație de e-mail sau dispozitiv inteligent.

Setări POP, IMAP și SMTP pentru Outlook.com

Dacă doriți să adăugați contul dvs. Outlook.com la un alt program de e-mail care acceptă POP sau IMAP, utilizați următoarele setări de server.

Note:

Numele serverului IMAP Outlook.Office365.com

Port IMAP: 993

Metoda de criptare IMAP TLS

Outlook.office365.com Nume server POP

Port POP: 995

Metoda de criptare POP TLS

Nume server SMTP SMTP.Office365.com

Port SMTP: 587

Metoda de criptare SMTP STARTTLS

Activați accesul POP în Outlook.com

Dacă doriți să utilizați POP pentru a vă accesa e-mailul în Outlook.com, va trebui să îl activați.

Modificați setările furnizorului dvs. de e-mail

Dacă încercați să conectați un alt cont la Outlook.com utilizând POP, poate fi necesar să modificați unele dintre setările furnizorului dvs. de e-mail pentru a stabili o conexiune care poate fi blocată.

Pentru conturile Gmail cu acces POP,.

Pentru conturile Yahoo POP, urmați pașii de mai jos.

Dacă utilizați alți furnizori de e-mail, ar trebui să îi contactați pentru instrucțiuni de deblocare a conexiunii.

Erori de conexiune IMAP Outlook.com

Dacă v-ați configurat contul Outlook.com ca IMAP pe mai mulți clienți de e-mail, este posibil să primiți o eroare de conexiune. Lucrăm la o remediere și vom actualiza acest articol dacă avem mai multe informații. Deocamdată, încearcă următoarea soluție:

Dacă utilizați Outlook.com pentru a accesa un cont folosind un alt domeniu decât @live. com, @hotmail. com sau @outlook. com, nu veți putea să vă sincronizați conturile IMAP. Pentru a remedia această problemă, ștergeți contul IMAP conectat în Outlook.com și reconfigurați-l ca conexiune POP. Pentru instrucțiuni despre cum să vă reconfigurați contul pentru a utiliza POP, contactați furnizorul contului dvs. de e-mail.

Dacă utilizați un cont GoDaddy, urmați aceste instrucțiuni pentru a modifica setările contului GoDaddy pentru a utiliza o conexiune POP. Dacă folosirea POP nu rezolvă problema sau doriți să activați IMAP (dezactivat implicit), trebuie să contactați serviciul

În acest articol, vă vom prezenta cum să configurați porturile RPC statice pentru RPC Client Access, Exchange Address Book și Public Folder Access în Exchange 2010.

Să presupunem că avem o organizație complexă cu Exchange Server 2010 SP1 (sau mai mare), care include. Serverele CAS sunt de obicei situate într-o rețea care este separată de firewall-uri de rețelele din care se așteaptă să acceseze utilizatorii (rețele Outlook). Clientul Outlook se conectează la serverul CAS prin RPC, ceea ce înseamnă că orice port din gama liberă de porturi poate fi utilizat la nivel de rețea. Nu este un secret pentru nimeni că în Windows Server 2008 și 2008 R2, intervalul 49152-65535 este utilizat ca interval de porturi dinamice pentru conexiunile RPC (în versiunile anterioare de Windows Server, porturile RPC erau utilizate în intervalul 1025-65535).

Pentru a evita transformarea firewall-urilor într-o sită, este de dorit să restrângeți gama de porturi RPC utilizate, în mod ideal, făcându-le statice pe fiecare server de acces client din matricea de acces client. În plus, utilizarea porturilor RPC statice poate reduce consumul de memorie la echilibratoarele de încărcare (în special HLB) și poate simplifica configurarea acestora (nu este nevoie să specificați intervale mari de porturi).

În Exchange 2010, puteți seta porturi statice pentru serviciul RPC Client Access, precum și pentru serviciul Exchange Address Book. Outlook comunică cu aceste servicii prin interfața MAPI.

Port static pentru serviciul de acces client RPC Exchange 2010

Serviciul virtual Exchange 2010 RPC Client Access este asociat cu serviciul RPC Client Access la care clienții Outlook MAPI se conectează în Exchange 2010. Când un client Outlook se conectează la Exchange, pe Exchange 2010 Client Access, serviciul RPC Client Access utilizează portul TCP End Point Mapper (TCP / 135) și un port aleatoriu din intervalul de porturi dinamice RPC (6005-59530) pentru conexiunile de intrare.

Pentru a seta un port static pentru serviciul RPC Client Access în Exchange 2010, deschideți următoarea cheie în Editorul Registrului:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ MSExchangeRPC

Creați o cheie nouă numită ParametriSistemîn interiorul căruia se creează un parametru de tip REG_DWORD Cu nume Port TCP/IP... Parametrul Port TCP / IP specifică portul static pentru serviciul RPC Client Access. În documentația Microsoft, este recomandat să selectați un port în intervalul 59531 - 60554 și să utilizați această valoare pe toate serverele CAS (am specificat portul 59532, desigur, nu ar trebui să fie folosit de niciun alt software).

După ce lucrările portului static au fost finalizate, serviciul Microsoft Exchange RPC Client Access trebuie repornit pentru ca modificările să aibă efect.

Restart-Service MSExchangeRPC

Port static pentru serviciul de agendă Exchange 2010

În Exchange 2010 înainte de SP1, a fost utilizat un fișier de configurare personalizat pentru a seta portul static pentru serviciul Exchange 2010 Address Book Microsoft.exchange.addressbook.service.exe.config... După lansarea Exchange 2010 SP1, puteți seta un port static pentru acest serviciu prin intermediul registrului. Pentru a face acest lucru, deschideți editorul de registry și accesați ramura:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ MSExchangeAB \ Parametri

Creați un nou parametru RpcTcpPort(de tip REG_SZ) și dați-i numărul portului pe care doriți să îl remediați pentru serviciul Exchange Address Book. Vă recomandăm să utilizați orice port liber din intervalul 59531-60554 și să continuați să îl utilizați pe toate serverele Exchange 2010 Client Access din domeniu. Vom seta RpcTcpPort = 59533

După aceea, trebuie să reporniți serviciul Agendă de adrese Microsoft Exchange

Restart-Service MSExchangeAB

Important: La migrarea de la Exchange 2010 RTM la SP1, această cheie trebuie setată manual, nu este moștenită automat.

Configurarea unui port static pentru conectarea la folderele partajate

Dosarele partajate sunt accesate de la un client Outlook direct prin serviciul RPC Client Access pe un server cu rolul Cutie poștală. Această setare trebuie făcută pe toate serverele cu rolul Cutie poștală care conțin o bază de date de foldere publice (similar cu serverele CAS). Deschideți Editorul Registrului și mergeți la ramură

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ MSExchangeRPC

Creați o cheie nouă numită ParametriSistem, în interiorul căruia se creează un parametru de tip REG_DWORD numit Port TCP/IP... Setați valoarea acestuia: Port TCP / IP = 59532.

După setarea static portul pentru folderele publice, trebuie să reporniți serviciul Microsoft Exchange RPC Client Access pe fiecare server de cutie poștală.

Verificarea utilizării portului static între Outlook și Exchange 2010

După efectuarea modificărilor, să verificăm dacă Outlook se conectează la porturile RPC statice pe care le-am specificat. Pentru a face acest lucru, reporniți Outlook pe computerul client și apoi executați comanda din linia de comandă:

Netstat -na

Se aplică la: Exchange Server 2010 SP1

Secțiunea a fost modificată ultima dată: 2011-04-22

Această secțiune oferă informații despre porturi, autentificare și criptare pentru toate căile de date utilizate în Microsoft Exchange Server 2010. Secțiunea Note de după fiecare tabel clarifică sau identifică metode non-standard de autentificare sau de criptare.

Servere de transport

În Exchange 2010, există două roluri de server care oferă funcționalitate de transport de mesaje: Hub Transport și Edge Transport.

Următorul tabel oferă informații despre porturi, autentificare și criptarea căilor de date între aceste servere de transport și alte servere și servicii Exchange 2010.

Căi de date pentru serverele de transport

Calea datelor	Porturi necesare			Suport pentru criptare
Între două servere Hub Transport				Da, prin TLS (Transport Layer Security)
Transport Hub la Transport Edge		Încredere directă	Încredere directă	Da, folosind TLS
De la un server Edge Transport la un server Hub Transport		Încredere directă	Încredere directă	Da, folosind TLS
Între două servere Edge Transport		Anonim, certificat de autentificare	Utilizarea anonimă a unui certificat	Da, folosind TLS
De la un server de cutie poștală la Serviciul de trimitere a e-mailurilor Microsoft Exchange		NTLM. Dacă rolul de server Hub Transport și rolul de server de cutie poștală rulează pe același server, se utilizează Kerberos.		Da, folosind criptarea RPC
Hub Transport Server la Server Mailbox prin MAPI		NTLM. Dacă rolul de server Hub Transport și rolul de server de cutie poștală sunt instalate pe același server, se utilizează Kerberos.		Da, folosind criptarea RPC
				Da, folosind TLS
Serviciul Microsoft Exchange EdgeSync de la serverul Hub Transport la serverul Edge Transport				Da, folosind LDAP peste SSL (LDAPS)
Accesarea Active Directory de pe un server Hub Transport
Accesarea Active Directory Rights Management Services (AD RMS) de pe un server Hub Transport				Da, cu SSL
Clienți SMTP către un server Hub Transport (de exemplu, utilizatorii finali care folosesc Windows Live Mail)				Da, folosind TLS

Note Server de transport

• Tot traficul dintre serverele Hub Transport este criptat folosind TLS și certificatele autosemnate instalate de Exchange 2010 Setup.
• Tot traficul dintre serverele Edge Transport și serverele Hub Transport este autentificat și criptat. TLS reciproc este utilizat ca mecanism de autentificare și criptare. În loc de autentificare X.509, folosește Exchange 2010 încredere directă... Încrederea directă înseamnă că prezența unui certificat în Active Directory sau Active Directory Lightweight Directory Services (AD LDS) validează autenticitatea certificatului. Active Directory este considerat un motor de stocare de încredere. Când utilizați încredere directă, nu contează dacă utilizați un certificat autosemnat sau un certificat semnat de o autoritate de certificare. Când un server Edge Transport se abonează la o organizație Exchange, abonamentul Edge publică certificatul serverului Edge Transport în Active Directory, astfel încât serverele Hub Transport să îl poată valida. Microsoft Exchange EdgeSync adaugă un set de certificate de server Hub Transport la Active Directory Lightweight Directory Services (AD LDS) pentru ca serverul Edge Transport să le valideze.
• EdgeSync folosește o conexiune securizată la serverul LDAP Hub Transport la serverele Edge Transport abonate pe portul TCP 50636. AD LDS ascultă și pe portul TCP 50389. Acest port nu utilizează SSL. Puteți utiliza utilitare LDAP pentru a vă conecta la acest port și pentru a valida informațiile AD LDS.
• În mod implicit, traficul dintre serverele Edge Transport situate în două organizații diferite este criptat. Configurarea Exchange 2010 creează un certificat autosemnat și activează TLS în mod implicit. Acest lucru permite oricărui sistem de trimitere să cripteze sesiunea SMTP de intrare către Exchange. În mod implicit, Exchange 2010 încearcă, de asemenea, să folosească TLS pentru toate conexiunile la distanță.
• Metodele de autentificare pentru traficul dintre serverele de transport Hub și serverele de cutie poștală sunt diferite dacă serverul de transport Hub și rolurile de server de cutie poștală sunt instalate pe același computer. Transferurile locale de e-mail utilizează autentificarea Kerberos. Transmiterea de e-mail la distanță folosește autentificarea NTLM.
• Exchange 2010 acceptă, de asemenea, securitatea domeniului. Domain Security este un set de caracteristici din Exchange 2010 și Microsoft Outlook 2010 care oferă o alternativă ieftină la S/MIME și alte soluții pentru securizarea transmiterii mesajelor prin Internet. Securitatea domeniului oferă o modalitate de a controla căile de comunicare securizate între domeniile de pe Internet. Odată ce aceste căi securizate sunt configurate, mesajele de la un expeditor autentificat care au trecut cu succes prin ele apar utilizatorilor Outlook și Outlook Web Access ca mesaje „protejate de domeniu”. Pentru mai multe informații, consultați Înțelegerea securității domeniului.
• Mulți agenți pot rula atât pe serverele Hub Transport, cât și pe serverele Edge Transport. De obicei, agenții anti-spam folosesc informații de pe computerul local pe care rulează. Astfel, practic nu este necesară nicio interacțiune cu computerele de la distanță. O excepție de la aceasta este filtrarea destinatarilor. Filtrarea destinatarilor necesită un apel către AD LDS sau Active Directory. Vă recomandăm să efectuați filtrarea destinatarilor pe un server Edge Transport. În acest caz, directorul AD LDS se află pe același computer în care este instalat rolul de server Edge Transport, deci nu este necesară o conexiune la distanță. Dacă Recipient Filtering este instalată și configurată pe un server Hub Transport, trebuie să aveți acces la Active Directory.
• Agentul de analiză a protocolului este utilizat de caracteristica Sender Reputation din Exchange 2010. Acest agent se conectează, de asemenea, la diferite servere proxy externe pentru a determina căile de intrare ale mesajelor pentru conexiuni suspecte.
• Toate celelalte funcții anti-spam utilizează date care sunt colectate, stocate și disponibile numai pe computerul local. De obicei, date precum lista sigură îmbinată sau datele destinatarului de filtrare a destinatarilor sunt forțate în directorul AD LDS local prin utilizarea Microsoft Exchange EdgeSync.
• Agenții Information Rights Management (IRM) de pe serverele Hub Transport se conectează la serverele Active Directory Rights Management Services (AD RMS) din organizația dvs. Active Directory Rights Management Services (AD RMS) este un serviciu web care se recomandă a fi securizat cu SSL. Vă conectați la serverele AD RMS utilizând HTTPS și utilizați Kerberos sau NTLM pentru autentificare, în funcție de configurația serverului AD RMS.
• Regulile de înregistrare, regulile de transport și regulile de clasificare a mesajelor sunt stocate în Active Directory și sunt accesate de agentul de jurnalizare și agentul de reguli de transport pe serverele Hub Transport.

  Servere de cutie poștală

  Pe serverele de cutie poștală, utilizarea autentificării NTLM sau Kerberos depinde de contextul utilizatorului sau de procesul în care rulează consumatorul Exchange Business Logic Layer. În acest context, consumatorii sunt orice aplicații sau procese care utilizează Stratul de logică de afaceri Exchange. Drept urmare, în coloană Autentificare implicită Mese Căile de date pentru serverele de cutie poștală multe linii au o valoare NTLM / Kerberos.

  Stratul de logică de afaceri Exchange este utilizat pentru a accesa și interacționa cu magazinul Exchange. Stratul de logică de afaceri Exchange este, de asemenea, apelat din magazinul Exchange pentru a comunica cu aplicațiile și procesele externe.

  Dacă un consumator Exchange Business Logic Layer rulează în contextul sistemului local, Kerberos este întotdeauna metoda de autentificare pentru ca consumatorul să acceseze magazinul Exchange. Metoda de autentificare Kerberos este utilizată deoarece destinatarul trebuie să fie autentificat utilizând contul de computer Sistem local și este necesară încredere bidirecțională autentificată.

  Dacă destinatarul stratului de logică de afaceri Exchange nu rulează în contextul sistemului local, metoda de autentificare este NTLM. De exemplu, atunci când un administrator rulează un cmdlet Exchange Management Shell care utilizează Stratul de logică de afaceri Exchange, este utilizată autentificarea NTLM.

  Traficul RPC este întotdeauna criptat.

  Următorul tabel oferă informații despre porturi, autentificare și criptare a căii de date pentru serverele de cutie poștală.

  Căile de date pentru serverele de cutie poștală

  Calea datelor	Porturi necesare	Autentificare implicită	Metodă de autentificare acceptată	Suport pentru criptare	Criptarea implicită a datelor
  	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (autentificare la rețea RPC)			Da, cu criptare Kerberos
  Acces administrativ la distanță (registru la distanță)				Da, cu IPsec
  Acces administrativ de la distanță (SMB, fișiere)				Da, cu IPsec
  Serviciu web de disponibilitate (Acces client cutie poștală)				Da, folosind criptarea RPC
  Clustering				Da, folosind criptarea RPC
  Între serverele de acces client (Exchange ActiveSync)	80 / TCP, 443 / TCP (SSL)		Kerberos, certificat de autentificare	Da, folosind HTTPS	Da, folosind un certificat autosemnat
  Între servere de acces client (Acces Web Outlook)	80 / TCP, 443 / TCP (HTTPS)			Da, cu SSL
  Server de acces client la server de acces client (servicii web Exchange)				Da, cu SSL
  Server de acces client la server de acces client (POP3)				Da, cu SSL
  Server de acces client la server de acces client (IMAP4)				Da, cu SSL
  Office Communications Server la Client Access Server (când este activată integrarea Office Communications Server și Outlook Web App)	5075-5077 / TCP (IN), 5061 / TCP (OUT)	mTLS (obligatoriu)	mTLS (obligatoriu)	Da, cu SSL

  Note pentru serverele de acces client

  Servere de mesagerie unificate

  Gateway-urile IP și IP PBX-urile acceptă doar autentificarea prin certificat, care utilizează autentificarea TLS reciprocă pentru a cripta traficul SIP și autentificarea bazată pe adrese IP pentru conexiunile SIP sau TCP. Gateway-urile IP nu acceptă autentificarea NTLM sau Kerberos. Prin urmare, atunci când se utilizează autentificarea bazată pe IP, adresele IP ale conexiunilor sunt folosite ca mecanism de autentificare pentru conexiunile necriptate (TCP). Când este utilizată în Mesageria unificată, autentificarea bazată pe IP verifică dacă o anumită adresă IP are permisiunea de a se conecta. Adresa IP este configurată pe gateway-ul IP sau pe IP PBX.

  Gateway-urile IP și IP PBX-urile acceptă Mutual TLS pentru a cripta traficul SIP. După importarea și exportul cu succes a certificatelor de încredere necesare, gateway-ul IP sau IP PBX va solicita un certificat de la serverul de mesagerie unificată și apoi va solicita un certificat de la gateway-ul IP sau IP PBX. Schimbul de certificate de încredere între gateway-ul IP sau IP PBX și serverul de mesagerie unificată permite ambelor dispozitive să comunice în siguranță folosind Mutual TLS.

  Următorul tabel oferă informații despre porturi, autentificare și criptare pentru căile de date dintre serverele de mesagerie unificată și alte servere.

  Căile de date pentru serverele de mesagerie unificată

  Calea datelor	Porturi necesare	Autentificare implicită	Metodă de autentificare acceptată	Suport pentru criptare	Criptarea implicită a datelor
  Accesarea Active Directory	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (autentificare la rețea RPC)			Da, cu criptare Kerberos
  Telefonie de mesagerie unificată (IP PBX / VoIP Gateway)	5060 / TCP, 5065 / TCP, 5067 / TCP (nesecurizat), 5061 / TCP, 5066 / TCP, 5068 / TCP (securizat), port dinamic de la 16000-17000 / TCP (control), porturi UDP dinamice din gama 1024-65535 / UDP (RTP)	După adresa IP	După adresa IP, MTLS	Da, prin SIP/TLS, SRTP
  Serviciu web de mesagerie unificată	80 / TCP, 443 / TCP (SSL)	Autentificare Windows integrată (Negociare)		Da, cu SSL
  De la un server de mesagerie unificată la un server de acces client	5075, 5076, 5077 (TCP)	Autentificare Windows integrată (negociere)	De bază, Rezumat, NTLM, Negociere (Kerberos)	Da, cu SSL
  Server de mesagerie unificată către server de acces client (Redare pe telefon)	RPC dinamic			Da, folosind criptarea RPC
  De la un server de mesagerie unificată la un server de transport hub				Da, folosind TLS
  De la un server de mesagerie unificată la un server de cutie poștală				Da, folosind criptarea RPC

  Note pentru serverele de mesagerie unificată

  • Când creați un obiect gateway IP UM în Active Directory, trebuie să determinați adresa IP a gateway-ului IP fizic sau IP PBX. Când determinați adresa IP a unui obiect gateway IP UM, adresa IP este adăugată la lista de gateway-uri IP valide sau IP PBX-uri (numite și Participanți la sesiune SIP) cu care serverul UM are permisiunea de a comunica. După ce creați un gateway IP UM, îl puteți asocia cu planul de apelare UM. Maparea unui gateway IP UM la un plan de apelare permite serverelor UM care sunt mapate la un plan de apelare să utilizeze autentificarea bazată pe adrese IP pentru a comunica cu gateway-ul IP. Dacă un gateway IP UM nu a fost creat sau configurat pentru a utiliza adresa IP corectă, autentificarea va eșua și serverele UM nu vor accepta conexiuni de la adresa IP a acelui gateway IP. În plus, atunci când implementați Mutual TLS, un gateway IP sau IP PBX și servere de mesagerie unificată, gateway-ul IP UM trebuie configurat pentru a utiliza un nume de domeniu complet calificat (FQDN). După ce configurați un gateway IP UM cu un FQDN, trebuie să adăugați și o înregistrare gazdă pentru acel gateway în zona de căutare DNS directă.
  • În Exchange 2010, serverul de mesagerie unificată poate comunica prin portul 5060 / TCP (nesecurizat) sau prin portul 5061 / TCP (securizat) și poate fi configurat să utilizeze ambele porturi.

  Pentru mai multe informații, consultați Înțelegerea securității VoIP pentru mesageria unificată și Înțelegerea protocoalelor, porturile și serviciile de mesagerie unificată.

  Reguli Windows Firewall create de Exchange 2010 Setup

  Paravanul de protecție Windows cu securitate avansată este un paravan de protecție cu stare bazat pe computer care filtrează traficul de intrare și de ieșire pe baza regulilor paravanului de protecție. Configurarea Exchange 2010 creează reguli Windows Firewall pentru a deschide porturile necesare pentru comunicarea server-client în fiecare rol de server. Prin urmare, nu mai trebuie să utilizați Expertul de configurare a securității pentru a configura aceste setări. Pentru mai multe informații despre Windows Firewall cu securitate avansată, consultați Windows Firewall cu securitate avansată și IPsec.

  Următorul tabel listează regulile paravanului de protecție Windows generate de Exchange Setup, inclusiv porturile care sunt deschise în fiecare rol de server. Puteți vizualiza aceste reguli utilizând paravanul de protecție Windows cu programul de completare MMC de securitate avansată.

  Numele regulii	Roluri de server	Port	Program
  MSExchangeADTopology - RPC (TCP Inbound)		RPC dinamic	Bin \ MSExchangeADTopologyService.exe
  MSExchangeMonitoring - RPC (TCP Inbound)	Server de acces client, server de transport Hub, server de transport Edge, server de mesagerie unificată	RPC dinamic	Bin \ Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost - RPC (TCP Inbound)		RPC dinamic	Bin \ Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost - RPCEPMap (TCP Intrare)			Bin \ Microsoft.Exchange.Service.Host
  MSExchangeRPCEPMap (GFW) (TCP de intrare)
  MSExchangeRPC (GFW) (TCP Intrare)	Server de acces client, server de transport hub, server de cutie poștală, server de mesagerie unificată	RPC dinamic
  MSExchange - IMAP4 (GFW) (TCP Intrare)	Server de acces client
  MSExchangeIMAP4 (TCP de intrare)	Server de acces client		ClientAccess \ PopImap \ Microsoft.Exchange.Imap4Service.exe
  MSExchange - POP3 (FGW) (TCP Intrare)	Server de acces client
  MSExchange - POP3 (TCP Intrare)	Server de acces client		ClientAccess \ PopImap \ Microsoft.Exchange.Pop3Service.exe
  MSExchange - OWA (GFW) (TCP Intrare)	Server de acces client	5075, 5076, 5077 (TCP)
  MSExchangeOWAAppPool (TCP de intrare)	Server de acces client	5075, 5076, 5077 (TCP)	Inetsrv \ w3wp.exe
  MSExchangeAB RPC (TCP Inbound)	Server de acces client	RPC dinamic
  MSExchangeAB-RPCEPMap (TCP de intrare)	Server de acces client		Bin \ Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (TCP de intrare)	Server de acces client	6002, 6004 (TCP)	Bin \ Microsoft.Exchange.AddressBook.Service.exe
  RpcHttpLBS (TCP de intrare)	Server de acces client	RPC dinamic	System32 \ Svchost.exe
  MSExchangeRPC - RPC (TCP Intrare)		RPC dinamic
  MSExchangeRPC - PRCEPMap (TCP Intrare)	Server de acces client, server de cutie poștală		Bing \ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeRPC (TCP de intrare)	Server de acces client, server de cutie poștală		Bing \ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeMailboxReplication (GFW) (TCP Intrare)	Server de acces client
  MSExchangeMailboxReplication (TCP de intrare)	Server de acces client		Bin \ MSExchangeMailboxReplication.exe
  MSExchangeIS - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic
  MSExchangeIS RPCEPMap (TCP de intrare)	Server cutie poștală
  MSExchangeIS (GFW) (TCP Intrare)	Server cutie poștală	6001, 6002, 6003, 6004 (TCP)
  MSExchangeIS (TCP Intrare)	Server cutie poștală
  MSExchangeMailboxAssistants - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic
  MSExchangeMailboxAssistants - RPCEPMap (TCP Intrare)	Server cutie poștală		Bin \ MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission - RPC (TCP Intrare)	Server cutie poștală	RPC dinamic
  MSExchangeMailSubmission - RPCEPMap (TCP Intrare)	Server cutie poștală		Bin \ MSExchangeMailSubmission.exe
  MSExchangeMigration - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic	Bin \ MSExchangeMigration.exe
  MSExchangeMigration - RPCEPMap (TCP Inbound)	Server cutie poștală		Bin \ MSExchangeMigration.exe
  MSExchangerepl - Copiator de jurnal (TCP Intrare)	Server cutie poștală		Bin \ MSExchangeRepl.exe
  MSExchangerepl - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic	Bin \ MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (TCP Intrare)	Server cutie poștală		Bin \ MSExchangeRepl.exe
  MSExchangeSearch - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic	Bin \ Microsoft.Exchange.Search.ExSearch.exe
  MSExchangeThrottling - RPC (TCP Intrare)	Server cutie poștală	RPC dinamic	Bin \ MSExchangeThrottling.exe
  MSExchangeThrottling - RPCEPMap (TCP Intrare)	Server cutie poștală		Bin \ MSExchangeThrottling.exe
  MSFTED - RPC (TCP Inbound)	Server cutie poștală	RPC dinamic
  MSFTED - RPCEPMap (TCP Intrare)	Server cutie poștală
  MSExchangeEdgeSync - RPC (TCP Intrare)	Server de transport hub	RPC dinamic
  MSExchangeEdgeSync RPCEPMap (TCP de intrare)	Server de transport hub		Bin \ Microsoft.Exchange.EdgeSyncSvc.exe
  MSExchangeTransportWorker - RPC (TCP Inbound)	Server de transport hub	RPC dinamic	Bin \ edgetransport.exe
  MSExchangeTransportWorker - RPCEPMap (TCP Intrare)	Server de transport hub		Bin \ edgetransport.exe
  MSExchangeTransportWorker (GFW) (TCP Intrare)	Server de transport hub
  MSExchangeTransportWorker (TCP de intrare)	Server de transport hub		Bin \ edgetransport.exe
  MSExchangeTransportLogSearch - RPC (TCP Intrare)		RPC dinamic
  MSExchangeTransportLogSearch - RPCEPMap (TCP Intrare)	Hub Transport, Edge Transport, Server Mailbox		Bin \ MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (TCP Intrare)	Server de mesagerie unificată
  SESWorker (TCP Inbound)	Server de mesagerie unificată		UnifiedMessaging \ SESWorker.exe
  UMService (GFW) (TCP de intrare)	Server de mesagerie unificată
  UMService (TCP Inbound)	Server de mesagerie unificată		Bin \ UMService.exe
  UMWorkerProcess (GFW) (TCP de intrare)	Server de mesagerie unificată	5065, 5066, 5067, 5068
  UMWorkerProcess (TCP de intrare)	Server de mesagerie unificată	5065, 5066, 5067, 5068	Bin \ UMWorkerProcess.exe
  UMWorkerProcess - RPC (TCP Inbound)	Server de mesagerie unificată	RPC dinamic	Bin \ UMWorkerProcess.exe

  Note despre regulile Windows Firewall create de Exchange 2010 Setup

  • Pe serverele cu Internet Information Services instalate, Windows deschide porturile HTTP (port 80, TCP) și HTTPS (port 443, TCP). Configurarea Exchange 2010 nu deschide aceste porturi. Prin urmare, aceste porturi nu sunt listate în tabelul anterior.
  • În Windows Server 2008 și Windows Server 2008 R2, Windows Firewall cu securitate avansată vă permite să specificați procesul sau serviciul la care este deschis portul. Acest lucru este mai sigur deoarece portul poate fi utilizat numai de procesul sau serviciul specificat în regulă. Configurarea Exchange creează reguli de firewall cu numele de proces specificat. În unele cazuri, din motive de compatibilitate, se creează și o regulă suplimentară care nu se limitează la acest proces. Puteți dezactiva sau elimina regulile care nu sunt restricționate de proces și puteți salva regulile corespunzătoare cu restricții de proces, dacă mediul dvs. actual de implementare le acceptă. Regulile care nu se limitează la procese pot fi distinse prin cuvânt (GFW)în numele regulii.
  • Multe servicii Exchange folosesc apeluri de procedură la distanță (RPC) pentru a comunica. Procesele de server care utilizează RPC-uri se conectează la mapatorul de puncte terminale RPC pentru a prelua punctele finale dinamice și pentru a le înregistra în baza de date a mapatorului de puncte terminale. Clienții RPC interacționează cu mapatorul de puncte terminale RPC pentru a determina punctele finale utilizate de procesul serverului. În mod implicit, mapatorul RPC endpoint ascultă pe portul 135 (TCP). Când configurați Windows Firewall pentru un proces care utilizează RPC, Exchange 2010 Setup creează două reguli de firewall pentru acel proces. O regulă permite comunicarea cu mapatorul punctelor finale RPC, iar a doua permite comunicarea cu un punct final alocat dinamic. Pentru mai multe informații despre apelurile de procedură la distanță, consultați articolul. Pentru mai multe informații despre cum să creați reguli Windows Firewall pentru RPC dinamic, consultați articolul.

    Pentru mai multe informații, consultați articolul 179442 din baza de cunoștințe Microsoft

Exchange Server și firewall-uri

Firewall-uri pentru servere de mail (Exchange Server), porturi pentru servere de mail, servere de mail front-end si back-end, servere virtuale SMTP, POP3, IMAP4

Ca și în cazul oricărui computer conectat la Internet, computerul care găzduiește serverul de e-mail trebuie protejat cu un firewall. În același timp, opțiunile de instalare a unui server de e-mail în ceea ce privește configurarea rețelei pot fi foarte diferite:

· Cea mai ușoară opțiune este să instalați un server de e-mail pe un computer care este și un server proxy/firewall, apoi deschideți porturile necesare pe interfața orientată spre Internet. Acesta este de obicei cazul organizațiilor mici;

· O altă opțiune este să instalați un server de e-mail în rețeaua locală și să îl configurați să funcționeze printr-un server proxy. Pentru a face acest lucru, puteți lega un IP public la serverul de e-mail și îl puteți trece prin proxy sau puteți utiliza instrumente precum maparea portului pe serverul proxy. Multe servere proxy au vrăjitori speciali sau reguli predefinite pentru organizarea unei astfel de soluții (de exemplu, în ISA Server). Această opțiune este folosită în majoritatea organizațiilor.

· O altă posibilitate fundamentală este de a crea un DMZ și de a pune în el un front-end Exchange Server (această posibilitate a apărut încă din versiunea 2000) sau SMTP Relay bazat pe un alt Exchange Server sau, de exemplu, sendmail pe * nix. Utilizat de obicei în rețelele organizațiilor mari.

În orice caz, pentru serverul de mail este necesar să se asigure comunicarea cel puțin pe porturile TCP 25 (SMTP) și UDP 53 (DNS). Alte porturi care pot fi necesare de Exchange Server în funcție de configurația rețelei (toate sunt TCP):

80 HTTP - pentru acces la interfața Web (OWA)

· 88 Protocolul de autentificare Kerberos — dacă se utilizează autentificarea Kerberos (rar);

· 102 conector MTA .X .400 peste TCP/IP (dacă conectorul X .400 este utilizat pentru comunicarea între grupurile de rutare);

· 110 Post Office Protocol 3 (POP 3) - pentru acces client;

· 119 Network News Transfer Protocol (NNTP) - dacă sunt folosite grupuri de știri;

· 135 Comunicare client/server Administrare RPC Exchange - port RPC standard pentru administrarea de la distanță a Exchange folosind instrumente standard System Manager;

· 143 Internet Message Access Protocol (IMAP) - pentru accesul clientului;

· 389 LDAP - pentru a accesa serviciul director;

· 443 HTTP (Secure Sockets Layer (SSL)) (și mai jos) - aceleași protocoale securizate prin SSL.

563 NNTP (SSL)

636 LDAP (SSL)

993 IMAP4 (SSL)

995 POP3 (SSL)

· 3268 și 3269 - interogări către serverul de catalog global (căutați în Active Directory și verificați apartenența la grupuri universale).

Nu are sens să acoperiți interfața Exchange Server care se confruntă cu interiorul organizației cu un firewall - va fi folosit pentru a interacționa cu controlere de domeniu, utilități de administrare, sisteme de backup etc. Pentru o interfață deschisă la Internet, se recomandă să părăsiți porturile 53 (dacă Exchange va rezolva singur numele de gazdă, mai degrabă decât să redirecționeze cererile către serverul DNS local) și 25. De foarte multe ori, clienții trebuie să își acceseze cutiile poștale din exterior (din exterior). acasă, într-o călătorie de afaceri etc.). Cea mai bună soluție în această situație este să configurați OWA (interfața Web implicită pentru acces la Exchange Server, disponibilă la http: // servername / exchange) să funcționeze prin SSL și accesul deschis doar pe portul 443. Pe lângă rezolvarea problemelor cu securitatea autentificarea și criptarea mesajelor rezolvă automat problema cu SMTP Relay (mai multe despre asta mai târziu) și cu situația în care un utilizator descarcă accidental e-mailurile de la serviciu în folderele clientului de e-mail de pe computerul său de acasă și apoi la serviciu nu găsește aceste mesaje (nu pentru menționați că stocarea corespondenței de serviciu acasă este o încălcare a securității).

Nouă funcție introdusă în Exchange Server. începând cu versiunea 2000, posibilitatea de a utiliza mai multe servere virtuale SMTP și POP3 cu diferite setări de securitate. De exemplu, serverul SMTP care interacționează cu Internetul poate fi configurat cu securitate sporită și restricții stricte de livrare, iar serverul SMTP care este utilizat de utilizatorii din cadrul organizației poate fi configurat la setările cele mai performante și ușor de utilizat.

De asemenea, este necesar să menționăm o anumită confuzie în terminologie - de foarte multe ori sistemele de filtrare a mesajelor sunt numite firewall-uri pentru Exchange, care vor fi discutate mai jos.