Get the associated site collection to the AppID that is registered

[bforsyt4]

I don't see a way to get the associated site collection to the AppID that is registered. I'd like to be able to report out all site collections and their respective owners where an AppID is registered using Graph API

These AppIDs do show up in Azure Portal under Azure Active Directory > App Registrations (filter by Enterprise Applications), but with little information and no owner to tie back to the related site collection.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 3d9d8235-c495-a7a3-a4a6-0d073db41d1d
• Version Independent ID: bdd22da6-06c6-569d-fccf-fd55baa3cef8
• Content: Replace an expiring client secret in a SharePoint Add-in
• Content Source: docs/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in.md
• Product: sharepoint
• GitHub Login: @VesaJuvonen
• Microsoft Alias: vesaj

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[bforsyt4]

I know you can create an app registration via Azure Active Directory, then take that AppID to the /AppRegNew.aspx page in SharePoint tenant, then apply permissions and start using it. This alternative, although not sure it's recommended by Microsoft, does give you the ability to fetch the properties of the AppID via Graph API, and get owner info. Is this suggested over simply going to /AppRegNew.aspx?

[funzel1]

I don't see a way to get the associated site collection to the AppID that is registered. I'd like to be able to report out all site collections and their respective owners where an AppID is registered using Graph API

These AppIDs do show up in Azure Portal under Azure Active Directory > App Registrations (filter by Enterprise Applications), but with little information and no owner to tie back to the related site collection.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 3d9d8235-c495-a7a3-a4a6-0d073db41d1d
• Version Independent ID: bdd22da6-06c6-569d-fccf-fd55baa3cef8
• Content: Replace an expiring client secret in a SharePoint Add-in
• Content Source: docs/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in.md
• Product: sharepoint
• GitHub Login: @VesaJuvonen
• Microsoft Alias: vesaj

There is more on Sp hosted app registration.
Type of app should be visible in AD include filter option
Owner not set and not vible in UI (AD)
expiration date not visible in UI (AD)
how extend expiration by site admins it is a mess...

[bforsyt4]

I agree @funzel1
Of the 14k+ app registrations within my company's Azure environment, it is very difficult to understand which are tied to a SharePoint site collection. The associated SharePoint AppIDs have gone rogue, with no responsibility back to the owner to manage the lifecycle.

If there was a way to grab the full properties plus owner and related site collection via Graph API, one could dump them to a DB table and process each sending out a communication to the owner to take care of it.

As far as renewing the secret, it doesn't always work. So we end up just creating a new AppID / Secret. And there have been occasions where you attempt to delete the AppID from the App Registration Inventory page, and errors out. We then pull out the trusty PowerShell script to force delete. If it doesn't delete, then it sits there, not managed.

[funzel1]

