Skip to Content

IT nieuczesane.
category

Category: Cloud

konsola EXO z MFA

PowerShell dla EXO to porażka, zwłaszcza z włączonym MFA. już sam fakt, że należy jej szukać w części ‚hybrid’ nie jest logicznie wyjaśnialny. podstawowym problemem jest jednak zaszyty hard-limit czasu sesji na 15 min. teoretycznie to czas bez aktywności (idle), ale zdarza mi się, że działający skrypt się sypie… najbardziej doqczliwe było jednak to, że za każdym razem trzeba się uwierzytelniać i przy każdym kolejnym połączeniu ponownie importowane są commandlety, a dodając do tego MFA… zaczyna się robić na prawdę nieprzyjemnie.

szukałem po forach i po doqmentach i miałem na prawdę dziwne pomysły jak to rozwiązać… aż w końcu znalazłem rozwiązanie. dodam, że trywialne.

jeśli uruchomi się po prostu ‚Connect-EXOPSSession’ … nie da się żyć. a wystarczy uruchomić z parametrem:

i owszem, sesja nadal jest zrywana po 15 min ale następuje automatyczne ponowne uwierzytelnienie, bez konieczności wpisywania hasła czy potwierdzania drugiego składnika. nie są również ponownie importowane commandlety. w skrócie – w końcu da się pracować.

być może to tak oczywiste, że nikt o tym nie pisze. być może to było wielką czcionką na ‚pierwszej stronie’. ale być może uratuję kogoś tym wpisem przed całkowitą utratą nerwów, czego byłem już kilka razy bliski przygotowując raporty z EXO.

eN.

Ribbon dies, long live the Ribbon!

zbliża się nowy wygląd dla Office365. czekam z nieciepliwością, bo nigdy się ze ‚wstążką’ nie polubiłem

source

eN.

usuwane danych użytkownika z Office365

niby proste. ale jest ‚ale’….

User

po usunięciu użytkownika – zostaje w śmietniq. to proste. czyli należy usunąć usera a potem go usunąć ze śmietnika

 

Exchange

teraz nie mogę znaleźć… ale jestem przekonany, że w artyqłach była informacja że po takim usunięciu wszystkie dane są również usuwane… ale tak nie jest! okazuje się, że skrzynka zostaje:

OneDrive

z OneDrive jest jeszcze dziwniej, bo po usunięciu użytkownika site nadal jest widoczny jako aktywny. jako dowód – po wykonaniu tego polecania, OD użytkownika nadal nie będzie na liście:

natomiast wyświetlenie aktywnego site OD pokaże go:

opis algorytmu dla OD można zleźć w artykule na support.office.com. site jest widoczny i dostępny przez 7 dni po usunięciu użytkownika i dopiero potem trafia do śmietnika.

podsumowując

  • proste operacje ‚pod spodem’ wcale niekoniecznie są takie proste.
  • każdy serwis żyje własnym życiem i ma własne zasady – office365 to nie jest pojedyncza usługa!
  • jeśli ktoś ma ‚onpremową intuicję’ to należy się jej wyzbyć.
  • to wszystko to niby niuanse, ale bywają istotne – zwłaszcza jeśli trzeba odtworzyć konto w AAD oraz ze względu na aspekty bezpieczeństwa i dostępu do danych.

eN.

 

 

 

 

Ograniczenia Exchange Hybrid

[updated]

pomimo, że hybryda Exchange jest dość typowym scenariuszem i to raczej docelowym środowiskiem dla większości większych firm, to niestety niesie ze sobą sporo ograniczeń. zwłaszcza w okresie migracji może to stanowić spory problem.

poniżej zebrane – nie wiem, czy wszystkie. ograniczenia dotyczą dostępu do skrzynek pomiędzy środowiskami (cross-premise)

  • nie działa ‚automapping’ dla kont cross-premise. czyli jeśli osoba w chmurze ma dostęp do skrzynki współdzielonej onprem to musi dodać ją ręcznie we właściwościach – sama się nie zmapuje.
  • największe hece są z kalendarzami dla skrzynek cross-premise. po migracji traci się udostępnienie, a przy ponownym udostępnieniu nie widać detali. jednym z obejść problemów jakie znalazłem jest ponowne udostępnienie skrzynki.. ale z OWA. to nie wszystko! akceptacja też musi być z OWA. ciekawy opis tu.
  • bardziej ogólnie problem polega na tym, że nie wszystkie uprawnienia są obsługiwane dla scenariuszy cross-premise. zwłaszcza uprawnienia item-level. i chociaż na stronie jest informacja że ‚sand as’ nie działa, to da się to zrobić.
  • nie ma dostępu do skrzynek archiwalnych dla cross-premise
  • właściciele grup nie mogą zarządzać grupami dystrybucyjnymi z Outlook. jako obejście można stworzyć skrót do narzędzia systemowego.

