TLS – zalecenia dla Exchange

UPDATE – ciekawy i bardzo obszerny wpis na temat wpisów w rejestrach i możliwości włączania/wyłączania poszczególnych algorytmów kryptograficznych można znaleźć tutaj - http://blogs.technet.com/b/askds/archive/2015/12/08/speaking-in-ciphers-and-other-enigmatic-tongues-update.aspx.

Rozmawiając o wdrożeniach Exchange, często pojawia się temat bezpieczeństwa dostępu i optymalnego zabezpieczenia dostępu klienckiego. Chociaż nie ma informacji o włamaniach z wykorzystaniem OWA, to poprawne skonfigurowanie protokołów dostępowych. Jest to istotne zwłaszcza w kontekście skompromitowania protokołu SSL 3.0 i pojawiających się w związku z tym zagrożeń. Bardzo dobry artykuł na ten temat pojawił się na blogu zespołu produktowego Exchange w lipcu tego roku - http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx. Opisano w nim ogólne zasady, których należy się trzymać, a nawet kroki konfiguracyjne, które należy wykonać. W skrócie chodzi o:

• wyłączenie protokołu SSL 3.0 na serwerach i klientach i oparcie komunikacji o protokół TLS, jeżeli się da to 1.2, ewentualnie 1.1 lub 1.0.

• jeżeli jest to możliwe to zablokowanie szyfrowania RC4 jako metody niewiarygodnej,

• wyłączenie hashowania MD5/MD2

• wykorzystanie RSA-2048 przy generowaniu nowych kluczy certyfikatów,

• przejście na podpis SHA 256-bit lub wyższy, jeżeli to możliwe

Oczywiście instalowanie na bieżąco poprawek zabezpieczeń na serwerach Exchange jest również warunkiem niezbędnym.

Pozwalam sobie umieścić rysunek z domyślnymi ustawieniami SSL w kolejnych wersjach Windows Server:

Zawsze jednak dobrze jest dodatkowo zabezpieczyć system Exchange poprzez reverse proxy, w przypadku środowiska składającego się z kilku serwerów, dobrze jest to realizować na urządzeniach, które jednocześnie realizują load balancing, jak np.LoadMaster firmy Kemp. Tutaj przy publikacji usług Exchange wszystko staje się proste (zwłaszcza gdy wybierzemy szablon z reenkrypcją) – w bardzo prosty sposób mamy możliwość wyłączenia SSL 3.0 oraz RC4. Domyślnie po włączeniu szablonu Exchange 2013z reenkrypcją i przypisaniu certyfikatu mamy ustawienia jak na rysunku poniżej:

Dodatkowo z listy ustawień algorytmów szyfrujących możemy wybrać szablon bez RC4 lub zdefiniować własny, również dodatkowo okrojony:

Takie ustawienia dają nam zgodność z zaleceniami bezpieczeństwa. przynajmniej dla protokołów SSL/TLS. Jakie to proste.

Pakiet poprawek CU1 do Skype for Business

Oficjalnie pokazał się pakiet aktualizacji CU1 dla Skype for Business 2015. Trochę długo po premierze (wcześniej była wydana jedna mała poprawka funkcjonalna i poprawka zabezpieczeń), ale dobrze, że w końcu jest. Informacje o zmianach można znaleźć w artykule https://support.microsoft.com/en-us/kb/3061064. W odróżnieniu od Lync 2013 nie ma potrzeby aktualizować baz danych.

Problem z certyfikatami Starfield w Firefoxie

Właśnie zauważyłem, że nowa wersja Firefoxa blokuje certyfikaty Starfield, nawet jeżeli doda się wyjątek bezpieczeństwa:

Dopiero zaimportowanie certyfikatu urzędu pośredniczącego rozwiązuje ten problem. W tym celu wchodzimy w Firefoxie w Opcje -> Zaawansowane -> Certyfikaty -> Wyświetl certyfikaty -> Organy certyfikacji –> Importuj.

Następnie wskazujemy certyfikat “Stafield Secure Certification Authority” i potwierdzamy import, zanaczając dodatkowo opcję “Zaufaj temu certyfikatowi przy identyfikacji witryn internetowych”.

