Skip to Content

IT nieuczesane.
category

Category: Cloud

zarządzanie użytkownikami w hybrydzie

ponieważ to pytanie wraca do mnie niemal przy każdym projekcie i ponieważ obserwuję problem w zrozumieniu tych mechanizmów, zamieszczam krótkie podsumowanie najważniejszych informacji, które powinny pomóc w przygotowaniu doqmentacji ‚zarządzania użytkownikiem’ oraz administracji w środowisq hybrydowym.

‚Hybryda’

wedle moich obserwacji najważniejsze, a zarazem wymykające się intuicji jest to, że ‚hybryda’ tak na prawdę w większości wdrożeń powinna być nazywa ‚hybrydy’ – w liczbie mnogiej. w standardowym scenariuszu mamy bowiem:

  • hybryda tożsamości – połączenie pomiędzy AD i AzureAD. obiekty wraz z atrybutami synchronizowane są z onprem do Chmury, zapewniając (przy odpowiedniej konfiguracji) pojedynczą tożsamość i SSO (lub same-password w mniej wykwintnej implementacji)
  • hybryda Exchange – połączenie pomiędzy Ex a EXO. to co zaburza intuicję jest fakt, że wiele atrybutów Exchange jest przechowywanych w AD i synchronizowanych w ten sam sposób. jednak włączenie/wyłączenie hybrydy Exchange to w dużej mierze właśnie zdefiniowane czy ten zestaw atrybutów ma być synchronizowany czy też nie.
  • hybryda SfB – czyli połączenie pomiędzy onpremowym Lync/SfB a SOL/Teams. i tutaj podobnie jak w przypadq Exchange – mylącym jest fakt, że w takim środowisq informacje na temat konta SfB są zapisywane w AD i tak synchronizowane.

każdą z nich można mieć lub nie mieć … no ok, hybryda tożsamości musi być w każdym scenariuszu – ale Ex czy SfB to już kwestia wymagań klienta.

teoretycznie ‚hybryda’ powinna dawać jedno, centralne miejsce zarządzania i unifikację… de facto sprawa jest bardziej zagmatwana, ale poniżej przedstawione zasady powinny pomóc

Zarządzanie użytkownikami

zarządzanie użytkownikami w środowisq tożsamości hybrydowej odbywa się w zasadzie w pełni z onprem. w tym przypadq jest zatem najmniej zmian w kwestii procedur zarządzania.

wyjątkiem są:

  • zarządzanie licencjami, ale wtedy na pomoc przychodzi Group-Based Licensing .
  • wymuszenie zmiany hasła
  • do różnic można dorzucić jeszcze rozwiązywanie problemów i audyt – oczywiście zdarzenia logowania i te ‚ruchome elementy’ dzieją się w ramach AAD więc tutaj też trzeba sięgnąć do chmury…. a w zasadzie do obu środowisk na raz (a w ogóle to najlepiej jakiś SIEM zintegrowany).

należy dodać do tego pewne bardziej skomplikowane sytuacje, ponieważ wybór strony gdzie należy wykonać akcję może się różnić zależnie od metody uwierzytelnienia (PH, PTA, ADFS) lub wdrożenia SSPR – ale to są wszystko kwestie z zakresu obsługi hasła czy blokady konta.

Zarządzanie Exchange

ten element jest najbardziej kłopotliwy i hybryda Ex generalnie ma swoje specyficzne ograniczenia… największą pomocą jest tutaj traktowanie oddzielnie skrzynki i użytkownika. w ogólności są dwie perspektywy: administracja serwisem i użytkownikiem. pierwsze jest proste do wyjaśnienia:

  • Ex i EXO są rozdzielne – polityki bezpieczeństwa, mail flow, ustawienia globalne – robi się oddzielnie po obu stronach i nie są to elementy podlegające synchronizacji.
  • sprawa jest dość skomplikowana w przypadq polityki maili (recipient policies) bo … przenikają się częściowo. nie mogę teraz znaleźć linka.. ale w uproszczeniu najlepiej też zarządzać z onprem – ponieważ tam jest konto użytkownika i synchronizowany atrybut ‚proxyAddresses’

