When I try querying extensionAttribute with Graph API (Hybrid Exchange), I cannot get any value.
E.g., if I try: https://graph.microsoft.com/v1.0/users/<userid or upn>?$select=extensionAttribute2, I cannot see the value even I know it’s there.
Do you know how to get it properly (or a workaround)?
Thank you
Are these values synced to Azure Active Directory? All properties for the AAD User can be found in the Microsoft Graph API docs here : https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
It sounds like these are being synced from an AAD Connect environment, so it's most likely you are trying to get the onPremisesExtensionAttributes.
Per the description:
Contains extensionAttributes 1-15 for the user. Note that the individual extension attributes are neither selectable nor filterable. For an onPremisesSyncEnabled user, this set of properties is mastered on-premises and is read-only. For a cloud-only user (where onPremisesSyncEnabled is false), these properties may be set during creation or update.
I suggest taking a look more thoroughly through the documentation in regards to this. In addition to that, as you mentioned Exchange, note that the custom attributes from exchange are the same as the extension attributes. For more info on this see : https://github.com/microsoftgraph/microsoft-graph-docs/issues/5950
This is a separate sort of "Extension Attribute" but I figured I would include this in the answer as well. There is a different extensibility section for the Microsoft Graph, and the docs on this can be found here : https://learn.microsoft.com/en-us/graph/extensibility-overview
If you see information on these extensions, know that this is separate from the on-prem extensions.
Related
We've created an application using SCIM 2 SDK from PingIdentity for provisioning with Azure AD. Custom mapping is set up and working.
However, when the user is CREATED, all of the fields are included in the import, but only a few fields are included in the provisioning step and sent to our application. Provisioning needs to run a second time on that user to UPDATE in order for all the fields to be included. Amongst other things, this means that first and last name are not split and it only sends the displayname (which ends up as firstname on our end).
For some users in normal provisioning, it can take days between the create and update runs so we're missing data for a long time.
Anyone know how can we can test for what's causing this and solve it so all the fields are included in the initial CREATE run for a user?
Here are the attribute mapping settings: https://imgur.com/ypfAAmD
And an example log of when the user is created with only basic fields: https://imgur.com/iOXACJh
vs. when the user is updated with all the other fields: https://imgur.com/UqDNyCv
I'm a product manager at Microsoft that works on the provisioning service and our SCIM client.
The behavior you're seeing occurs when you have attributes that are not part of the SCIM core schema included as "short" names. Attributes not defined in the SCIM core schema (RFC 7643) should have full URN syntax. Something to the effect of urn:ietf:params:scim:schemas:extension:appName:2.0:User:attributeName is commonly used by other implementations. The shaky behavior you're seeing where the AAD provisioning service fails to send these attribute values via a POST but later includes them in a PATCH comes down to different code paths in the AAD provisioning service, and the PATCH code happens to handle this differently than the POST code. This is purely by chance, however, and isn't an intentional design choice. At some future point I'm hoping we'll make this more consistent and disallow incorrectly structured attribute names entirely.
If you adjust your attribute names to align with the guidance in the SCIM spec's schema RFC and provide the attributes with fully defined URNs, you should see consistent behavior that works on both POST and PATCH.
This is my first question, so I hope I don't miss a thing. To be clear from the start: I don't expect an answer which dives deep into detail. This is just about getting a general understanding of how to work with this kind of software.
So I don't know if "Identity Management System" is a suitable term for what I mean but when I talk about Identity Management Systems I think of something like Azure AD, which as far as I know provides e.g. web developers the possibility to integrate a way users can authenticate (including access privilege etc.) on their website.
What I'm quite unsure about is how to work with/ integrate such tools in a project. I will try to make it clear with an example: Assuming I have a website let's say this website is a blog. The blog consist of different posts which are stored in my own database which is connected to the website. The posts are written by different users which authenticate with a tool like Azure AD. The user's data is stored somewhere on a server run by e.g. Microsoft. If I want to display the posts togethere with the name, email.... of the user who wrote them, how would I do this?
Is it possible to query the user's data directly from the Identity Management System and display it? This does not sound ideal to me as the consequence would be that data the website uses is stored in two different locations.
Would you kind of copy the user's data from the Identity Management System to the websites database and query it from there? This does not sound like a good solution either because then data would be duplicated.
So whats the "right workflow"?
I appreciate any hints and further information I can get:-)
AFAIK To get the user's information like name, email etc. you can add these claims while generating the JWT token.
To generate access token, you have multiple authentication flows such as Authorization code flow, ROPC flow, Implicit flow.
To add the claims that you need to return with the token, you can make settings like below:
Go to Azure Portal -> Azure Active Directory -> App Registrations -> Your app -> Token configuration -> Add optional claims
When you decode the token via JSON Web Tokens - jwt.io you can find the user information that you need.
To know how to generate access token, you can refer SO Thread which I solved it before.
I'm trying to get the preferred username of a user via the Graph API for Microsoft Office / Azure
If a user logs in via an enterprise application with an id_token I get the preferred_username claim.
This has the user's actual email address.
If I try to look up the user separately by ID, I can't find any way to get that username.
Seems related to Sign-in to Azure Active Directory using email as an alternate login ID (preview).
The user in question is using a GitHub linked account, it likely has an ugly UPN that I would prefer not to be seen anywhere. Instead I would like to use their preferred_username.
Example "ugly" UPN":
***_gmail.com#EXT##***gmail.onmicrosoft.com
To my knowledge, the preferred_username value isn't exposed by Graph in either v1.0 or Beta.
One potential workaround is to use the otherMails property. This is an array, so this may contain multiple entries for a given user. That said, any otherMails entry is likely to be less 'ugly'.
As per the guidelines specified in the Microsoft Azure Docs, I have configured a custom attribute to sync with Azure AD.
When viewing the Tenant Schema Extension App in the Microsoft Graph Explorer
using /beta/applications/Blocked_Tenant_Schema_Extension App_Id/extensionProperties, I can see the extension property has been registered.
The problem is I can't work out how to view this in the Microsoft Graph for a user.
I have tried using Extensions for a user, but can't see it against that.
I have also tried using Directory Object in the Microsoft Graph https://graph.microsoft.com/beta/directoryObjects/Blocked-User-Id?$select=id,extension_Blocked-App-ID_otherTelephone
If you get the user and $select the extension, it should be returned.
E.g.:
https://graph.microsoft.com/v1.0/users/user#company.com?$select=id,extension_b569610d09e44cddbadeb9beaaaaaaaa_ApiRoles
One important thing to note is that the property has the app's id without dashes.
I'm having a problem with Microsoft Graph API... Currently I have a web application that has an openid integration with Microsoft/Azure using the common v2 endpoint.
We are trying to get the signed in user company name and job information. The official docs say that we need to make a request to the MS Graph API.
We are testing it on Microft Graph Explorer but it doesn't seem to work.
We've selected the 'User.Read' as a permission in our app, then tried these endpoints:
https://graph.microsoft.com/v1.0/me/
https://graph.microsoft.com/v1.0/me?$select=companyName,jobTitle
https://graph.microsoft.com/v1.0/users/?$select=companyName,jobTitle
In MS offical doc (https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference) on User/Remarks sections, it clearly says that
"On reads, only a limited number of properties are returned by default. To read properties that are not in the default set, use $select"
Is this doc outdated?
I've tried to reach MS support for developers, but they answered saying that I should ask this on Stack Overflow...
So probably there are no official support for developers?
Is it really possible to get the company name and job title from a MS account?
Thanks in advance!
edit. Update question with MS graph explorer screenshots
edit.2. Update screenshot with proper encoding.
Also, it's a MS account not an Azure account, since our web app accepts both of them on the common v2 endpoint.
Update
My goal was trying to get the Work Info section from a MSA account.
The documentation is correct, by default we only return a subset of user properties:
id
userPrincipalName
displayName
givenName
surname
jobTitle
mail
mobilePhone
businessPhones
officeLocation
preferredLanguage
If you want a different set of properties, you can request them using the $select query parameter. The queries you provided in your question should work fine. For example, when I execute https://graph.microsoft.com/v1.0/me?$select=companyName in Graph Explorer (after logging in with my credentials) I get the following:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(companyName)/$entity",
"companyName": "MICROSOFT"
}
Update Regarding MSA
When using Microsoft Graph against a Microsoft Account (MSA) there are several differences in what properties get surfaced. As an MSA is by definition a personal/individual account, organizational properties such as Job Title and Office Location are simply not applicable.