IPS w Kemp Load Master

Niedawno miałem przyjemność prowadzić webinarium na temat użycia urządzeń Kemp LoadMaster do ochrony do dostępu do poczty w zastępstwie Forefront TMG 2010. Jako uzupełnienie prezentacji chciałem napisać kilka słów o prostej ale potrzebnej funkcjonalności, jaką jest wykrywanie ataków (IPS). Po zmianach w licencjonowaniu, jakie zaszły w kwietniu zeszłego roku, zarówno funkcje bezpiecznej publikacji (Edge Security Pack - ECP) jak i IPS są dostępne w subskrypcji Enterprise. O ile jednak funkcjonalność ECP jest często opisywana na różnych blogach i prezentacjach to IPS jest przeważnie tylko wspominany hasłowo - jest i koniec. Ale czy to faktycznie takie proste? Jeżeli na naszym LoadMasterze, który publikuje witryny w Internecie zajrzymy do logu systemowego, to możemy zauważyć np. zapisy dotyczące atak XSS, jak widać na poniższym rysunku.

Oznacza to, że IPS działa i reaguje na ataki poprawnie. Ale jak go skonfigurować i czy jest to w ogóle możliwe?
Jak najbardziej jest, chociaż w ograniczonym zakresie. Możemy ręcznie zmieniać sposób reagowania - począwszy od samego logowania ataków, aż do odrzucania wszystkich zagrożeń. Wszystkie cztery tryby pracy są nieco dokładniej opisane w dokumentacji, jednak same nazwy jak dla mnie są wystarczająco intuicyjne.

Ponadto możemy ręcznie aktualizować reguły, używane do wykrywania ataków, pobierając nowe wersje pakietu z regułami wykrywania ze strony SNORT. Load Master obsługuje paczki reguł w wersji zgodnej ze specyfikacją SNORT 2.9. Są one dostępne w pakiecie community-rules.tar.gz na stronie SNORT. Możemy pakiet pobrać i załadować (nie wymaga restartu i automatycznie jest replikowana między urządzeniami w trybie HA). Lepiej jednak wyedytować wcześniej listę reguł i aktywować wybrane z nich, zgodnie z potrzebami organizacji. W tym celu należy z pobranego archiwum community-rules.tar.gz otworzyć odpowiedni plik. W archiwum znajdują się pliki:

• community.rules
• AUTHORS
• LICENSE
• sid-msg.map
• VRT-License.txt

W pliku comunity.rules znajdują się reguły, jak pokazuje kolejny rysunek.

Reguły blokujemy umieszczając znak # na początku wiersza, aktywujemy kasując znak #. Po modyfikacji listy reguł zapisujemy zmodyfikowany plik w archiwum i pobieramy do Load Mastera.

Urządzenie jest gotowe do ochrony zgodnie ze zmodyfikowaną przez nas listą reguł.

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.

Kemp Load Master za darmo?

Od kiedy Microsoft wycofał się ze sprzedaży Forefront TMG i UAG, zainteresowałem się rozwiązaniami alternatywnymi, głównie Load Balancerami Kemp Technologies, które potrafią publikować serwery Exchange, Lync i innych usług. O ich funkcjonalności pisałem wielokrotnie na blogu, wdrażając je również w wielu firmach. Od kilku dni Kemp dodatkowo wprowadził nową możliwość dla klientów, którzy potrzebują przez dłuższy czas sprawdzić funkcjonalność Load Balancerów lub w małej firmie użyć ich produkcyjnie – bezpłatną wersję bez ograniczeń czasowych. Jeżeli wydajność będzie niewystarczająca można bardzo prosto zaktualizować licencję do wersji komercyjnej. Poniżej porównanie funkcjonalne:

