Czy Ty też wielokrotnie zadawałeś sobie pytanie po co Microsoft pozwala logować się do Azure na tyle sposobów? I czym one się różnią? Prawdziwe, pełne wyjaśnienie różnic pomiędzy kontami znajdziesz tu. Warto zajrzeć, zrozumieć różnice i wiedzieć, którego z tych kont w danej chwili używasz.
Ja chciałbym Ci opowiedzieć historię o tym, jak nie wpaść w pułapkę tożsamości i jak NIE PLANOWAĆ swojego Azure Active Directory.
Żebyś mnie lepiej zrozumiał w całym wpisie będę używał konta: michal@cloudarchitects.pl.
Założenia
- Zaczynasz swoją przygodę z chmurą. Dopiero założyłeś swoją subskrypcję i tu od razu pierwsza, niespodziewana rzecz. Twoja domyślna domena Azure Active Directory nazywa się *.onmicrosoft.com. Gdybym przy rejestracji użył konta jak wyżej, byłoby to prawdopodobnie michalarchitektwchmurze.onmicrosoft.com.
- Na początku Twoje konto michal@architektewchmurze.pl jest tylko kontem lokalnym, założonym w lokalnym Active Directory i ma przypisany służbowy adres email.
- Zdecydowałeś, że w pierwszym kroku będzie nadawał uprawnienia do Azure za pomocą kont z domeny Azure AD lub wykorzystując Microsoft Account. Jeśli nie wiesz czym jest Microsoft Account to koniecznie to przeczytaj.
I co teraz? Czy już mogę mieć jakieś problemy? Tak!
- Nazwa Twojego domyślnego katalogu Azure Active Directory została w taki sposób wygenerowana przez Azure, aby była unikalna. Absolutnie nie warto z takiego katalogu dalej korzystać. Po pierwsze dlatego, że każde utworzone konto w takim katalogu będzie wyglądało tak: jakub@michalarchitetkwchmurze.onmicrosoft.com. Słabo prawda?
- Po drugie, i to może Cię zaskoczyć. Jeśli utworzysz subskrypcję Office 365 i przypisze ją do tego katalogu Azure Active Directory to domyślna witryna SharePoint będzie miała adres: michalarchitektwchmurze.sharepoint.com. To nie jest ponury żart ani dowcip, Office365 weźmie całą nazwę domeny przed .onmicrosoft.com. Tak to zostało zaprojektowane i warto o tym wiedzieć.
O Azure AD i jego wykorzystaniu przez Azure, Office365 czy Intune znajdziesz dużo tutaj i tutaj. Lektura obowiązkowa!
Co więc należy zrobić?
- Po utworzeniu subskrypcji przejść do usług w Azure i utworzyć nowy katalog o nazwie, która Ci się podoba. Np. architektwchmurze.onmicrosoft.com. Jeśli okaże się, że domena jest zajęta mamy wewnętrzny proces odzyskiwania domeny o ile jej nazwa jest zgodna z nazwą Twojej firmy czy Twojej zarejestrowanej domeny.
- Zmienić domyślną domenę Azure Active Directory dla dane subskrypcji. Subskrypcja Azure może mieć wiele katalogów ale tylko jeden z nich może być domyślny. Możesz to zrobić w „starym portalu”. Wiele subskrypcji może korzystać z jednego, domyślnego katalogu co jest bardzo często stosowane w dużych środowiskach. Osobiście preferuję ten model z wyjątkami. Np. dostawcy zewnętrzni, dla których klient przygotował oddzielną subskrypcję jako sandbox do testów i proces uwierzytelniania jest inny mogą mieć dedykowany katalog.
Pierwszy krok za Tobą. Gratulacje! Ale to nie koniec.
- Teraz zapewne zechciałbyś by zamiast domeny architektwchmurze.onmicrosoft.com było po prostu cloudarchitects.pl. Nic prostszego. Dzięki temu konta użytkowników, które powstaną tylko w chmurze, będą pięknie wyglądały np. jakub@architektewchmurze.pl. Procedura jest prosta, szybka, łatwa i przyjemna. Nie może być lepiej:)
- Kolejny krok to integracja katalogu AD on-premises z Azure Active Directory. Bardzo szeroki temat, daje wiele możliwości. Poczytaj proszę ten artykuł by zobaczyć, co możesz osiągnąć. Szczególnie, że dużo się dzieje w tym obszarze i AD FS nie jest już konieczny do wykonania federacji i osiągnięcia SSO. Jeszcze nie dawno była do jedyna opcja. Dzięki integracji będziesz miał jedno miejsce tworzenia, kasowania i zarządzania kontami, co znakomicie ułatwia sprawę a pracownicy pokochają Cię za SSO, szczególnie jeśli ich komputery z Win10 też podłączysz do domeny AAD.
A więc, gdzie te problemy o których pisałem na początku i co z nich wynika?
Przy zakładaniu swojej pierwszej subskrypcji korzysta się najczęściej z tzw. Microsoft Account a więc efektywnie z służbowego lub prywatnego adresu email michal@architektewchmurze.pl do którego Microsoft dopisał w swojej bazie tożsamości unikalny identyfikator tzw. Microsoft ID. Kroki procedury są bardzo proste.
UWAGA: nie działa dla domeny *.microsoft.com i zależnych:). To prawie tak jak wpisać w Google hasło Google, świat internetu wybucha.
- A więc w moim lokalnym AD jest konto michal@cloudarchitects.pl. Przypisalem do tego konta Microsoft Account i to konto otrzymało uprawnienia w Azure AD.
Komentarz, 21.07.2017: Microsoft zablokował możliwość przypisywania Microsoft Account do tzw. Work Account czyli kont z własną domeną. Nadal to można zrobić dla „kont prywatnych”.
Pod adresem https://account.microsoft.com/account znowu można to zrobić dla dowolnego konta, dlatego poprzedni komentarz poszedł do piachu!
- W katalogu Azure AD przypisałem własną nazwę domeny czyli cloudarchitects.pl.
- I teraz najlepsze… W katalogu Azure AD stworzyłem konto michal@cloudarchitects.pl, które jest w pełni kontem chmurowym, stworzonym w Azure Active Directory. Czy to możliwe? O tak, w pełni i nie ma w tym sprzeczności.
Tak, masz rację. Proszę się o kłopoty. Mam dwa konta, z tym samym Display Name, które nie mają ze sobą nic wspólnego i każdego konto to inna, niezależna tożsamość. 
Żeby jeszcze bardziej skomplikować… zintegrowałem swoją lokalną domenę Active Directory z domeną Azure Active Directory. I z niej spłynęło konto michal@cloudarchitects.pl.
Czy to możliwe? Jak wyżej. Nazwa wyświetlana tych kont będzie taka sama, UPN różny więc wszystko się zgadza.
O ile system 🙂 to rozumie to Ty zapewne już nie wiesz co się dzieje i jak dalej tego używać? I dobrze, bo chcę Cię namówić byś przenigdy nie tworzył sobie takiego Matrixa Tożsamości. Nagle będziesz mógł zalogować się do swojej domeny Azure efektywnie 3 różnymi kontami, każde z nich będzie „wyglądało” tak samo. I teraz tylko od podanego hasła i wybranego typu konta będzie zależało jakie zasoby zobaczysz i jakie uprawnienia będziesz posiadał.
Co więc zalecam?
- Od razu wybierz poprawną nazwę swojej domeny Azure AD. Nie czekaj z tym ani chwili. Jeśli w domyślnej domenie utworzysz tożsamości i przypiszesz im uprawnienia w Azure a potem domenę zmienisz… No cóż. Wszystkie nadane uprawnienia będziesz przypisywał jeszcze raz. Boli. Nie polecam. Ćwiczyłem dwa razy.
- Korzystaj z kont typu Microsoft Account do nadawania uprawnień tylko na początku albo w czasie szkoleń. Nie zarządzasz tymi kontami, nie panujesz nad nimi. Załóż sobie natywne konta w Azure AD i na bazie tych nadawaj uprawnienia w Azure. Na poziomie Azure AD możesz wyłączyć możliwość nadawania uprawnień innym kontom, niż tym, które są w Azure AD (czy to utworzone czy zsynchronizowane)
- Jeśli masz jeszcze katalog AD on-premises, rozważ integrację poprzez synchronizację samych kont lub kont i haseł. Proponuję od razu to drugie, Twoi użytkownicy polubią Cię za SSO. Do tego celu wykorzystaj Azure AD Connect, nowa jego wersja daje dużo możliwości i będzie ich tylko więcej. I będzie to dużo łatwiejsze niż konfiguracja usługi ADFS.
Im więcej możliwości tym lepiej, o ile wiesz, jak z nich korzystać.
Mam nadzieję, że pokazałem Ci czego nie robić i z większą uwagą podejdziesz do planowania tożsamości w swoim Azure Active Directory. Powodzenia!