Hello @bforsyt4
on top do not forget if app deleted in spo or site itself deleted, app still listed in Azure AD.
First step monitor expiration and handle deletions in AD.
Check Azure sentinel,audit log can you monitor app creation and are the information enough (site(who) to updste in AD app details.

Regarding graph we got from MS:
o List servicePrincipals - Microsoft Graph v1.0 | Microsoft Docs
https://docs.microsoft.com/en-us/graph/api/serviceprincipal-list?view=graph-rest-1.0&tabs=http
o servicePrincipal: addKey - Microsoft Graph v1.0 | Microsoft Docs
https://docs.microsoft.com/en-us/graph/api/serviceprincipal-addkey?view=graph-rest-1.0&tabs=http
o servicePrincipal: removeKey - Microsoft Graph v1.0 | Microsoft Docs
https://docs.microsoft.com/en-us/graph/api/serviceprincipal-removekey?view=graph-rest-1.0&tabs=http

Resources:
• Replace an expiring client secret in a SharePoint Add-in | Microsoft Docs
https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in
• Accessing SharePoint using an application context, also known as app-only | Microsoft Docs
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly
• Granting access using SharePoint App-Only | Microsoft Docs
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs

[bforsyt4]

@VesaJuvonen any internal noise on this one?

[bforsyt4]

We ended up writing a custom C# application to meet our needs:

1. Created console application to run PowerShell script to grab all service principals and shove results into database table (for script see https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in )
2. Created another console application that iterates through all our site collections in our tenant, unlock the site temporarily if needed > temporarily add an admin to the site via CSOM > screen scrape appprincipals.aspx page using WebClient() using an ID that is an O365 tenant administrator (have to build a cookie using this ID) > return screen scraped data (app name and identifier off appprincipals.aspx page) > shove results, including associated site collection URL and site owner, into database table > remove temporary admin and relock site if needed
3. created SQL report cross referencing all service principals associated w/ the site collection, displaying site URL, site owner, service principal ID, service principal key, and key create and expire dates.

I do take care of service principals that no longer exist, cleaning up records in our database so they don't show up on the report. (but for service principals deleted from the SharePoint side, they still exist in Azure Portal as @funzel1 mentioned - that is for another team to clean up).

Now we can send out email notifications to site owners where the service principal will be expiring soon, or is expired, and also instructions to take responsibility to clean up and delete unused ones.

Hope this helps others experiencing this pain!

[KuotingChiu]

@bforsyt4 , is it possible that you can share the 2nd console application ?

[bforsyt4]

@KuotingChiu - unfortunately it is proprietary to my company and I cannot share.

[robertcaretta]

Fascinating thread. Does anyone know if it is possible to completely disable SharePoint app registration page across the tenant?
/_layouts/15/appregnew.aspx

[bforsyt4]

@robertcaretta not sure. If you are thinking what most may be thinking, which is to abandon this process and move toward Azure App Registrations - need Microsoft weigh in on this - @VesaJuvonen thoughts?

[robertcaretta]

Here is an interesting write-up. We recently implemented a POC using Option 3 (Hybrid). We created an Azure app then granted specific permissions at site level via "AppInv.aspx". This page still allows for setting read access to the site and read/write to a list. There is the option for Sites.Selected on the Azure app, but it's still not granular enough. So as far as I can tell there is still a gap.

Disabling "AppRegNew.aspx" while leaving "AppInv.aspx" available would be ideal for us... at least for now.

I can definitely understand all of the other points made in this thread in regards to reporting, secret expiration, ownership, orphaned cleanup, etc.

[funzel1]

Hello @robertcaretta with the hybrid way you cannot restrict the app to a specific site, reusable on other sites, you will have other problems
I have no problems if site admins can build solutions based sp hosted apps, problem is how identify sp hosted apps in azure without msol, ownership, expiration and mapped SPO site.

[robertcaretta]

Hello @robertcaretta with the hybrid way you cannot restrict the app to a specific site, reusable on other sites, you will have other problems I have no problems if site admins can build solutions based sp hosted apps, problem is how identify sp hosted apps in azure without msol, ownership, expiration and mapped SPO site.

Hello @funzel1 - Agreed, it would be nice if the Azure app could be locked down to a URL pattern. The use case required Graph API permissions, so that's the setup we had to use.

I haven't worked through all the links listed above in this thread, but this is just an observation in my testing so far. I created a new SPO native app. Then in Azure AD, on the Enterprise applications page remove all the filters for "Application type" and "Applications ID starts with". Click the X next to each one. At that point ALL apps will be listed.

Then I find the native SPO app. Under the audit logs I can see that the Activity = "Add Service Principal"; Initiated by (actor) = "spo_service@support.onmicrosoft.com"; then under the modified properties tab it shows AppAddress = "https://MYDOMAIN.sharepoint.com/sites/MYSITE". Perhaps that activity could be monitored, datawarehoused, and connected up with the site owners?

Yeah, there really should be another column indicating where the app was sourced from though. Similar to how Groups are classified by Security, Microsoft 365, Dynamic, etc.

[funzel1]

Now this topic should have higher priority
With MC660075 customer no more able to register or update , also not Global or SPO administrators.
We got a lot of noise and had to re-enable the feature,.
For right planning we need a report for whole tenant with app name, app id, expiration, spo site where registered

[bforsyt4]

We enabled the feature as well using PowerShell command Set-SPOTenant -SiteOwnerManageLegacyServicePrincipalEnabled $true

We have also blocked the appregnew.aspx page via a SharePoint Framework extension (overwrite content using JavaScript) and display a message to move forward and create Azure App Registrations using Azure Portal. We are also keeping the appinv.aspx page open to allow users to continue to utilize it to trust the newly created Azure Application Registrations to their site collections. This hybrid approach allows the older ACS created App Registrations to fall off eventually while the customer base moves forward using new modern approach. Much like @robertcaretta described above.

Next step is to Use PnP to set permissions for user's App Registrations using Sites.Selected to scope it to specific site collection(s).

https://pnp.github.io/powershell/cmdlets/Grant-PnPAzureADAppSitePermission.html
https://www.youtube.com/watch?v=SNIF3zCYNUk

@funzel1 - if a custom solution is not feasible from your end, then maybe a design change request to Microsoft is your next step

[funzel1]

Hello @bforsyt4
yes using Azure AD and site.selected makes sense and we are fine with it.
The issue is we have no way to identify apps and affected sites so we can inform/communicate.
"false" means also Global and SPO admins are not able to support, doing blocked actions because "False" means
blocked for everyone.

[funzel1]

Also for the new way, in an Azure AD app registration audit you will never see the spo sites got assigned site.selected.