scenariusz: skrzynki w o365, federacja ADFS, włączona została opcja 'self password reset’ dla użytkowników. firma zgłasza, że książce adresowej pojawiają się dziwne telefony i nawet po zmianie w AD, zmiany się nie synchronizują.
sprawdzam … i faktycznie – telefony ustawione prawidłowo, a w książce jakieś dziwne takie… ADSync nie zgłasza żadnych błędów, a jednak po wyświetleniu wartości atrybutów użytkowników w o365 telefony są inne niż w AD.
szczęśliwie trochę już walczyłem z tym problemem więc przyczynę znam – jest opcja 'self-service password reset’ i MFA, które przechowują numer telefonu w jakimś innym atrybucie. klasyczny przypadek INBIF – ’it’s not a bug it’s a feature’.
większość informacji dot. tego ficzera, wraz linkami gdzie co jest, można znaleźć w doqmentacji Azure.
no dobrze… jak zatem administracyjnie zmienić ten numer? udało mi się znaleźć tylko jedną ścieżkę – przez stary portal https://manage.windowsazure.com . w części AD w zarządzaniu użytkownikami, jest część 'authentication contact info’. w nowym portalu też ta część jest, ale nie wiedzieć czemu 'readonly’.
co ciekawe tego atrybutu w żaden sposób nie da się zmodyfikować via API – ani z poziomu PS, ani [o ile udało mi się dowiedzieć] z poziomu graphAPI.
ostatnio na spotkaniu grupy produktowej EMS w Microsoft miałem okazję rozmawiać z Keith Brintzenhofe, Managerem 'Azure Active Directory Identity and Access Management product group’. nie omieszkałem go zaatakować tym pytaniem i odpowiedź jaką otrzymałem to:
- jest to znany problem, wiele firm zgłasza brak możliwości edycji tego atrybtu
- wynika z historycznych założeń kiedy było tworzone AAD
- atrybut jest przechowywany w ramach tego samego tenanta/tego samego AAD [obawiałem się, że jest synchronizowany z jakiejś innej bazy]
- z jakiś [IMHO – niewytłumaczalnych] założeń, ten atrybut nie jest widoczny normalnie [udostępniony publicznie]
- problem ma być zaadresowany w ciągu najbliższego pół roq – w Q1 2o17
ręczna zmiana tego numeru dla kilqset czy nawet kilqnastu osób jest upierdliwa, mam więc nadzieję, że obietnica będzie zrealizowana.
PS. ilość portali, portalików, stron i stronek w [no właśnie – azure? office365?] jest lekko deprymująca. nie mówię nawet o stronach partnerskich ale nawet zarządzanie kontem. można się pogubić, co jest na której stronie i skąd przepływa. nie udało mi się znaleźć 'mapy’. jest profil widoczny z poziomu office365, jest też stronka https://account.activedirectory.windowsazure.com/profile/ , a ze strony profilu jeśli przejdziemy do 'o mnie’ zostaniemy przeniesieni na site SharePoint…. i tak można by jeszcze kilka miejsc wymienić. to jest trudne nawet dla osób, które tym zarządzają – jak ma sobie z tym poradzić przeciętny user??
eN.