przy zarządzaniu pojedynczym użytkownikiem:

  • operacje związane z kontem użytkownika wykonuje się z onprem (aliasy mailowe, zmiany nazw/opisów/informacji)
  • operacje związane ze skrzynką – po tej stronie gdzie jest skrzynka [bo może być przecież albo tu albo tam] (limity skrzynki, statystyki, uprawnienia). w skrócie to, co robi ‚set-mailbox*‚ wykonuje się tam, gdzie ten mailbox leży.

jest kilka ‚dzwinostek’ typu uprawnienie ‚send as’ które wynika z faktu, że jest de facto zapisywane w AD i niesynchronizowane. zarządzanie, czy wspomniane przetwarzanie polis recipient policies, które w specyficznych przypadkach może wydawać się niespójne… są też różnice zależnie czy która wersja jest w OnPrem (zwłaszcza, jeśli to Ex 2o1o).

napisanie spójnych procedur zarządzania dla Exchange Hybrid jest wyzwaniem.

Zarządzanie SfB

do czasu Teamsów sprawę dało się jeszcze ogarnąć. szczęśliwie dla SfB w zasadzie nie ma specjalnie zarządzania

  • konto w hybrydzie trzeba włączyć/wyłączyć, co robi się oczywiście po stronie onprem,
  • wszelkie zarządzanie danymi o userze to de facto zapis do AD – więc też onprem

są oczywiście elementy integracji VoIP, polisy czy inne elementy usługi – i to jest rozdzielnie dla każdej strony.

  • przypisanie polis – to tam, gdzie jest konto SfB, oddzielne są polisy więc zależnie od strony hostującej, tam się te polisy definiuje i przypisuje.

hybryda SfB jest imho najtrudniejsza do zestawienia ale najmniej potem przy niej administracji i ‚ruchomych elementów’ a najtrudniejsze części to równocześnie te najrzadziej wykorzystywane czyli część integracji z VoIP, cloud PBX itp.

procedury administracyjne nie wymagają zatem specjalnych zmian.

na zakończenie

o ile hybryda tożsamości to ‚must have’ dla każdego środowiska opartego o AD, o tyle przejście do cloud-only i rezygnacja z hybrydy jest posunięciem często możliwym a w takim przypadq – sugerowanym. środowiska hybrydowe tylko pozornie są ‚zunifikowane’ – po obu stronach barykady (firewalla) są produkty w innych wersjach i choć mają symulować ‚jedną organizację’ to jest to proteza, która wprowadza sporo niejasności i komplikacji w konfiguracji i zarządzaniu. konieczność wykorzystania PowerShell do części zadań powoduje, że niektóre zadania normalnie wykonywane przez helpdesk, nagle są eskalowane do 2giej linii. przykładem mogą być procedury provisioningu użytkownika w hybrydzie Ex1o z EXO – gdzie nie ma wsparcia zakładania konta ze skrzynką online z interfejsu, a skrzynkę współdzieloną da się tylko zrobić hackując z poziomu atrybutów AD bo nawet PowerShell w tej wersji nie ma opcji ‚-Shared’ która pojawiła się w Ex13.

przejście dla tych usług na cloud-only znacznie ułatwia administrację.

eN.

Spotkania w czasie kryzysu

jest dziwnie. osobiście czuję się jakbym był częścią filmu SF o pandemii… tyle, że to się dzieje na prawdę. ponieważ pracuję w większości zdalnie, nie odczuwam tak tej kwarantanny ani paniki. zacząłem to lepiej rozumieć w momencie, kiedy zorganizowaliśmy otwarte wydarzenie dla pracowników. i o tym wydarzeniu chciałem trochę opowiedzieć w dwóch kontekstach.

TECHNICZNIE

korzystamy z Teams Live Event. max liczba odbiorców to 1oK więc nawet duża organizacja może zrobić otwarte wydarzenie dla pracowników. konfiguracja jest dość prosta. nie korzystałem z żadnych dodatkowych narzędzi tym bardziej, że wszyscy prezentujący byli w domach. TLE działa inaczej niż zwykłe Teamsy i służy tylko do broadcastowania – video i voice nadają tylko prezenterzy/producenci a uczestnicy tylko słuchają. można włączyć funkcję QnA aby mieć kontakt z uczestnikami.

