I have a question similar to: On premise Active Directory ObjectId is different than Azure Active Directory ObjectId
We used objectGUID in AD to uniquely identify the users and groups. We also maintain the group memberships using objectGUID. When querying Microsoft tenant using Microsoft Graph, what we see for the id from User or Group objects is different from what we get from the on-prem AD. This makes it difficult to correlate the AAD and AD resources.
I tried to use onPremisesImmutableId using the request below, only to find that this id is my employee id.
/v1.0/me?$select=id,userPrincipalName,onPremisesSecurityIdentifier,displayName,onPremisesImmutableId
Any idea how to retrieve the same objectGUID in the AAD world? I could not find anything close by looking at the User documentation.
Also for Group objects, I could not find the property onPremisesDomainName, similar to that in User objects. Is this by design?
That was the correct answer back when was written but things have changed a bit since then. There is an excellent blog post at Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid that discusses this change. Specifically this bit:
Before Azure AD Connect version 1.1.524.0, Azure AD Connect (but also Azure AD Sync and DirSync) defaulted to the objectGUID attribute for objects as the source anchor. Azure AD Connect version 1.1.553.0, and beyond, defaults to the mS-DS-ConsistencyGuid for user objects, but objectGUID for groups and computer objects.
In your case, it sounds like your particular tenant mapping was configured differently (i.e. your employee id).
Given the issues raised in the blog post, I'd recommend against using objectGUID for this purpose altogether. If you're looking for a single property across both User and Group resources, I'd suggest looking at onPremisesSecurityIdentifier instead. This holds the SID from your on-prem AD.
Related
I'm trying to setup a user lifecycle flow that will allow me to create an Azure Active Directory user (Member, not Guest) when an employee is created in our HRIS tool (HiBob). There is a pre-existing integration which is enabled and allows us to get basic information (name, location, etc.).
In the HRIS system we also store some more unique data that I would like to be added to the users AAD profile (maybe an emergency contact for example) that we can then use to provision other applications (like Slack).
My issue is trying to create these custom property fields. I have read about Azure B2C as well as directory schema, custom security extensions and using MS Graph. None of these seem to be totally relevant to my situation.
FYI we are fully cloud, so Azure AD Connect is also not an option.
To store custom data in Azure AD objects such as users you can leverage Azure AD Directory Extensions in tandem with Azure AD Provisioning trough SCIM.
I am setting up a new company and we are using Azure AD. We are remote-first and cloud-only. We do not and will not have an on-premises Active Directory controller.
How is it recommended to store employee data such as birthday, hire date, and social security number? It is unclear how to extend the schema. When I try to fetch a birth date using the Graph API, I get "Error message: This operation target is not yet supported.". When I extend the schema using "External Identities -> Custom User Attributes", I don't see a way to edit those inside the Azure AD portal.
My administrative interface is a Java application built using the Microsoft Graph API. It works fine for the standard fields (e.g., displayName, givenName, surname, etc.).
I am currently integrated with a PostgreSQL database in Azure using the authentication that works against the Azure AD API. That works fine and I can put employee metadata there, but is is not clear if I should.
We can store the employee data like birthday and hire date in azure AD through couple of ways.
One way is to use azure ad connect (if you have on premise active directory) and the other way is using schema extensions. You need to use Microsoft Graph API to work with azure ad schema extension, there is no direct option to extend the schema from azure portal.
Please follow the steps in this doc to Create schemaExtension
Schema extensions are supported for following resource types.
1.contact
2.device
3.event on a user or Microsoft 365 group calendar
4.post of a Microsoft 365 group
5.group
6.message
7.organization
8.user user resource type
Here is the reference article written by #Toni PohI, About Azure AD schema extension Working with Azure AD schema extensions and Microsoft Graph
Using AAD Connect you can flow an extension attribute from AD to the MV attribute employeeHireDate which will export successfully to AAD.
Make sure your extension attribute uses Generalized-Time syntax. These dates are strings in the format "YYYYMMDDhhmmss.0Z".
Then create an inbound sync rule to populate employeeHireDate
This will flow to AAD. This was completed with AAD Connect Version: 2.1.16.0
My problem is that we have 2 On-Premises Active Directory domains:
mycompany.com
mycompany-dev.com
Some people are present in both of these AD-s. I want to sync them with Azure Active Directory so that they are all represented once, and all have the #mycompany.com suffix (instead of #mycompany.onmicrosoft.com). I also don't want some users to have #mycompany-dev.com in their azure AD account login name, so I want to do some sort of mapping I guess.
Is this possible with Azure AD Connect, or do I have to implement a synchronization method manually?
You can sync multiple on-premises domain to Azure AD. Kindly check the link and you will get a detailed information about different topologies supported
Do AAD Group objects have onPremisesDomainName property, similar to that in User objects. I did not find it in the doc
Just wondering why there isn't a parity with User objects.
The onPremisesDomainName contains the on-premises domainFQDN, also called dnsDomainName synchronized from the on-premises directory.The property is only populated for customers who are synchronizing their on-premises directory to Azure Active Directory via Azure AD Connect.
The domainFQDN and DnsDomainName have been added for Group objects as of version 1.1.553.0. https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history
There are a number of similar threads worth checking out.
Find Domain Name in Active Directory
Get domain\username from microsoft graph
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.