Feature	Free LoadMaster	Commercial LoadMaster
Deployment on all supported hypervisors(VMware, Hyper-V, KVM, Xen, Oracle VirtualBox)	Yes	Yes
Balancer Throughput License (L7)	Up to 20Mbps	Up to 10Gbps
TLS (SSL) TPS License (2K Keys)	Up to 50	Up to 12,000
Layer 4 concurrent connections	Limited only by throughput license and available memory	Up to 3,000,000
Max Servers / Virtual Clusters	1000/256	1000/1000
TMG Replacement	Yes	Yes
GSLB Multi-Site Load Balancing	Yes	Yes
Support	Community	Up to 24 x 7 available
Layer 4/7 Load Balancing	Yes	Yes
Web Application Firewall Pack (AFP)	Yes	Yes – option to include commercial ruleset
Content Switching	Yes	Yes
Caching, Compression Engine	Yes	Yes
IPS (SNORT-Rules compatible)	Yes	Yes
L7 Cookie Persistence (Active/Passive)	Yes	Yes
Optimized templates for all major application workloads	Yes	Yes
Active/Hot-standby Redundant Operation	No	Yes
Edge Security Pack(TMG Replacement)- Pre-Authentication- Single Sign On- Persistent Logging	Yes	Yes
IPSec Tunnels	Yes	Yes
Licensing Mechanism	Online (Call home every 30 days to refresh)	Online and Offline

Wersja bezpłatna co 30 dni automatycznie aktualizuje licencję. Wystarczy tylko pobrać obraz maszyny wirtualnej, założyć sobie konto na stronie Kempa (KempID) i aktywować licencję online.

Konferencja Exchange/Lync/System Center

Już za tydzień APN Promise organizuje konferencję w Warszawie, która podobnie jak zeszłoroczny PreMTS koncentruje się na zagadnieniach z rodziny Unified Communication i System Center, ze szczególnym uwzględnieniem chmury publicznej (Office365 i Azure) oraz modelu hybrydowego.

Ja będę opowiadać o integracji funkcji głosowych dla Lync Online, Load Balancerach Kemp w Azure oraz narzędziach migracyjnych do Exchange. Serdecznie zapraszam 6 listopada do Millenium Plaza przy placu Zawiszy w Warszawie.

Nowy kwadrat magiczny Gartnera w kategorii ADC

Gartner opublikował magiczny kwadrat dla kategorii Application Delivery Controllers. Jak można się było spodziewać, leaderami są nadal F5 i Citrix, a Kemp Technologies powoli przesuwa się w górę kwadratu. Co ciekawe zniknął z niego Fortinet, za to pojawił się lokalny producent z Południowej Korei – Piolink.

Kemp jest chwalony za szeroki wybór modeli, jako jedyny z graczy oferuje opcję Bare Metal z wykorzystaniem serwerów najważniejszych producentów, dobrze oceniony jest również ze względu na przyjazne ceny. Minusami wg. Gartnera jest brak firewalla aplikacyjnego (który pojawi się już za chwilę), oraz niewielka wielkość firmy, co stanowi potencjalne zagrożenie.

Przekierowania na Kempie

Definiując publikację Exchange na load balancerach Kempa z szablonu, automatycznie tworzony jest wirtualny serwis 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).

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.

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


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


Podobnie postępujemy dla innych URL-i.

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.

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.

Agregacja interface’ów na Load Masterze i vlany

Jedną z ciekawszych opcji konfiguracyjnych, jakie można skonfigurować na Load Balancerach firmy Kemp jest tzw. bonding, czyli agregacja portów. Load Mastery, znajdujące się obecnie w sprzedaży mają od 4 do 8 portów o przepustowości 1GB, więc z pozoru może się wydawać, że jest wartość wystarczająca do normalnej pracy. Jednak agregacja portów zapewnia nam nie tylko zwiększenie przepustowości, ale i dodatkowy poziom zabezpieczeń w przypadku problemów sieciowych (uszkodzenie portu w przełączniku sieciowym, a nawet całego przełącznika).

Jak to skonfigurować poprawnie? Jest to opisane w dokumentacji https://support.kemptechnologies.com/hc/en-us/articles/202009643-LoadMaster-Bonding-and-Virtual-LAN-VLAN-, ale nie wszystkie punkty są wystarczająco jasne, dlatego chciałem to opisać po swojemu.

