I wanted to let you know about a few changes we're making in Azure AD data in preparation for a very cool set of new capabilities we're working to bring online. In the next few days, those of you who use Azure AD to manage access to Azure itself and who are also using a Microsoft Account to administer that directory will receive an email below regarding you Azure subscription like this:
Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API. In preparation for upcoming management capabilities, Microsoft is ensuring that all Azure subscription administrators are members of the directory that secures access for that subscription. Microsoft accounts being used as subscription administrators will be added as Guest accounts in the directory if they are not already registered in the directory. You are receiving this notice because:
Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API. The Guest accounts will be added by August 31st 2014. While as Guests these subscription administrators will have limited access to the Azure Active Directory, they will have no change in their experience for managing Azure resources. These users do not need to take any action. For more information on Guest accounts including how to search in the directory for them, please see: http://go.microsoft.com/fwlink/?LinkId=507349
A Guest is a user in your directory that has a User Type set to "Guest". Normal users will have a user type of "Member" to indicate that they are a member of your directory. Guests added, as part of the process above, will have the department set to 'Created as guest by Microsoft Azure'. You can find these users in your directory by using the Azure Active Directory PowerShell module. For example the command below will return all guest users that were created by the back fill operation.
Get-MsolUser -All -Department "Created as guest by Microsoft Azure"
Guests have a limited set of rights in the directory. These rights limit the ability for Guests to discover information about other users in the directory while still being able to interact with the users and groups associated with the resources they are working on. For example, a Guest assigned to an Azure subscription will be able to see other users and groups associated with the Azure subscription. They can also locate other users in the directory who should be given access to the subscription provided they know the full email address of the user. A Guest is only able to see a limited set of properties of other users. These properties are limited to Display name, email address, user principal name (UPN) and thumbnail photo.
If you want to give a Guest the same access as a Member, you can change a Guest into a Member by setting the User Type to Member. This is possible via the Azure AD PowerShell module using a command similar to the following.
Set-MsolUser -UserPrincipalName firstname.lastname@example.org -UserType Member
We're really excited about some of the big improvements we have coming over the next 90 days. This set of changes sets us up to be able to share them with you soon!
Alex Simons (twitter: Alex_A_Simons)
Director of PM
Active Directory Team
Is there some new/upgraded cmdlets coming with this as well? The set-msoluser doesn't list -usertype as an option:
and if I dump a full list of attributes for a user (Get-MsolUser -UserPrincipalName email@example.com | fl), I don't see usertype listed as a value.
How will this work if the current Azure Subscription Administrators using Microsoft Accounts have the same @domain.com as which is used in the Azure AD? Thinking along the lines of Azure Subscription that is linked to same Azure AD as Office 365. Admins
that were setup prior to ability to use Organisation IDs setup Microsoft Accounts with company email address. When I try to do this manually I get conflict saying you can't add members with same domain (don't remember the exact error).
What impact will this have on those of us that are not actively managing our members in Azure AD but have Microsoft Accounts? Will it be necessary to change the user from a Guest to Member or can we safely ignore this until we have more time to dig into
AD at a later date?
Your right that our documentation is not as up to date as our actual code. We are working on updating the documentation, but it is possible to set the value, you may need to get the latest version of our PowerShell module (see above) but it is there. Similarly
we don't expose all items in the general listing of a user. if you do the following you can see what value is set for a user.
$u = Get-MsolUser -UserPrincipalName firstname.lastname@example.org
(Get-MsolUser -UserPrincipalName email@example.com).UserType
or you can get all users and their type as follows:
Get-MsolUser | ft userPrincipalName,UserType
Hope this helps.
@dharbert: It's a good point and we have an allowance for this in the creation process so that we don't create a duplicate. Effectively, we will ensure that we don't break the user from being able to login in to the Azure management portal, but they will
look different in the directory as we make the username unique and update the domain portion. So some display differences but the user will be able to login and be part of the directory.
@Eli: You don't need to do anything. It will keep on working just as before.
I have a problem adding a co-administrator to a subscription and somebody says, that the problem belongs to the changes mentioned in this blog posting. Can anybody please check the validity of that?
Thank you very much!
BTW: I have a problem authenticating with the Microsoft Online Services Sign-In Assistant when my subscription contains a Microsoft Account and a AD user with the absolute identical user name. The web login asks for using "Microsoft Account" or "Company Account"
(which is the AD account) to solve that problem. The Sign-In Assistant seems to use the Company Account (AD account) without respecting the fact that there is also a Microsoft Account with the same user Name.
Sorry, in my previous post I meant "Organization Accounts" not "Company Account".