So there are a bunch of application registrations that are ownerless on the tenant in Microsoft Azure and I was wondering if there is a way to find out WHO created the application registrations in the tenant.
You can find who created an ownerless application in the Azure AD audit logs filtering by Service eq "Core Directory", Category eq "Application Management" and Activity eq "Add application". The Initiated by (actor) will contain the (user or service) principal that created the application.
Keep in mind that logs are persisted only for 7 days minimum and 30 days maximum unless custom archiving has been configured.
Related
If users once synced with Azure AD Connect Cloud Provisioning can be moved to synchronization via Forest trust without having to remove and re-add the users?
Cloud provisioning can be used to sync from multiple Active Directory forests. In the multi-forest environment, all the references (example, manager) need to be within the domain. Users and groups must be represented only once across all forests.
Kindly check the document for Azure AD connect cloud provisioning supported topologies to get detailed information about this
I am using Redgate Data Platform Studio to transfer data from on-premise SQL Server to Azure-hosted SQL Server. This web-based application has the ability to use an Azure Storage account (for data transfer purpose) simply by logging into my company's ADFS. The web application can successfully see storage accounts inside a subscription (let's call it Subscription A) owned by my ADFS user, when I log in to my company's active directory (via ADFS). Let's call my company's AD Directory A.
I also have subscription B owned by a Microsoft account NOT related to my company's Active Directory. This subscription B is managed by another Azure AD Tenant B, with that Microsoft account as the Service Administrator & Owner. To link the two directories, I used B2B State 3 configuration described here. So in Directory B, my Directory A user shows up as Guest User with the Source=External Azure Active Directory.
For the storage accounts in Directory B, I grant the built-in role "Storage Blob Data Contributor" and "Storage Account Contributor" to the Guest User (source=external AAD Directory A). Therefore, in both Microsoft Azure Storage Explorer as well as in portal.azure.com I can see storage accounts inside Subscription B.
BUT if I log in to the Redgate application using Directory A credential (via my company's ADFS), only storage account inside Subscription A shows up in the Redgate application. I already tried giving the guest user in Directory B the following roles to the user, even at the highest Subscription B level, but no luck:
As Co-Administrator
As Contributor
As Storage Account Contributor
As Storage Blob Data Owner
My question: is this the application's limitation of not being able to access subscription in another directory (B), or is there some configuration either in directory A/B and/or subscription A/B that I need to set?
Is this the application's limitation of not being able to access subscription in another directory?
As per my official document and my understanding you cannot assign your subscription among many directory.
As said on official document "Multiple subscriptions can trust the
same Azure AD directory, but each subscription can only trust a single directory".
See the below screen shot and refer here
Note: When you associate a subscription to a different directory, users that have roles assigned using role-based access control (RBAC)
will lose their access. Classic subscription administrators
(Service Administrator and Co-Administrators) will also lose
access. Please check the Important Note here
If you want to know more details please refer this docs
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,
When RBAC was introduced in Azure Active directory, roles can be granted to users or collection of users (groups).We followed this blog post and added that functionality for our apps when it first got introduced. But now, we have to go for active directory premium to assign roles to groups and get roles in bearer token.Going with Azure Active directory is not a feasible solution for us as premium is gonna cost us $6 user/ month and we have lot of groups and each group has lot of users. Looking at the costs our IT team is not willing to go for this package. I was just wondering if there an alternative approach for mapping roles to groups. Or this is only doable using premium.
Using Azure Active Directory (Azure AD) with an Azure AD Premium or Azure AD Basic license, you can use groups to assign access to a SaaS application that's integrated with Azure AD( refer here about detail).
So if you want to manage the roles using the group, we need at least the Azure AD Basic license. If you were using the free edition, we can only assign the roles to the users one by one.
Instead using the role manage the access for the application, we can also use the group which also supports for the Azure AD free edition. You can check the code sample about authorization in a web app using Azure AD groups & group claims from here.
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.