nazwy licencji i planów w o365

scenariusz

przy pracy z licencjami pojawia się wiele problemów. niektóre z nich to:

  • odwzorowanie nazw SKU na nazwy potoczne – np. SKU 'Deskless’ to w interfejsie 'MICROSOFT STAFFHUB’. dość często są one trudne do rozszyfrowania lub wręcz mylące.
  • jakie plany zawiera dana licencja? przykładowo – klient posiada licencję 'o365 E1′ – czy zawiera ona service plan AAD P1?

jest oczywiście wiele podobnych scenariuszy podczas audytów czy planowania konkretnych funkcjonalności czy np. migracji zarządzania licencjami do GBL. odpowiedzi na te pytania dostarcza [a w każdym razie powinna] strona ze spisem: https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/licensing-service-plan-reference . co więcej – jest na niej link do CSV z zamieszczoną tabelą… do czego już tylko krok do napisania sobie prostego skryptu pomagającego w zadanych scenariuszach.

UWAGA jak się przekonałem tej stronie nie można w pełni ufać – jest na niej dużo błędów i niespójności, najradykalniejszy przypadek jaki znalazłem to licencja M365 Business Premium, które wedle tabeli zawiera 24 plany, a w rzeczywistości, listując SKU – jest ich ponad 4o. błąd zgłoszony i mam nadzieję, że poprawią.

dla tych, którzy szukają rozwiązania

napisałem krótki skrypt, który zasysa tabelę w postaci CSV i pozwala na odpytania się kilka podstawowych rzeczy:

  • rozwiązywanie nazw technicznych SKU na 'displayName’ [i odwrotnie] dla licencji i planów
  • listowanie planów w licencji
  • listowanie licencji zawierającej dany plan

przykłady

C:\ :))o- .\get-ServicePlanInfo.ps1 -resolveName deskless
Microsoft StaffHub

C:\ :))o- .\get-ServicePlanInfo.ps1 -resolveName 'MICROSOFT 365 BUSINESS standard'
O365_BUSINESS_PREMIUM

dla tych, którzy szukają nauki

na co warto zwrócić uwagę w kodzie, to wykorzystanie ParameterSetName. są 4 różne operacje/bloki, wykonywane zależnie od wybrania jednego z 4 ParameterSetName:

