Virtual Study

04 września 2014

Przekierowania na Kempie

Definiując publikację Exchange na load balancerach Kempa z szablonu, automatycznie tworzony jest wirtualny serwis przekierowania przekierowania ruchu portu http na https, tak że po wpisaniu nazwy hosta w przeglądarce zostajemy przekierowani do wirtualnego katalogu usługi OWA po protokole https (podobnie jak w IIS realizowane jest to poprzez obsługę kodu 302).

image

image

Jednakże, gdy chcemy wpisać krótką nazwę, a jest ona inna niż nazwa hosta, którą umieściliśmy w certyfikacie (przykładowo chcielibyśmy używać nazwy poczta, pełna nazwa serwisu OWA to poczta.pepug.org, a wewnętrzna domena Active Directory nazywa się pepug.local), to dostaniemy warning o niepoprawnym połączeniu – domyślna reguła doklei tylko /owa na końcu nazwy i zamieni http:// na https://, czyli po wpisaniu nazwy poczta, zostaniemy przekierowani na nazwę https://poczta/owa. Podobny problem będziemy mieli wpisując w przeglądarce np. adres IP wirtualnej usługi.

Co zatem robić? Najprościej jest zmienić przekierowanie na poziomie wirtualnej usługi, jednak metoda taka jest mało elastyczna – czasami na serwerach Exchange chcemy mieć dwie witryny różniące się obsługiwaną nazwą i w tym przypadku taka konfiguracja nie zadziała. Żeby ten problem rozwiązać w sposób elegancji pierwsze rozwiązanie, jakie sięnasuwa, to wykorzystanie reguł wybierających zawartość, podobnie jak to opisałem wcześniej przy okazji SSO i Sharepointa- http://pepugmaster.blogspot.com/2014/07/publikacja-sharepoint-2013-na-kempie-i.html. W tym celu tworzymy dwie reguły, które pozwolą wybrać nazwę hosta zgodną z docelową (w tym przykładzie poczta.pepug.org) lub inną wskazaną przez nas.

image

image

Teraz pozostaje nam zmodyfikować regułę przekierowania http. W tym celu musimy dodać dwa subinterface’y, na których ustawimy przekierowania.

image

image

Teraz tylko pozostaje nam w głónej definicji VIP-a włączyć Content Switching i podpiąć zdefiniowane wcześniej reguły.

image

image

Podobnie postępujemy dla innych URL-i.

image

Teraz jeszcze tylko wyczyszczenie ustawienia przekierowania na poziomie głównego VIP i gotowe. Niezależnie od tego, czy wpiszemy w przeglądarce nazwę poczta, poczta.pepug.org czy adres IP, zostaniemy przekierowani na url https://poczta.pepug.org/owa. Oczywiście musimy mieć w DNS dla domeny Active Directory dodany rekord host o nazwie poczta z tym samym adresem IP. Należy również pamiętać, że zadziała to tylko z poziomu sieci wewnętrznej.

26 sierpnia 2014

Poprawki do Exchange i Lynca

Zaledwie 10 dni temu zespół Lyncowy wydał najnowszą porcję poprawek dla serwera Lync 2013, a kilka dni później dla telefonów sprzętowych:

Product

Version

Download

Lync Phone Edition (for Aastra 6721ip and Aastra 6725ip)

4.0.7577.4451

2988177

Lync Phone Edition (for HP 4110 and HP 4120)

4.0.7577.4451

2988178

Lync Phone Edition (for Polycom CX500, Polycom CX600, and Polycom CX3000)

4.0.7577.4451

2988181

Lync Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540

4.0.7577.4451

2988182

Dzisiaj zespół Exchange wydał poprawki dla wszystkich wspieranych wersji Exchange:

15 lipca 2014

Współpraca telefonów Audiocodes serii 400 z Lync–“Better Together”