znasz inne?

eN.

czy OneDrive ma skanowanie antywirusowe?

krótko – tak, ma. zarówno OD jak i SP. tutaj można znaleźć kilka szczegółów.

to, co jest dodatkowo ciekawe, to kwestie prywatności… skoro działa skaner antywirusowy, to znaczy że eMeS może zajrzeć do zawartości pliqw? w zasadzie to indexer też działa – przecież jest search, który dokładnie to robi – skanuje [‚zagląda’] do pliqw po to, żeby pomóc je wyszukiwać.

poza politykami prywatności i zapewnieniami ze strony Microsoft, że żaden pracownik nie ma wglądu w treści klientów bez ich wiedzy i zgody, nie udało mi się znaleźć technicznego ‚dowodu’ że tak faktycznie jest. w końcu usługi działają w zupełnie innym kontekście. pozostaje zaufanie, poparte również tym, że jeśli choćby jeden taki przypadek wyciekł publicznie, odbyłby się globalny lincz i utrata zaufania.

eN.

Exchange hybrid – niespójność informacji

ogólnie synchronizacja jest jednostronna – z onprem do online. obiektami środowiska hybrydowego najlepiej zarządza się z onprem, ponieważ w o365 są tylko do odczytu… ale są pewne wyjątki, powodujące niespójność. przykładem może być konwersja skrzynki User<>Shared.

od momentu, kiedy skrzynka jest już w ExOL, o statystyki czy operacje na skrzynce, trzeba sięgać bezpośrednio. o ile get-recipient można uruchomić również onprem, o tyle np. konwersję typu należy przeprowadzić w ExOL. dodajmy do tego fakt, że synchronizacja jest w jedną stronę i…

…po konwersji skrzynki, jeśli uruchomimy get-recipient lokalnie, to pokaże nam typ z przed konwersji. w efekcie, jeśli takie operacje są wykonywane często, statystyki będą przekłamywane. należy więc po dokonaniu konwersji ręcznie zmodyfikować atrybuty w AD tak, aby odpowiadały obecnemu stanowi. trzeba przy tym uważać, bo nazwy są bardzo podobne i łatwo je pomylić:

 SharedMailbox UserMailbox
msExchRemoteRecipientType 100 6
msExchRecipientTypeDetails 34359738368 2147483648
msExchRecipientDisplayType -2147483642 -2147483642

szczegółowy opis parametrów tutaj

przykładowy link do dalszej lektury: http://jetzemellema.blogspot.co.uk/2016/02/convert-user-mailbox-to-shared-in.html

eN.

Fixes and Workarounds

