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

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