As stated in this article from microsoft on group naming policies, selected administrators are exempted and able to override any given naming policy.
In my case I have registered an app that is used to run azure functions creating unified groups through the graph api.
I want to override the naming policy when using the app but I can't find a way to make it happen.
Any ideas?
The application you registered will have a service principal in Azure AD. Your application performs the actions under the service principal's identity.
You can assign the exempted roles to the service principal object of your application and then your application should be exempted as well.
You can find the role ID using this command :
Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Helpdesk Administrator'}
You can find the object ID of the service principal either by searching directly under enterprise applications or through PS using this command:
Get-AzureADServicePrincipal -searchstring (your enterprise application name)
Finally, you can assign the role to your application using this command:
Add-AzureADDirectoryRoleMember -ObjectId $AADRole.ObjectId -RefObjectId $service princiapl.ObjectId
Hope this helps.
Related
Recently I watched a course on Pluralsight.com, Getting Started with Azure Active Directory for Developers. In the section, Service Principals->Apps and Service Principals, the author said that we can create a service principal without app, and it's also possible to create an app without service principal. But he didn't show how to do so, and I cannot find out online how to do so either. So how can we do so? And can we do so from the Azure Portal?
Yes it is possible to create an azure ad app without creating a service principle(using powershell only) . Through portal if you will create it will create service princple along with app.
You can view the newly created app in the App registrations blade, under All applications in the Azure portal
Powershell cmdlet.
New-AzureADApplication -DisplayName "MTS Demo App"
It is not possible to create a service principle without creating an application. Service Principle will create an azure active directory as an application
# Create a service principal for a resource group using a preferred name and role
az ad sp create-for-rbac --name myServicePrincipalName \
--role reader \
--scopes /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName
Note : For creating Service Principle you need to admin role at the subscription level and Adminsitator role at Azure Active Directory Level.
Reference : https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli#code-try-0***
I would like to automate deployment and it requires to update settings for Azure AD Application registration.
So far I am able to :
create an Azure AD Appregistration and Service Principal with certificate (thx MS documentation)
then use command Connect-AzureAD with previous service Principal with its certificate
use command like Get-AzureADApplication -ObjectId 11111111-2222-3333-4444-555555555555
In previous bullet ObjectId 11111111-2222-3333-4444-555555555555 match with application i created on first bullet
However i am unable to execute command like:
Get-AzureADApplication -Filter "DisplayName eq '$aADApplicationame'"
and $aADApplicationame matches with application created previously
Set-AzureADApplication -ObjectId $aADApplication.ObjectId -ReplyUrls $ReplyUrls
Get-AzADServicePrincipal
I get following error message
Set-AzureADApplication : Error occurred while executing SetApplication
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation
Based on my research, i set up some API permissions as follow:
Unfortunately no luck and still get insufficient privilege although all permissions were granted.
Do you know if I miss something ? Is there any specific permissions i should add to make it works ?
Regards.
As mentioned by another reply, you could give the Global Administrator role to the service principal, it is correct, but the permission of Global Administrator is too large in this case, it may cause some security issues.
In this case, the commands Get-AzureADApplication and Set-AzureADApplication you used essentially call the Azure AD Graph API, so to solve the issue, a better solution is to add the permission of Azure AD Graph API, please follow the steps below.
1.Navigate to the API permissions of your AD App -> select Azure Active Directory Graph(not Microsoft Graph).
2.Select Application permissions(not Delegated permissions) -> Application.ReadWrite.All -> click Add permissions.
3.At last, click the Grant admin consent for xxx button.
After a while, try the commands again, it will work fine.
Update:
After I check the doc, I find there are already some new commands released by MS which call the Microsoft Graph, haven't seen them before.
e.g. In your case, you can use Get-AzureADMSApplication instead of Get-AzureADApplication.
Get-AzureADMSApplication -Filter "DisplayName eq 'joyttt'"
Use Set-AzureADMSApplication instead of Set-AzureADApplication.
Set-AzureADMSApplication -ObjectId <object-id> -Web #{ RedirectUris = "https://mynewapp.contoso.com/" }
For Get-AzADServicePrincipal, there is no equivalent currently, there should be one in the future. When using the commands above, the permissions of Microsoft Graph will work, no need to use Azure AD Graph, but you should use Application permission, not Delegated permission (you used the Delegated permission in your question.)
You are facing this issue because Powershell cmdlet works differently than compared to MS Graph. Instead of permissions, Powershell require roles to do this operations. Please add Global Administrator role to your service principle and then try the Connect-AzureAD so that, the issue will be fixed.
For more details, you may refer to Assigning administrator roles in Azure Active Directory.
I was also facing similar issue, make sure are doing below two things:
Set Run as account for azure automation account
In newly created app registration for azure automation account after setting Run as account, make sure you add Cloud application administrator role explicitly.
Add API permission for Application.ReadWrite.All (Microsoft graph)
In my case the app registration was showing cloud application administrator role under Roles and Administrator screen, which I thought gives the new app registration required permission but that was not the case. PowerShell script only worked after we assigned the cloud application administrator role explicitly.
In the beginning thanks for previous posts it gave a lot of inspiration according topic. Problem occurred in our case at automated bicep mechanism that is supposed to add API permissions for Microsoft Graph.
Error: Authorization_RequestDenied
Solution:
We needed to give Enterprise Application running mechanism Microsoft Graph (not Azure Active Directory Graph it will be deprecated) Application permissions:
Application.ReadWrite.All
AppRoleAssignment.ReadWrite.All
Directory.ReadWrite.All
My question is, do we have any documented method of granting a Manage Service Identity permissions to the Graph API as we would with an Azure App Registration in the portal? I was unable to find any Powershell options or ability to manage permissions for the MSI service principal in the Azure Portal or documentation. I found a similar question on MSDN forums, but wanted to make sure there were not any further updates or workarounds that anybody knew of?
MSDN Forum Post: https://social.msdn.microsoft.com/Forums/azure/en-US/dae34534-f193-4444-b52e-ba9cfa4a1fda/does-azure-msi-support-accessing-graph-api?forum=WindowsAzureAD
Disclaimer - I'm not overly familiar with MSIs, but as they are modeled as service principals, this should work. Also I'm not able to validate these steps.
These steps require that you use Azure AD PowerShell (v2) to assign application permissions to your MSI (to access Microsoft Graph), and that you are an administrator or app admin in your tenant. For Microsoft Graph, the documented permissions can be found here. The same instructions could be used for other resources secured by Azure AD too. I'll assume that you've already installed the PowerShell module.
Connect-AzureAD to connect PS to Azure Ad. Enter your admin creds.
$graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" to find the service principal representing Microsoft Graph and assign it to a variable. The service principal for Microsoft Graph is currently created just in time on first access, so there is a possibility it doesn't exist. It can be created by calling New-AzureADServicePrincipal -AppId "00000003-0000-0000-c000-000000000000".
$graph.AppRoles - this will show you all the available application permissions that you can choose from that are exposed by Microsoft Graph. For example if your MSI needs to read group information, find the "Group.Read.All" permission from the list, and make a note of its permission Id (it's a GUID). For example here's one of the records from the AppRoles list:
AllowedMemberTypes : {Application}
Description : Allows the app to read events of all calendars without a signed-in user.
DisplayName : Read calendars in all mailboxes
Id : 798ee544-9d2d-430c-a058-570e29e34338
IsEnabled : True
Value : Calendars.Read
Find your MSI's objectId (assuming you don't know it, but that you do know its clientId/appId):
$msi = Get-AzureADServicePrincipal -Filter "AppId eq '{Your_MSI_appId}'"
For each of the permissions your MSI needs, run the following PS cmdlet to assign the permission to your MSI:
New-AzureADServiceAppRoleAssignment -Id {permissionId} -PrincipalId $msi.ObjectId -ResourceId $graph.ObjectId
And that should do it. You should now be able to acquire an access token for your MSI to call Microsoft Graph, and the access token should contain a roles claim that matches the permissions (ids) that you've assigned above. You can then use that access token to call Microsoft Graph. This is similar to steps 6 and 7 in https://learn.microsoft.com/en-us/azure/active-directory/msi-overview.
Hope this helps,
The RequestDenied message is expected. There was a change to this that updating the System MSI SP is now blocked.
If one synchronizes custom attributes via Azure AD Connect, schema extensions are made to Azure AD and there is an associated application made in Azure AD with a DisplayName of "Tenant Schema Extension App".
Unfortunately, these extensions are uniquely named, as well with extension_AppIdGuid_attributeName.
With the Azure AD PowerShell module, it is easy enough to find this:
$ExtensionGuid = ((Get-AzureADApplication |
Where-Object {$_.DisplayName -eq "Tenant Schema Extension App"}).AppId).Replace("-","")
These can also be queried within the Microsoft Graph. However, I cannot find a mechanism within the Microsoft Graph to find what the AppId is.
I have queried:
/organization
/schemaExtensions
/$metadata
The Azure AD Graph seems to have the capability, but it is going away and the Microsoft Graph is the future. I want it there. Any help is appreciated.
You can find the Tenant Schema Extension app in Microsoft Graph via the following query:
https://graph.microsoft.com/beta/applications?$filter=displayName eq 'Tenant Schema Extension App'
Unlike the Azure AD Graph which Application object which has an id and an appId, the Microsoft Graph Application object only has an id property which corresponds to the appId value in the Azure AD Graph.
Note: As per the Microsoft Graph documentation for GET /applications you require any the following permissions:
Delegated (work or school account): Directory.Read.All, Directory.ReadWrite.All, Directory.AccessAsUser.All
Application: Directory.Read.All, Directory.ReadWrite.All
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.