ciekawy przypadek
firma X qpiła klientowi licencje i założyła tenant office365. projektu nie zrealizowała i przeszedł na nas. pozmienialiśmy wszystkie dane, przepięliśmy konto Global Admina, łącznie z 'aternative mail address’. można to zrobić z interfejsu, a z PS wygląda to tak:
PS C:\_ScriptZ> Connect-MsolService -cred $creds
PS C:\_ScriptZ> Get-MsolUser -UserPrincipalName admin@domain.onmicrosoft.com|select *mail*
AlternateEmailAddresses
-----------------------
{admin.email@server.com}
i niby wszystko załatwione….
ale zupełnie przypadkiem postanowiłem sprawdzić zmianę hasła i moim oczom ukazało się:
przy czym ten drugi adres, należał do osoby z firmy X.
przeczesałem wszystkie znane miejsca i nigdzie tego adresu nie ma. w panelu o365 również widać tylko podstawowy.
o365 support
bardzo rozczarowało mnie wsparcie o365. wysłałem ticket jako partner obsługujący klienta, z oznaczeniem 'critical – security breach’. przy każdej wymianie korespondencji były mi proponowane te same kroki, te same pytania, wysłałem screenshoty, wysłałem PSR (problem steps recoder) i nadal dostawałem instrukcję jak zmienić email przez portal o365. po kilq mailach ticket został zamknięty z informacją mniej-więcej 'ten problem to nie problem’. nie było eskalacji, po prostu nie potrafił rozwiązać to zamknął. łoś.
rozwiązanie
trochę mi zajęło, ale znalazłem miejsce, gdzie zapisany został drugi adres. trzeba założyć AzureAD [tak na prawdę pod spodem i tak się zakłada, ale cały portal manageazure jest nieaktywny], wyedytować właściwości domeny, włączyć usługę 'Reset Password’ i przejść do skonfigurowania maila. okazuje się, że jest to oddzielna baza, do której nie ma innego dostępu [?]. poniżej kroki w obrazkach:
- założenie portalu AAD
- Przejście do konfiguracji domeny
- włączenie Reset Password. następnie trzeba przejść na stronę gdzie można skonfigurować dane [zaznaczone]
- i już widok samej strony gdzie są skonfigurowane dane
eN.
