Azure Active Directory – Guest Users – gmail.com / outlook.com – I nie tylko
Dawno temu, jeżeli dodawaliśmy użytkownika do Azure Active Directory typu gość i wysyłaliśmy zaproszenie na @gmail.com lub outlook.com, czy też @interia.pl – użytkownik ten nie mógł zalogować się do Azure Active Directory, a więc i nie miał dostępu do aplikacji używających uwierzytelniania Azure Active Directory – od portalu Azure, aż do np. Teams.
Po co używać takowych kont (typu gość), jak można użyć kont normalnych – a chociażby po-to aby np. nadawać uprawnienia do Teams, Sharepoint w sposób uporządkowany i np. jak użytkownik zapomni hasła, to będzie mógł go odzyskać na swój własny adres email lub przy pomocy telefonu – a w naszej organizacji nie będziemy musieli ponosić kosztów licencji Office 365 dla takiego użytkownika. Dodatkowo konta Microsoft Account są dość dobrze zabezpieczone, jak zalogujemy się z nieznanej lokalizacji musimy odebrać telefon lub SMSa.
Jakiś czas temu Microsoft zniósł różnice pomiędzy kontami typu B2B i B2C, co uważam za bardzo dobrą decyzje!
„I thought Azure AD B2B didn’t accept gmail.com and outlook.com email addresses, and that B2C was used for those kinds of accounts?
We are removing the differences between B2B and business-to-consumer (B2C) collaboration in terms of which identities are supported. The identity used is not a good reason to choose between using B2B or using B2C. For information about choosing your collaboration option, see Compare B2B collaboration and B2C in Azure Active Directory.”
Jak konta Guest działają obecnie w domenach publicznych typu @gmail.com, @outlook.com, @interia.pl:
- Jeżeli dodajemy konto do AAD (Guest) i użytkownik nie miał konta Microsoft Account (Dawniej Live ID) – to użytkownik dostaje maila i tworzymy konto, ustawiamy hasło do takiego konta – ale wg. moich dochodzeń jest tworzone konto Microsoft Account (Live id).
- Jeżeli dodajemy konto do AAD (Guest) i było już utworzone konto Microsoft Account z takim adresem email – to nie możemy ustawić hasła dla takiego konta, a po-prostu zalogować się hasłem Microsoft Account.
Przy okazji wspomnę, iż identycznie jest z kontami firmowymi (Office 365) – albo konto zostanie utworzone w Azure AD wraz z nową domeną w której nie będzie Global Admina(!), albo skorzystamy już z istniejącego. Oczywiście później po weryfikacji domeny dodamy Global Administratora.
Przy zakładaniu użytkownika typu Gość, mamy miejsce na wpisanie komunikatu i warto to ładnie opisać zwłaszcza, że ostatni krok mówiący o dostępnych aplikacjach zazwyczaj jest troszkę mylący, a mianowicie pusty.
Zakładanie konta typu Gość w Azure Active Directory:
Email informujący:
Mylący komunikat o dostępnych aplikacjach:
Użytkownicy bez Global Admin (założone konta typu gość w innych organizacjach):
Więcej informacji: https://docs.microsoft.com/en-us/azure/active-directory/b2b/faq
Long time ago if we added a Guest user to the Azure Active Directory type and sent an invitation to @gmail.com or @outlook.com, or @interia.pl – this user could not log in to Azure Active Directory, so he had no access to the application using Azure Active Directory authentication – from the Azure portal to Teams.
Why we should use Guest type account? For example, to grant Teams, Sharepoint rights in an orderly manner and for example if a user forgets a password, he will be able to recover it to his own address email or using a telephone – and in our organization we will not have to pay Office 365 license costs. In addition, Microsoft Account Accounts are quite well secured, as we log in to an unknown location, we must answer the phone or text message.
Some time ago Microsoft abolished the differences between B2B and B2C accounts, which I think is a very good decision!
„I thought Azure AD B2B didn’t accept gmail.com and outlook.com email addresses, and that B2C was used for those kinds of accounts?
We are removing the differences between B2B and business-to-consumer (B2C) collaboration in terms of which identities are supported. The identity used is not a good reason to choose between using B2B or using B2C. For information about choosing your collaboration option, see Compare B2B collaboration and B2C in Azure Active Directory.”
How Guest accounts currently operate on public domains like @gmail.com, @outlook.com, @interia.pl:
- If we add an account to AAD (Guset) and the user did not have a Microsoft Account (Live ID) – then the user receives an email and create an account and set a password for such an account – but according to my investigations Microsoft Account is created (Live id).
- If you add an account to AAD (Guest) and you have already created a Microsoft Account (Live ID) with such an email address – then we cannot set a password for such an account and simply we need to log in with the Microsoft Account password.
By the way, I will mention that it is almost identical with company accounts (Office 365) – either the account will be created in Azure AD along with a new domain in which there will not be Global Admin (!), Or we will use the existing one. Of course, we will add Global Administrator after domain verification.
When creating a Guest user, we have space to enter a message and it is worth describing it nicely, especially since the last step about available applications is usually a bit misleading, simply it is empty.
Invite Guest Account in Azure Active Directory:
Email with information:
Misleading message about available applications:
Users without Global Admin (Guest accounts in other organizations):
More info: https://docs.microsoft.com/en-us/azure/active-directory/b2b/faq