Wchodzimy we właściwości interface’u, który ma być pierwszy w danym bondzie (uwaga – interface’y eth0 i eth1 nie mogą być częścią tego samego bondu). Jeżeli chcemy zestawić bond na interface’ach eth1 i eth2 to zaczynamy od interface’u eth1. Klikamy w przycisk “Interface bonding” (jak widać na poniższym rysunku).

Pojawia się ekran konfiguracji bondingu, na którym klikamy w przycisk “Create a bonded interface 1”.

Po chwili przetwarzania naszego żądania wracamy do głównego menu. Zamiast interface’u eth1 na liście interface’ów powinien pojawić się interface bnd1, z adresem IP, który mieliśmy przypisany wcześniej do interface’u eth1.

Po kliknięciu w przycisk “Bonded Devices” dodajemy drugi interface (oczywiście może być ich więcej), klikając w przycisk “Add link”. Dodatkowo możemy zmienić tryb agregacji – albo “Active-Backup”, czyli jeden interface aktywny, drugi w trybie czuwania, albo bardziej uniwersalny “802.3ad”, który zapewnia nam agregację pasma sieciowego i wysoką dostępność portów. Oczywiście musimy po stronie urządzeń sieciowych skonfigurować analogicznie agregację portów 802.3ad, częściej znaną jako LACP (Link Aggregation Control Protocol).

Po poprawnym dodaniu portu, na liście interface’ów zobaczymy *, a we właściwościach zbondowanego interface’u w nawiasie pojawi się informacja o dodatkowym interface fizycznym, jak widać na poniższym rysunku.

Niezależnie od agregacji portów, możemy potrzebować ze względów bezpieczeństwa opublikować różne usługi w różnych podsieciach. W tym celu na Load Masterze należy włączyć tagowanie i przypisać dodatkowe interface’y powiązane z konkretnymi vlanami. Konfiguruje się je bardzo prosto, wystarczy we właściwościach interface’u wybrać opcję “VLAN Configuration”, a następnie na ekranie konfiguracji vlanu dodać odpowiedni nr vlanu, jak na poniższym rysunku.

Pojawi nam się na liście interface’ów dodatkowy interface, powiązany z danym vlanem, na którym należy ustawić odpowiedni adres IP, z puli adresowej danego vlanu. Jak widać na poniższym rysunku, interface “vlan 20” został utworzony na zagregowanym interface bnd1, który był utworzony wcześniej.

W przypadku wykorzystania vlanów na wszystkich interface’ach (np. na 4 fizycznych interface’ach konfigurujemy dwa bondy, na których z kolei definiujemy vlany) urządzenia, musimy w opcjach sieciowych Load Mastera wybrać opcję korzystania z alternatywnych bram, jak pokazuje poniższy rysunek.

Na interface’ach bondowanych czyścimy ustawienia IP, a na interface vlanu, przez który chcemy ustawić domyślny routing, zaznaczamy pole “Use for Default Gateway”. W tym momencie można będzie na interface ustawić adres IP odpowiedniego routera.

Kemp Load Master – niestandardowy ekran logowania

Aktualizacja:

Zauważyłem, że Kemp nieco zaktualizował szablon oraz dokumentację do niego. Zaktaulizowałem linki w artykule.

Od kilku wersji w firmware load balancerów Kempa z opcją ESP (Edge Security Pack) jest dostępna opcja dodawania niestandardowego zestawu graficznego dla logowania typu formularzowego (Form Based Authentication). Niestety nie była ona opisana, co utrudniało wykorzystanie w praktyce takiej opcji. Niedawno jednak pojawił się opis konfiguracji - https://support.kemptechnologies.com/hc/en-us/articles/203126599-Custom-Authentication-Form i przykładowa paczka z zawartością strony webowej formularza - https://kemptechnologies.com/files/assets/tools/SSOImageSet.zip.

W ramach przetestowania możliwości pobrałem paczkę i po rozpakowaniu okazało się, że zawiera folder z dwoma plikami html, plikiem stylów, elementami graficznymi i krótkim javascriptem. Lista plików zawarta jest w pliku manifestu.