Coraz więcej producentów telefonów IP dla Lynca wprowadza możliwość współpracy telefonu ze stacjonarnym klientem – zarówno Lync 2010 jak i Lync 2013 i to nie tylko po kalblu USB, ale również bezpośrednio po sieci IP. W zeszłym roku takie funkcjonalności ogłosił zarówno Polycom jak i SNOM, o czym pisał na swoim blogu Matt Landis - http://windowspbx.blogspot.com/2013/07/how-will-lync-enhanced-better-together.html. Kilka miesięcy temu, na konferencji Lyncowej Audiocodes ogłosił uruchomienie wersji Beta swojej wersji integracji dla telefonów z serii 400HD - http://windowspbx.blogspot.com/2014/03/an-update-on-audiocodes-440hd-430hd.html?vsmaid=184. A dosłownie kilka dni temu pojawiła się finalna wersja firmware dla telefonów i aplikacji dla komputerów, przeznaczonych dla Lynca do współpracy z klientem stacjonarnym. Jak tego użyć?

Po pierwsze trzeba zaktualizować firmware w telefonie. Telefony audiocodes mają bardzo przyjemny i przyjazny interface webowy (podobny do tego na bramkach z linii Mediant), przez który można wejść i ręcznie zaktualizować firmware, jak widać na rysunku poniżej.

Ręczna aktualizacja firmware telefonu 420HD

Tutaj od razu uwaga – logowanie przez przeglądarkę działa domyślnie na zalogowanego na telefonie usera (czyli np. jak mój SAMAccountName jest konrad, to muszę się zalogować przez przeglądarkę jako użytkownik konrad, z hasłem domenowym). Żeby zalogować się przez przeglądarkę na konto administratora (domyślnie admin i hasło 1234) trzeba się wylogować z telefonu. Niezbyt oczywiste, prawda?

Po aktualizacji firmware do wersji 2.0.5, na wyświetlaczu telefonu pojawia się dodatkowa opcja – BToE (czyli Better Together over Ethernet).

Dodatkowa opcja BToE w menu

Po wybraniu tej opcji pojawi nam się kod niezbędny dla sparowania telefonu z aplikacją na komputerze:

Kod parowania telefonu z aplikacją na komputerze

Będzie to nam potrzebne za chwilę. Teraz instalujemy na komputerze aplikację, łączącą klienta Lyncowego z telefonem - AudioCodes Better2Gether 0.0.0.6.exe. Instalacja jest prosta – wystarczy kliknąć w plik i kilkakrotnie potwierdzić Next. Wersja beta nie chciała się instalować na Windows 8/8.1, wersja finalna na szczęście działa. Ważną kwestią, która potwierdza prawidłowe zainstalowanie aplikacji jest dodanie sterownika USB do urządzeń systemowych (rysunek poniżej).

Sterownik USB Audiocodes dodany

Oprócz tego pojawi nam się na taskbarze ikonka aplikacji.

image

Teraz pozostaje drobiazg – sparowanie aplikacji z telefonem. W tym celu należy wybrać z meny kontekstowego opcję Enter Pair Code… i wpisać kod, który odczytaliśmy z wyświetlacza telefonu.

image

W tym momencie (jeżeli wszystko poszło poprawnie) zobaczymy, że instaluje nam się sterownik audio, a ikonka aplikacji zmienia kolor, zmieni nam się również układ w menu kontekstowym:

image

W tym momencie również na liście urządzeń, dostępnych w kliencie Lync pojawia nam się dodatkowa pozycja

image

Teraz po podniesieniu słuchawki telefonu i wybraniu połączenia z klienta na komputerze, rozmowa zostanie uruchomiona z telefonu. Proste, prawda?

05 lipca 2014

Publikacja Sharepoint 2013 na Kempie i SSO

Konfigurując usługi Exchange i Lync czasem również mam okazję wykonać pewne akcje integracyjne dla Sharepointa. Publikacja Exchange i Lynca z wykorzystaniem zewnętrznych Load Balancerów jest dobrze opisana, zarówno przez producentów tych urządzeń jak i przez Microsoft, jednak w zakresie publikacji usług Sharepoint trudno znaleźć w internecie procedurę w tym zakresie. Zwłaszcza, że ze względu na kończące się wsparcie dla TMG, jeżeli firma chce opublikować swoją witrynę z dodatkowym zabezpieczeniem problem ten nabiera dodatkowego wymiaru. Niedługo Kemp udostępni niebawem dokumentację opisującą publikację usług Sharepointowych, jednak jak na razie tylko w zakresie pojedynczej witryny portalu firmowego.

