Microsoft Entra ID: Service Principal Account Management Feature is now Generally Available

[dinesh_mishra]

Description

We are super excited to share that the “Lifecycle management of Service Principals as Accounts” feature of Microsoft Entra ID Connector is now generally available in the production tenants!

We are super excited to share that the “Lifecycle management of Service Principals as Accounts” feature of Microsoft Entra ID Connector is now generally available in the production tenants!

Last year, we released this capability of the connector everywhere in the sandbox tenants and we continued to enable this feature in the production tenants as per the request only as of now. These capabilities are now generally available in all the production environments so that you can get the maximum benefit of this feature for managing your Service Principals as accounts.

In Microsoft Entra, workload identities are applications, service principals, and managed identities. Microsoft Entra ID Connector simplifies the lifecycle management for Service Principals and User-assigned managed Identities.

What is the Problem?

There was no direct way for managing Service Principals for enterprise applications.

What is the Solution?

Microsoft Entra ID Connector has following capabilities,

• Aggregation
  • Aggregate Service Principals for enterprise applications with all the associated attributes.
  • Ability to get Service Principal Roles, Owners, Application ID details, and memberOf information.
  • Aggregate application Roles as a separate entitlement object.
• Get or Refresh Account
• Create Service Principals for applications
  • Create an application instance of enterprise application and then a Service Principal for that application
  • Create a Service Principals for an existing enterprise application
  • Create a Service Principals for a multi tenant enterprise application
  • While creating the applications and Service Principals for enterprise applications – Ability to add owner, ability to set password and certificates for applications.
• Update Operation
  • Basic attributes
  • Non-basic attributes: Certificates and Secrets, Owners
  • Entitlement attributes: directoryRoles, azureADPimRoles, azurePim, azureRBACRoles, applicationRoles
• Enable and Disable
• Add and Remove Entitlements
  • Add and Remove Roles
  • Add and Remove User’s Group Membership
  • Add and Remove Application Role Memberships (appRoleAssignments)
  • Add and Remove PIM Role Memberships (azureActiveRoles and AzureADActiveRoles)
  • Add and Remove RBAC Role Memberships (azureRoleAssignments)
  • Add and Remove Admin Consented Delegated Permissions (spn_adminConsentedPermissions)
  • Remove User Consented Delegated Permissions (spn_userConsentedPermissions)

Documentation References

• Service Principal Account Management
• Service Principal Account Attributes
• Account Profile for Service Principals

** If you are also interested to know the User-assigned Managed Identities, refer followings-

• User-assigned Managed Identities Management
• User-assigned Managed Identities Attributes

NOTE - This is an upcoming capabilities of Microsoft Entra (SaaS) Connector, which will be available soon.

If you have any questions, please reach out to us, and we would be more than happy to help you in all possible ways.

Thanks!

[ccarlton (Chad Carlton)]

These are great additions! Exciting stuff.

We would love to be able to use the Entra connector but unfortunately can’t because IDN is unable to handle (hide) the read only AD groups AAD has a copy of.

Due to how IDN learns about entitlements during account aggregation, even if we set an entitlement filter on the Entra source to not include on-premises AD groups, all of our on-premises (replicated) AD groups are being pulled in anyway (because they are listed on the accounts).

These read only duplicate entitlements add lots of noise to our Access History and confuse our Certifiers. These entitlements are not AAD entitlements, they are mastered in AD and are read only in AAD.

At this point I believe I have to wait for a platform change before we can start using IDN with Entra/AAD. Disappointing because we have lots of interesting ideas on IDN + Entra.

More details we (and others) are experiencing with IDN; that are are slowing/preventing customers from using IDN + Entra.

IDN: Source Entitlement filtering only sometimes works?

I do not agree with your statement " This is for visibility into who has access, and what they have access to, so that it can be remediated via certification campaigns if necessary. If account aggregations honored the entitlement filter then this would break the visibility and governance feature of identity access because the source would be giving access to accounts that IDN can not see or govern." For example: Azure Active Directory: on premise active directory groups are replicated into A…

Someone else made an Idea post about it: Sailpoint better handling of hybrid joined | SailPoint Ideas Portal