Do Not Forward – czy to działa?

sie 4, 2026nExoRExOnline, security, tips'n'tricks

Problem

W Microsoft Purview, można zdefiniować Sensitivity Label 'Do Not Forward’. Potencjalnie bardzo fajna opcja do zabezpieczenia maila
Problem polega na tym, że jeśli w mailu jest plik, to zależnie od tego czy odbiorca ma konto pocztowe 3rd party czy M365 – osoba będzie w stanie plik otworzyć lub nie… i poszkodowana jest osoba posiadająca konto M365!

Wewnętrznie na EXO istnieją dwa workflowy:

OTP, dla kont, które nie są RMS-aware (3rd party), klient dostaje link 'pobierz kod’, kod przychodzi na zadeklarowany email i dzięki temu osoba ma dostęp do maila oraz pliku.
RMS-aware czyli M365. Microsoft chwali się, że usługa działa cross-tenant… ALE – musi być ALE.

Tutaj link opisujący cross-tenant: Microsoft Entra configuration for content encrypted by Microsoft Purview Information Protection | Microsoft Learn . W praktyce działa to tak (zakładając default configuration), że wiadomość 'Do Not Forward’ faktycznie można odczytać beż żadnych kodów przez posiadacza skrzynki EXO. Ale pliku nie da się otworzyć w żaden sposób… chyba, że zrobimy to tak, jak pisze MS:

”

For external users who have a Microsoft Entra account in their own tenant, we recommend you use External Identities cross-tenant access settings to configure trust settings for MFA claims from one, many, or all external Microsoft Entra organizations.
For external users not covered by the previous entry, for example, users who don’t have a Microsoft Entra account or you haven’t configured cross-tenant access settings for trust settings, these external users must have a guest account in your tenant.

”

…i cały wspaniały plan łatwego dostarczenia rozwiązania szyfrującego idzie w diabły. Bo kto będzie wszystkim ludziom zakładał konta gości? nie tak miała ta usługa ułatwiać życie – no i co za absurd, że użytkownicy nie-M365 mogą się dostać a M365 nie mogą.

Ale oczywiście nie pisałbym, gdyby nie dało się tego obejść…

Rozwiązanie

Okazuje się, że tym szablonem można zarządzać. Wybiera go Purview, które na ostatnim etapie mail flow, dodaje własne reguły transportowe (niewidoczne) – jeśli email ma jakieś Sensitivity Labels, to usługa dokona odpowiednich modyfikacji, sprawdza typ routingu i wybierze szablon – inny dla EXO, inny dla 3rd party. Tutaj nie da się nic zrobić, ponieważ całość jest black-box.

Ale da się:

Stworzyć label o jakiejś nazwie – np. 'Secure Email’, który nic nie robi poza oflagowaniem maila
ustawić dwie reguły transportowe na EXO – dla maila z i bez załącznika – dla tej etykiety

W efekcie mamy takie scenariusze dla maila z Do Not Forward (Secure Email):

do użytkownika non-M365 z lub bez załącznika: użyj szablonu OTP
do użytkownika M365 z załącznikiem: użyj szablonu OTP (inaczej nie ma szansy podejrzeć pliku)
do użytkownika M365 bez załącznika: użyj cross-tenant RMS, bo wiadomość się wyświetli

te reguły to:

New-TransportRule `
    -Name "Label secure external mail - Do Not Forward via OME portal" `
    -FromScope "InOrganization" `
    -SentToScope "NotInOrganization" `
    -HeaderContainsMessageHeader "msip_labels" `
    -HeaderContainsWords "MSIP_Label_<LABEL GUID>_Enabled=True" `
    -ApplyRightsProtectionTemplate "Do Not Forward" `
    -ApplyRightsProtectionCustomizationTemplate "OME Configuration"

New-TransportRule `
    -Name "Secure Email external WITHOUT business attachment - DNF native" `
    -FromScope "InOrganization" `
    -SentToScope "NotInOrganization" `
    -HeaderContainsMessageHeader "msip_labels" `
    -HeaderContainsWords "MSIP_Label_<LABEL GUID>_Enabled=True" `
    -ApplyRightsProtectionTemplate "Do Not Forward"

Żeby zdobyć GUID najlepiej użyć get-label, tylko najpierw trzeba się połczyć connect-iPPSSession.

> connect-iPPSSession -UserPrincipalName nexor@w-files.pl
> get-label|select name,guid
[...]

A jeśli ktoś byłby chętny modyfikować szablon [OTP/native, disclaimers, images…] to jest to szablon 'OME Configuration’:

> get-oMEConfiguration|fl

TemplateName : OME Configuration
Image :
ImageUrl :
EmailText :
PortalText :
DisclaimerText :
BackgroundColor :
IntroductionText :
ReadButtonText :
OTPEnabled : True
SocialIdSignIn : True
ExternalMailExpiryInterval : 00:00:00
PrivacyStatementUrl :
Identity : OME Configuration
IsValid : True
ObjectState : Unchanged

I ten właśnie default jest użyty w pierwszej regule, z parametrem 'OTPEnabled: True’.

Rebranding a nazwa usługi

To jedna z tych usług w stajni Microsoft, która po pierwsze od zawsze jest zaniedbana, i jak gorący kartofel – przechodzi rebranding co kilka lat. A podstawowe funkcjonalności – jak widać w tym scenariuszu – są często zaparkowane na zawsze. Po raz pierwszy wdrażałem RMS na Server 2oo8 – właśnie mniej-więcej w roku wydania serwera. Niemal dwie dekady, a usługa cały czas boryka się z tym samym problemem – fajnie działa w obiegu firmowym, zamkniętym, gorzej z zastosowaniem powszechnym, tzw. publicznym Internecie. A co najciekawsze to zasadniczo wszystko działa i wszystkie elementy układanki są dostępne… tylko MS z jakiegoś powodu wymyślił 'zakładajcie wszystkim konta gości’ zamiast pójść po rozum i zmienić workflow /:

Co do historii nazw:

Rok	Nazwa
2003	Windows Rights Management Services (RMS)
2008	Active Directory Rights Management Services (AD RMS)
~2013	Azure Rights Management (Azure RMS)
~2015-2019	Azure Information Protection (AIP)
~2019-2021	Microsoft Information Protection (MIP)
obecnie	Microsoft Purview Information Protection (MPIP)

I na wszystkie te nazwy można cały czas natrafić podczas korzystania z produktu – np. do otwarcia zaszyfrowanego pliku należy zainstalować RMS Client – pewnie ze względu na to, iż tak cały czas nazywa się w środowisku on-premises, na Server 2o25. W chmurze natomiast czas nie stoi – dla tego dziś mówimy o Purview i Sensitivity Labels…

A więc zasadniczo, na dzień dzisiejszy: MPIP – Microsoft Purview Information Protection, korzystający z RMS do szyfrowania plików.

AI nie pomogło

Takie problemy to dobry benchmark AI – tutaj nie pomogło. Nie znalazłem rozwiązania wyszukiwarką, a AI, jak się okazało, nie było w stanie samodzielnie 'rozumować’ – skoro nie znalazło tekstu, to 'nie wymyśliło’ rozwiązania. Udało mi się przygotować to rozwiązanie tylko dla tego, że pracując tyle z Ex/EXO po prostu wiedziałem czego szukać i po kilku próbach udało się wydziargać rozwiązanie…

eN.

disable-eNAuditorperUserMFA – jak pozbyć się per-user MFA

cze 2, 2025nExoRDevOps/Scripting

„per-user MFA” czyli najstarsza z metod MFA, jest coraz bardziej odstawiana na bok. nie ma póki co mowy o tym, żeby była zupełnie wyłączona, ale od 3o Października na pewno będzie jeszcze mniej przydatna, ponieważ pierwotne polisy SSPR oraz MFA zostają wycofane.

po wykonaniu migracji per-user MFA jest oczywiście cały czas dostępny, jednak metody MFA zarządzane są już (w końcu!) z jednego miejsca:

z SSPR nadal jest pewien babol, związany z hasłami i mailem… ale to oddzielny temat.

czy należy się bać migracji do nowego MFA?

raczej nie. jeśli po prostu zaakceptuje się kolejne ekrany procesu, włączone zostaną wszystkie metody MFA, cały proces pozostanie przeźroczysty dla użytkownika końcowego.

ALE…

jest to IMHO świetny moment, aby zrobić trochę więcej niż tylko przeklikać się przez kilka stron wizarda na standardowych ustawieniach. warto faktycznie opracować polityki metod MFA, pozbyć się wszystkich per-user MFA oraz wymusić rejestrację. „kampania rejestracji” jest mniej znaną funkcją, z obserwacji większość firm zostawia te polityki nieskonfigurowane, a to ma ciekawe zastosowanie. i konsekwencje.

wyłączanie per-user MFA

jednym z dość częstych błędów, które widzę, to mieszanie per-user MFA z Conditional Access, wynikający głównie z braku zrozumienia że są różne metody MFA (do niedawna było ich więcej, pow0li zaczyna się unifikować). oczywiście aby wyłączyć per-user MFA zupełnie, należy w pierwszej kolejności upewnić się, że mamy odpowiedni poziom licencjonowania. choć wystarczy pojedyncza licencja aby móc zacząć korzystać z Conditional Access, każde konto powinno mieć licencję. jeśli ktoś korzysta z Security Defaults, to tworzona polityka CA obejmuje wyłącznie konta posiadające odpowiednią licencję, a w takim przypadku model mieszany jest niezbędny.

w dużej ogólności należy pamiętać, iż

per-user MFA ma priorytet i nawet dla osób z licencją i objętych Conditional Access, jeśli skonfigurowane jest per-user MFA, będzie wygrywało

co prowadzi do dziwnych zachowań, może wydawać się, że polityki nie działają.

w module eNAuditor jest funkcja, która pozwala wyłączyć per-user MFA dla pojedynczego obiektu lub dla całego tenanta – wygodne przy przejściu na model CA, np. po zakupie większej ilości licencji:

#disable for a single user with <userID>
disable-eNAuditorperUserMFA -userId <userID> -forceReconnect

#disable for a whole tenant
disable-eNAuditorperUserMFA

flaga 'forceReconnect’ przydaje się do wyczyszczenia kontekstu lub uzupełnienia go o odpowiednie uprawenienia.

kampania rejestracji

fajna funkcja pozwalająca na uzupełnienie CA. możemy pozwolić użytkownikom na korzystanie z różnych metod – np. aplikacja oraz SMS, ale chcemy aby każdy miał aplikację skonfgurowaną obowiązkowo oraz jako podstawową metodę. wtedy możemy uruchomić kampanię rejestracyjną oraz wymuszenie:

standardowe ustawienie to „Microsoft Managed” czyli „nie znasz dnia ani godziny”… osobiście nie lubię takich ustawień. włączenie kampanii wymusi wizarda MFA na wszystkich użytkownikach – nawet tych, którzy mają odpowiednią metodę skonfigurowaną. po prostu będą musieli przejść „pustego” wizarda.

należy jednak przy tym ustawieniu uważać, ponieważ może doprowadzić do pętli na kontach, które wymagają nietypowego ustawienia. np: mamy konta administracyjne czy breakglass, konta usług etc – takie, które są do użytku kilku osób, a zatem mają nie aplikację, tylko kod z password managera (konto breakglass nie powinno mieć MFA w ogóle, dłuuuuugie, złożone hasło). w takim przypadku można wpaść w pętlę. long story short – nie zapomnij zrobić odpowiednich wyjątków od rejestracji, żeby nie zrobić sobie krzywdy.

ogólnie jest to ustawienie bardzo przydatne i pozwala na wymuszenie minimum, ale bądź ostrożny! przypomnę jeszcze, że jeśli korzystasz z EAM, to masz problem.

eN.

mordęga z MgGraph (get-eNAuditorBasicSecurityInfo, show-eNAuditorScopes)

maj 19, 2025nExoRCloud, DevOps/Scripting, w-files

dziś dwie malutkie funkcje, które dodałem ostatnio, żeby pomóc sobie w wykonywanym zadaniu oraz w pracy z GraphAPI. o ile działanie samych skryptów jest średnio ciekawe i robią stosunkowo niewiele, posłużą do komentarza na temat pracy z Graph.

funkcja 'get-eNAuditorBasicSecurityInfo’ miała pomóc mi zebranie informacji z ok. 3o tenantów, dotyczących tego jak są w tej chwili zabezpieczane, poprzez sprawdzenie czy jest licencja EID P1/P2 oraz czy włączone są Security Defaults. tylko tyle, ale z punktu widzenia zapytania 'aż tyle’ – ze względu na to ile dwa proste commandlety wymagają zakresów (scopes) podczas autoryzacji. ilość jest absurdalna, ale o tym za chwilę. skrypt po prostu zwraca np coś takiego:

C:\temp :))o- get-eNAuditorBasicSecurityInfo
Tenant name: W-Files
deault domain: W-Files.pl
EID Plan: AAD_PREMIUM_P2, AAD_PREMIUM
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy_Get: You cannot perform the requested operation, required scopes are missing in the token. Status: 403 (Forbidden)
ErrorCode: AccessDenied Date: 2025-05-19T17:26:18 Headers: Cache-Control : no-cache Vary
: Accept-Encoding Strict-Transport-Security : max-age=31536000 request-id :
23232323-2155-40bb-8b55-73dd81b18a15 client-request-id : 23232323-0f82-457a-b671-ce55695f552f
x-ms-ags-diagnostic : {"ServerInfo":{"DataCenter":"Canada
Central","Slice":"E","Ring":"3","ScaleUnit":"000","RoleInstance":"TO1PEPF00009BE7"}} Date :
Mon, 19 May 2025 17:26:17 GMT

Recommendation: See service error codes: https://learn.microsoft.com/graph/errors
Security defaults are DISABLED
done.

skąd ten błąd? ano dla tego, że w obecnym kontekście nie mam odpowiedniego zakresu. a skąd mam wiedzieć, przed połączeniem się do tenanta, o jakie zakresy mam prosić?

scopes

zakresy to prawdziwe piekło. ciekawą propozycję odpowiedzi można znaleźć w artykule Get started with the Microsoft Graph PowerShell SDK gdzie wykorzystuje się Find-MgGraphCommand. Każdy commadlet Graph potrafi pokazać jakie uprawnienia są mu potrzebne… teoretycznie. tutaj będę korzystał ze swojej funkcji:

show-eNAuditorScopes -FunctionName Get-MgSubscribedSku

Name IsAdmin Description FullDescription
---- ------- ----------- ---------------
Organization.Read.All False Read organization information Allows the app to read the organization and…
Organization.ReadWrite.All False Read and write organization information Allows the app to read and write the organi…
Directory.ReadWrite.All False Read and write directory data Allows the app to read and write data in yo…
Directory.Read.All False Read directory data Allows the app to read data in your organiz…

super. tylko:

Read jest podzbiorem ReadWrite. a więc czy mam zażądać obu czy wystarczy RW?
dlaczego w poleceniu Get, które nic nie zapisuje, wymagane jest RW?

po sprawdzeniu w praktyce:

C:\_ScriptZ :))o-  connect-mggraph -scopes "Organization.Read.All" -NoWelcome

C:\_ScriptZ :))o- Get-MgSubscribedSku -all

Id AccountId AccountName
-- --------- --------
23232323-4563-43cf-ad1e-232323232323_1e615a51-59db-4807-9957-232323232323 8fc43c60-4563-43cf-ad1e-232323232323 w-files
[...]

działa. czyli stawiam tymczasową tezę:

wcale nie jest potrzebny Write, wystarczy Read
nie potrzebne są wszystkie – z wymienionych wystarczył jeden zakresy

…ale to jeszcze nie koniec. w odkrywaniu od strony praktycznej jest jeszcze kilak innych utrudnień, zniekształcających obraz – cache oraz zgody (consents) wydane w przeszłości. zróbmy taki test, zaraz po wydaniu tego polecenia:

C:\temp :))o- (get-mgcontext).Scopes
AuditLog.Read.All
Directory.AccessAsUser.All
Directory.Read.All
Directory.ReadWrite.All
Domain.Read.All
email
Group.ReadWrite.All
openid
Organization.Read.All
Policy.ReadWrite.AuthenticationMethod
profile
RoleManagement.Read.Directory
User.Read.All
User.ReadWrite.All
UserAuthenticationMethod.Read.All

hmmm.. co tu się zadziało? poprosiłem o jednego Read a dostaję cały kubeł uprawnień, również ReadWrite? skąd to? wedle artykułu na Practical365 podczas zapytania, automatyczne są dodawane uprawnienia, na które daliśmy consent w przeszłości. ile jeszcze jest takich króczków i niuansów – nie wiem, ale jest to potwornie trudne w ustalaniu.

drugi sposób ustalania wymaganych scope jaki stosuję, to podejrzenie jakie są wysyłane w zapytaniu, i utrwalam to w skrypcie. dla tego funkcja 'show-eNAuditorScopes’ posiada parametr 'url’, żeby szybko dokonać ekstrakcji zakresów z zapytania URL wywoływanego podczas wykonania polecenia (copy-paste z paska URL wyszukiwarki):

show-eNAuditorScopes -URL "https://login.microsoftonline.com/common/oauth2/v2.0/authorize?scope=User.Read.All+UserAuthenticationMethod.Read.All+Directory.Read.All+Policy.Read.All+Policy.ReadWrite.ConditionalAccess+AuditLog.Read.All+Domain.Read.All+RoleManagement.Read.Directory+openid+profile+offline_access&response_type=code&client_id=23232323-204b-4c2f-b7e8-232323232323&redirect_uri=http%3A%2F%2Flocalhost%3A51987&client-request-id=32323232-54e5-4393-a5a5-323232323232&x-client-SKU=MSAL.NetCore&x-client-Ver=4.61.3.0&x-client-OS=Microsoft+Windows+10.0.26100&prompt=select_account&code_challenge=8wSisaiudhfjrL6PnMTM09kEAfe8Ae4Khywl63cwBlQ&code_challenge_method=S256&state=23232323-2aaa-4d27-912a-45a92b9fa45bbf42bcaf-7727-48e5-b528-232323232323&client_info=1"

User.Read.All
UserAuthenticationMethod.Read.All
Directory.Read.All
Policy.Read.All
Policy.ReadWrite.ConditionalAccess
AuditLog.Read.All
Domain.Read.All
RoleManagement.Read.Directory
openid
profile
offline_access

fajnie, tylko temu też nie można wierzyć chyba, że wyczyści się najpierw lokalny cache i wszystkie przeszłe zgody dla aplikacji Grpah w tenancie… i nie wiadomo czy nie ma jeszcze jakiś innych, automagicznych usprawnień – np. ciasteczka w przeglądarce. a to jeszcze nie koniec!

artykuł zacząłem od pokazania skryptu, który pokazał błąd 'Access Denied’ – wynikający właśnie z braku jakiegoś zakresu. i tutaj kolejna karuzela z zachowaniem, zależna od nieokreślonej ilości zmiennych takich jak cache, historia poprzednich działań i licho wie co jeszcze. obserwowane zachowania to:

skrypt wysypie się z Acc Denied
jeśli brakuje jakiegoś zakresu, automatycznie pokaże się okno przeglądarki pozwalające potwierdzić uprawnienie
w przeźroczysty sposób odświeżony zostanie token i uzupełniony o brakujące uprawnienie
…i jeszcze jedno zachowanie, do którego nie znalazłem dokumentacji więc nie mogę potwierdzić – ale jeśli poprosimy podczas połączenia o wiele zakresów, to będziemy mieli dwa ekrany zgód…

to ostatnie stwierdzenie to trochę strzał na ślepo. dokumentacja mówi o tym, że zapytanie może zostać podzielone na token OID i OAuth, albo że jeśli żąda się uprawnień zarówno delegowanych i aplikacyjnych – wtedy będą oddzielne żądania zgód. porobiłem trochę testów i to się nie spina – czasem to prawda, a czasem nie. mam nadzieję udaje mi się przekonać, że ilość zmiennych jest spora i nie do końca wiadomo czego się jeszcze nie wie ze względu na ilość elementów biorących udział w procesie i to, w jaki sposób 'pomagają’.

..dodajmy (a może raczej pomnóżmy) jeszcze fakt tego jak zmienna jest Chmura – jutro może wyjść nowa wersja MgGraph i wszystko będzie inaczej.

jak obejść problem?

w dużym skrócie można stwierdzić, że temat jest nie-do-ogarnięcia z poziomu skryptów. trzeba się pogodzić z tym, że czasem będzie kilka żądań (consent request). albo skorzystać z Service Principal.

wykorzystanie aplikacji omija wszystkie wymienione problemy:

wszelkie niezbędne zgody wydane są 'z góry’, przed użyciem skryptu
potem można łączyć się np. za pomocą Secret

przykładem jest moduł PnP.PowerShell, którego twórcy postanowili przestać walczyć z wiatrakami i uprościć sobie życie, wymagając zarejestrowanej aplikacji.

czemu zatem ja tak nie robię w skryptach? ano ze względu na pewien paradygmat tego do jakiego scenariusza skrypt jest robiony. konkretnie podstawowa różnica pomiędzy 'administracją’ a 'pojedyncze zadanie’. jeśli tenantem zarządzamy (administrujemy) i potrzebujemy uruchomić skrypt regularnie – metoda z aplikacją jest jedyną sensowną. gorzej, jeśli logujemy się po wielu tentach (że zacytuję siebie samego: „zebranie informacji z ok. 3o tenantów„) – wtedy jest to dodatkowe przygotowanie a potem posprzątanie, co mocno redukuje ideę 'skryptu’ jako szybkiego wsparcia.

na zakończenie

słowo komentarza na temat zakresów – bo widać wyraźnie dwa typy zakresów – jedne określane są krótkim słowem (np. email), inne są złożone (np. Something.ReadWrite.All). to właśnie złożenie dwóch tokenów – OID, który zawiera informacje

openid, profile oraz email to elementy tekenu OID
offline_access choć również jest zakresem OID, występuje niejawnie – jeśli zażądasz go, to dostaniesz błąd. dodawany jest automatycznie.

„This permission currently appears on all consent pages, even for flows that don’t provide a refresh token (such as the implicit flow). This setup addresses scenarios where a client can begin within the implicit flow and then move to the code flow where a refresh token is expected.”

Scopes and permissions in the Microsoft identity platform

do samej pracy/zabawy z tokenami można skorzystać z modułu MSAL.PS, co pozwala trochę lepiej kontrolować proces.

…kiedyś życie skryptera było prostsze /:

eN.

get-eNAuditorMFAReport : raport MFA

maj 15, 2025nExoRCloud, DevOps/Scripting

być może przygotowujesz się do przejścia na nowy model MFA i chcesz upewnić się, czy konta są odpowiednio skonfigurowane. a może po prostu chcesz zweryfikować stan MFA w ramach tenanta?

(między innymi) tego rodzaju raporty muszę dostarczać często, dla tego potrzebuję dobrego narzędzia. takim jest funkcja get-eNAuditorMFAReport z modułu eNAuditor. postaram się opisać kilka funkcji wraz ciekawostkami… bo dawno nie było o PowerShell.

instalacja to po prostu wywołanie „install-module enauditor”. funkcja pozwala na sprawdzenie stanu MFA dla pojedynczego konta lub (default) dla całego tenanta. można też od razu wygenerować plik Excel (-xlsxReport):

C:\temp :))o- get-eNAuditorMFAReport -userId catest@w-files.pl -extendedMFAInformation -xlsxReport
VERBOSE: connected as nexor@w-files.pl.
VERBOSE: 1 member users found. gathering MFA status...

MFAstatus : enabled
softwareAuth : False
authApp : True
authDevice : [SM-S921W]
phoneAuth : False
authPhoneNr :
fido : False
fidoDetails :
helloForBusiness : False
helloForBusinessDetails :
emailAuth : False
SSPREmail :
tempPass : False
tempPassDetails :
passwordLess : False
passwordLessDetails :
UserDisplayName : Test
UserPrincipalName : catest@w-files.pl
Id : 23232323-a33b-45a5-8484-232323232323
AccountEnabled : True
IsAdmin : False
IsMfaCapable : True
IsMfaRegistered : True
IsPasswordlessCapable : True
IsSsprCapable : False
IsSsprEnabled : False
IsSsprRegistered : False
LastUpdatedDateTime : 2025-05-05 8:23:06 PM
MethodsRegistered : macOsSecureEnclaveKey,microsoftAuthenticatorPush,softwareOneTimePasscod
e
IsSystemPreferredAuthenticationMethodEnabled : True
SystemPreferredAuthenticationMethods : PhoneAppNotification
UserPreferredMethodForSecondaryAuthentication : push
AdditionalProperties : 0

VERBOSE: results saved as eNMFAReport-w-files.pl-250514-203901.csv.
08:39:04> INFO: creating C:\temp\eNMFAReport-w-files.pl-250514-203901.xlsx excel file...
08:39:04> INFO: adding eNMFAReport-w-files.pl-250514-203901.csv data as worksheet...
08:39:04> INFO: ',' detected as delimiter.
08:39:05> convertion done, saved as C:\temp\eNMFAReport-w-files.pl.250514-203901.xlsx
08:39:05> OK: done and cleared.
done.

userId może być GUIDem lub UPNem natomiast do konwersji CSV to XLSX wykorzystywana jest funkcja convert-CSVtoXLS z biblioteki eNLib.

extendedMFAInformation

ciekawosta związana z MFA jest taka, że są dwie funkcje Graph, które pozwalają na odpytanie się o MFA:

pierwsza jest bardziej uniwersalna i łatwiej znaleźć przykłady Internecie, jednak ta druga dostarcza bardzo fajnych, szczegółowych informacji… ale. musi być jakieś 'ale’. choć nie jest to opisane w dokumentacji, Get-MgReportAuthenticationMethodUserRegistrationDetail wymaga:

aby konto było aktywne – nie zadziała na wyłączonym koncie
aby miało licencję. jestem jeszcze w trakcie sprawdzania czy jakąkolwiek licencję czy EID P1/P2.
na pewno nie zadziała, jeśli nie ma P1 w ramach tenanta

tak, że parametru 'extendedMFAInformation’ można użyć, ale niekoniecznie uda się uzyskać dodatkowe informacje.

outro

na zakończenie dodam, że moduł jest na GitHub jeśli ktoś chce sobie dokładnie przejrzeć działanie.

w ramach modułu jest na tą chwilę kilka innych funkcji, które też będę po krótce opisywał. na dziś są to:

disable-eNAuditorperUserMFA
get-eNAuditorADPrivilegedUsers
get-eNAuditorBasicSecurityInfo
get-eNAuditorEntraIDPrivilegedUsers
get-eNAuditorMFAReport
get-eNAuditorReportADObjects
get-eNAuditorReportEntraUsers
get-eNAuditorReportMailboxes
join-eNAuditorReportHybridUsersInfo

jak większość tego rodzaju projektów – moduł rośnie w trakcie kiedy mam jakiś projekt z tym związany. w poczekali leży funkcja to weryfikacji uprawnień aplikacji EID, ale nie jest skończona. przy najbliższym audycie na pewno ją dodam.

ze względu na funkcję get-eNAuditorADPrivilegedUsers musiałem ustawić kompatybilność modułu na PS5, chociaż to jedyna funkcja dla tej wersji, jednak wszystkie funkcje dla Chmury wymagają PS7. niestety dodanie #requires dla chociaż jednej funkcji powoduje, że podczas ładowania modułu w ramach PS5 moduł się wysypie – a funckję dla AD przyodziło mi odpalać niedawno na w2k12 (bez R2 nawet!).

taki urok modułów, taki urok środowisk on-premises.

eN.

LockedShields 2o25

maj 9, 2025nExoRsecurity, social

w tym roku po raz kolejny stanęliśmy na podium LockedShields, organizowanego przez CCDCOE. POL-FRA drużyna stanęła na wysokości zadania, minimalnie ustępując drużynie z Niemiec.

to ważne wydarzenie dla mnie co roku – zupełnie inne spojrzenie na bezpieczeństwo i pracę w stanie wysokiego stresu. przez 3 dni miałem dostarczane jedzenie na biurko, a wypad na siku raportowany resztom osób, bo przez 2 min nie jestem w stanie wspierać reszty teamu. świetny trening, który przypomina mi, jak bardzo różni się dzień powszedni od sytuacji kryzysowej. trzeba wykrzesać z siebie więcej, pracować inaczej, a 'książkowe zasady’, które stosuje się na co dzień do zabezpieczania systemów nagle stają się farsą i trzeba rzeczy adresować zupełnie inaczej.

pomimo wysokiej lokaty ten rok wyjątkowo oberwaliśmy [jako team AD] – szacun dla Red Teamu, tym razem nas wyprzedzili. ale to dobrze – chodzi o to, żeby się rozwijać, nie spocząć na laurach i co rok odtwarzać te same procedury. co z takich ćwiczeń się wynosi to tzw 'drill’:

praca w nietypowych warunkach wymagająca podejmowania natychmiastowych decyzji
hierarchia i wykonywanie rozkazów – wbrew pozorom, bardzo trudne dla cywilnych IT. mamy swoją dumę, wielu z nas w wojsku nie było i przyzwyczajeni do brylowania w środowiskach, w których pracujemy, wcale nie jest łatwo utrzymać hierarchię, słuchać rozkazów. starcie charakterów, umiejętność 'zamknięcia się’ i po prostu zrobienia czegoś, nawet jak się z tym nie zgadzamy czy przekazane jest zbyt dosadnie… komunikacja i zarządzanie kryzysowe 'w praktyce’ to co innego niż narysowanie drzewka na papierze.
przestrzeganie procedur ale i umiejętność improwizacji, kiedy zawodzą

do tego oczywiście duża dawka wiedzy od reszty zespołów, co też ma swoje znaczenie, jednak IMHO 'drill’ w takich sytuacjach jest najcenniejszym doświadczeniem.

wiele food for though na przyszły rok po otrzymaniu wyników – mam szczerą nadzieję, iż będę miał zaszczyt i okazję poprawić ochronę naszej części środowiska i udowodnić, że się rozwijamy – technicznie i i w zakresie zarządzania kryzysowego.

dziękuję gorąco całemu zespołowi LS25 i wielkie kudos dla organizatorów, bo impreza jest na na prawdę wysokim poziomie!

PS. dla wszystkich, którzy chcieliby wesprzeć kraj jako cywile – Dowództwo Komponentu Wojsk Obrony Cyberprzestrzeni uruchomiło program CyberLEGION.

eN.

Warszawskie Dni Informatyki 2o25

mar 20, 2025nExoRnews

już 04.04 online i 05.04 w Warszawie, (bud. MiNI PW, Koszykowa 75, Warszawa) zapraszam na kolejną edycję Warszawskich Dni Informatyki – jedną z największych polskich konferencji IT.

organizatorzy oraz Członkowie Rady Programowej przygotowali dla Was ciekawą i bogatą agendę, w której znajdziecie 25 ścieżek tematycznych, ponad 300 wystąpień, networking, afterparty i wiele więcej… znajdzie się również moja prezentacja dotycząca analizy danych audytu tożsamości hybrydowej. dane zbierane są za pomocą modułu eNAuditor, który będę opisywał w ramach swojego bloga.

do 31.03.2025, ze specjalnym kodem rabatowym od Rady Programowej: WDI25SP20 możecie kupić bilet Core, Standard lub Exec 20% taniej. Więcej informacji i rejestracja na: https://warszawskiedniinformatyki.pl/

eN.

ROPC – czy polisa 'Block Legacy Authentication’ ma sens?

lut 19, 2025nExoRCloud, exchange, w-files

ROPC, czyli „Resource Owner Password Credentials”- jest częścią OAuth 2.o i daje możliwość logowania aplikacji bezpośrednio podając hasło. zgodnie z opisem na stronie „it’s incompatible with multifactor authentication (MFA)„.

do tego wpisu usiadłem po śledztwie – jak to jest, że niektóre konta logują się bez MFA pomimo, że jest ustawiona polityka Conditional Access zarówno wymuszająca MFA jak i wyłączająca legacy authentication. pomimo to urządzenia nadal mogą logować się do Exchange, bez MFA, korzystając z czystego SMTP…

w EID wygląda to tak:

w tym scenariuszu, to konto reprezentujące skaner, do realizacji scan-to-email – MFD (Multi-Function Device) nadal spokojnie wysyła skany przez EXO. to wzbudziło moją ciekawość – czemu żadna z polityk nie zadziałała, i czemu legacy authentication nadal jest możliwe – a koniec końców: w jaki sposób można omijać CA wyznaczającą politykę bezpieczeństwa? co tak na prawdę blokuje 'block legacy authentication’, skoro nie zablokował tego połączenia?

jak to się dzieje?

odpowiedź na część problemu już jest, ze wspomnianego artykułu:

ROPC nie jest zgodne z MFA – mówiąc inaczej, omija je
przykładem kiedy jest wykorzystywane – jest użycie ’hasła aplikacji’ dla konta

a co z 'legacy authentication’? jak zwykle chodzi o semantykę i prawidłowe zrozumienie modelu ISO/OSI albo 4/5 warstwowego modelu Internetowego. najpierw ciekawe spojrzenie któreż to protokoły mają status 'legacy’:

Autodiscover
Exchange ActiveSync
Exchange Online PowerShell
Exchange Web Services
IMAP
MAPI over HTTP
Offline Address Book
Other Clients
Outlook Anywhere (RPC over HTTP)
POP
Reporting Web Services
SMTP
Universal Outlook

…w zasadzie cały Exchange do niedawna… (czym jest 'Universal Outlook’ wie chyba tylko developer który implementował filtr protokołów w EID), co ciekawe 'legacy’ są tylko protokoły związane z Exchange, co pokazuje równocześnie priorytetowy obszar do zaadresowania elementów bezpieczeństwa. o ile ’łamie się ludzi a nie systemy’, co pokazują statystyki najpopularniejszych metod włamania, to SMTP pozostaje cały czas najłatwiejsze dla bruteforce. Microsoft

to z czego w końcu korzysta Exchange Online, skoro wszystko jest poblokowane? jak wymienia się z innymi serwerami, skoro nawet SMTP jest na liście?

po pierwsze, trzeba przyjąć do wiadomości, że chodzi o uwierzytelnienie. nie została wyłączona obsługa całego protokołu, również Conditional Access nie pełni roli firewalla – używany jest do weryfikacji uwierzytelnienia (trochę kłamię, bo obsługa sesji to w sumie sporo więcej, ale to advanced feature więc pomijam tutaj). nie chodzi więc np. o SMTP jako protokół wymiany informacji a o SMTP AUTH – i wyłączenie tych starych, jak PLAIN czy LOGIN.

podobnie Outlook – nadal używa jakiejś tam wersji MAPI do komunikacji. problem z ogarnięciem jak zwykle ma naturę semantyczno-marketingową:

MAPI jest protokołem aplikacji, językiem jakim rozmawia Outlook z Exchange
do tego jest warstwa transportowa – i ta mocno się zmieniła powolnie transformując od paskudnego RPC, przez zamknięcie w HTTP, potem silniejszą integrację z MAPI… na dziś dzień te warstwy nie są już tak oczywiste bo zbyt to jest wymieszane, stąd twory nazewnicze
i do tego dochodzi uwierzytelnienie. które jest jakby obok, albo bardziej dosłownie – na froncie. stosuje swoje własne protokoły, które również operują w kilku warstwach, a po zakończonym procesie uwierzytelnienia przekazują pałeczkę do części operującej transportem i aplikacją.

kiedy dokona się analizy i porozkłada się pojedyncze nazwy na ich składowe – zaczyna powoli być jasne które elementy podlegają, a które nie podelagają polityce Conditional Access. CA zajmuje się wyłącznie ostatnim z wymienionych – uwierzytelnieniem i nie dotyka warstw transportu ani aplikacji wykorzystywanych do komunikacji.

kiedy jeszcze używany jest ROPC, poza scenariuszem z EXO? przez developerów/adminów tworzących zapytania przez SPN aplikacji.

w-files

niby szczegół. ale nadal pozostaje wiele niedomówień w kwestii tego kiedy i co de facto zadziała, co ma bezpośrednie przełożenie na bezpieczeństwo. w jaki sposób mechanizmy CA wiedzą żeby nie przetwarzać polityki MFA ale uznać inną?

wszystko jasne z ROPC, tak? ot, przykład z innego tenanta, skonfigurowanego zasadniczo tak samo:

i tutaj ROPC, który wedle dokumentacji nie obsługuje MFA – nagle magicznie zaczyna je obsługiwać i żądać. co więcej – nagle został zaliczony do 'legacy’ – ale jak, skoro ROPC nie jest 'legacy’, bo jest częścią oAuth2?

albo np. Microsoft zaznacza, że basic authentication jest wyłączony. skoro został wyłączony.. to czemu nadal wszędzie jest włączony i po co polisa na coś, co niby od dawna nie powinno działać? pojawiła się polityka 'block legacy authentication’ ale to nie jest wyłącznie. kolejne zdanie, z tego samego artykułu, również idiotyczne:

„We also disabled SMTP AUTH in all tenants where it wasn’t being used.”

nie chce mi się teraz rozkodowywać ruchu i sprawdzać, ale w sumie nie muszę, bo standardy 'starego internetu’ są opisywane w RFC i SMTP AUTH jest podstawową komendą. skróty myślowe w dokumentacji technicznej prowadzą do zamieszania i dezorientacji. generyczny log pokazujący negocjację protokołu z Outlook (modern auth):

2024-02-19 10:12:45 SMTP AUTH connection started from [192.168.1.100] (client.w-files.pl)
2024-02-19 10:12:46 EHLO client.w-files.pl
2024-02-19 10:12:46 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:46 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:46 250-SIZE 15728640
2024-02-19 10:12:46 250 STARTTLS
2024-02-19 10:12:47 STARTTLS
2024-02-19 10:12:47 220 2.0.0 Ready to start TLS
2024-02-19 10:12:48 TLS negotiation successful (TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384)
2024-02-19 10:12:49 EHLO client.w-files.pl
2024-02-19 10:12:49 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:49 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:50 AUTH XOAUTH2 dXNlcj1hbGljZUBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LkEwQWY2eHplN…
2024-02-19 10:12:51 235 2.7.0 Authentication successful
2024-02-19 10:12:52 MAIL FROM:<nexor@w-files.pl>
2024-02-19 10:12:52 250 2.1.0 Sender OK
2024-02-19 10:12:53 RCPT TO:<b0b@w-files.pl>
2024-02-19 10:12:53 250 2.1.5 Recipient OK
2024-02-19 10:12:54 DATA 2024-02-19 10:12:54 354 Start mail input; end with <CRLF>.<CRLF>
2024-02-19 10:12:56 Message content sent successfully
2024-02-19 10:12:56 250 2.0.0 OK 2024-02-19 10:12:57 QUIT
2024-02-19 10:12:57 221 2.0.0 server.w-files.pl closing connection

czyli jednym sensownym wyjaśnieniem byłoby 'wyłączyliśmy SMTP AUTH w tenantach gdzie nie ma Exchange’. co za ściema.

nie lubię niejasności. ciężko się zabezpieczać a wśród niejasności rodzą się potencjalne furtki. a po wszystkich tych testach niby wiem więcej a czuję się tak samo bezradny.

eN.