Wielu administratorów wykorzystuje konfigurację Sharepointa, gdzie portal firmowy wykorzystuje krótką nazwę, np. http://intranet lub http://portal, a witryny użytkowników wykorzystują witrynę http://mysite. Jak w takim wypadku poprawnie opublikować Sharepointa dla naszych pracowników/współpracowników w internecie, tak żeby nie musieli przechodząc między tymi witrynami ponownie się uwierzytelniać?

Pierwszą kwestią jest oczywiście AAM (alternative access mapping). Chociaż można i bez tego skonfigurować publikację na Kempie, jednak dla porządku i spójności architektury dobrze jest zdefiniować publikację po https, z wykorzystaniem dostępnej z internetu nazwy hosta – np. https://intranet.pepug.org i https://mysite.pepug.org. Niestety Sharepoint zmusza nas do dodania certyfikatów dla tych witryn po stronie serwera IIS z poziomu konsoli IIS Managera oddzielnie, ale jak się o tym pamięta, to nie powinno być problemów.

Kolejnym krokiem jest dodanie na witrynie Sharepointowej możliwości uwierzytelnienia typu Basic.Zarówno dla witryny intranet jak i mysite. Jest ot bardzo proste, ale miejsce, gdzie to należy ustawić nie jest już takie oczywiste (przynajmniej dla mniej zaawansowanych). Należy zatem w centralnej konsoli administracyjnej Sharepointa wejść w zarządzanie aplikacjami (Central Administration-Application Management-Manage Web Application). Wybrać daną witrynę (na rysunku wybrana witryna intranet), a następnie kliknąć w przycisk Authentication Providers. Wybieramy z listy dostępnego providera (jeżeli nie konfigurowaliśmy Sharepointa w specyficzny sposób, powinien być tylko jeden – domyślny) – rysunek 2, a następnie zaznaczamy checkbox przy uwierzytelnieniu Basic (rysunek 3).

Wybór Authentication providerów dla aplikacji

Rysunek 1. Konfiguracja opcji uwierzytelniania dla aplikacji

Wybór providera

Rysunek 2. Wybór providera

Dodanie uwierzytelnienia typu basic do sposobów uwierzytelnienia

Rysunek 3. Włączenie uwierzytelniania typu Basic

Oczywiście po tym niezbędny będzie restart IIS-a, ale nie musimy za to ręcznie zmieniać ustawień w IIS Managerze.

Przejdźmy teraz do publikacji witryny (lub całej farmy, jeżeli mamy kilka FrontEndów Sharepointa).

Na Kempie tworzymy nową wirtualną usługę, do której dodajemy dwa subinterface’y powiązane z każdą z naszych witryn:

Standardowe opcje publikacji, zalecane dla Sharepointa przez Kempa

Rysunek 4. Standardowe opcje publikacji, zalecane dla Sharepointa przez Kempa

Na poziomie głównym serwisu dodajemy również certyfikat – bądź to zawierający obie nazwy publiczne, bądź to wildcardowy dla naszej domeny.

Subinterface’y dodane dla naszych witryn

Rysunek 5. Subinterface’y dodane dla naszych witryn

Teraz musimy utworzyć reguły,  które pozwolą wybrać z tej listy odpowiednią witrynę na podstawie nagłówka zapytania https, przekazanego przez klienta – jedną dla witryny intranet, jedną dla mysite:

Tworzenie reguły na podstawie nazwy witryny

Rysunek 6. Tworzenie reguły na podstawie nazwy witryny

Następnie we właściwościach zaawansowanych witryny włączamy content switching:

Włączenie content switchingu dla wirtualnej usługi

Rysunek 7. Włączenie content switchingu dla wirtualnej usługi

Teraz trzeba tylko przypisać odpowiednią regułę do obu witryn:

Dodanie reguły przełączania dla subinterface’u

Rysunek 8. Dodanie reguły przełączania dla subinterface’u

Dodanie reguły – wybór z listy reguł

Rysunek 9. Dodanie reguły – wybór z listy reguł

Po dodaniu reguł będzie o tym informacja pokazana we właściwościach subinterface’ów.