cały streaming, aby był skalowalny na takie liczby idzie przez Azure Media Services. wadą jest 1o-2o sek opóźnienia dla odbiorcy końcowego (więc nie tak 1oo% live) ale to nie przeszkadza przy tej skali eventu. pomimo kłopotów jakie ostatnio występują u dostawców chmury publicznej, wydajność i działanie – bez zarzutu. oczywiście zdarzało się, że komuś domowe wifi słabo działało ale to już niezależnie od usługi. mamy okres globalnego stress testu sieci na całym świecie.

jestem bardzo pozytywnie zaskoczony tym jak TLE działa – narzędzie jest proste, może nawet trochę prymitywne, ale w 9o% scenariuszy to wystarcza, a całość jest płynna, daje możliwości przeanalizowania statystyk i wrzucenia nagrania np. na Streams.

PSYCHOLOGICZNIE

na pierwsze spotkanie dołączyło 55o osób. dwa-trzy dni później, na kolejnej edycji, ta liczba została zdublowana.TLEspotkanie prowadzone przez Chiefs, Heads, Directors itp. jednymi z najczęściej zadawanych pytań to ‚czy stracimy pracę?’ oraz ‚czy adopcja pracy zdalnej zostanie po kwarantannie?’. o ile pytanie o qlturę jest po prostu ciekawe, to ogólnie przeglądając QnA i pytania jakie zadają ludzie uświadomiły mi jak bardzo ludzie boją się – nie wirusa, ale o przyszłość, co po nim? pracując z domu, trochę jakbym miał normalnie kwarantannę. ale dla osób pracujących klasycznie, w biurze, przyzwyczajonych do przemieszczania się i ciągłego spędzania czasu wśród ludzi … to olbrzymia zmiana. pozostawienie z własnymi myślami i zatruwani wiadomościami o rosnącej liczbie zarażeń… ludzie się boją. choć szukając odrobinę pozytywnego aspektu – dobrze, że boją się o przyszłość, a nie tego co jest teraz, bo to oznacza, że jeszcze nie jest tak tragicznie, że każdy tą przyszłość widzi i nie jest to jeszcze apokalipsa (choć i takie głosy dochodzą mnie już brrrr!).

PODSUMOWUJĄC

widzę jak ważne jest ‚spotykanie się’. w różnych kontekstach. ludzie w tej trudnej chwili potrzebują pocieszenia w postaci konkretów, faktów, informacji wskazującej co będzie dalej, zbudowania wizji przyszłości. uważam, że to zacna inicjatywa i polecam wszystkim firmom/organizacjom na robienie spotkań – w mniejszych lub większych grupach. nie pozostawiać swoich pracowników samym-sobie, aby nie pogrążali się w strachu i panice.

to ważny czas dla każdego aby wyłuskać z siebie trochę mocy i podjąć inicjatywę -zarówno firmowa jak prywatnie – i organizować jakieś spotkania. być razem. szczęśliwie żyjemy w czasach w których miejsce fizycznie nie musi nas więzić i możemy spotykać się w wirtualu. hasło ‚tomorrow is today’ spadło nam na karki i trzeba wycisnąć z tego wszystko dobre co się da.

NIE PODDAWAJCIE SIĘ DEPRESJI I PANICE, sięgajcie o pomoc do znajomych i szefów, organizujcie się!

eN.

EXO V2

muszę (przynajmniej częściowo) odszczekać to, co pisałem w nie tak dawno temu – konkretnie część dotyczącą ClickOnce dla Exchange Online. w końcu, po wielu cierpieniach pojawił się moduł EXO V2 – i to na chwilę przed wpisem, czyli moje przeoczenie. w końcu można normalnie zainstalować z repozytorium! co prawda konsola wita jeszcze w klimacie helloween, z dreszczykiem, ale i to powinno wkrótce się zmienić:

