to się nie powinno zdarzyć… [combo]
takiego przypadq w-files nie miałem od dawna. od początq do końca – same zagwozdki. a zaczęło się tak…
objawy i pierwsza diagnoza
użytkownik zgłasza, że niektóre maile kierowane do niego, wysyłane są … na prywatną skrzynkę innej osoby. środowisko w hybrydzie exchange a cała sprawa zadziwia, bo zgłoszenie jest od użytkownika onprem.
po krótkim debugowaniu udaje się ustalić, że w AAD użytkownik ma wypełniony atrybut 'otherMails’. czemu innego użytkownika to da się wytłumaczyć ale czemu Exchange wysyła maile korzystając z tego atrybutu?? czy to oznacza kompromitacją routingu Exchange? mocno niepokojące zachowanie..
schodzimy głębiej
po dalszym dochodzeniu udaje się ustalić kilka innych faktów. większość pominę, bo pomimo, że dały dużo pikanterii do sprawy, i mocno utrudniły całe dochodzenie wprowadzając w ślepe zaułki, sqpię się na najważniejszym. udało się ustalić, że to konto jest widziane jako 'GuestMailUser’ przez Exchange lub 'Guest’ w AAD. to już lepiej, ponieważ parę rzeczy da się wyjaśnić: Exchange używa właśnie atrybutu otherMails [który wbrew nazwie jest typu 'string’ a nie tablicą] do wysyłki, a to oznacza, że pomimo iż sytuacja jest co najmniej dziwna, to nie jest kompromitacja całego tenanta. udało zawęzić się grupę zagrożonych użytkowników do kilqnastu osób.
no to impas: w onprem AD nie ma nigdzie informacji z adresem zewnętrznym, a w o365 nie da się go usunąć, ponieważ obiekt jest synchronizowany, więc zmiany autorytatywnie mogą pochodzić tylko z AD.
dla niektórych użytkowników udaje się skonwertować obiekt na 'member’ poprzez „set-msoluser -userprincipalname <UPN> -userType member”
ale po wyświetleniu pełnego obiektu AAD „get-AzureADUser -searchstring <UPN>|fl” okazuje się, że w atrybucie proxyaddresses cały czas siedzi adres #EXT#. czyli konwersja obiektu jest obejściem problemu, ale niedostatecznym rozwiązaniem.
jak do tego doszło?
no dobra. sytuacja opanowana, maile nie wyciekają. ale jak to się w ogóle mogło zdarzyć?
jak zwykle w takich przypadkach, nie da się tego na 1oo% potwierdzić, ale scenariusz był najprawdopodobniej taki:
- był sobie tenant, który nie był w pełni zsynchronizowany
- projekt rozpoczął się od testu SharePoint, gdzie jacyś użytkownicy bawili się, testowali, licho-wie-co jeszcze.
- ponieważ tenant nie był w pełni zsynchronizowany, ba! zmieniane były UPNy użytkowników, ktoś wysłał zaproszenie do zasobu na SP. użytkownik przyjął to zaproszenie, ale zamiast się zalogować jako user tenanta, zalogował się jako zewnętrzny użytkownik, podając firmowy email. został więc utworzony obiekt Guest, z mailem odpowiadającym mailowi firmowemu
- po uporządkowaniu UPNów i wymuszeniu synchronizacji część obiektów się nie zsynchronizowała. ktoś popoprawiał obiekty z błędem tak, żeby zadziałał soft-match. teoretycznie podczas takiej operacji, obiekt synchronizowany z onprem, powinien 'nadpisać’ obiekt Guest i stać się Member. ale tak się nie stało…
co na to Microsoft i czy to się powtórzy?
sprawę oczywiście potwierdzałem ze wsparciem MS żeby mieć jakieś autorytatywne odpowiedzi. potwierdzili scenariusz jak do tego doszło, z zastrzeżeniem, że nie mają pełnych danych z tamtego okresu. sprawdzili jednak, że ktoś manipulował przy obiekcie zmuszając do spasowania z onpremowym.
kolejne zapewnienie jakie otrzymałem, to iż już jakiś czas temu wdrożony został patch, który chroni przed takimi sytuacjami – czyli w trakcie synchronizacji nie może w efekcie dojść do pozostawienia obiektu jako Guest. sytuacja jest tak trudna i ulotna, że nie podejmuję się weryfikacji.
mówiąc w skrócie: to się nie ma prawa powtórzyć.
grande finale
jedynym sensownym rozwiązaniem problemu jest usunięcie użytkowników z synchronizacji, wywalenie ze śmietnika i powtórna synchronizacja. drugim rozwiązaniem byłaby dalsza eskalacja we wsparciu tak, aby użytkownicy nie potracili dostępów [bo przecież ich konta zostaną usunięte i utworzone totalnie nowe obiekty], ale od razu zastrzegli, że to może nawet nie zostać zaakceptowane a na pewno długo potrwa.
no więc usunąłem z synchronizacji… ale na koniec czekała mnie jeszcze jedna niespodzianka. otóż nie byłem w stanie usunąć niektórych kont ze śmietnika. co ciekawe get-msolUser -ReturnDeletedUsers pokazywał, że są tam te obiekty.. ale przy próbie usunięcia wywalało błąd, że obiekt nie istnieje.
a więc na koniec ostatni w-files: po wyświetleniu atrybutów obiektu poza UserPrincipalName znalazłem SignInName. dla użytkowników, których nie udało się usunąć, różnił się on tym, że był zawiera lokalny prefix domenowy – czyli np. zamiast username@logincunion.com było username@logicunion.com.pl . tak wyglądały te obiekty przed wspomnianą wcześniej zmianą UPN, i jak widać gdzieś ta informacja utknęła. i pomimo, że remove-msolUser -RemoveFromRecycleBin ma parametr ’-UserPrincipalName’ to de facto używa właśnie SignInName …
eN.
jabłko bez reklam to koniec świata?
bawią mnie statystyki podawane przez zatrwożonych fanów apple, głoszących zamach na światową gospodarkę opartą na reklamach:
„Its Safari browser has a 25% share of all mobile web browsing, by some estimates.”
że safari ma niby 25% rynq? ciekawe, że statystyki IDC udziału urządzeń mobilnych mówią o ledwie 14% udziale iOS na rynq. to by musiało znaczyć, że safari jest takie popularne na androidzie. a sumaryczny udział światowy, nie tylko na urządzenia mobilne, będzie jeszcze mniejszy. są zresztą blockery na safari OSX. co by oznaczało, że potencjalnie ~9o% użytkowników może korzystać z blokerów reklam i świat jakoś się kręci nadal. firmy nadal publiqją, działają, zmieniają formę owej reklamy na mniej inwazyjne. w3school pokazuje, że safari ma 4.5%. oczywiście – statsy są brane z konkretnej grupy stron. jakby sprawdzić jaki udział przeglądarek na podstawie wejść na update.windows.com to pewnie będą się lekko różnić od tych z www.apple.com (;
czytanie newsów z aj-świata jest za prawdę zabawne. można dowiedzieć się jakież to rewelacyjne nowości się pojawiają [typu apka do newsów], jak to cały świat jest zależny od reklam na najpopularniejszej przeglądarce świata, czy jaki to google jest potworny, bo ludzie nie odróżniają linków sponsorowanych od wyniqw wyszukiwania. normalnie jakbym się cofnął dekadę i poczytał o nadchodzącym 'roq linuxa’ q:
eN.