Lista subinterface’ów z informacją o przypisanych regułach wyboru treści

Rysunek 10. Lista subinterface’ów z informacją o przypisanych regułach wyboru treści

Ostatni punkt programu to skonfigurowanie ESP (Edge Security Pack) dla każdej z naszych witryn. W ramach konfiguracji ESP należy skonfigurować SSO, czyli w tym wypadku komunikację z kontrolerem/kontrolerami naszej domeny Active Directory.

Konfiguracja domeny dla SSO

Rysunek 11. Konfiguracja domeny dla SSO

Jeżeli na Kempie wcześniej było konfigurowane SSO dla Exchange, to nie musimy tego robić, wystarczy wybrać z listy już dostępnych domen.

Konfiguracja ESP dla subinterface’u

Rysunek 12. Konfiguracja ESP dla subinterface’u

W ten sposób publikujemy obie witryny. Wpisując w przeglądarce adres https://intranet.pepug.org pojawi nam się formularz logowania, po wpisaniu nazwy użytkownika domenowego i hasła zalogujemy się do portalu, po kliknięciu na odnośnik “O mnie” zostaniemy przekierowani do drugiej publikowanej witryny http://mysite.pepug.org, bez konieczności dodatkowego uwierzytelnienia. Jeżeli wpiszemy url naszej witryny OWA np. https://owa.pepug.org/owa, to również korzystając z SSO zostaniemy zalogowani do strony OWA naszego Exchange.

Certyfikat Wildcard dla usługi POP/IMAP w Exchange

Tym razem chciałem przestawić ciekawy artykuł, przygotowany przez Jacka Światowiaka – MVP w kategorii Directory Services. Nie prowadzi własnego bloga, więc w ten sposób chciał się podzielić własnymi doświadczeniami.

Jak przypisać certyfikat typu Wildcard do usług POP/IMAP w Exchange?

Mimo że natywnym kanałem komunikacyjnym dla klientów systemu Exchange 2013 jest MAPI, to cały czas wiele organizacji musi wykorzystywać jeszcze kanały POP3/IMAP4, chociażby ze względu na aplikacje LOB. Domyślnie protokoły POP3 i IMAP4 nie są włączone w żadnej wersji serwera Exchange. By wykorzystać POP3/IMAP4 należy w pierwszej kolejności zmienić tryb uruchomienia tych usług z ‘manual’ na ‘automatic’  i włączyć odpowiednie usługi. Nie będę omawiał przeznaczenia obu usług.

image

Rysunek 1. Usługi Exchange – obsługa POP – konfiguracja domyślna

image

Rysunek 2. Usługi Exchange – obsługa POP – konfiguracja zmodyfikowana

Zakładam, że w magazynie certyfikatów konta komputera znajdują się certyfikaty wymagane przez Exchange, jak również certyfikat wildcard, co widać z rysunku 3.

image

Rysunek 3. Magazyn certyfikatów konta komputera

Na początek parę informacji, właściwości oraz przeznaczenia znajdujących się w tym magazynie certyfikatów.

Domyślny certyfikat typu self-sign generowany w momencie instalacji serwera Exchange

Wygenerowany certyfikat typu SAN, który został przypisany do usług webowych (IIS)

image image

Certyfikat wykorzystywany wewnętrznie przez Exchange

Nazwy alternatywne dla certyfikatu powyżej.

image image

Rysunek 4. Właściwości certyfikatów na serwerze Exchange

Aby podejrzeć parametry skonfigurowanej usługi POP czy IMAP, przechodzimy na poziom konfiguracji serwerów, klikamy właściwości serwera poziom POP.

image image
image

Rysunek 5. Właściwości usługi POP w konsoli Exchange 2013

Najbardziej interesujące parametry dla administratora to metody uwierzytelniania:

image

Rysunek 6. Zmiana metody uwierzytelniania dla usługi POP

Domyślnie jest skonfigurowany mechanizm Secure TLS connection. Jednak wiele starszych klientów wymaga metody prostszej – Basic authentication (Plain text).

Aby podejrzeć, do jakich usług są przypisane poszczególne certyfikaty, należy sięgnąć w konsoli EAC na poziom Server – Certyfikaty. Jak widać z rysunku 7 certyfikat o nazwie WILDCARD nie jest powiązany z żadną usługą.