nie tylko instalacja jest doprowadzona do normalności, ale pojawiło się wiele nowych commandletów. osoby pracujące z EXO na pewno odetchną z ulgą (:

eN.

 

MFA, SSPR – ‚unified experience’?

scenariusz

typowy w-files czyli hejcik przy kawie. dziś o konfiguracji MFA oraz fakcie, że od czasów portalu Azure, który niewielu już pamięta, ten fragment cały czas jest w starej wersji. można się do niego dostać linkiem https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx i wygląda tak:

…już pominę kwestię, że MFA jest jednym z częściej koniecznych obszarów do obsługi przez 2gą linię, a nie ma możliwości użycia RBAC i konieczny jest Global Admin, czy taki szczegół, że ‚podpowiedzi’ pokazują prywatne pule adresowe (LoL).

żeby zaadresować te problemy i w końcu dać nowy interfejs, powstał ‚combined security information registration (preview)‚. na razie ‚preview’ – chociaż nie wiem po co w tych czasach dodawać taki dopisek, skoro wszystko jest w metodyce CI/CD co oznacza ‚neverending preview’. dodajmy teraz do tego SSPR – czyli Self-service Password Reset. konfiguracja wygląda tak:

 

efekt?

otóż ustawienia metod uwierzytelnienia dla MFA, skonfigurowane w SSPR mają pierwszeństwo nad ustawieniami z MFA server. czyli np. :

  • chcielibyśmy dać możliwość ludziom użycie dowolnej metody 2FA (call, text, app) i równocześnie wymusić, że podczas zmiany hasła musimy skorzystać z odpowiadania na pytania – nie da się. jeśli włączymy X metod uwierzytelnienia, te same będą dozwolone przy resecie hasła.
  • konfiguracja MFA z panelu użytkownika znika. na razie nie udało mi się znaleźć jak ‚wyklikać się’ do ekranu zmiany opcji. użytkownik musi skorzystać z linka bezpośredniego – https://aka.ms/mfasetup .
  • nawet jeśli SSPR jest konfigurowany tylko dla ograniczonej ilości osób (np. przez grupę), to i tak te opcje działają na wszystkich
  • nie oznacza to wcale, że stary MFA server setup jest już zbędny! ponieważ to jest jedyna opcja, która działa z nowego miejsca – cała reszta, czyli opcja trusted IP czy ile czasu MFA jest cache’owane – to wszystko konfiguruje się ze starego panelu.

no. łatwiej teraz jest, nie?

eN.

 

ClickOnce

emotHateporanny hejcik przy kawie.

jest sobie taka stara technologia dostarczania aplikacji – ClickOnce. i chociaż na stronach eMeSu nie ma informacji, że jest ‚depricated’ mimo to – jest. z tym rodzajem instalacji można spotkać się w kilq miejscach w M365 – trafiłem na trzy, pamiętam dwa:

  • instalacja PowerShell dla EXO w hybrid mode
  • eDiscovery export tool

sposób w jaki taka apka jest opublikowana powoduje, że nie da się (standardowo) użyć opcji ‚uruchom jako’, udostępnić komuś, przenieść między profilami czy cokolwiek innego. ale nie to jest najpasqdniejsze. na tej stronie jest informacja, że aby uruchomić aplikację należy mieć Internet Explorer. jest też info o FF z jakimś dodatkiem – tego nie testowałem ale nie omieszkam. drugą przeglądarką, choć nie wymienioną, był/jest Edge. był – ponieważ nowy Edge, na Chromium już nie jest. pozostaje więc konieczność używana IE /:

drogi Microsofcie… czasem brak mi słów. z jednej strony wszyscy przestali nadążać za nowo-pojawiającymi się opcjami, dodatkami, panelami etc – a z drugiej, podczas dochodzenia w incydencie bezpieczeństwa trzeba odpalać spapranego IE, o którym cały świat wolałby już zapomnieć i waszym interesie jest, żeby to się stało ASAP…

eN.

Cloud IT Architecture Resources

bookmark https://docs.microsoft.com/en-us/office365/enterprise/microsoft-cloud-it-architecture-resources

eN.

zmieniłeś nazwę kanału Teams? możesz go stracić

jest w MS Teams bug – jeśli kiedykolwiek zmieniłeś nazwę kanału, może ci go ‚rozpiąć’ od katalogu biblioteki SharePoint. same pliki nie są gubione, można się do nich dostać poprzez widok SharePoint.

problem dodatkowy jest taki, że nie ma jak takiego problemu zaudytować – logi nic nie powiedzą. nie dość, że akcja jest w tle, i po prostu nagle znika kanał na Teams, to nawet samej zmiany kanału się nie zaudytuje, bo logi są max 9o dni a zmiana kanału mogła się wydarzyć dawno – w moim przypadq był to luty O_o

dobre informacje

  • jak zostałem zapewniony, fix będzie wkrótce rolloutowany. nie zmapuje z powrotem rozłączonych katalogów, ale zabezpieczy przed takimi incydentami
  • w private preview jest opcja trzymania logów audytowych przez rok – funkcja ma być dostępna w planie E5 i w jakimś add-onie dla E3. i to jest super wiadomość, bo te 9o dni to stanowczo na mało!

eN.

Migracja w hybrydzie – zakończenie pojedynczej skrzynki w zadaniu synchronizacji

ciekawostka, bo wszyscy piszą, że się nie da… a się da.

jeśli założy się zadanie migracyjne Ex-EXO w którym jest wiele kont, to można potem usunąć pojedynczą skrzynkę użytkownika, ale nie bardzo jest sposób na to, żeby tylko jedną skończyć. jeśli jednak się przyjrzeć w jaki sposób działa parametr ‚AutoComplete’ dla wsadu migracji, sprawa okazuje się oczywista.

korzystając z PowerShell, jeśli chcemy zsynchronizować skrzynki ale ręcznie ustalić kiedy mają się przełączyć wygląda to np tak:

gdzie opisywanym parametrem jest oczywiście ‚AutoComplete’. ale kiedy podejrzy się potem takie zadanie – gdzie to sobie siedzi? jeśli posłużymy się get-migrationUser żeby to znaleźć – nie bardzo się uda. parametr jest dziedziczony z całego wsadu, stąd może wydawać się niemożliwe ukończenie pojedynczej skrzynki. jeśli jednak wyświetli się i sprawdzi w jaki sposób jest to de facto zrealizowane, to rozwiązanie nasuwa się samo. tak na prawdę dla całego zadania ustawiany jest atrybut ‚completeAfter’ na jakąś chorą datę – w tym przypadq wyjątkowo szybko:

wyjątkowo szybko, bo zazwyczaj widzę 31.12.9999 . z jakiegoś powodu tym razem czas został kapkę skrócony, ale i tak jestem zbyt niecierpliwy, żeby czekać tyle czasu (;

…a zatem aby skończyć pojedynczą synchronizację wystarczy ustawić jej czas ‚completeAfter’ na obecny. korzystam z jednej z dwóch metod:

lub

ustawiając datę z przeszłości – jeśli chcę mieć 1oo%, że to nie chodzi o UTC. nie porównywałem czy efekt jest identyczny. przez jakiś czas nic się nie dzieje (statystyki nie pokazują statusu jako ‚completing’), ale po ok 1h skrzynka jest ‚completed’.

eN.

Uruchamianie usług chmurowych w hybrydzie

Usługi czyli EXO (Exchange Online) i SOL (Skype for Business Online). Problem w hybrydzie polega na tym, że nie można skorzystać z interfejsu portal.office.com – należy konta założyć w środowisq onprem. i oczywiście prostą odpowiedzią byłoby skierowanie do commandletów Exchange i SfB w onprem… ale po co wtedy byłby wpis?

Scenariusz

zakładamy konto użytkownika i chcemy aby od razu miał skrzynkę w EXO i uruchomione usługi SOL. można założyć całość w onprem a potem migrować… ale to straszna strata czasu i wysiłq.

Standardowo

niemniej zacznę od standardowej metody, ponieważ tak to się robi oficjalnie.

po założeniu konta w AD, należy wykonać enable-RemoteMailbox – opis polecenia oraz doqmentacja do hybrydy. następnie trzeba włączyć konto SOL poleceniem enable-CSUser, a sztuczka polega na dodaniu parametru  „-HostingProviderProxyFqdn sipfed.online.lync.com”.

problem z tym rozwiązaniem jest taki, że żeby założyć konto potrzebne są aż trzy różne moduły: Active Directory, Exchange oraz Skype for Business. Prawidłowo administracja powinna być tak zorganizowana, że administratorzy logują się na stację zarządzającą, gdzie mają wszystkie narzędzia zainstalowane – w szczególności te wymienione. i oczywiście sugerowałbym aby tak to się odbywało. jednak… życie pisze własne scenariusze, np. taki, że jest sobie system HR, z którego wypływają dane o użytkownikach. i jak developer ma sobie z tym poradzić? do LDAP dość łatwo się dostać i są do tego standardowe biblioteki w samym frameworq, a do Ex czy SfB już tak różowo nie jest.

HACKED

….podam sposób, jak można założyć mailbox i włączyć SIP, wyłącznie przy pomocy modułu Active Directory/dostępu do LDAP. zaletą takiego rozwiązania jest brak konieczności instalacji pozostałych – i to właśnie był czynnik, który zmusił mnie do zrobienia takiego rozwiązania. zacznę od przestrogi:

zaprezentowane rozwiązanie nie jest wspierane, a konsekwencje użycia mogą być ciężkie do przewidzenia – dla tego przetestuj dokładnie, upewnij się, że rozumiesz co robisz i jak to działa tak, aby w razie co być w stanie naprawić. pełne commandlety wykorzystują mechanizmy sprawdzające poprawność ustawianych wartości, czy nie występują duplikaty w domenie, i wiele innych, których tutaj nie ma – a więc można namieszać. korzystasz na własną odpowiedzialność.

no to jak już się przestraszył[ae]ś, to teraz rozwiązanie.

w zasadzie najważniejszym trikiem jest zrozumienie jak działa hybryda – wszystkie zmiany wprowadzane są w onprem i synchronizowane do chmury. czyli wskazane polecenia – enable-RemoteMailbox czy enable-CSUser – wbrew temu co możesz sądzić, w żaden sposób nie łączą się z Office365. jedyne co robią, to modyfiqją wartości atrybutów w AD. w związq z tym można napisać skrypt, który dokładnie to zrobi.

nie będę zamieszczał całego skryptu – są w nim elementy specyficzne dla konkretnego klienta – ale wszystko co niezbędne znajdziesz poniżej.

Exchange

atrybuty, które należy zmodyfikować mogą się różnić, zależnie od klienta – wiadomo, różne firmy mają różne wymagania. poniżej zestaw atrybutów ‚podstawowych’:

to, co widać powyżej, to oczywiście zestaw atrybutów obiektu User w AD, niezbędnych do założenia skrzynki.

  • mail: $oUser to obiekt użytkownika, pobrany wcześniej jako „$oUser=get-aduser <name> -properties *”. tutaj założenie jest, że podstawowy email jest taki sam jak UPN
  • mailNickname: standardowo jest taki sam jak SAM
  • msExchPoliciesExcluded: jeśli chcę ustawiać adresy email ręcznie to wskazana polisa (GUID taki sam dla każdego Ex) jest odpowiednikiem odznaczenia ‚Automatically update email addresses…’ . jeśli adresy będą się wypełniały standardowymi polisami, to można pominąć
  • msExchangeRecipient*: wskazują na typ skrzynki. szczegóły tutaj. ogólnie – wskazuje, że skrzynka typu RemoteUserMailbox ma być założona
  • msExchUMDtmfMap: będzie za chwilę wypełnione – funkcja poniżej. de facto chodzi o konwersję na cyferki z cyferblatu telefonu, fragment UC.
  • msExchVersion: jest zawsze taka sama, i pochodzi z onpremowego Exchange. można sobie zweryfikować z jakimś lokalnym kontem
  • proxyAddresses: to oczywiście aliasy. jeśli ustawiamy inne niż podstawowy, warto nie zapomnieć wyłączyć polisy msExchPoliciesExcluded…
  • showInAddressBook: to CN list adresowych, w których ma się pojawić. tutaj standardowa lista globalna. ten CN można odczytać z innego użytkownika.
  • targetAddress: bardzo ważne pole, wskazujące na przekierowanie do chmury. na jego podstawie robiony jest routing do chmury na connectorze.

zmienna jest typu hashtable, można więc sobie powyliczać np. proxyaddresses, poustawiać co potrzeba. np. DTMF. funkcja, która konwertuje ciągi do DTMF:

i fragment kodu, który ustawia DTMF:

zmienna jest tablicą zawierającą zazwyczaj trzy elementy w zapisie DTMF – adres email [a w zasadzie nazwa użytkownika – bez domeny], nazwa użytkownika ‚lastNameFirstName’ oraz ‚firstNameLastName’. a więc wyliczam przy pomocy funkcji konwertującej i paqję do zmiennej $EXOattributes.

kiedy $EXOAttributes zawiera wszystko to, co potrzebne, pozostaje pchnięcie tego do AD. i tutaj piękno i prostota PS:

i już. atrybuty są wypełniane, zsynchronizuje się do o365, a ten podejmie odpowiednie działania – czyli założy skrzynkę.

SOL

całość wykonuje się analogicznie – buduję hashtable, który potem pchnę do AD, a poniżej niezbędne atrybuty dla Skype for Business Online:

te zbudowane są dla środowiska sfederowanego, gdzie po stronie OnPrem stoi Lync 2o13. to może mieć znaczenie dla atrybutu msRTCSIP-PrimaryHomeServer – ponieważ nie wiem czy tak samo wygląda CN usługi SfB.

dla ‚OptionFlags’ link z wyjaśnieniem wartości można znaleźć tutaj.

zakończenie

jak wspomniałem, nie publiqję całego skryptu, ponieważ logika wyliczania czy to proxyaddresses czy innych elementów jest dla konkretnego środowiska i każdy musi sam to oprogramować. celem wpisu jest tak na prawdę pokazanie na czym polega ‚od spodu’ założenie konta w EXO czy SOL w środowisq hybrydowym. niby każdy wie, że zmiany synchronizują się w jedną stronę, a jednak podczas rozmów, okazuje się, że wszyscy spodziewają się jakiejś dodatkowej komunikacji pomiędzy systemami. a tu nic takiego nie ma – jest tylko synchronizacja i tyle.

nie jest to zalecany sposób tworzenia… ale na pewno fajna zabawa (;

eN.

SSPR vs contact info

ciekawy case dotyczący uruchamiania Self-Service Password Reset (SSPR) i zarazem lekcja – workaround to nie solution q:

zgłosił się do mnie zapłakany klient, że uruchamiają SSPR i muszą jakoś dostarczyć dane użytkowników do portalu. do niedawna nie było to możliwe (uservoice z 2o18), ale od jakiegoś czasu Microsoft w swojej wielkości dostarczył… no właśnie, co dostarczył? obejście problemu opisane tutaj. ‚czemu obejście?’ zapyta ktoś, kto uważnie przestudiuje, sprawdzi i stwierdzi że działa…

…ano problem polega na tym, że informacje do SSPR brane są z atrybuty ‚StrongAuthenticationUserDetails’. ten atrybut ma kilka cech odróżniających go od zwykłego atrybutu np. ‚telephoneNumber’ a jednym z nich jest fakt… że nie wypełnia wizytówki użytkownika. jest niewidzialny.

i teraz taki myk…

tak wygląda użytkownik, który wszedł na portal i wypełnił sobie dane do MFA/SSPR:

i wyświetlmy sobie właściwości w AAD:

a teraz, za artykułem, prepopuluję (dziś super po polsq) atrybuty:

no i output takiej operacji:

co się dzieje dalej? hasło dla testuser02 resetuję i działa. kiedy próbuję dostać się do portalu o365, dostaję standardowe pytanie o uzupełnienie obligatoryjnych pól do zabezpieczenia konta (czyli te do MFA, które zapisują się w StrongAuthenticationUserDetails).

a więc to …’rozwiązanie’ nie działa dla MFA, jest obejściem dla SSPR, i dane ‚zabezpieczające’ stają się *publicznie* dostępne dla wszystkich w organizacji ROTFLMAO.

eN.

%d bloggers like this: