Skip to Content

IT nieuczesane.
category

Category: office365

zdrada z SSO do chmury

Simple-Cloud-Iconscenariusz: aplikacje office365 + ADFS. wdrożona integracja.

realizacja SSO: da się skonfigurować całe rozwiązanie tak, żeby z dowolnej przeglądarki mieć logowanie SSO – automatyczne przekazanie tokena, bez konieczności podawania hasła. wymaga to trochę gimnastyki, ale da się zmusić zarówno Edge, Chrome oraz FF. innych nie testowałem, ale nie widzę powodów, dla których by nie miało działać.

linki może kiedyś w innym wpisie a tymczasem coś, o czym rzadziej się mówi – czyli zdrady z tym związane.

  1. SSO – czyżby? nie tak do końca. ze względu na przekierowania i obsługę domeny, trzeba wpisać przynajmniej nazwę użytkownika. owszem – jeśli z rozwiązania się korzysta, to nazwa jest zapamiętana i wystarczy kliknąć. jeśli użytkownik posiada konto w o365 o takiej samej nazwie jak liveID to dochodzi ekran wyboru work account\live id.
    tylko IE da się zmusić do tego, żeby w pełni automatycznie przekazywał token logowania – choć nie jestem pewien czy nie ma tu też jakiegoś scenariusza z wyjątkiem.
  2. kiedy skonfigurowany jest pełny automat, to dla osób posiadających kilka kont – np. konto administracyjne, jest pewna zdrada: choćby na ekranie logowania w ADFS po stronie chmury wpisać konto administracyjne, po przekierowaniu na lokalnego ADFS pobrany już zostanie token z lokalnej sesji i zostaniemy zalogowani na konto użytkownika, w którego kontekście właśnie pracujemy. w praktyce oznacza to, że dla osób z dostępem administracyjnym, są dwie metody:
    1. maszyna wirtualna poza domeną/inny login
    2. konfiguracja SSO tylko dla wybranych przeglądarek tak, żeby mieć jakiś wybór do logowania innym kontem

niby oczywiste ale … spodziewałem się że wystarczy pornomode. ale również w trybie private token jest automatycznie pobierany i przekazywany. ot taka ciekawostka.

eN.

modern authentication – uwierzytelnienie do chmury

adalchmura zmienia wszystko. kto tego nie odczuł, to chyba przez ostatni rok był na wakacjach na Marsie. od długiego czasu Microsoft przepisuje wszystkie usługi na WS*, podstawą integracji Azure z onpremem jest ADFS, musi przyjść kolej i na protokoły uwierzytelnienia. stare, ‚LANowskie’, mają swoje wady przy wykorzystaniu w takiej integracji. odpowiedzią jest coś, co nazywa się ‚modern authentication’.

do czego służy? krótko – do pobrania tokenu z Azure AD, którym aplikacje będą mogły się posługiwać w celu uwierzytelnienia. efekt końcowy – natywne wsparcie dla MFA (MultiFactor Authentication) przez aplikacje oraz realizacja pełnego, przeźroczystego SSO dla aplikacji Azure.

nowość!(?)

modern authentication jest obecnie w fazie public preview – a więc w zasadzie go jeszcze nie ma. największy buzz zaczął się w listopadzie 2o15, kiedy pojawiała się nowa wersja biblioteki… ale co ciekawe, nowością nie jest. jeden z lepszych wpisów, wyjaśniających działanie biblioteki można znaleźć tutaj – datowane na sierpień 2o12… biblioteka, która odpowiedzialna jest za realizację logowania przeszła nazewniczne metamorfozy – AAL (Windows Azure Authentication Library), WAAL, a obecnie ADAL (Microsoft Azure Active Directory Authentication Library).

lista obecnie wspieranych cech i zakresu gotowości ADAL jest w poście z listopada, który wspominałem oraz na technecie. na razie więcej informacji developerskich – dość normalne dla produktu w tej fazie.

w praktyce

w praktyce potrafi skorzystać już z tego office2o16 (outlook, skype) oraz office2o13. przy czym w o16 ten typ uwierzytelnienia jest włączony standardowo, w o13 wymagane są poprawki (standardowe, więc jeśli ktoś dba o aktualizacje, to tą funkcjonalność ma) oraz włączenie funkcji w rejestrze.

to jednak nie wystarczy. podstawową zmianą jest włącznie obsługi modern authentication dla office365 – a konkretnie dla Exchange OL:

set-organizationconfig -oauth2clientprofileEnabled $true

po włączeniu, outlook i skype urzywają już MA zamiast basic authentication, co w praktyce przekłada się na niby błahą, ale istotną zmianę – nie ma już ramki z pytaniem o użytkownika i hasło, gdzie jedynym sposobem automatyzacji jest zaznaczenie opcji ‚save credentials’ i przechowywanie ich w credential managerze. teraz zmiany hasła są również przeźroczyste dla użytkownika końcowego.

eN.

mobilna poczta korporacyjna

OWAcoraz więcej projektów związane jest z przeniesieniem usług do chmury. jedną z najpopularniejszych usług – Exchange online. taką pocztę trzeba jakoś odbierać… w przypadq standardowych skrzynek nie ma problemu – niemal każdy klient, nawet wbudowany w OSa (nawet srajfon), poradzi sobie z połączeniem ActiveSync i obsługą poczty.

trochę gorzej jest w momencie, kiedy korzysta się np. ze skrzynek współdzielonych (shared mailbox) – nie są wspierane przez protokół ActiveSync i należy skorzystać z klienta OWA. i tu zaczynają się kolejne ciekawostki…

  • klient OWA jest obecnie na iOS oraz w wersji beta na Android. zadziwiający fakt, że aplikacje eMeSowe są szybciej przez nich robione i poprawiane na wersje konqrencyjne jest zauważany i mocno krytykowany na forach WinBeta.
  • na Android są aż 3 apki do odbioru poczty by MS: MS Outlook, OWA (pre-release) i Outlook.com.
    • MSOutlook ma zupełnie nowy look (; nie korzystałem dużo ale na pewno jest nowoczesny, zgodnie z obecnie obowiązującymi trendami [które są dla mnie katorgą… ehh.. jak mi się nie podobają te nowe interfejsy…]. ale oczywiście działa via ActiveSync więc shared mailboxów nie obsługuje.
    • Outlook.com jest do office365 – prywatnego
    • OWA – dla o365 korporacyjnego. niestety przy uwierzytelnieniu sfederowanym z domeną nie udało mi się połączyć więc nie miałem okazji przetestować. nie wiem czy w innych scenariuszach w ogóle działa – zrzucam to na karb wersji beta.

rzuca się niemniej w oczy kilka problemów. po pierwsze podkreślany fakt opóźnień aplikacji dla bądź-co-bądź natywnej platformy jaką jest Windows Phone. po drugie – sama ilość aplikacji. czy to są jakieś wyścigi między teamami? czemu nie ma jednej, która obsługuje różne protokoły? już rozróżnienie pomiędzy o365 prywatnym i firmowym jest nieco dziwne. i finalnie – pomimo ilości aplikacji, nadal nie da się w pełni korzystać z poczty [firmowej].

nie sądzę, żeby takie zaburzenia dysocjacyjne pozytywnie wpływały na odbiór przez end-userów. odnoszę wrażenie braq spójności wizji rozwoju, i problemów z jasnym przekazaniem kompetencji pojedynczej komórce – jakby kilka działów miało własną wizję i wydają zbliżone produkty, o zbliżonej funkcjonalności.

PS. taka ciekawostka: jest na droida apka do zarządzania o365 – Office 365 Admin.

eN.

odzyskiwanie maili w o365

bardzo fajny link do opracowania dotyczącego odzyskiwania maili w office365 – zagregowane wiadomości co, jak, dlaczego i z czego to wynika. fajna lektura nie tylko z instrukcją, ale dobrym wyjaśnieniem całego mechanizmu:

czemu jest ‚1/3’ w nazwie… nie wiem. nie znalazłem kolejnych części a w tej wydaje się być wszystko co potrzeba. informacja, która straciła na aktualności [to art z 2o12] to dostępność aplikacji do backupu o365 – ponieważ tych już się trochę pojawiło. i jeszcze wyciągnięty z tegoż artu link z apką, która wchodzi na stałe do mojego menu:

eN.

%d bloggers like this: