Customized Administrator

czy zauważyliście, że zależnie od interfejsu, widać inne role w AAD? jeśli zajrzymy z Office Admin Center to:

kiedy tworzy się 'Customized Admin’ z portalu Admin, to już ilościowo widać, że jest coś więcej:

a tak na prawdę, jak nie trudno się domyślić, jest ich jeszcze więcej.  scenariusz 'po co?’ zostawię sobie na kiedy indziej a tymczasem – jak sprawdzić te role i jak do nich przydzielić? jakich braqje?

jak sprawdzić wszystkie role

najkrócej: za pomocą Microsoft Graph. zakładam, że używanie tego mechanizmu dla wielu osób nie jest oczywiste, dla tego krótka instrukcja. po wejściu stronę, należy się uwierzytelnić do swojego tenanta [po lewej stronie 'microsoft sign-in’]. w innym przypadq będziemy w testowym tenancie Microsoftu.

w oknie akcji widać trzy podstawowe elementy – okno zapytania, 'request body’ uzupełniające zapytanie oraz 'response body’ gdzie będą się pojawiać wyniki.

dla sportu można sobie kliknąć 'run query’ i zobaczyć wynik w 'response body’. szybko można się zorientować, że wszędzie widzimy legendarnego Dżejsona, a zapytania są w stanie spoczynq [REST]. jak nie rozumiesz – na razie nie szkodzi, ale warto uzupełnić sobie informacje o zapytania REST oraz format JSON. w odpowiedzi dowiemy się paru rzeczy o własnym koncie.

można się również szybko zorientować w dostępnych metodach rozwijając listę 'GET’ gdzie widać jeszcze 'PUT’, 'POST’, PATCH’ oraz 'DELETE’. widać również, że są dwie wersje Microsoft Graph – v1.0 oraz beta.

pierwsza niespodziewajka – czytając i przeglądając artykuły zaczniecie trafiać na wersje 1.5 czy 1.6… a to dla tego że oprócz Microsoft Graph jest jego poprzednia wersja – AzureAD graph. trzeba zatem uważać przy stosowaniu przykładów, do której są wersji.

dostępne role dla Customized Administrator – bo taki jest cel niniejszego zadania – widoczne są w części 'directoryRoles’. i tu widać pełną listę, m.in. niedostępnego z interfejsu 'CRM Service Administrator’, 'Power BI Service Administrator’ i kilka innych.

jak dodać rolę

pomimo, że w naszym świecie rolę przydziela się użytkownikowi, tutaj to roli przydziela się użytkownika. czyli operację trzeba wykonać dla pożądanej roli a nie dla użytkownika. to, co będzie nas interesować to 'ID’ roli. zanim coś przypiszemy najpierw sprawdźmy członków 'Global Admins’. tutaj nazywa się to 'Company Administrator’ … pewnie dla ułatwienia (; spisujemy ID i wykonujemy GET dla https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members -> Run Query. pojawią się wszyscy GA dla tenanta.

aby kogoś dodać, należy wysłać żądanie [POST] a w treści zamieścić opis obiektu zapisany jako JSON.

polecenie HTTP:

POST v1.0 https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members/ref$

oraz request body, gdzie zamieszczamy opis obiektu:

{
"@odata.id": "https://graph.microsoft.com/v1.0/users/<userID - może być UPN lub objectID>"
}

wykonujemy request i….

dostajemy błąd o braq uprawnień. pomimo, że jesteśmy adminami?

uprawnienia dla GraphExplorera

Graph Explorer działa jako proxy i standardowo ma tylko uprawnienia odczytu. należy aplikacji nadać uprawnienia, aby mogła wykonać operacje zapisu. zwróć uwagę, że tam, gdzie było 'Sign In’, teraz pod loginem jest 'modify permissions’ oraz 'sign out’. dla nadania roli wymagane są dwa uprawnienia:

  • Directory.AccessAsUser.All
  • Directory.ReadWrite.All

zostaniemy zapytani, czy nadać aplikacji odpowiednie uprawnienia i voila. wykonanie wcześniej opisanego query – doda userowi pożądaną rolę.

eN.

-o((:: sprEad the l0ve ::))o-

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.