Most of my work is Europe based, and I am used to an Azure AD tenant behaving in a specific way when it comes to the B2B invitation/redemption process. The other day, we were running a hands-on lab in my masterclass, and a user was invited to join a tenant as a guest user. The user had an email address of sam@partners.xtshub.com, a partners.xtshub.com Azure AD tenant existed, but Sam was not a member. When Sam went to redeem the email, I expected the redemption process to fail because she was not a member of the partners.xtshub.com tenant. However, the redemption succeeded, and Sam was automatically added as a user to partners.xtshub.com using email verification. In my experience, email verification had always been disabled in an Azure AD tenant, and I immediately checked the -AllowEmailVerifiedUsers attribute which can be viewed using Get-MsolCompanyInformation |fl *. The value was set TRUE which allows users to be added via email verification.
My immediate thought was that Microsoft had changed the default value for newly created tenants. From a security and compliance perspective, this was not a welcome change, many of my clients do not want users to be able to automatically become members of their Azure AD tenants via email verification. When email verification is enabled it is a really simple task for a user to add themselves to the tenant (provided they have a DNS email domain that matches the tenant domain). All a user needs to do is set up an Azure AD trial tenant and invite themselves to the trial tenant as a guest user. When they redeem the invitation, they will be added to the tenant that matches their email DNS domain. As an alternative method, and even easier to implement, sign up as an individual for Power BI or Azure Information Protection (AIP) and you will be added to the tenant that matches your email address provided email verification is enabled. To get a subscription licence automatically assigned to the user -AllowAdHocSubscriptions must be enabled.
After talking with the Microsoft product group, thanks to Alex Simons and Sarat Subramaniam, I discovered that -AllowEmailVerifiedUsers was enabled by default for Azure AD in some countries and disabled in others.
Here’s a list of countries in which it is disabled:
Pakistan, United Arab Emirates, Kazakhstan, Turkey, Yemen, Azerbaijan, Kuwait, Jordan, Qatar, Bahrain, Oman, Lebanon, Cyprus, Saudi Arabia, Israel, United Kingdom of Great Britain and Northern Ireland, Ukraine, Switzerland, Sweden, Svalbard, Spain, Slovenia, Slovakia, Serbia, San Marino, Russian Federation, Romania, Portugal, Poland, Norway, Netherlands, Montenegro, Monaco, Moldova, Malta, Macedonia, Luxembourg, Lithuania, Liechtenstein, Latvia, Jersey, Italy, Isle of Man, Ireland, Iceland, Hungary, Holy See (Vatican City), Guernsey, Greece, Gibraltar, Germany, France, Finland, Faroe Islands, Estonia, Denmark, Czech Republic, Croatia, Bulgaria, Bosnia and Herzegovina, Belgium, Belarus, Austria, Andorra, Albania, Aland Islands.
Apparently, the change was made about 4 years ago to make it easier for users to sign up for subscription services such as Office 365 Education, Power BI and Azure Information Protection. The reason that it caught me out was because Sam’s email domain sam@partners.xtshub.com matched the DNS name of an Azure AD tenant created in the United States where email verification is enabled by default.
Lesson Learnt
I am actually really pleased to have experienced this as without it I would still have assumed that all Azure tenants have the same default settings. The real learning to take away from this is that it is essential to check that the -AllowEmailVerifiedUsers and -AllowAdHocSubscriptions flags are set the way that you require for your security and compliance stance. If you want to know if a user has been created through email verification, you can enumerate the creationType attribute for a user object.
There is lots of great work going on for Azure AD B2B Collaboration, expect to see significant changes in the near future.
That’s it for now, until next time. If you enjoyed the blog, please let me know on Twitter @john_craddock.