Kolejne połączenie przebiegnie pomyślnie. Co ciekawe problem pojawił się ostatnio i występuje tylko w Firefoxie. Ciekaw jestem czy podobne problemy pojawiły się dla jakiś innych dostawców certyfikatów?

Automatyzacja konfiguracji wirtualnych katalogów Exchange

Zaczął się sezon na migracje, także do Exchange 2016. Jednym z elementów konfiguracji jest odpowiednie przygotowanie wirtualnych katalogów dla roli CAS. Exchange od dawien dawna dla  każdej z usług webowych udostępnia nazwę zewnętrzną (exernal URL) i wewnętrzną (internal URL). Od Exchange 2013 ten dualizm dotyczy również usługi Outlook Anywhere – wcześniej można było zdefiniować tylko publiczną nazwę hosta dla tej usługi. Żeby było ciekawiej, nie wszystkie nazwy można skonfigurować przez Exchange Admin Center, co utrudnia proces. Dla jednego serwera musimy zdefiniować więc następujące URL-e:

• dwa dla usługi ActiveSync,
• dwa dla OWA,
• dwa dla ECP,
• dwa dla OAB,
• dwa dla EWS,
• dwa dla Outlook Anywhere,
• dwa dla Poweshell,
• dwa dla MAPI (jeżeli włączamy ten typ dostępu),
• jeden dla Autodiscover (jako atrybut serwera CAS)

Daje nam to 17 URL-i na jeden serwer (!), czyli całkiem sporo. A jeżeli w organizacji mamy kilka takich serwerów do skonfigurowania daje nam to odpowiednio więcej wpisów. Jakiś rok temu, żeby zaoszczędzić sobie pracy przygotowałem (a w zasadzie uaktualniłem) skrypt, który automatyzuje ten proces, jak widać na poniższym rysunku. W ostatni weekend znalazłem chwilę, żeby to trochę poprawić i dopasować do Exchange 2016. Zapraszam do korzystania i przekazywania sugestii na temat możliwych ulepszeń.

Aktualizacja dla Lync Room Systems

10 listopada Microsoft wydał istotną aktualizację dla urządzeń Lync Room Systems wszystkich producentów - Crestron, Polycom oraz SMART-a, który dostosowuje szatę graficzną do nowej wersji systemu – Skype for Business. Urządzenie SMART w DemoRoom Promise również się zaktualizowało i teraz przedstawia się jako Skype for Business:

Więcej informacji na blogu - https://blogs.office.com/2015/11/06/a-new-skype-for-business-look-for-lync-room-systems/

Integracja Exchange 2016 ze Skype for Business 2015

Jakiś czas temu pisałem na blogu o integracji Exchange 2013 z Lyncem 2013. Kwestie dotyczące wykorzystania unified store nie uległy zmianie, więc po weryfikacji URL usług webowych puli serwerów SfB oraz usługi autodiscover dla poczty, po stronie serwerów Exchange musimy wykonać skrypt Configure-EnterprisePartnerApplication.ps1. Podobnie jak w wersji 2013 znajduje się on w katalogu z innymi skryptami Exchange. Składnia parametrów również nie uległa zmianie – niezależnie od tego, czy będziemy łączyć się z Lync 2013 czy z Skype for Business 2015, to jako parametr połączenia podajemy “Lync”:

Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl “https://<EnterprisePoolFQDN>/metadata/json/1″ -ApplicationType Lync

Kolejnym etapem jest konfiguracja po stronie SfB – utworzenie aplikacji partnerskiej:

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.<domain>/autodiscover/metadata/json/1

Jeżeli nie zrobiliśmy literówki, to test integracji powinien zakończyć się sukcesem:

Test-CsExStorageConnectivity -SipUri “user@domain” –Verbose

Integracja w zakresie OWA w Exchange 2013 jest dosyć uciążliwa. Również już o tym pisałem wcześniej, więc tylko przypomnę, że kluczowym elementem konfiguracji była edycja pliku web.config, co niestety wymagało ponownej edycji pliku po każdej instalacji pakietu Cummulative Updates. W Exchange 2016 na szczęście mechanizm ten został poprawiony. Został do tego wykorzystany mechanizm nadpisywania ustawień domyślnych. W przypadku organizacji z jednym serwerem Exchange sytuacja jest prosta – sprawdzamy jaki certyfikat jest przypisany do usługi OWA