[CmdletBinding(DefaultParameterSetName='default')]
param (
    #resolve Service Plan or License name
    [Parameter(ParameterSetName='resolveNames',mandatory=$true,position=0)]
        [string]$resolveName,
    #display all licenses containing given SP
    [Parameter(ParameterSetName='listLicenses',mandatory=$true,position=0)]
        [string]$showProducts,
    #show SPs for given license type
    [Parameter(ParameterSetName='listServicePlans',mandatory=$true,position=0)]
        [string]$productName    
)
zazwyczaj logikę kodu opiera się dalej na switchu, zależnie od wykorzystanego PSN:
switch($PSCmdlet.ParameterSetName) {....}
ale postanowiłem to uprościć… w zamian, napisałem 4 funkcje, które mają nazwy identyczne z PSN:
function resolveNames {...}
function listLicenses {...}
function listServicePlans {...}
function default {...}
dzięki temu, zamiast switcha, wystarczy że uruchomię funkcję o nazwie PSN:
$run = "$($PSCmdlet.ParameterSetName) -name '$([string]$PSBoundParameters.Values)'"
Invoke-Expression $run
ładne, nie? (=
eN.

lista subskrypcji z właścicielami

scenariusz

Enterprise Agreement i dużo subskrypcji. potrzebna lista wszystkich subskrypcji wraz z ich właścicielami. moje konto nie ma uprawnień do wszystkich subskrypcji więc korzystam z przygotowanego AppID dla konta monitorującego. powinno niby być proste…

  • po pierwsze trzeba zdefiniować, co się rozumie przez właściciela. mogą to być osoby, które mają nadane uprawnienie 'owner’ w IAM, ale w przypadq subskrypcji bardziej logicznym wydaje się znalezienie ’Account Administrator’ subskrypcji – czyli konta, które ją zakładało.
  • po drugie, trzeba mieć konto, które będzie miało odpowiednie uprawnienia i mam takie konto – w opisywanym scenariuszu chodzi o tożsamość aplikacyjną… i tu się zaczynają schody – ale to opiszę w części praktycznej.
  • po trzecie – jak mamy już prereq to trzeba wymyślić jak to przygotować

schody

Microsoft przepisuje narzędzia na Microsoft Graph, ze starego GraphAPI. a że wszystko u mnie PowerShellem stoi, ostatnimi czasy obserwuję wiele czerwonych wykwitów, a co gorsza – skrypty zaczęły się wieszać. sqpiając się jednak na zadaniu…

najpierw chciałem wylistować wszystkich, którzy mają uprawnienie 'owner’ w IAM. okazuje się, że był bug w commadlecie get-AzRoleAssignment: jeśli używa się tożsamości Aplikacji, zwracany jest błąd:

Exception of type 'Microsoft.Rest.Azure.CloudException' was thrown

błąd został poprawiony w ostatniej wersji, update commadletów, działa!… ale czy aby na pewno? co prawda błąd już nie wyskakuje i wszystkie subskrypcje się listują… ale nie ma SignInName ani DisplayName!

$s=Get-AzSubscription -SubscriptionName 'w-files'
Get-AzRoleAssignment -Scope "/subscriptions/$($s.id)"|? RoleDefinitionName -eq owner

RoleAssignmentName : e740d3e4-7809-4104-876c-8ce2a27edbf9
RoleAssignmentId : /subscriptions/01234567-3223-3223-2332-012345678901/providers/Microsoft.Authorization/roleAssignme
nts/e740d3e4-7809-4104-876c-8ce2a27edbf9
Scope : /subscriptions/01234567-3223-3223-2332-012345678901
DisplayName :
SignInName :
RoleDefinitionName : Owner
RoleDefinitionId : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
ObjectId : 76543210-3223-3223-2332-109876543210
ObjectType : Unknown
CanDelegate : False
Description :
ConditionVersion :
Condition :

obejściem problemu może być wykorzystanie az cli… ma pasqdną składnię, ale ma swoje zalety.

az role assignment list --subscription 01234567-3223-3223-2332-012345678901 --role owner

niedługo należy się spodziewać problemów:

The underlying Active Directory Graph API will be replaced by Microsoft Graph API in a future version of Azure CLI. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration

a teraz 'bardziej prawidłowy’ scenariusz, czyli listing 'account manager’. tu dla odmiany sytuacja jest odwrotna, ponieważ az cli nagle rzyga błędem:

az role assignment list --subscription 01234567-3223-3223-2332-012345678901 --include-classic-administrators

Insufficient privileges to complete the operation.

natomiast z PowerShell hula:

Get-AzRoleAssignment -Scope "/subscriptions/$($s.id)" -IncludeClassicAdministrators|? RoleDefinitionName -match 'AccountAdministrator'


RoleAssignmentName :
RoleAssignmentId :
Scope : /subscriptions/01234567-3223-3223-2332-012345678901
DisplayName : nexor@w-files.pl
SignInName : nexor@w-files.pl
RoleDefinitionName : ServiceAdministrator;AccountAdministrator
RoleDefinitionId :
ObjectId :
ObjectType : Microsoft.Authorization/classicAdministrators
CanDelegate : False
Description :
ConditionVersion :
Condition :

jedyny sensowny komentarz, jaki mi przychodzi do głowy, to starobabcine 'masz ci babo placek’. w każdym razie teraz to już bułka z masłem:

Get-AzSubscription|%{$sub=$_;Get-AzRoleAssignment -Scope "/subscriptions/$($sub.id)" -IncludeClassicAdministrators|? RoleDefinitionName -match 'AccountAdministrator'|select @{L='subscirption name';E={$sub.name}},@{L='subscription ID';E={$sub.id}},@{L='subscirption state';E={$sub.state}},@{L='owner signin name';E={$_.SignInName}},@{L='owner display name';E={$_.DisplayName}} } | export-csv -nti subscriptionList.csv

eN.

 

AzureAD priv preview

funkcje preview można niby włączyć… ale nie wszystkie. niektóre są dostępne – jeśli doda się specjalną flagę.

znalazłem poszukując narzędzia do weryfikacji uprawnień Enterprise Apps. obecnie jest spory śmietnik – apki pojawiają się i po pewnych czasie są trudności z określeniem co do czego ma uprawnienia (globalnie/centralnie).

po włączeniu tej funkcji dostępne  są dodatkowe opcje pozwalające na przejrzenie uprawnień wszystkich aplikacji – niestety brak opcji 'download’. ciekawą funkcją jest również application risk:

próbowałem znaleźć inne opcje, które dzięki tej fladze są dostępne, ale na razie nie trafiłem – zachęcam do poszukania i podzielenia się odkryciami.

eN.

katalog stricte sieciowy

w jaki sposób 'dostarczyć’ jakiś katalog na kilka serwerów/VDI? łatwym i popularnym sposobem jest wykorzystanie Azure Files i po prostu podmapować dysk sieciowy.

takie rozwiązanie ma (potencjalnie) kilka wad. potencjalnie – ponieważ wszystko zależy od założeń po co i dla kogo to robimy:

  • dodatkowa litera dysq
  • trzeba dodatkowe polisy GPO żeby ścieżka była zaufana i żeby system nie pluł się przy każdym uruchomieniu

chodziło o dostarczenie wspólnego repozytorium, dostępnego na wszystkich VDI. można taki efekt osiągnąć mapując udział sieciowy jako katalog.

potrzebny do tego jest Storage Account wspierający Azure Files, dodany do domeny. jest to konieczne ze względu na możliwość uwierzytelnienia. a kiedy mamy już założony Azure Files, wystarczy utworzyć w systemie katalog, który będzie na niego wskazywał:

PS> new-item -type SymbolicLink -path c:\myRepo -target \\wfilesrepo.file.core.windows.net\repo

as simple as that. i mamy katalog, który zachowuje się i wygląda (niemal) jak normalny katalog. nie trzeba już polis GPO ponieważ Windows już nie traktuje tego jako dysq sieciowego a zwykły katalog lokalny.

dodam do tego kilka uwag i ciekawostek:

  • taki symlink jest tylko wskazaniem. a to oznacza, że każdy oddzielnie musi mieć uprawnienia dostępu – to nie jest tak, że admin ma dostęp i podmapuje i każdy wlezie. trzeba więc odpowiednio posiedzieć nad uprawnieniami
  • standardowo uprawnieniami dostępu do Azure Files jest moduł IAM – to zresztą ogólna zasada. pojawia się tutaj problem nadania uprawnienia wszystkim – ponieważ nie nadamy na poziomie IAM uprawnienia dla 'authenticated users’. jest od jakiegoś czasu możliwość obejścia tego problemu, ustawiając atrybut ’defaultSharePermissions’ dla Storage Account.
  • ponieważ jest to link do sieci, jest problem z cache przy operacjach zapisu. zauważyłem, że czasem zapis jest odrzucany.
  • SymLink zachowuje się jak katalog… ale nie do końca. SymLink jako katalog odziedziczy uprawnienia z katalogu nadrzędnego, ale nawet jeśli jest włączona flaga dziedziczenia, nie do końca uprawnienia spływają poniżej. należy uważać i dobrze przetestować. najlepiej odpowiednio przygotować strukturę i wyłączyć dziedziczenie:
    \\wfilesrepo.file.core.windows.net\repo\wlasciwykatalog – i wyłączyć dziedziczenie na poziomie 'wlasiciwykatalog’
    albo
    c:\root\[repo] – gdzie [repo] to symlink – i wyłączyć dziedziczenie na poziomie 'root’…
    to problemu nie będzie. tylko jest wtedy bzdurny dodatkowy katalog /:
  • dodatkowy problem z uprawnieniami jaki zauważyłem, to fakt, że uprawnienia nadane dla grupy 'administrators’ bezpośrednio na file share, nie działają O_o . ogólnie: UWAGA NA UPRAWNIENIA, bo zachowują się dziwnie.
  • i jeszcze – jak takiego symlinka usunąć? najlepiej:
(get-item c:\symlink).delete()

mimo pewnych dziwnych zachowań sprawdza się fajnie a dla użytkowników wygląda i zachowuje się jak folder lokalny.

eN.

AzPseudoGUI – łatwiejsza praca z commandletami Az

trochę GUI dla commandline’a

pracując z linii poleceń braqje możliwości szybkiej weryfikacji nazw i list. ponieważ nie ma GUI, co chwile trzeba listować obiekty, wybierać odpowiednie właściwości (properites) i dopiero w ten sposób wykorzystać nazwę dalej. jest to denerwujące zwłaszcza w połowie pisania jakiegoś długiego oneliner’a i nagle 'o rety, ale jak była nazwa tej resorsgrupy?’ … i ctrl+c, listing wszystkich Resource Group i dopiero od nowa pisanie komendy…

żeby sobie ułatwić życie, oraz pisanie prostych skryptów, przydatny jest moduł AzPseugdoGUI, który obudowuje popularne funkcje Az i dodaje do niech out-gridView. w ten sposób, bez konieczności pamiętania nazw, często dość długich i pokrętnych można np.:

$ctx=select-subscription

co pozwoli wybrać konkretną subskrypcję i zwróci obecny kontext pracy, który można potem wykorzystać.

jak szybko wybrać maszynę wirtualną? po prostu

$vm=select-VM

za dużo maszyn w subskrypcji ale pamiętasz o którą resource group chodzi?

$vm=select-RG -isCritical | select-VM

ułatwia życie i nie trzeba ciągle sięgać do Azure Portal czy listować w kółko… moduł można łatwo zainstalować

install-module AzPseudoGUI

nowy destroy-AzureVM

wykorzystując ten moduł, poprawiłem destroy-AzureVM – który teraz również wykrywa backup maszyny i pozwala wybrać które zasoby mają zostać usunięte a które nie.

przy okazji ciekawostka:

  • W Azure (niemal) wszystko jest zasobem (resource) a dowolny zasób można usunąć uniwersalną funkcją 'remove-AzResource’.

to bardzo wygodnie i nawet złożone konstrukty takie, jak VM można potencjalnie usunąć jedną komendą… niestety zasobem (resource) nie jest kontener Storage Account. ale i tak można zoptymalizować skrypt, tworząc tabelę URI zasobów i wrzucając je do niszczarki:

foreach($resource in $resourcesForDeletion) {
    write-log "removing $resource" -type info
    $resourceSplited=$resource.split('/')
    try{
        remove-AzResource -ResourceID $resource -force
        write-log "$($resourceSplited[-2]): $($resourceSplited[-1]) removed." -type ok
    } catch { 
        write-log "error removing $($resourceSplited[-2]): $($resourceSplited[-1])." -type error
        write-log $_.exception -type error
    }
}
wygodne.
eN.

passwordless EXO connection

przeglądając ostatnio changelog dla commandletów ExchangeOnlineManagement znalazłem bardzo miłą informację.

po pierwsze w końcu PS dla EXO zaczyna się normalizować. po dziwnych zawirowaniach i wydania ExchangeOnline 1.0.1 określonej jako… V2, w końcu ktoś poszedł po rozum do głowy i dał i wersję 2.x . niby drobna rzecz, ale istotna, ze względu na przejrzystość.

ponadto, pomimo że GraphAPI dla EXO jeszcze nie ma, dostarczony został [trochę wydrutowany, ale zawsze] sposób, na bezhasłowe połączenie do konsoli. nie wymaga to zbyt dużo gimnastyki, a pozwala na tworzenie skryptów w trybie nienadzrorowanym [unattended].

eN.

MFA – dodatek czy konieczność?

zgodnie z zapowiedzią kolejny fragment arcyciekawego wywiadu z d0m3lem. to ważny temat, więc warto o nim porozmawiać…

Czy MFA jest ważne?

<MG> W kontekście architektury zabezpieczeń, chciałbym rozszerzyć to pytanie. W ogóle jakie są największe teraz wyzwania, z którymi mierzycie się w całej tej działce Identity? Czy to jest brak wiedzy? Czy jednak te ograniczenia technologiczne, czy ten dług technologiczny?

<d0m3l> Ludzie nie chcą korzystać z MFA.

<MG> Czyli jednak interface białkowy to jest największe wyzwanie?

[…]

<d0m3l> Tak, generalnie kwestia jest taka: Spytaliśmy naszych kolegów z Google’a, jaką mają adopcję MFA? Okazuje się, że w momencie, kiedy jesteś goniony przez atakujących, przez hackerów to jest tak, jak bycie gonionym przez stado wilków. Jak Cię gonią wilki to nie chodzi o to, żeby prześcignąć wilki. To chodzi o to, żeby prześcignąć najwolniejszego w tłumie. Więc w momencie, kiedy masz włączony SMS jako jedyne MFA na Twoim koncie, na Twojej usłudze, gdziekolwiek, to Cię broni przed 1oo% zautomatyzowanych ataków. Czyli jak jest scriptkidi albo narzędzia tych atakujących hackerskich grup narodowych takich jak Iran, Somalia, Nigeria, jest parę takich bardzo fajnych organizacji, które próbują się dostać do Twojej poczty. Jeżeli masz SMS jako jedyne MFA na swoim koncie, jakikolwiek skrypt, oprogramowanie jakie mają, żeby Cię zbruteforce’ować, zespray’ować jest zablokowane. Jeżeli targetują Ciebie, jako osobę koszt zhackowania Ciebie rośnie z 70 centów do 70 dolarów i udaje im się to w 40% przypadków.

<nExoR> To jeszcze tylko jedna rzecz apropos tego MFA i statystyk, chciałem zaznaczyć, że strasznie kłamiecie. Bo nie potraficie zliczać MFA wymuszonego Conditional Accessem, gdzie na przykład w firmach administratorzy to np. 2% w stosunku do użytkowników. Administratorzy mają wymuszone MFA, cała reszta, czyli 98% ma Conditional Accessem. Co mówi Microsoft? 98% ludzi nie ma włączonego MFA.

<d0m3l> W tej chwili z mogę Ci powiedzieć dokładnie ile jest ludzi, którzy mają MFA. To jest 33% użytkowników w Office 365 podało jakiś sposób weryfikacji, że można ich w jakiś sposób wymusić.

<nExoR> Czyli to jest nie na podstawie włączonej opcji, że musisz mieć MFA, tylko to jest na podstawie danych, które zostały podane do kont?

<d0m3l> Tak.

<nExoR> To jak jesteśmy przy tym od razu. Czy będzie jakaś usługa, jakiś sposób zabezpieczenia, bo jest taka dziura w MFA przy onboardingu. Bo jak założysz konto, włączysz MFA, masz provisioning użytkowników to nadal do kogo pierwszego trafią Credentiale, ten sobie MFA ustawia. No i teraz wiadomo, że jest jakiś duży procent użytkowników, którzy, no wiadomo są takie cienie, ktoś nigdy nie przyszedł do pracy albo nie używa konta i one sobie wiszą. Jak zhackujesz takie konto to od razu sobie ustawiasz MFA, i jest jakby podwójnie uwierzytelniony w tej domenie i przez to jeszcze bardziej zhackowany. Czy tutaj można się spodziewać jakiegoś wyjścia naprzeciw? […]

<d0m3l> Generalnie są 2 sposoby. Sposób proceduralny i sposób technologiczny. Sposób proceduralny, pomijanie MFA ze względu na lokalizację, jedno z najgorszych zaleceń, jakie Microsoft kiedykolwiek wydał. MFA  powinno być też wymuszone w Corpnecie. MFA musisz zrobić zawsze. Jeden prompt per użytkownik, per urządzenie, per zmiana hasła, koniec kropka. To, że spiąłeś się VPNem nie powinno Cię wykluczać z wymagania MFA. To jest Zero Trust. To jest proceduralnie. Drugi to jest taki, że jest funkcjonalność w Conditional Accessie, która mówi, że żeby się zenrollować do MFA musisz spełniać wymagania. Jest takie coś, co nazywa się User Actions jako warunek w Conditional Accessie, gdzie możesz powiedzieć: “Żeby zenrollować się do MFA musisz być na urządzeniu, które uważam za zaufane” albo “Musisz być w konkretnym zakresie adresów IP”.

<nExoR> Zakresy IP to w ogóle są trochę od czapy te polityki z zakresami IP, bo połowa firm używa Proxy, Application Proxy czy innych mechanizmów przekierowujących ruch i wychodzenie ze stałego IP, zwłaszcza w świecie mobilnym, to jest w ogóle jakieś nieporozumienie.

<d0m3l> Kwestia jest taka, że nie ma wystarczającej ilości technologii na świecie, żeby naprawić gówniane procesy. Nie ma. Jeżeli Twój proces jest niewystarczający to możesz się bawić w hocki-klocki. Takie podatności o jakich Ty mówisz, że hacker albo zły aktor dostanie się i uwierzytelni zamiast użytkownika zdarzają się 2 w miesiącu na całą skalę Office 365. Na 320 milionów użytkowników. 2 w miesiącu. Oba z nich są łapane przez zwykłych użytkowników, którzy zostają wykopani z konta w momencie, kiedy ktoś zamiast nich dokona poświadczenia. Więc takie reaktywne wyłapywanie działa bardzo dobrze pod warunkiem, że nie masz wykluczeń MFA. Okazuje się, że najbardziej popularną polityką Conditional Access jaka istnieje jest: MFA dla wszystkich, poza zaufaną lokalizacją, czyli jeżeli jesteś na Cornplecie albo na Wi-Fi, żadnego MFA. Czyli Pani Józia, która siedzi w biurze i nigdy nie dostaje się do maila poza biurem, nigdy tego MFA nie zobaczy.

<nExoR> Tak, no wtedy go nigdy nie skonfiguruje, czyli jest niebezpieczne. No właśnie, czyli to taki drugi scenariusz.

<d0m3l> Dlatego jeżeli zły aktor dostanie hasło i spróbuje zrobić zarejestrowanie tego MFA, możesz to Conditional Accessem ograniczyć. Mówisz, że ktoś, kto ma hasło Pani Józi, żeby zarejestrować jej MFA musi być na urządzeniu, które jest dopięte do naszej domeny, musi być Hybrid Joined. I tyle.

[…]

<d0m3l> MFA musi być włączone zawsze. Ten link, który pokazałem, M365 Golden Config. Użytkownik przychodzi pierwszego dnia w pracy. Tego pierwszego dnia w pracy użytkownik musi potwierdzić, że ma dostęp do jakiegoś MFA. Problemem zaczyna się robić wdrożenie gdzie masz 23.ooo użytkowników, którzy jeszcze nie podali danych. MFA ma 1o% Faliure Rate przy rejestracji. 1o% użytkowników będzie Ci krzyczało, że nie umieją zeskanować kodu QR na ekranie.

[…]

<MG> Czy MFA jest, zadam takie pytanie znowu z wyższego poziomu, czy MFA jest idealnym zabezpieczeniem? Jak nie, to czego mu brakuje?

[…]

<d0m3l> Powiem tak: Grzesiek pytał o te statystyki Googlowe. Statystyki są prosto z konferencji, która nazywa się “Stripe”. Google mówił, że jedyne idioto-odporne, bo MFA da się zfishować. Fishing, czyli ktoś wysyła Ci maila, klikasz link i podajesz Twój login, hasło i MFA. MFA da się zrobić fish. Bez problemu, potem mam dostęp do Twojej poczty forever and ever, dopóki nie zmienisz swojego hasła. Jedyny sposób, który takiemu atakowi zapobiegnie to używanie metod poświadczeń, które są oparte o sprzęt. Czyli: Hello for Businnes – niefishowalny, Tokeny FIDO – niefishowalne. Dlatego, w momencie kiedy masz hasło i coś po haśle dopóty, dopóki to będzie aktywnym MFA, dopóty będziesz miał możliwość, że ktoś je zhackuje. Do wtedy, gdy będziesz klikał w te linki fishingowe. Nie da się zrobić, żeby mniej niż 20% Twoich użytkowników klikało w linki fishingowe. Możesz robić banery, ostrzeżenia itd.., 2o% ludzi kliknie w link, który się im pojawi w skrzynce odbiorczej. SANS Institute zrobił badania. 2o% to jest podłoga. W Microsofcie 35% ludzi jest fishowalnych, wewnętrznie u nas w firmie, bo jesteśmy przyklejeni do maila 24/7. 35% ostatnia kampania wewnętrzna fishingowa, testowa.

<MG> Czyli trzeba ogólnie całkowicie ominąć możliwość tego fisha, czyli tak, jak mówiłeś, Tokeny FIDO na przykład.

<A> Ale pamiętaj, że jeszcze masz drugą możliwość, czyli na przykład “o, tu jest taka fakturka”; “Ty, słuchaj, nie chce mi się w niczym otworzyć, zobacz co to”.

<d0m3l>     No. „Każdy burdel da się ogarnąć, tylko proszę dane do faktury”, nie? Ale to już jest chyba trochę taki Social Engeneering, prawda?

End Of Quote

oryginał rozmowy tutaj.

o ważności MFA jestem świadom i zawsze jest to pierwsza rzecz jaką sprawdzam – czy jest włączone. muszę przyznać, że zezwolenie na brak MFA kiedy się jest w biurze wydawało mi się zawsze dobrym pomysłem. teraz nie jestem już taki pewien (; pozostawiam do oceny czytelnikom.

eN.

czy Microsoft słucha użytkowników?

pasjonaci IT

nie tak dawno zapraszałem na spotkanie z Danielem Stefaniakiem, IAM Product Manager w Microsoft, pracującym w samym sercu tego, gdzie powstają usługi M365 – w Redmond. pełne nagranie z tego spotkania można obejrzeć na YT na kanale „Pasjonaci IT” . ilość wiedzy jaka posypała się podczas tych 1,5h okazała się olbrzymia. ponieważ nie każdy lubi słuchać, niektórzy nadal lubią czytać – zamieszczę kilka ważnych informacji jakie padły podczas tej rozmowy. dziś na smaka wrzucę fragment dotyczący User Voice – czy to tylko taki 'anti-stress button’ żeby ludzi mogli wylać swoje frustracje, czy faktycznie Microsoft przygląda się tym wpisom, analizuje i zmienia swoje plany?

poniżej fragment transkryptu, który może być nieco zmodyfikowany dla wygody czytania.

UserVoice

  • <nExoR>   […] to ciekawe, co powiedziałeś. Wiem, że uservoice funkcjonuje całkiem fajnie od jakiegoś czasu, natomiast jak to realnie wygląda procentowo? No bo uservoice – uservoice’em, natomiast musi być jakaś road mapa odgórna. czy jesteś w stanie określić na ile procentowo jest to uservoice, na ile odgórne ustalenia? np. uservoice to jest 15% całego rozwoju, a 85% to jest roadmapa, czy może jest odwrotnie, że właśnie 15% to jest jakaś odgórna wizja, a 85% to jest to, co ludzie chcą? Jak byś to mniej więcej określił?
  • <d0m3l>  W mojej działce, w Azure Active Directory [IAM], uservoice to jest około 15 – 2o% . Tak naprawdę chodzi o to, że w tej chwili Azure AD to jest system, który wiezie ze sobą 32o milionów użytkowników codziennie, więc to nie jest taki stateczek, który da się zawrócić z dnia na dzień. Więc w tej chwili korzystamy z uservoice’ów, albo z pracy z największymi klientami z Fortune 5oo, którzy na nas krzyczą: “Dlaczego to, kurka, tak nie działa? Bo próbuję zrobić XYZ, ale Wy mi nie dajecie takiej możliwości”. więc szturchamy na prawo i lewo, żeby ten stateczek popłynął tam, gdzie klienci będą chcieli na niego wsiąść, bo na pewno nie stoi w miejscu. Więc z uservoice te rzeczy, które mają powyżej 1oo głosów, czy tam 15o, muszą być wciśnięte w road mapę na najbliższe 12 miesięcy. Nasza Pani Vice President powiedziała, że tak ma być, koniec kropka: „Właściciele funkcjonalności wymyślcie, jak zaadresować uservoice’a”.
  • <MG>        1oo – 15o głosów to nie jest taki duży próg…
  • <domel>     W Azure AD to jest bardzo wysoki próg.
  • <nExoR>   Naprawdę? Tak mało jest uservoice’ów?
  • <domel>     Tak. Największy uservoice ma 13oo głosów.
  • <nExoR>   I na co jest?
  • <domel>     Rozdzielenie albo połączenie Microsoft Account i kont Azure AD. Bo, jak pamiętacie LifeID rozdzieliło się od Office 365 w jednym momencie i teraz się okazuje, że  jak masz LifeID i konto w Office 365 na ten sam adres e-mail to masz ten głupi label pod tytułem “konto organizacyjne vs. konto prywatne“, więc ludzie na to bluzgają strasznie. Drugi w tej chwili to jest chyba cel w Service Password Reset bez dostępu do kontrolera domeny, więc to są dwa takie największe. Teamsy mają dziesiątki tysięcy uservoice’ów [bo to frontend’owa aplikacja]

End of Quote

swoją drogą sprawdziłem i są jeszcze dwa requesty:

  • nested groups: ~18oo głosów
  • tokeny B2C zawierające członkostwo użytkownika: ~15oo głosów

i to faktycznie max. a Top Ideas dla Teams ma ponad 55k. to pokazuje, różnicę backend vs frontend q:

w świetnym dziele filozoficznym, post-humanistycznym „Po piśmie„, Jacek Dukaj pokazuje jak zmieniała się ludzkość na przestrzeni dziejów – z kultury mówionej, teraz przez literacką… a w przyszłości w przekaz natychmiastowy. ludzie już dziś wolą obejrzeć niż przeczytać, podcasty i filmy zastępują książki, video zastępuje instrukcje i poradniki…

jestem dinozaurem – ja wolę czytać. albo może to technologia jeszcze nie dorosła po prostu – bo jak wyszukać jakiś interesujący fragment? jak wyszukać interesującą frazę w 1,5h materiale? albo jak 'przelecieć wzrokiem’ video? czasem mniej ciekawe fragmenty artu można po prostu szybko ominąć, przy video trudniej. dla tego  w najbliższych dniach dodam jeszcze trochę fajnych informacji z naszej rozmowy – bo czasem tygodnie, a nawet miesiące surfowania, nie dadzą takich wyniqw.

d0m3lu – dzięki [twoje konto cały czas jeszcze jest na w-files q: ]

eN.

M365 jako platforma – inna perspektywa

kolejne spojrzenie na 'platformę’ – w dwóch kontekstach. po pierwsze – bezpieczeństwo, po drugie – konsekwencje 'on-premowego myślenia’. w sumie to odwrotnie, bo zaniechania z w prawidłowej konfiguracji bezpieczeństwa wynikają głównie z faktu, że M365 nie jest prawidłowo rozumiane. bo cały czas poqtuje 'stare myślenie’. taka oto anegdota [prawdziwa], która powinna dobrze zobrazować, co mam na myśli…

dzień dobry, my po Teamsy….

niedawno, po wybuchu pandemii, duża firma postanowiła zwiększyć możliwości pracy z domu [#WFH]. więc firma chce wdrożyć Microsoft Teams. *tylko* Teams…

[parafrazując] „no bo przecież takie Teamsy, to zainstaluje się i już – ludzie mogą sobie korzystać. mamy jakieś licencje i to w ramach EA nawet O365 E3 i to całkiem sporo. nie chcemy od razu dla wszystkich tylko małymi kroczkami – odpalimy dla np. 5o osób jako PoC a potem dla reszty organizacji. a jakieś dodatki typu skrzynki czy OneDrive to może potem. na razie chcemy szybko [i tanio], żeby skorzystać z możliwości tej wspaniałej pracy grupowej, jaką daje Teams”…

khmmm… no i to takie „onpremowe myślenie”. zupełnie wszystko do góry nogami. jeśli nie wiecie o czym mówię – to znaczy, że jeszcze musicie się w M365 wgryźć… jakie błędy zostały popełnione w tym rozumowaniu? zadajmy klientowi kilka pytań i co się okaże:

  • jest już AD. oczywiście powinno być SSO, a w przyszłości bardziej wykorzystać usługę. czyli trzeba zacząć od zaprojektowania tożsamości hybrydowej, synchronizacji, określić zasady synchronizacji – nawet jeśli początkowo synchronizowałoby się tylko kilka osób, to trzeba zrobić pełny projekt. firma niemała, AD niemałe, a wiadomo – jak się zajrzy do szafy [AD] to zaczną trupy wypadać [cała historia i nakładające się modele zarządzania]. trzeba jakieś serwery dla ADConnect postawić, redundancja, ustalić metodę uwierzytelnienia – w końcu to ma być produkcja, jak się źle poustala, to potem będzie ciężko to zmieniać… to tak w ramach rozgrzewki…
  • jest Exchange on-premise. ale Teams korzysta ze skrzynek pocztowych. nie dość, że trochę ciężko przewidzieć co by się stało jak by to tak po prostu rozdzielnie potraktować [znaczy duplicate-mailbox by się stało], ale klient wspomniał, że będzie raczej chciał usługę mocniej utylizować w przyszłości. a to oznacza hybrydę Exchange – i znów projekt i DNSy i mailflow i reguły na FW itd….
  • jest oczywiście i SfB on-premise… czyli musi być współdzielony SIP domain, hybryda SfB … i znów – trzeba to zaprojektować, wdrożyć ….
  • przetwarzane są informacje wrażliwe a firma podlega licznym normom i wymaganiom bezpieczeństwa – a więc trzeba skonfigurować polityki bezpieczeństwa dla wszystkich komponentów, ustalić co użytkownicy mogą a czego nie mogą … o tym więcej za chwilę, ale już widać – że to nie zadanie na 5 minut tylko ciężki projekt.

w dużym skrócie – nie ma pojęcia 'tylko Teamsy’… no ok, da się 'tylko Teamsy’. można wdrożyć na szybko tenant M365, zostać przy domenie *.onmicrosoft.com i sobie z Teamsów korzystać od razu. ale nie ma mowy o integracji, nie ma mowy o tym, żeby to post factum łączyć ze środowiskiem on-premise [technicznie się da, ale czas i koszty…], funkcjonalność będzie ograniczona, no i tak czy inaczej – trzeba to przecież zabezpieczyć… ma być zgodność z normami i bezpieczeństwo – a gdzie licencje EMS? a to będzie kosztowało …. w sumie to bez różnicy bo kwota już i tak przekroczyła jakiekolwiek wyobrażenia wstępne – coś co miało być szybkim wdrożeniem dla 5o osób okazuje się olbrzymim projektem – być może na długie miesiące. o kwotach nawet nie wspominam.

to tylko skrzynki Exchange

o bezpieczeństwie myślą niby wszyscy, niektórzy próbują, ale niewiele osób ma pojęcie co to w ogóle znaczy 'bezpieczeństwo M365′. może inna anegdota, tym razem mniejsza firma, ale schemat [czy raczej końcowy efekt], który obserwuję bez względu na wielkość firmy:

„mamy pocztę w takim to serwisie, i kupiliśmy licencje o365 i będziemy migrować”

„a bezpieczeństwo? macie jakiś projekt/pomysł jak to zabezpieczyć?”

„ale to tylko skrzyneczki”

czy aby na pewno? najbardziej oczywistym elementem, który pewnie każdy wskaże – jest tożsamość. w rozwiązaniach Chmury publicznej bezpieczeństwo sqpia się głównie na tożsamości [i danych]. w nazwie 'Chmura Publiczna’ dość kluczowe jest słowo 'Publiczna’. każdy – skądkolwiek na świecie, może próbować się logować, atakować konta itd. ale to dopiero początek… o czym [z przerażeniem zauważam] się zapomina. przecież wystarczy pojedyncza licencja, choćby trial, choćby wygasła dawno temu – ale jeśli była, to uruchamiane zostały w ramach M365 usługi, które objęte są/były licencją! to że licencje wygasły – nie wyłącza usług w ramach tenanta – co najwyżej z usługi nie da się w pełni korzystać, ale ona działa. to, że firma chce 'tylko skrzyneczki’, nie oznacza, że cała reszta nie istnieje. to nie jest onprem – w którym stawiamy sobie Exchange, a reszty nie ma, bo jeszcze nie zdecydowaliśmy czy instalować serwer SharePoint – te usługi są, działają, mają jakieś ustawienia wyjściowe, są dostępne – czyt. można próbować się do nich dostać. i nie mówię tylko o próbach włamania. zauważyłem, że powszechną praktyką jest przypisywanie użytkownikom pełnych licencji, bez wyłączania planów serwisowych – nawet jeśli firma jeszcze nie planowała z nich korzystać. a to oznacza, że użytkownicy mogą korzystać z pozostałych usług i zrobić sobie krzywdę. czy też firmie. np. przypadkiem udostępniając plik z danymi wrażliwymi, lub w ramach zabawy i nauki ustawić jakiś konektor, który automatycznie gdzieś tam wysyła maile czy kopiuje pliki…

a tych usług jest dużo: OneDrive, SharePoint, Teams, same grupy M365, co za tym idzie wieloraka możliwość współdzielenie plików na zewnątrz, możliwość dodawania dowolnych konektorów – i w Outlook i w Teams i w … można by tak wymieniać a szczegółów jest dużo.

a całe środowisko M365 projektowane jest przez DevOpsów tak, aby zaspakajać ich potrzeby. czyli wszycy-wszytko-wszytkim-zawsze-wszędzie-proszęBardzo. zupełnie jak na tych teaserach reklamowych Microsoft Teams – gdzie wszyscy są kreatywni, wszyscy piękni, młodzi i ambitni i świetnie adaptują te nowe super technologie. taaa… i rozgrzeszenie i życie wieczne za darmo, przy wyqpieniu Software Assurance.

życie zazwyczaj wygląda nieco odmiennie. dla tego…

ZABEZPIECZ SWOJE M365 KOMPLEKSOWO i AUDYTUJ

nie ma że 'tylko skrzyneczki’ czy 'tylko Teams’. trzeba wdrożyć minimum bezpieczeństwa dla *całego tenanta* – czyli wszystkich usług, bez względu no to czy dziś chcemy z nich korzystać. tym bardziej, że jest bardzo wiele elementów, związanych bezpośrednio z AAD i o365, które są dla wszystkich – a [prawie] nikt i tak tego nie konfiguruje zostawiając ustawienia wyjściowe, które są [za]bardzo liberalne. do tego trzeba pamiętać, że Chmura to nie jest 'produkt w wersji X’ – to jest dynamicznie rozwijające się środowisko. dla tego nie wystarczy 'zabezpieczyć’ – trzeba robić przeglądy, sprawdzać jakie nowe aplikacje się pojawiły, jakie dodatki – bo za chwilę pojawi się kolejna nowa aplikacja, która wymaga znów przyjrzenia się jej możliwościom i bezpieczeństwu, ocenić czy użytkownicy będą z niej korzystać i w jaki sposób i zaplanować co z nią zrobić i jak skonfigurować – bo wbrew dość powszechnej opinii – SaaS wcale nie oznacza, że tam się nic nie konfiguruje, czy że wszystko jest od razu bezpieczne.

jeśli myślisz poważnie o bezpieczeństwie a twoja firma musi być zgodna z normami – pomyśl od razu o licencjach EMS, M365sec, albo przynajmniej Business Premium dla mniejszych.

a po wiedzę – cóż, trzeba zgłosić się do odpowiednich konsultantów (:

eN.