On a Windows 10 Azure AD Joined device the local Administrators group includes:
AzureAD\Admin (S-1-12-1-38678509…)
S-1-12-1-3346315821-114…
S-1-12-1-445845933-119…
Note that in this example the device was joined to Azure AD via Settings after already being set up with a local admin account.
That list would include the Azure AD user that performed the join and I assume the Azure AD global administrator role and Azure AD device administrator role. (based on info here https://learn.microsoft.com/en-us/azure/active-directory/devices/assign-local-admin)
It seems that the SIDs are being generated by Azure AD and are pushed (along with other bits of info) to the client in an ID token (based on info here https://jairocadena.com/2016/02/01/azure-ad-join-what-happens-behind-the-scenes/comment-page-1/#comment-3506)
However I can't find any tools that show a SID associated with an Azure AD entity. Does Azure AD in fact generate these SIDs and if so, is there any way to expose them to verify which SIDs match an entity?
I found an answer to this old question, and i think there are still people who can benefit from the answer. Before getting to the truth i tried to convert those SIDs to AAD usernames. Only to discover there is no SIDs in AAD only (cloud only) users.
https://www.petervanderwoude.nl/post/managing-local-administrators-via-windows-10-mdm/
Every Azure AD joined device contains two SIDs (one representing the Global administrator role and one representing the Device administrator role) that are by default part of the local administrators.
AAD Joinded device Administrator group
The SID of the Azure AD user is S-1-12-1- followed by the unsigned integer representation (4 parts) of the Azure AD Object ID.
https://kb.policypak.com/kb/article/862-how-do-i-get-azure-ad-sids-and-use-them-with-item-level-targeting/
If you want to get the user SID on the device, you could run the below command:
wmic useraccount get name,sid
It will return the local user list:
To get the SID for the current logged in domain user, you could run the command:
whoami /user
The return like this:
Related
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
I am trying to create a new service principal using the command below using azure cli v2.0.
az ad sp create-for-rbac --name ServicePrincipalName
Changing "ServicePrincipalName" to a valid URI of "http://ServicePrincipalName", which is the required format used for service principal names
Found an existing application instance of "abcd-8f27-47cf-9976-xkkfigif5e1de". We will patch it
Insufficient privileges to complete the operation.
I am not sure what privileges the Azure Admin of my tenant should assign to my user so i can create a servicePrincipal any guidelines or document pointers please
First, you have to know what this command will do. The command az ad sp create-for-rbac --name ServicePrincipalName will create an AD App(app registration) along with a service principal in your tenant, the AD App will have an Application ID URI named http://ServicePrincipalName, a Display name named ServicePrincipalName. Then the command will add the service principal to your subscription as a Contributor.
The error you got means there is already an AD App with the Application ID URI equals http://ServicePrincipalName existing in your tenant. And you are not the Owner of the AD App. (Note: in the tenant, the Display name is not unique, but the Application ID URI is.)
To solve the issue and use this command successfully, follow the tips below.
1.Change the ServicePrincipalName to a different one. (Or if your admin allow you to use the existing AD App mentioned above, just let him add your user account as an Owner to the AD App. - not recommend)
2.If your account's User type is just a Member in the tenant. Make sure in the portal -> AAD -> User settings -> Users can register applications is Yes. If your account is a Guest , except the Users can register applications need to be Yes, also User settings -> External collaboration settings -> Guest users permissions are limited need to be No.
3.Your user account should be the Owner of the subscription. Otherwise you can create the service principal successfully, but you cannot add it to the subscription.
I used Graph explorer->Logged in with Global administrator -> Modify Permissions-> chose User.ReadWriteAll,Group.ReadWriteAll,Directory.AccessAsUser.All and then select "access to your entire organization" and logged in again with global administrator
I get below error.
Selected user account does not exist in tenant 'Microsoft' and cannot
access the application 'de8bc8b5-d9f9-48b1-a8ad-b748da725064' in that
tenant. The account needs to be added as an external user in the
tenant first. Please use a different account.
How can I add permissions to global administrator user?
Since your account is a guest in the tenant, you could not use the account to query the tenant, even if you are a global admin.
For more details, refer to this post.
Credentials are only owned by a single tenant. The tenant is discovered by Graph Explorer based on domain. You cannot use Graph Explorer to query tenants your account is a guest on, it can only query the tenant that owns the account. The only way to use those creds with another tenant would be to force the OAuth uri to use that tenants ID instead of "common". This isn't supported by Explorer. You'd have to download the source an reengineer the auth process
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,
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.