30 grudnia 2017

Podsumowanie roku 2017

Widzę na FB i Linkedin, że kolejni znajomi MVP robią podsumowanie roku 2017, więc ja też spróbuję napisać kilka przemyśleń.
Patrząc na życie prywatne, to mijający rok był udany. Fajne ferie zimowe, dwie wspaniałe wycieczki objazdowe po miejscach, o których zawsze marzyłem, próby (czasami udane) na oderwanie się od szarej rzeczywistości, 33 przeczytane książki nie związane z IT (chociaż biografia Steve Jobsa jednak trochę była). Sporo fajnych i ciekawych filmów i niestety za mało sportu.
Pod względem zawodowym było ciekawie ale i męcząco. Dużo wdrożeń i migracji. Trochę szkoleń i warsztatów. No i oczywiście nauka - Office 365 rozwija się bardzo dynamicznie, Azure również, więc trzeba się nieźle nagimnastykować, żeby nadążać za zmianami. Gwałtowny rozwój Teams, oraz wielu innych komponentów budzi szacunek, ale zmusza do ciągłej nauki. Pod tym względem rok 2018 będzie na pewno ciekawy - nie dość, że Teams mają przejąć wszystkie funkcje Skype for Business w chmurze, to na dodatek wychodzą nowe wersje serwerów Office. Więc będzie zabawa z betami Exchange 2019, Skype for Business 2019, a nawet Sharepoint 2019. Udało mi się również trochę zaktualizować wiedzę na temat technologii webowych - nie tylko HTML 5, ale również JavaScript i TypeScript oraz Node.JS i Angulara. Nie to, żebym chciał wrócić do programowania, ale raz na jakiś czas jakąś stronę webową zrobię i warto być w tym obszarze również na bieżąco.
Pod względem społecznościowym rok nie był najlepszy. Duża ilość pracy ograniczyła ilość konferencji, w których brałem udział i chociaż udało mi się przygotować Office Servers Summit 2017 (w tym roku z dwoma ścieżkami), to kilka innych pomysłów (np. Office 365 Bootcamp) nie wypaliło - po prostu nie starczyło czasu.
W przyszłym roku na pewno będę chciał zorganizować kolejny Office Servers Summit, być może już ze wstępnymi informacjami o nowych wersjach serwerowych, no i uzupełnić kilka certyfikacji, na które ciągle nie znalazłem czasu, a którymi się zajmuję. Mam jeszcze kilka pomysłów, ale podzielę się nimi publicznie, kiedy będą bardziej sprecyzowane.
Szczęśliwego Nowego Roku!

19 grudnia 2017

Grudniowa paczka poprawek do Exchange

Aktualizacja: W CU8 dla Exchange 2016 wykryto problem z prawidłową obsługą statusu Free/Busy, dla użytkowników hybrydowych ze skrzynką w chmurze bez archiwum. Jeżeli ktoś nie chce czekać na CU9 (koniec Q1 2019), powinien zainstalować poprawkę KB4058297.
Microsoft w końcu opublikował grudniowe aktualizacje dla serwerów Exchange. W ostatnich dniach pojawiły się szczegółowe informacje o nowej funkcjonalności, wprowadzanej w CU8 dla Exchange 2016 i CU19 dla Exchange 2013, czyli HMA (Hybrid Modern Authentication), wielu administratorów na pewno czekało również na informację o wsparciu dla .NetFramework 4.7, którego nie zdołano zweryfikować dla poprzedniej tury aktualizacji. Tym razem było wystarczająco dużo czasu i wsparcie zostało zapewnione, od razu dla wersji 4.7.1. Warto przy okazji zauważyć, że zespół produktowy poinformował, że wersja 4.7.1 będzie od poprawek z czerwca 2018 roku niezbędnym komponentem do instalacji Exchange lub jego aktualizacji.
Dodatkowo wydano również paczkę poprawek RU19 dla Exchange 2010, szczególnie istotnej dla firm, w których działają jednocześnie Exchange 2010 i 2016, ponieważ poprawia koegzystencję i rozwiązuje problemy z EWS proxy opisane w KB4054456. Jednocześnie Microsoft przypomina, że Exchange 2010 jest już poza regularnym okresem wsparcia (tzw. Extended Support) i nie należy się spodziewać regularnych poprawek w przyszłości.
Warto również zauważyć, że jeżeli ktoś ma zainstalowane poprawki z września 2017, to nie zachodzi potrzeba rozszerzania schematu AD dla najnowszych poprawek.
Poniżej artykuły KB z opisem aktualizacji oraz bezpośrednie linki do ich pobrania:


17 grudnia 2017

bramki antyspamowe i LDAPS

Niedawno miałem ciekawy przypadek przy konfiguracji bramki Symantec Messaging Gateway. Dla lepszej ochrony systemu pocztowego (jak dla mnie oczywiście Exchange), bramki te, podobnie jak wiele innych tego typu rozwiązań, pobierają z katalogu LDAP listę adresową organizacji. W ten sposób mogą weryfikować listę odbiorców dla poczty przychodzącej i listę nadawców dla poczty wychodzącej. W ten sposób również użytkownicy Exchange mogą łączyć się do swojej kwarantanny, znajdującej się na bramce. Konfiguracja integracji bramki antyspamowej z Active Directory jest stosunkowo prosta i polega na wskazaniu serwera, DN konta używanego do czytania danych (w przypadku AD może być również UPN tego konta), no i oczywiście hasła tego konta. Dodatkowym atrybutem połączenia jest port TCP (domyślnie 389). Kolejnym krokiem jest test połączenia.
Błąd przy zestawianiu połączenia z AD





















