I am trying to delete user on Azure AD using the Graph Api but everytime i tried i came across error saying
Insufficient privileges to complete the operation.
After doing some research I found that we have to add application to “company administrators” role on Azure for delete user to work.
When trying to add the role I am getting below error.
Add-MsolRoleMember : This role does not exist. Check the name and try again.
At line:1 char:1
+ Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Add-MsolRoleMember], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.RoleNotFoundException,Microsoft.Online.Admini
stration.Automation.AddRoleMember
I believe you should be able to easily overcome this problem by using the RoleObjectId parameter in Add-MsolRoleMember.
I cover in my blog post here exactly how to do this using the MSOL PowerShell Module, and I use a few steps to first get the object Id of the Company Administrator role, and then assign it to the Service Principal.
Note that this will only affect the access your app has in your tenant.
Also you must already be a Company Administrator of the tenant to follow these instructions.
In order to make the change, you will need to install the Azure Active
Directory PowerShell Module.
Once you have the module installed, authenticate to your tenant with
your Administrator Account:
Connect-MSOLService
Then we need to get the Object ID of both the Service Principal we
want to elevate, and the Company Administrator Role for your tenant.
Search for Service Principal by App ID GUID:
$sp = Get-MsolServicePrincipal -AppPrincipalId <App ID GUID>
Search for Directory Role by Name
$role = Get-MsolRole -RoleName "Company Administrator"
Now we can use the Add-MsolRoleMember command to add this role to the
service principal.
Add-MsolRoleMember -RoleObjectId $role.ObjectId -RoleMemberType ServicePrincipal -RoleMemberObjectId $sp.ObjectId
To check everything is working, lets get back all the members of the
Company Administrator role:
Get-MsolRoleMember -RoleObjectId $role.ObjectId
You should see your application in that list, where RoleMemberType is
ServicePrincipal and DisplayName is the name of your application.
Now your application should be able to perform any Graph API calls
that the Company Administrator could do, all without a user signed-in,
using the Client Credential Flow.
Let me know if this works!
In-addition to Shawn Tabrize's solutlion. We can acquire the token which's contains corresponding permission to call the Graph API. For example, if you were requesting using Microsoft Graph REST, the Directory.AccessAsUser.All (refer here). And you need to use the admin of that tenant to acquire this access token in this scenario.
To check whether the token contains the correct permission, we can decode it from this site.
Related
AAD complains about errors in the sync process.
But I don't understand what the duplicate is there.
Already tried a full import, delta import, full sync etc.
How do I find the duplicate?
There are three attributes mainly checked during azure ad connect: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID in Azure AD Connect.
You can make use of IDFix tool to identify the duplicate objects.
Please Check below scenarios if they are the cause:
If you/ User is Global Admin
Try to remove the role and sync the user without admin role or by adding user role.After the sync then you can add the role again.
Or
If it is already in sync ,Disable the directory sync process ,then delete the user
from domain (on-prem directory) and then do the azure ad sync and then add the
user role to admin back if required.
During Azure ad connect , we must take care of SMTP Soft match and ImmutableID hardmatch. soft-vs-hard-match
$credential = Get-Credential
Connect-MsolService -Credential $credential
$ADUser = "username"
$AzureADUser = "username#emaildomainname.com"
$guid =(Get-ADUser $ADUser).Objectguid
$immutableID=[system.convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName "$AzureADUser " -ImmutableId $immutableID
This can take care of mismatch .See error-type-attributevaluemustbeunique & this
Note : Please do resync after any changes.
Other references:
Azure AD Sync, duplicate user - Server Fault
Troubleshoot directory synchronization errors | Microsoft Docs
diagnose sync errors (github.com)
AAD connect design concepts
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
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
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.