I have 2 users in Azure AD
Microsoft Account user
Microsoft Azure Active Directory user
User 2 always works in Graph API calls but not the user 1.
https://graph.windows.net/tenantid/users/testmail#hotmail.com?api-version=2013-04-05
(Email actually is url encoded as testmail%40hotmail.com).
This gives the following error
"{\"odata.error\":{\"code\":\"Request_ResourceNotFound\",\"message\":{\"lang\":\"en\",\"value\":\"Resource 'testmail#hotmail.com' does not exist or one of its queried reference-property objects are not present.\"}}}"
Does anyone know how to fix this?
Edited:
Things I figured out trying to fix this. I am using UserPrincipal name in the query above(..users/testmail#hotmail.com?..). For built-in domain accounts userPricipal name is testmail#domain.com(this works) but for a Microsoft account userPrincipal name is testmail_hotmail.com#EXT##domain.com. This was given in the all users list (https://graph.windows.net/tenantid/users?api-version=2013-04-05). But even when I changed the query to '..users/testmail_hotmail.com#EXT##domain.com?..' ofcourse after url encoding(testmail_hotmail.com%23EXT%23%40domain.com), still it does not work. Objectid always works though for all accounts(..users/objectId?..) .
Also tried otherMails. May be the api is wrong as otherMails is an array. "https://graph.windows.net/tenantId/Users?$filter=otherMails eq 'testmail%40hotmail.com'&api-version=2013-04-05"
So the question still remains. if only email is available for an MS account(not objectid) when making the call, how to get user details?
You are missing your domain in the URL you posted. It should be
https://graph.windows.net/[your Azure AD domain]/users
To get the email address for a user you need to add the object Id of the user in the request URL. So, for example, to get an Azure AD user it would be like this:
https://graph.windows.net/[your Azure AD domain]/users/[object ID of user]/mail
For users in the directory sourced from a Microsoft Account, the mail property is null. So, you will have to look in the otherMails property like this:
https://graph.windows.net/[your Azure AD domain]/users/[object ID of user]/otherMails
If you want to access the full user account using a user's UPN, you can do that for users sourced from Azure AD. For example, for a tenant domain contoso.com and a user with a UPN johndoe#contoso.com, the query would look like this:
https://graph.windows.net/contoso.com/users/johndoe#contoso.com
This doesn't work for users sourced from Microsoft Accounts. For these accounts, the UPN contains characters (#, . for example) that break the query. You can filter by the UPN though using the naming convention that is used for users sourced from Microsoft Accounts. Suppose you have a user whose email is jayhamlin#yahoo.com in your directory. The UPN would be something like jayhamlin_yahoo.com#EXT##contoso.com. So, you could use a filter and look for the first part of the UPN like this:
https://graph.windows.net/contoso.com/users?api-version=2013-11-08&$filter=startswith(userPrincipalName, 'jayhamlin_yahoo')
You can easily explore the Graph API and object properties for your directory using https://graphexplorer.cloudapp.net.
That filter can work, but you could also filter on otherMails. Your original query didn't work because otherMails is a multi-valued property- so you need to use "any":
https://graph.windows.net/tenantId/users?api-version=1.5&$filter=otherMails/any(x:startswith(x,'testmail#hotmail.com'))
When are you using this lookup? Is it once the user has signed in or for some people picking scenario?
Cheers,
Related
Hoping someone can shed some light on the following matter;
I got an Angular & .Net core Web API application that uses Azure B2C to authenticate users.
User accounts are created by the users themselves via the signin/signup custom policy or administrator can create accounts via the app using the Graph API.
Due to the requirements, the app uses usernames (as opposed to email addresses) to log into the application. So far I've managed to get everything working except for the following scenario:
When an account is created via the Graph API, the owner of that account cannot reset the account's password. The error is "An account could not be found for the provided user ID".
This isn't the case for accounts that get created via the custom signup policy so I did some comparison and found that for those account that get created via the Graph API, the Email is missing (which can be found under User -> Authentication Methods). I looked at populating that field, but it appears the "Mail" attribute is 'read only' (not sure if that's the right attribute anyway).
At the moment I'm having to manually set the email via Azure so those account's passwords can be reset by their owner if necessary. This is obviously not ideal and wanted to see if there is anyone that might have gotten around this issue, or a least get confirmation that this is indeed a limitation of the Graph API.
Thanks in advance for your help
So I managed to get this working using the approach outlined by Jas Suri. These are the steps that I went through
Created a custom attribute in my B2C tenant to hold the account email address
Included the custom attribute claim type (extension_emailAddress) as well as the strongAuthenticationEmailAddress in the TrustFrameworkBase.xml
Updated my apps's custom policies to include the technical profile for local account discovery. I basically just copied the necessary bits and pieces from here
Updated the local account discovery to perform the comparison against the extenstion_emailAddres instead of strongAuthenticationEmailAddress.
Added an extra step to the Sign up user journey so that the value in strongAuthenticationEmailAddress is copied to extension_emailAddress
Updated my Web API / Graph API "create user" function so that it sets the extension_appidguid_emailAddress
That's it. Now it doesn't matter how the account gets created, the email address will be stored in the extension attribute and the password reset will be able to find the account using that attribute.
happy to provide more details if anyone comes across this.
The problem is as you’ve identified, the Sign Up policy uses the strongAuthEmail attribute to store the verified email for a username based account. The Password reset policy will use this to verify the user owns the username. When creating the user with graph api, you can’t populate this field, it’s not exposed. The only option is to use a custom policy which stores this secure email in an extension attribute, and your graph api created users can then also target the same attribute to allow the stars to align.
Mail attribute is not the same as the Email under Authentication Methods, and currently there is no such graph api to set the Email value under Authentication Methods.
By the way, there is no need to create Azure AD B2C user for a user as users can sign up themselves.
We are trying to set up Azure AD connect, but we seem unable to get to the situation we desire.
Our current situation is a local AD where we fill in the email field for all users (and all external users). Our admins have a normal and an admin account. The email for the adminaccount is the same for all. We don't have Exchange linked to AD, nor do we yet have the possibility to set up ADFS.
I've been trying to set up the sync for the admins only. So let's assume the following situation:
Account 1:
SamAccountName: Admin1
UPN: admin1#company.com
Email: Admin#company.com
Account 2:
SamAccountName: Admin2
UPN: admin2#company.com
Email: admin#company.com
Our first sync stopped after the first one, with the message that the UPN is duplicate.
When checking, AAD had 1 account:
Account 1:
UPN: admin#tenant.onmicrosoft.com
So, I undid everything and started from scratch. This time, I changed account 2 to not have an email. This is the result:
Account 1:
UPN: admin#tenant.onmicrosoft.com
Account 2:
UPN: admin2#tenant.onmicrosoft.com
So basically, we want our UPN to be like SamAccountName#tenant.onmicrosoft.com, but it seems like we need to clear the email field, sync and fill it again. A lot of our internal tools use the email field currently, which makes it quite impossible.
I tried changing the Azure AD connect setup as well, to change the place where they ask for UPN to SamAccountName, but either I get errors or it doesn't work. What am I missing.
We also have accounts for external partners, something like this:
SamAccountName: partner_userx
UPN: partner_userx#company.com
email: someuser#externalpartner.com
If I sync this, the AAD UPN was someuser#tenant.onmicrosoft.com.
If I set up everyting in staging and take a look at csexport output, I see nothing special. Just the properties described as they are on my local AD.
For some reason the Sync uses the mail field, which I do not want.
Sorry for the delayed response. Azure AD is picking up the email address as the UPN prefix value and appending your initial domain (e.g. #tenant.onmicrosoft.com) simply because the UPN suffix being sync'ed from on-premises is not valid/not verified domain. If you have the AD:UserPrincipalName set on-premises and its UPN suffix is a Verified Domain on your Azure tenant it should work as you expect. Meaning, you'll get the expected UPN value in Azure AD, if you sync a UPN suffix with a domain that is verified on the tenant (either a custom domain or the tenant's initial domain).
Taking the example provided:
SamAccountName: partner_userx
UPN: partner_userx#company.com
email: someuser#externalpartner.com
You need to either:
a) set the on-premises UPN as partner_userx#tenant.onmicrosoft.com instead, or;
b) verify the domain 'company.com' on your Azure AD tenant
If neither of these options are feasible then you'll have to work on some advanced sync rule customization (which is not supported) to map an alternative AD attribute to serve as the source attribute for the UPN and set this attribute with the alternative UPN value containing a verified domain suffix (e.g: extensionAttribute10 = partner_userx#tenant.onmicrosoft.com)
Basically, I just want to use Microsoft Graph to get a list of active directory users and their email addresses.
Ideally, I could get all the admin users for a certain subscription.
How do I do that? I couldn't find any good examples online.
Assuming you have the correct access to a tenant, and an authenticated token granting you access to the Microsoft Graph, you can use the following REST API calls to get the data you are looking for:
List Users - Documentation
GET https://graph.microsoft.com/v1.0/users
List Admins (via directory roles) - Documentation
This is a multi-step process. First you must find the directory role for the Company Administrator, which will always have the roleTemplateId of 62e90394-69f5-4237-9190-012177145e10. This should not be confused by the actual directory role id, which will be different per directory.
GET https://graph.microsoft.com/v1.0/directoryRoles
Then you want to list the users who are a part of that directory role:
GET https://graph.microsoft.com/v1.0/directoryRoles/<id>/members
If you really need to get started from scratch, I recommend you look at this PowerShell sample I made which simplifies authentication, and allows you to make queries to resource endpoints like the Microsoft Graph.
https://github.com/shawntabrizi/Microsoft-Authentication-with-PowerShell-and-MSAL
My customer is in the process of modifying all of their UPNs to match their primary SMTP. They have a few Azure AD Directories and around 100 of the accounts they are changing the UPN are external users in the other Azure AD directories (for admin purposes). As I understand it, after adding an external user, any attribute changes are independent and not synced over after that point.
If these users have their UPN change, will they still be able to log in to the external? If so, what attribute is being used to verify the account? Is it ObjectID, liveID or something else?
If these users have their UPN change, will they still be able to log in to the external? If so, what attribute is being used to verify the account? Is it ObjectID, liveID or something else?
Yes, it is possible.
The Azure AD external users doesn't use the ObjectID, liveID to link to the users in the orignal tenant. You can using PowerShell( get-msolUser) list and compare these proprieties. It seems that it use the internal field however I am not able to find the relative document about this.
I have created a trial account for Microsoft Azure. In Azure Active Directory, I'm trying to create a new user, but I'm not seeing email address field. I see only username, firstname, lastname and display name fields. Will Azure treat username (like testuser#mydomain.onmicrosoft.com) as an email? or I'm I missing something? I didn't find much information in its documentation.
No, Azure AD will not assume that the username (known as "UserPrincipalName", in the Azure AD Graph API and Azure AD PowerShell module) is actually an email address that can receive emails.
If you would simply want a place to store a given user's email address (one that actually has a mailbox behind it), you can use the "Alternate Email Address" field in the Azure Portal (under "Profile" section for a given user in your directory):
(Note: This field is known as otherMails in Azure AD Graph API, AlternateEmailAddresses in Azure AD PowerShell v1 (MSOnline), and OtherMails in Azure AD PowerShell v2 (AzureAD). In all cases, it's an array of strings, not a single value.)
You can create more user-friendly usernames by adding and verifying a custom domain name to you Azure AD directory: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-add-domain. Once you've done this, you can create users that have usernames such as user#contoso.com (assuming contoso.com is the domain you added).
At this point, it may be that user#contoso.com is also the email address of that user, but again—there is no assumption in Azure AD that this is the case.
For anyone running into issues using with this with an Office 365 developer account, make sure you go through the entire registration process. I thought I had completely setup my office 365 dev account, but I had missed a part related to setting up email.
Also if you are using your personal Microsoft account, for testing etc., be aware that it may appear like some things work the same as the full version or Office 365 dev, but they don't.