Przy próbie połączenia kreator pokazywał mi błąd, świadczący o nieprawidłowym koncie. Jednak próba połączenia z AD z komputera domenowego działała poprawnie. Po weryfikacji haseł, ustawień firewalla i innych kwestii sieciowych, sprawdziłem polisy GPO. Okazało się, że zarówno na kontrolerach domenowych, jak i na stacjach roboczych jest ustawione wymuszenie podpisywania pakietów LDAP (LDAP signing). Niestety funkcja ta powoduje problemy z uwierzytelnieniem z urządzeń takich jak SMG czy SonicWall.
Alternatywą było ustawienie połączenia na LDAPS. Przełączyłem port na 636 (domyślny port połączenia LDAPS) i tym razem dostałem komunikat, że nie mogę nawiązać połączenia z serwerem. O co chodzi? Człowiek przyzwyczaił się, że w środowisku domenowym wdrażany jest do wewnętrznych celów organizacji urząd certyfikacyjny (CA), a że całkiem sporo firm instaluje CA na kontrolerze domeny, a w takim wypadku dla kontrolerów domyślnie instalowane są certyfikaty, właśnie służące do szyfrowania komunikacji LDAP (czyli właśnie LDAPS). Jeżeli jednak w AD nie ma zainstalowanego urzędu certyfikacji, to takich certyfikatów niestety nie ma domyślnie zainstalowanych, więc LDAPS nie działa. Jak to zmienić? Bardzo prosto. Można oczywiście wdrożyć urząd certyfikacyjny na jednym z serwerów Windows, jednak nie zawsze jest to możliwe. Tak naprawdę, do uruchomienia LDAPS na kontrolerach domeny możemy użyć dowolnego urzędu CA, do którego mamy dostęp, żeby wygenerować potrzebne nam certyfikaty. Dobra instrukcja, jak to zrobić znajduje się na stronach wikipedii Technet. Możemy jednak postąpić jeszcze prościej - użyć certyfikatów self-signed. Tak naprawdę do uruchomienia LDAPS certyfikaty muszą spełniać 3 warunki:
  1. Certyfikat musi obsługiwać funkcję Server Authentication. Czyli innymi słowy musi zawierać Server Authentication OID: 1.3.6.1.5.5.7.3.1
  2. Atrybut Subject Name lub pierwsza nazwa w atrybucie Subject Alternative Name (SAN) musi  być zgodna z nazwą Fully Qualified Domain Name (FQDN) serwera - np. SubjectCN=server1.contoso.com
  3. W lokalnym magazynie konta komputera musi znajdować się klucz prywatny certyfikatu.
Czyli możemy z linii komend wygenerować certyfikat komendą:
certreq -New -Machine policy.inf
Wcześniej oczywiście musimy sobie przygotować plik policy.inf zawierający niezbędne informacje.
Kilka przykładów prostego i bardziej rozbudowanego pliku znalazłem na blogu Oskara Virota.
Jeżeli jednak kontrolery domeny są w wersji Windows 2012 lub nowszej możemy użyć cmdleta powershell New-SelfSignedCertificate
Tworząc certyfikat nawet przy minimalnej ilości atrybutów uzyskamy odpowiedni wynik, chociaż certyfikat będzie miał standardową długość życia certyfikatu (jeden rok):
New-SelfSignedCertificate -DnsName "server1.contoso.com" -CertStoreLocation "cert:\LocalMachine\My"
Teraz musimy wyeksportować certyfikat (najlepiej w formacie Base64) i zaimportować go ponownie, tym razem wybierając magazyn Zaufanych Głównych Urzędów Certyfikacji, na wszystkich kontrolerach domeny, z którymi chcemy, żeby komunikacja LDAPS działała (oczywiście na nich również powinniśmy wygenerować i wyeksportować kolejne certyfikaty), oraz na bramce SMG.
Po restarcie kontrolera domeny połączenie LDAPS powinno uruchomić się bez problemów.

Paczka aktualizacji CU6 dla Skype for Business

Kilka dni temu Microsoft wydał paczkę aktualizacji CU6 dla Skype for Business. Paczka wprowadza Location-Based Routing dla urządzeń mobilnych poprawia obsługę spotkań na kliencie dla Mac'a. No i oczywiście usuwa jeszcze kilka drobnych problemów, co opisuje odpowiedni artykuł KB. Oczywiście najlepiej przeczytać go w całości, stosując poprawnie procedurę instalacji.
Microsoft niestety znowu trochę namieszał i wystawił poprawki na Windows Update, a przecież do ich instalacji należy wyłączyć usługi Skype for Business. Problemy z tym związane opisuje Tobie Fysh. Mam nadzieję, że zespół Windows Update szybko skoryguje swój błąd i "schowa" paczkę poprawek.

Problem bezpieczeństwa w Azure AD Connect

Kilka dni temu Microsoft poinformował o zagrożeniu związanym z uprawnieniami do konta serwisowego tworzonego w trakcie instalacji Azure AD Connect. Najnowsza wersja AAD Connect build 1.1.654.0 wprowadza dodatkowe zabezpieczenia konta, dlatego też warto przeprowadzić aktualizację. W przeciwnym wypadku możemy użyć modułu Powershell - AdSyncConfig.psm1 do zabezpieczenia konta - szczegóły dokładniej opisałem na blogu IT, jaki od pewnego czasu tworzą moi współpracownicy. Zapraszam do lektury.