Change service principal owner to group - azure-active-directory

Is there a way to change the owner of an Azure AD service principal after it has been created? And can it be changed to a group that should own the SP?
When creating with az ad sp create-for-rbac it doesn't allow you to specify the owner.
I'd like to change the owner for a SP to a different AD principal (group).

It looks like this is not a current feature. Another relevant discussion is on GitHub.

Related

Is there a way to manage snowflake default roles like Accountadmin via Scim Api calls

Is there a way to manage snowflake default roles like Accountadmin via Scim Api calls.
I want a user to get Accountadmin role in snowflake when its added to the corresponding group in Active Directory. I know that in order to create a group-user association using Scim call, I need the snowflake group ID for that particular group. In this case, the group is Accountadmin and I don't think there is a way to get the group ID for the same. Even if I get the group ID, the Scim calls won't work because Accountadmin is not owned by the Generic_Scim_Provisioner role.
Note: I am using custom SCIM integration to sync snowflake with the Active Directory. All the roles and users created in snowflake are owned and managed by Generic_Scim_Provisioner role, as suggested here:
https://docs.snowflake.com/en/user-guide/scim-custom.html
You could create a custom role called SCIM_ACCOUNTADMIN or something along those lines, grant ACCOUNTADMIN to that role, and then use the group ID of SCIM_ACCOUNTADMIN for the SCIM integration. It's a bit of a workaround, but should work pretty nicely.
you have to create the accountadmin group in AD as SCIM in AD mapped groups to role in Snowflake, so any users assigned to the group gets provisioned in snowflake and with default accountadmin role.

Change owner of Azure AD

How do you change the owner of an Azure AD directory? I have two accounts and see the tenant/directory I want listed as a directory. I want to transfer the ownership to the other account.
UPDATE
Ok. More information. I had one subscription and created 3 B2C directories. Each time I linked to the subscription, which is part of the process. Apparently you cannot have more than 1 B2C tenant linked to a subscription, so the other two were left "stranded" outside of a subscription. So I had to create a new subscription and associate the B2C directory with it, so it was a resource of the subscription. Then I used IAM to add the 2nd Azure account as a co-administrator of the subscription. I transferred the subscription to the 2nd Azure account.
The biggest authority in Azure AD is Global administrator. If you want to transfer ownership to another user, you only need to give that user Global administrator.

Azure create servicePrincipal results in Insufficient privileges to complete the operation

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.

Can't Create Role Assignment in Pipeline with Owner Service Principle

I have a build pipeline which deploys some ARM templates. It's a requirement for some of those resources to have role assignments for RBAC.
The service principle that the pipeline uses to connect to subscription is an owner, but if either the templates try to create role assignment resources, or I try to run az cli in the pipeline to create the assignments, there's insufficient permissions.
What permissions above owner is required to allow this?
I suppose you misunderstood the Global admin and Owner. The Global admin is an Administrator role in Azure AD, and the Owner is an RBAC role in the subscription. They are different things.
When you use the azure cli like below to create the role assignment, it adds the service principal joytestsp as an Owner to the storage account. The service principal which you login needs to call the AAD Graph to get the object first and then call the azure mangement rest api to add it to the storage account.
az role assignment create --assignee 'joytestsp' --role 'Owner' --scope '/subscriptions/xxxxxx/resourceGroups/xxx/providers/Microsoft.Storage/storageAccounts/joyfunction'
So to fix the issue, you could navigate to the Azure Active Directory in the portal -> Roles and administrators -> click the Global administrator -> Add assignments-> add your service principal which used to login as a Global administrator. Then it should work.
Besides, if you don't want to give it the Global administrator to the service principal, you can also specify the object id of the service principal/user in the command, then it will also work.
az role assignment create --assignee 'b4d3c922-xxxxxxx-3ab785333011' --role 'Owner' --scope '/subscriptions/xxxxxx/resourceGroups/xxx/providers/Microsoft.Storage/storageAccounts/joyfunction'

WSO2 Mapping wso2 role to LDAP group

I would like to map automatically wso2 application roles to existing LDAP groups from an Active Directory.
Example:
internal wso2 role admin is given to users resolved as
(&(objectClass=user) (memberOf=administrators)) in DC=acme,DC=com
internal wso2 role publisher is given to users resolved as
(&(objectClass=user) (memberOf=developers)) in DC=acme,DC=com
... etc
So no provisioning to do, and role mapping has not to be done manually by the wso2 administrator.
To give a user access to an interface, we just have to add the user in the right AD group (or AD mailing list, even easier).
This king of mapping is used in Nexus Sonatype (using the apache Shiro library).
https://books.sonatype.com/nexus-book/reference/ldap-sect-external-role-mapping-config.html
Is it possible to do that in WSO2?
Is it a requested feature?
Best regards
What you can do is use the role which already exists in the LDAP as itself. In the WSO2 server side, just assign the necessary permissions to that role.
For example, admin role name is defined in the /repository/conf/user-mgt.xml file as below.
<AddAdmin>true</AddAdmin>
<AdminRole>admin</AdminRole>
<AdminUser>
<UserName>admin</UserName>
<Password>admin</Password>
</AdminUser>`
Here, replace the AdminRole value with the role name that already exists in the LDAP side. Upon the first startup of the server, WSO2 will map all the admin permissions to the mentioned role.
For other roles, you can view the existing roles from the Management Console and assign required permissions to them there.
Hope this helps.
Cheers

Resources