Zmieniłem nazwę rozpakowanego folderu na IMAGESETNAME_ENG, a następnie skopiowałem cały folder pod inną nazwą (IMAGESETNAME_PL). Następnie w ramach testu przetłumaczyłem napisy, znajdujące się w treści pliku lm_initial.html, zarówno te występujące w oknie formularza, jak i komunikaty błędów, pojawiających się np. po niepoprawnym wpisaniu nazwy użytkownika). Oba foldery ponownie spakowałem 7zipem do formatu tar, i tak utworzoną paczkę mogłem zaimportować na Load Balancer, jak widać na poniższym rysunku.

Ważne jest, żeby do pliku tar przenieść nie pojedyncze pliku, czy folder, ale drzewo folderów począwszy od poziomu imagesets:
imagesets//
                //
Jak widać na kolejnym obrazku, oba foldery, spakowane do paczki pojawiły się jako osobne zestawy graficzne, o nazwach identycznych jak nazwy folderów.

Teraz tylko wystarczy w ustawieniach wirtualnego serwisu, dla którego mamy włączony ESP z typem uwierzytelnienia FBA wybrać jeden z zaimportowanych zestawów i gotowe.

Przy próbie logowania do OWA pojawi się nam zaimportowany przed chwilą zestaw graficzny.

Oczywiście można dodać logo swojej firmy, oraz zmienić kolorystykę i inne elementy graficzne, ale to wymaga trochę więcej pracy i zmysłu estetycznego.
Uwaga dla osób, które nie czytają dokumentacji, a chciały przeczytać ten artykuł do końca. Nazwa pliku z logo musi być wyszczególniona w pliku MANIFEST (widocznym na pierwszym obrazku), który zawiera listę wszystkich plików w ramach pakietu. Umieszczając odnośnik do niej w pliku lm_initial.html użyjmy taga .

Kemp Load Master dla Azure – nowa odsłona

Kiedy na konferencji preMTS prezentowałem publikację farmy serwerów Exchange działającej w Azure przez bezpłatny load balancer Kemp LoadMaster for Azure byłem zadowolony. Wszystko działało dobrze. Instrukcja wdrożenia jest prosta i przejrzysta, (są nawet filmiki video dla opornych). Jednakże czas, potrzebny do pobrania obrazu dysku vhd z LoadMasterem, a następnie załadowania go do Azura był bardzo długi.Jednakże, kiedy ostatnio chciałem zaktualizować firmware, dowiedziałem się, że dużo szybciej można przeprowadzić wdrożenie korzystając z biblioteki obrazów VMDepot, gdzie Bhagrav Shukla wrzucił obraz maszyny z aktualną wersją firmware. Ścieżka ta jak na razie nie jest opisana w dokumentacji Kempa, więc parę słów warto jej poświęcić.

Po zalogowaniu się do panelu administracyjnego swojej subskrypcji Azure w lewym pasku wybieramy pozycję “Virtual Machines”, a następnie w prawym oknie przechodzimy do zakładki “Images”. W tym momencie na środku okna, na dolnym pasku widzimy pozycję “Browse VM Depot” (jak na poniższym rysunku).

Po kliknięciu pojawia nam się przeglądarka wszystkich obrazów dysków, które zostały zaimportowane do VM Depotu.

Możemy kliknąć More, żeby przejść do VM Depotu i przeczytać dodatkowe informacje (kolejny rysunek), lub kliknąć strzałeczkę w prawym dolnym rogu, żeby przejść do okna zatwierdzenia wyboru.

Teraz tylko musimy wybrać region, gdzie mamy utworzone swoje konto składowania danych i zatwierdzić wybór klikając na “ptaszku” w prawym, dolnym rogu.

Kopiowanie obrazu trwa tylko 1 minutę (w odróżnieniu od kilkugodzinnego uploadu do chmury ze swojego komputera).

Teraz tylko wystarczy zarejestrować obraz maszyny. Na dolnym pasku pojawił się przycisk “Register”. Po kliknięciu możemy zmienić nazwę obrazu i url do VHD.

Ostatnim krokiem jest dodanie maszyny wirtualnej z zaimportowanego do Azure’a obrazu. Ale to robimy już standardowo, jak przy każdym innym obrazie.