image

Rysunek 7. Informacje o przypisaniu certyfikatu o nazwie WILDCARD

image

Rysunek 8. Informacje o przypisaniu certyfikatu EX2k13

image

Rysunek 9. Informacje o przypisaniu certyfikatu Microsoft Exchange Server Auth Certificate

image

Rysunek 10. Informacje o przypisaniu certyfikatu Microsoft Exchange

Ostatni certyfikat, domyślnj nazwie WMSVC nie jest przypisany do żadnych usług pocztowych i przez Exchange nie jest wykorzystywany. Czasem na liście może również pojawić się certyfikat dla usług federacyjnych, ale to dotyczy tylko niektórych konfiguracji.

Jak widać z prezentowanych rysunków 8 i 19 do usługi pop są przywiązane aż dwa certyfikaty (sic!). Również dla usługi SMTP są przypisane dwa certyfikaty. Pozostaje odpowiedzieć na pytanie jak Exchange wybiera właściwy certyfikat, który ma być użyty z daną usługą.

Spróbujmy zatem przypisać certyfikat WILDCARD do usługi POP. Po kliknięciu na certyfikat, w jego właściwościach na zakładce Services, mamy możliwość wybrania z jakimi usługami ma on być powiązany.

image

image

Rysunek 11. Przywiązanie certyfikatu do usług

Niestety czeka na niespodzianka. Konsola nie pozwala na przypisanie certyfikatu typu wildcard do usługi POP/IMAP. Próba skorzystania z polecenia Set-PopSettings również zakończy się niepowodzeniem.

image

Rysunek 12. Komunikat błędu przy powiązaniu certyfikatu typu wildcard

Jak podejrzymy konfigurację poleceniem Get-PopSettings (rysunek 13), wartość pola X509CertificateName będzie dość dziwna. Nie ma w magazynie certyfikatu o takiej nazwie. Tu jest właśnie rozwiązanie naszego zagadnienia. Serwer Exchange stara się z listy certyfikatów dostępnych w magazynie wybrać najbardziej pasujący do nazwy serwera (SERWER nosi krótką nazwę EX@K13-1, nazwa ta jest zawarta w certyfikacie typu SAN, który sobie wygenerowałem korzystając z wewnętrznej jednostki certyfikującej – sam certyfikat prezentowany jest na rysunku 4 i 8.

image

Rysunek 13. Konfiguracja POP

Załóżmy teraz ze usługa POP wystawiona jest na zewnątrz pod jakąkolwiek nazwą – byle by była rozwiązywana na prawidłowy adres IP, np. mail2.testowa.pl – tej nazwy nie ma w naszym certyfikacie typu SAN przypisanym do usługi POP – zatem klienci POP3 zestawiając połączenie po SSL będą dostawać poniższe okno informujące o niezgodności nazw.

image

Rysunek 14. Komunikat niezgodności nazwy w certyfikacie

Przechwycona komunikacja jeszcze na fazie uzgadniania sesji SSL. Jak widać nie zgadza się common-name.

image

Rysunek 15. Przechwycony ruch negocjacji sesji SSL dla POP

Aby podstawić certyfikat wildcard należy skorzystać z polecenia Set-PopSettings.

image

Rysunek 15. Zmiana mapowania nazwy certyfikatu dla usługi POP

Jako nazwę certyfikat należy podać dowolną nazwę z danej domeny – tak, która nie pasuje do żadnej z nazw zawartych w certyfikacie typu SAN. Który również mógłby być przez exchange podstawiony.

Teraz Exchange próbując dopasować nazwę, do której zestawimy połączenie SSL wybierze certyfikat wildcard, ponieważ on pokrywa wszystkie nazwy dla danej domeny.

image

Rysunek 16. Uaktualniona konfiguracja usługi POP

image

Rysunek 17. Dopasowany certyfikat wildcard do sesji SSL

Teraz już klienci POP po SSL nie będą generować komunikatu błędu, a tym samym certyfikatem SSL (typu Wildcard) , będzie można obsłużyć usługi IIS, SMTP, POP3 oraz IMAP4.