coś, co warto sobie dodać do bookmarków – Fixes or workarounds for recent Office issues. na tej stronie znajdują się aktualne informacje dotyczące znanych błędów wraz z rozwiązaniami. w moim przypadq – nagle przestało mi działać uwierzytelnienie ADAL/MFA w outlook. w części windows/outlook/other issues można znaleźć, że ostatni fix coś uszkodził i na razie obejściem jest wyłączenie ADAL. albo poczekanie na fixa do fixa (;

Unable to create second profile with different account on ADAL enabled tenant. [WORKAROUND]

Last Updated: February 7, 2018

ISSUE

When you try to configure a secondary account from the same Office 365 tenant in Outlook 2016 (Current Channel) with ADAL enabled, you receive the following error: „An encrypted connection to your mail server is not available. Click Next to attempt using an unencrypted connection.”

STATUS: WORKAROUND

To workaround this issue, you can disable ADAL on the client. To do this, follow these steps to Disable modern authentication on devices.

**********

warto mieć link pod ręką!

eN.

role AzureAD – jak zacząć pracę z graphAPI

Customized Administrator

czy zauważyliście, że zależnie od interfejsu, widać inne role w AAD? jeśli zajrzymy z Office Admin Center to:

kiedy tworzy się ‚Customized Admin’ z portalu Admin, to już ilościowo widać, że jest coś więcej:

a tak na prawdę, jak nie trudno się domyślić, jest ich jeszcze więcej.  scenariusz ‚po co?’ zostawię sobie na kiedy indziej a tymczasem – jak sprawdzić te role i jak do nich przydzielić? jakich braqje?

jak sprawdzić wszystkie role

najkrócej: za pomocą Microsoft Graph. zakładam, że używanie tego mechanizmu dla wielu osób nie jest oczywiste, dla tego krótka instrukcja. po wejściu stronę, należy się uwierzytelnić do swojego tenanta [po lewej stronie ‚microsoft sign-in’]. w innym przypadq będziemy w testowym tenancie Microsoftu.

w oknie akcji widać trzy podstawowe elementy – okno zapytania, ‚request body’ uzupełniające zapytanie oraz ‚response body’ gdzie będą się pojawiać wyniki.

dla sportu można sobie kliknąć ‚run query’ i zobaczyć wynik w ‚response body’. szybko można się zorientować, że wszędzie widzimy legendarnego Dżejsona, a zapytania są w stanie spoczynq [REST]. jak nie rozumiesz – na razie nie szkodzi, ale warto uzupełnić sobie informacje o zapytania REST oraz format JSON. w odpowiedzi dowiemy się paru rzeczy o własnym koncie.

można się również szybko zorientować w dostępnych metodach rozwijając listę ‚GET’ gdzie widać jeszcze ‚PUT’, ‚POST’, PATCH’ oraz ‚DELETE’. widać również, że są dwie wersje Microsoft Graph – v1.0 oraz beta.

pierwsza niespodziewajka – czytając i przeglądając artykuły zaczniecie trafiać na wersje 1.5 czy 1.6… a to dla tego że oprócz Microsoft Graph jest jego poprzednia wersja – AzureAD graph. trzeba zatem uważać przy stosowaniu przykładów, do której są wersji.

dostępne role dla Customized Administrator – bo taki jest cel niniejszego zadania – widoczne są w części ‚directoryRoles’. i tu widać pełną listę, m.in. niedostępnego z interfejsu ‚CRM Service Administrator’, ‚Power BI Service Administrator’ i kilka innych.

jak dodać rolę

pomimo, że w naszym świecie rolę przydziela się użytkownikowi, tutaj to roli przydziela się użytkownika. czyli operację trzeba wykonać dla pożądanej roli a nie dla użytkownika. to, co będzie nas interesować to ‚ID’ roli. zanim coś przypiszemy najpierw sprawdźmy członków ‚Global Admins’. tutaj nazywa się to ‚Company Administrator’ … pewnie dla ułatwienia (; spisujemy ID i wykonujemy GET dla https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members -> Run Query. pojawią się wszyscy GA dla tenanta.

aby kogoś dodać, należy wysłać żądanie [POST] a w treści zamieścić opis obiektu zapisany jako JSON.

polecenie HTTP:

POST v1.0 https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members/ref$

oraz request body, gdzie zamieszczamy opis obiektu:

wykonujemy request i….

dostajemy błąd o braq uprawnień. pomimo, że jesteśmy adminami?

uprawnienia dla GraphExplorera

Graph Explorer działa jako proxy i standardowo ma tylko uprawnienia odczytu. należy aplikacji nadać uprawnienia, aby mogła wykonać operacje zapisu. zwróć uwagę, że tam, gdzie było ‚Sign In’, teraz pod loginem jest ‚modify permissions’ oraz ‚sign out’. dla nadania roli wymagane są dwa uprawnienia:

  • Directory.AccessAsUser.All
  • Directory.ReadWrite.All

zostaniemy zapytani, czy nadać aplikacji odpowiednie uprawnienia i voila. wykonanie wcześniej opisanego query – doda userowi pożądaną rolę.

eN.

user@tenant.onmicrosoft.com w hybrydzie

każdy obiekt użytkownika w o365 w hybrydzie ma standardowo zakładane dwa adresy email:

  • user@tenant.mail.onmicrosoft.com – który służy jako email routingowy. EXO jest de facto oddzielnym środowiskiem, oddzielną organizacją Exchange, a więc jeśli jest email user@w-files.pl, musi istnieć sposób na przesłanie maila do konkretnego serwera – wtedy wykorzystywany jest ten adres.
  • user@tenant.onmicrosoft.com – który jest tworzony na podstawie standardowej polityki adresowej EXO. czy użytkownik jest synchronizowany, czy założony bezpośrednio – jest nadal mailboxem i podlega polityce.

istnieją różne scenariusze, w których chcielibyśmy zmienić istniejący adres – np. chcemy go zwolnić tak, aby mógł być wykorzystany dla innego obiektu. ale….

w środowisq hybrydowym wszystkie zmiany muszą być zrobione w on-prem. próba dokonania adresu bezpośrednio w EXO skończy się Acc Denied. ale…

jeśli wykonamy polecenie

to zobaczymy adres routingowy user@tenant.mail.onmicrosoft.com ale nie będzie na liście adresu EXO /:

jak zatem go zmienić?

da się, ale wymaga nieco gimnastyki. skoro nie da się zmienić dla konta synchronizowanego to trzeba je uczynić na chwilę kontem lokalnym o365. a więc kroki są następujące:

  • przesunąć obiekt w on-prem AD do OU, które nie jest synchronizowane
  • wymusić/poczekać na synchronizację
  • konto w AAD zostanie usunięte wraz z mailboxem
  • odzyskać konto w AAD [np. restore-msolUser]
  • zmienić adres w EXO
  • przywrócić pierwotną lokalizację obiektu w AD
  • poczekać na synchronizację

jeśli konto zniknie przy pierwszym cyklu, może to wynikać z niepełnym sync w domenie on-prem. najlepiej wykonywać operacje na AD, z którego jest robiony sync do AAD.

eN.

współdzielenie OneDrive – ciekawostki

OneDrive Sharing

na początek oczywiste oczywistości:

  • OneDrive to de facto SharePoint. główne ustawienia współdzielenia [Sharing] dziedziczy z globalnych ustawień SP
  • od jakiegoś czasu dostępny jest OneDrive Admin Center z poziomu Office365. z jego poziomu można pozornie ustawić zabezpieczenie współdzielenia na poziomie niższym, niż jest zdefiniowany w SharePoint. ale nie można [co zresztą jest opisane małym druczkiem na dole].

  • od niedawna rozbudowany został klient OneDrive – w końcu można nadawać uprawnienia ‚bezpośrednio’ z Exploratora. co mnie pozytywnie zaskoczyło – okienko uprawnień jest renderowane przez OneDrive.exe a nie, tak jak się spodziewałem, iexplore.exe/edge .

Jak powstaje ACE dla osoby z zewnątrz

i tu się zaczyna robić ciekawie. standardowo, do czego przyzwyczaiły nas systemy operacyjne, flow jest taki:

  • użytkownik wybiera plik i nadaje uprawnienia
  • tworzony jest ACE – Access Control Entry – który staje się nieodłączną częścią pliq… w dużym uogólnieniu.
  • osoba próbuje się dostać
    • uwierzytelnia się
    • token uwierzytelniony porównywany jest z ACL [Access Control List] w poszukiwaniu ACE dla danego usera – rodzaj filtra
  • osoba dostaje dostęp lub nie.

wydaje się tak oczywiste… a jednak dla pliq współdzielonego z osobą z zewnątrz w OneDrive, jest inaczej. czy zastanawiałeś się po co jest poniższa opcja? skoro można uzyskać dostęp przez osobę inną niż zaproszona, to znaczy, że ACE nie może istnieć w momencie dostępu. zakładając, że wyłączone są linki anonimowe, w dużym uogólnieniu wygląda to tak:

  • użytkownik wybiera plik, uprawnienia edit/view i adres osoby z zewnątrz.
  • tworzony jest *link*, URL, zawierający token dostępu. ten link wysyłany jest mailem.
  • osoba, która otrzymała link otwiera go. zakładając, że wymuszone jest uwierzytelnienie, zostanie przekierowana na stronę logowania.
  • po pozytywnym uwierzytelnieniu, na podstawie linka generowane jest ACE, które dopiero teraz dopisywane jest do pliq
  • tworzone jest również konto [jeśli nie było wcześniej] „username_server.name#EXT#@company.onmicrosoft.com” w AAD

czemu tak i jakie to ma konsekwencje

opisywane zachowanie będzie zależne od kilq ustawień bezpieczeństwa na SP – czy włączone są linki anonimowe, oraz czy mogą być otwierane przez osoby inne, niż te, do których się je oryginalnie wysłało. współdzielenie linkiem jest znane od lat, i dość oczywiste, dla osób korzystających z usług chmurowych. po prostu w rozproszonym świecie chmury, gdzie nie ma centralnej bazy użytkowników, token jest przekazywany wraz z linkiem – w dużym skrócie posiadanie linka oznacza posiadanie dostępu. stąd powstały mechanizmy rozszerzające to rozwiązanie – np. o wymaganie uwierzytelnienia. czemu zatem link wysłany przez jedną osobę, standardowo może być otworzony przez inną? ta opcja została stworzona głównie z tego powodu, że ludzie korzystają z masy adresów, i mogą mieć konto MS Account założone z innym adresem niż my znamy – np. wysyłamy do kogoś na x@gmail.com a ktoś ma konto MS Account jako x@outlook.com. dzięki temu osoba nie jest zmuszona zakładać kolejnego konta, co było istotne zwłaszcza jakiś czas temu, kiedy nie istniał uproszony proces zakładania konta, i było to bardzo upierdliwe. ale ze względu na bezpieczeństwo, nie włączenie tej opcji, jest dość niepokojącym scenariuszem i sugerowałbym jednak, aby wymuszać weryfikację odbiorcy. w takim wypadq, nawet jeśli przekaże się linka innej osobie [lub zostanie wykradziony!], nie zostanie on obsłużony. można się przyczepić, że komunikat błędu pokazuje zdekodowany adres email osoby, która oryginalnie była w tokenie, ale nie jest to już tak wielki problem.  załóżmy, że opcja jest na ‚default’, czyli może być otwarty przez inną osobę. co się stanie, jeśli roześlę link do stu osób? czy wszystkie będą miały dostęp? NIE. link zawiera ‚token jednorazowego dostępu’. pierwsza osoba się dostanie i dla niej utworzony zostanie ACE, pozostałe osoby dostaną acc denied.

ciekawostki (bugs?)

nie może obyć się bez zagadek w-files. trafiłem na dwie. w porywach do trzech q:

  1. jeśli jakiś user ma wpisany alternate email z jakimś adresem zewnętrznym – np. x@gmail.com, i chcemy udostępnić plik tej osoby na tenże adres zewnętrzny… to się nie uda. AAD rozpoznaje użytkownika jako wewnętrznego i co prawda wysyła linka [zależnie od tego z jakiego interfejsu skorzystamy zachowanie może być różne], ale nie ma szansy zalogować się na kontem x@gmail.com .
  2. jak sądzicie, czy usunięcie konta #EXT# z AAD spowoduje, że osoba straci dostęp do pliq? scenariusz:
  • administrator doszedł do wniosq, że posprząta trochę, i *dla bezpieczeństwa* usunie konta #EXT# żeby zabrać dostępy.

no to się zdziwi, ponieważ usunięcie konta, nie powoduje usunięcia ACE – te systemy są rozdzielne, i nie ma ‚centralnego repozytorium dostępów’. a ponieważ centrum uwierzytelnienia jest również rozłączne z naszym systemem, user zostanie poprawnie uwierzytelniony [przez Microsoft Account a nie przez nasz tenant AAD], ACE istnieje – ergo dostęp będzie. nie wierzycie – spróbujcie, podzielcie się wrażeniami. właśnie ta część pracy – odpowiedź na pytanie ‚kto ma gdzie dostęp’ – jest nadal niełatwym zadaniem. 3. PS. czy zwróciliście uwagę, że w OneDrive for Business jest ‚shared with me‚ a w OneDrive personal jest ‚Shared by me‚? i żadne ze środowisk nie udostępnia mechanizmu dla pełnego rozeznania się co komu i dla nas….  

OneDrive for Business OneDrive personal

eN.