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.

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).

Po wybraniu tej opcji pojawi nam się kod niezbędny dla sparowania 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).

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

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.

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:

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

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

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).

Rysunek 1. Konfiguracja opcji uwierzytelniania dla aplikacji

Rysunek 2. Wybór providera

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:

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.

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:

Rysunek 6. Tworzenie reguły na podstawie nazwy witryny

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

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

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

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

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.

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.

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.

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?

UPDATE:
W Exchange 2016 nastąpiła istotna zmiana - jest bezpieczniej, ale trudniej. Nawet wpisując (jak widać dalej w artykule) nazwę usługi, należy wpisać nazwę, która jest zapisana w certyfikacie. Na szczęście zdecydowana większość certyfikatów wildcardowych oprócz nazwy *.testowa.pl ma również nazwę samej domeny - testowa.pl. Czyli konfigurując usługę musimy wpisać
set-popsettings -X509certificatename testowa.pl

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.

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

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.

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)
Certyfikat wykorzystywany wewnętrznie przez Exchange	Nazwy alternatywne dla certyfikatu powyżej.

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.

Rysunek 5. Właściwości usługi POP w konsoli Exchange 2013
Najbardziej interesujące parametry dla administratora to metody uwierzytelniania:

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ą.

Rysunek 7. Informacje o przypisaniu certyfikatu o nazwie WILDCARD

Rysunek 8. Informacje o przypisaniu certyfikatu EX2k13

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

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.

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.

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.

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.

Rysunek 14. Komunikat niezgodności nazwy w certyfikacie
Przechwycona komunikacja jeszcze na fazie uzgadniania sesji SSL. Jak widać nie zgadza się common-name.

Rysunek 15. Przechwycony ruch negocjacji sesji SSL dla POP
Aby podstawić certyfikat wildcard należy skorzystać z polecenia Set-PopSettings.

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.

Rysunek 16. Uaktualniona konfiguracja usługi POP

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.