New-SettingOverride -Name <Nazwa> -Component OwaServer -Section IMSettings -Parameters @(“IMServerName=<Pool FQDN>”,”IMCertificateThumbprint=<Odcisk Certyfikatu>”) -Reason “OWA IM config”

Nazwa ustawienia może być dowolna. Następnie musimy odświeżyć ustawienia serwera:

Get-ExchangeDiagnosticInfo -Server $ENV:COMPUTERNAME -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Na koniec pozostaje restart usługi webowej (nie musimy restartować całęgo IIS-a, wystarczy restart puli OWA:

Restart-WebAppPool MSExchangeOWAApppool

Jeżeli jednak mamy kilka serwerów Exchange, a na dodatek wykorzystują one indywidualnie wygenerowane certyfikaty (z innymi odciskami), to wtedy musimy zdefiniować oddzielne override’y dla każdego z serwerów, jak to opisuje Jens Trier Rasmussen na swoim blogu. Jeżeli mamy serwery o nazwach EX1 oraz EX2, to komendy będą wyglądały następująco:

New-SettingOverride SetIMServerEx1 -Server Ex1 -Component OwaServer -Section IMSettings -Parameters @('IMServerName=<Pool FQDN>') -Reason "OWA IM config"
New-SettingOverride SetIMCertificateThumbprint1 -Server Ex1 -Component OwaServer -Section IMSettings -Parameters @('IMCertificateThumbprint=<Odcisk Certyfikatu 1>') -Reason "OWA IM Config"
New-SettingOverride SetIMServerEx2 -Server Ex2 -Component OwaServer -Section IMSettings -Parameters @('IMServerName=<Pool FQDN>') -Reason "OWA IM config"
New-SettingOverride SetIMCertificateThumbprint2 -Server Ex2 -Component OwaServer -Section IMSettings -Parameters @('IMCertificateThumbprint=<Odcisk Certyfikatu 2>') -Reason "OWA IM config"

Następnie na każdym z serwerów EX1,EX2 należy wymusić odświeżenie konfiguracji (tak jak dla pojedynczego serwera komendą Get-ExchangeDiagnosticInfo), a następnie zrestartować pulę OWA.

Kolejnym krokiem jest wskazanie, że integracja ma być włączona (co ciekawe, tutaj używamy parametru jeszcze z czasów Office Communications Servera). Najwygodniej wykonać komendę korzystając z potokowania dla wszystkich witryn razem:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled $True -InstantMessagingType OCS

Dodatkowo powinniśmy taką samą operację przeprowadzić na poziomie polis OWA. Jeżeli nie tworzyliśmy własnych polis, wystarczy zmodyfikować polisę domyślną:

Set-OwaMailboxPolicy -Identity “Default” -InstantMessagingEnabled $True -InstantMessagingType “OCS”

W interface OWA powinna pojawić się teraz informacja o statusie SfB:

Jeżeli nadal nie możemy się zalogować do “usługi wiadomości błyskawicznych”, dodatkowo powinniśmy w konfiguracji Skype for Business wskazać serwery Exchange jako zaufaną pulę serwerów (wykorzystując nazwę dostępową dla usługi OWA):

New-CsTrustedApplicationPool -Identity <owa FQDN> -Registrar <Pool FQDN> -Site <Site name> -RequiresReplication $False

Następnie w nowoutworzonej puli dodajemy aplikację, wskazując dodatkowo port komunikacyjny. Oczywiście po stronie Exchange należy zweryfikować, czy port nie jest zablokowany przez ustawienia firewalla:

New-CsTrustedApplication -ApplicationId OutlookWebApp -TrustedApplicationPoolFqdn <owa FQDN> -Port 6100

Pozostaje odświeżenie ustawień:

Enable-CsTopology

Osobnym zagadnieniem jest integracja w zakresie Unified Messaging. Tutaj nie ma zmian w stosunku do Exchange 2013, więc może do tego zagadnienia  wrócę innym razem.