Tag Archives: Daemon App

Daemon App (or service application, or scheduled job, or background serve etc.) – application that runs unattended, on behalf of it’s own credentials (vs application that uses current user authentication and permissions).

SharePoint AppRegNew.aspx and AppInv.aspx

There are well-known SharePoint app-only service principals and ACS-based permissions. It is kind of old-school way – introduced as part of Add-Ins for SharePoint 2013 – to get unattended access to SharePoint site (application access, i.e. access without user presence). Such apps are called daemon apps or service apps or background jobs etc…

Microsoft announced retirement of ACS in 2026 and takes measures to stop using ACS in new and existing tenants. For you to smoothly switch to new, recommended Entra Id based service principals and permissions – it is important to know some details about classic app-only service principals and ACS-based permissions.

As you know, any access is a two-step procedure:

  • Authentication, when systems ensures you are indeed the one you claim you are
  • Authorization, when system grants you access to the resource, as it knows that this id is allowed to access such and such resource with these permissions

So, when it comes to deprecated SharePoint app-only service principals and ACS-based permissions, AppRegNew is responsible for authentication and AppInv is responsible for authorization.

AppRegNew.aspx

To get a SharePoint app-only service principal – you’d need to register a new one at any SharePoint site using the AppRegNew.aspx page. This page is not available from GUI, so you’d need to type the Url manually. You’d need to be a site collection admin to register a new app.

Let say, your site Url is “https://YourTenant.sharepoint.com/teams/YourSite“.
Then this appregnew page’s Url would be
“https://YourTenant.sharepoint.com/teams/YourSite/_layouts/15/appregnew.aspx

If you go to this page, you’ll see (*) something like

You’d click generate client id, then generate client secret and type your app display name. I usually use “localhost” as app domain and “https://localhost” as redirect Url.

If all good – you’d get app id (client id) and app secret (client secret) and you’d be able to authenticate to your SharePoint site.

AppInv.aspx

Providing permissions for your SharePoint app-only service principal to your SharePoint site is done using AppInv.aspx page. This page is also not available from GUI, so you’d need to type the Url manually again. You’d need to be a site collection admin to use this page.

Let say, your site Url is “https://YourTenant.sharepoint.com/teams/YourSite“.
Then this appinv page’s Url would be
“https://YourTenant.sharepoint.com/teams/YourSite/_layouts/15/appinv.aspx

If you go to this page, you’ll see (*) something like

At this moment – you need to enter app (client) id here and click lookup – so all the app metadata would be populated, then you’d need to enter Permission Request XML.
Via this “Permission Request XML” you are specifying exact permissions your app will have in this site. E.g. you can specify scope – all site collection or one specific subsite (web) or even one specific list or library. Also you can specify permissions level – e.g. read, read/write, manage or full control. This is tricky, but let me share some examples with you.

Permission Request XML for the app to have full control over entire site collection:

<AppPermissionRequests AllowAppOnlyPolicy="true">  
   <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" 
    Right="FullControl" />
</AppPermissionRequests>

Permission Request XML for the app to have read access to a subsite (web):

<AppPermissionRequests AllowAppOnlyPolicy="true">  
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" 
   Right="Read" />
</AppPermissionRequests>

Permission Request XML for the app to have read/write access to a list/library:

<AppPermissionRequests AllowAppOnlyPolicy="true">  
   <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list" 
    Right="Write" />
</AppPermissionRequests>

Any mistake in XML might prevent app access, so be very careful.

Finally, your AppInv.aspx page would look like

If you specify scope as web – you’d do it on the specific web url, e.g.
“https://YourTenant.sharepoint.com/teams/YourSite/SubSite/_layouts/15/appinv.aspx”

If you specify scope as list – you’d do it on the specific web url, e.g.
“https://YourTenant.sharepoint.com/teams/YourSite/SubSite/_layouts/15/appinv.aspx”
and after you click “Save” – there will be a page – you’ll be asked to choose a list from available web lists.

After all, you’ll be asked to confirm that you trust the app:

And after that your app (SharePoint app-only service principal) will have access (ACS-based access) to you site.

AppPrincipals.aspx

From site settings page (/_layouts/15/settings.aspx) you should be able to see apps registered on your site with “Site app permissions” or “Site collection app permissions” links available via GUI. That would be “appprincipals.aspx” page.

Unfortunately, you cannot see you app permissions here or your secret expiration time. Some date can be pulled via PowerShell with Get-PnPAzureACSPrincipal

Possible complications

After Microsoft announced retirement of ACS – you can see this message on appinv and appregnew pages:

You might also see “Your SharePoint tenant admin doesn’t allow site collection admins to create an Azure Access Control (ACS) principal” message at appregnew page and “Your SharePoint tenant admin doesn’t allow site collection admins to update app permissions. Please contact your SharePoint administrator.” at appinv page.

That’s because a recent update to Microsoft 365 (MC660075) pushed by Microsoft in Aug/Sep 2023 changes default behavior so only tenant administrators can create or update ACS service principal by default.

If you are facing issues above – or you want to switch to modern Entra Id service principals, but by some reasons you need ACS-based permissions – here is the article on “Entra Id vs ACS for SharePoint and how to survive during transition period

References

Access SPO Site Programmatically via MS Graph API and SharePoint API

Scenario

You are a software developer. Your company uses Microsoft Office 365 (SharePoint, Teams etc.). The need is to work with a specific site collection programmatically (from code – Python, C#, Java, PowerShell, JavaScript etc.) – e.g. upload/download documents, update list items, search etc.

The code must run without user interaction (unattended, aka daemon app). Sometimes this is also called “SharePoint Automation”.

The solution is based on a new Graph API feature – Sites.Selected and a classic SP-Only app.

Solution

  1. Register an Azure App and configure it as usual.
    Select API Permissions blade and add two permissions:
    – Microsoft Graph -> Applications Permissions -> “sites.selected
    – SharePoint -> Applications Permissions -> “sites.selected
  2. Request “Grant admin consent” from a tenant/global admin
  3. Request SharePoint admin to run PowerShell code (e.g. this one) to assign proper permissions to your azure app for a specific site collection (consider site owner consent)
  4. (optionally) Provide SharePoint API permissions:
    (require Site Collection Owner/Admin account) – use
    https://YourTenant.sharepoint.com/teams/YourSite/_layouts/15/appinv.aspx
    to add SharePoint API permissions to your app. E.g. full control permissions to site collection would be
<AppPermissionRequests AllowAppOnlyPolicy="true">  
   <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" 
    Right="FullControl" />
</AppPermissionRequests>

Consider minimal permissions (e.g. Right=”Read” see more with Sumit)

Problem Solved

  • you get access to one and only one site collection (“least privilege” principal)
  • you get both – SharePoint API and Microsoft Graph API permissions to SharePoint
  • you can use app secret or certificate to authenticate – depending on what are your security requirements

Note: if your scenario require authenticated user present – the solution would be a little different: Connect-PnPOnline Interactive with Client App Id

Update:

Sites.Selected API MS Graph permissions was introduced by Microsoft in 2021. It was a huge step forward, but still devs were limited with MS Graph API against SharePoint.
So devs had to use AppInv at site level to provide ACS permissions to their apps to use SharePoint CSOM and REST APIs.
Recently Microsoft introduced Sites.Selected SharePoint API permissions for registered Azure Apps! So now devs should be fully happy without ACS-based permissions AppInv.aspx. (See more here on disabling SP Apps Only SPNs)

Thanks to Leon Armston and Scott Murdock

Update 2:

Microsoft announced end-of-life for ACS permissions, so we’d need to avoid ACS permissions for new development.

References: