Blog Post

Microsoft Teams Blog
4 MIN READ

Upcoming changes for creating and managing Teams Phone resource accounts

DanielaChocron's avatar
Jun 18, 2024

Microsoft Teams Phone is a cloud-based phone system that enables smart communication and effortless collaboration for Teams users. To enable Teams Phone features such as auto attendants and call queues, resource accounts are required. Resource Accounts These specific accounts are associated with these features and are not intended for actual users.

 

We are committed to providing secure and compliant services to our customers and users. As part of this commitment, we continuously identify areas of improvement for our security privileges for administrative roles in Microsoft 365.

 

Currently, Teams administrators can create and manage resource accounts without requiring any user management permissions in Microsoft 365. As part of our commitment to deliver secure solutions that meet the highest standards, we are implementing changes to the management of resource accounts. Going forward, Teams administrators will need to have user management permissions in Microsoft 365 to create and manage resource accounts. This change will take effect 3rd quarter of 2024.

 

This change will impact the Teams administrative experiences and workflows, as well as the Teams end-user features that depend on resource accounts. To prepare for this change, we have created the guidance below for Teams administrators:

  1. Ensure you have the appropriate user management permissions in Microsoft 365 to create and manage resource accounts. These permissions include User Administrator, Global Administrator, or custom roles that include the User Management permission. To assign these permissions, use the Microsoft 365 admin center or the Azure Active Directory PowerShell for Graph.
  2. Review the existing resource accounts in your tenant and make sure that they are configured correctly and assigned to the relevant Teams Phone features. Resource accounts can be viewed and managed in the Teams Admin Center or using PowerShell cmdlets. 
  3. Update your processes and documentation to reflect the new requirements and best practices for creating and managing resource accounts. Resource accounts should have a clear naming convention and description that indicate their purpose and association with the Teams Phone features. Resource accounts should also have a valid license assigned to them, such as Microsoft Teams Phone Resource Account
  4. Communicate the change and its implications to the relevant stakeholders and end-users in your organization. End-users may experience service disruptions or feature unavailability if the resource accounts are not created or managed properly by the Teams Phone administrators. For example, if a resource account is deleted or disabled, the associated auto attendant or call queue will stop working. If a resource account is not licensed or assigned to a phone number, the associated voicemail or conference bridge will not function.

 

Possible paths forward

To streamline the creation and management of resource accounts, Teams Phone administrators can consider the following options:

  • Use split provisioning to divide the tasks of creating and configuring resource between user administrators and Teams administrators. Split provisioning is a process that allows user administrators to create resource accounts using the Microsoft 365 Admin Center or PowerShell, and then assign them to Teams administrators who can configure them using the Teams Admin Center or PowerShell.
    • Use staged resource accounts to pre-create a set of resource accounts in bulk and then assign them to the Teams Phone features as needed. Staged resource accounts are resource accounts that are assigned a license and a phone number
  • Use Privileged Access Management (PAM) to delegate the permissions and roles needed to create and manage resource accounts. PAM is a feature of Microsoft 365 that allows you to control who can perform certain administrative actions and when. With PAM, you can create policies that grant access to specific tasks or cmdlets for a limited time period and require approval from designated approvers. For example, you can create a policy that allows a Teams administrator to run the New-CsOnlineApplicationInstance cmdlet to create a resource account, but only after getting approval from a global administrator. To learn more about PAM and how to use it, see Privileged Access Management in Microsoft 365.
  • Use Power Platform to create a custom solution that automates the creation and management of resource accounts. Power Platform allows you to build low-code apps that connect to various data sources and services. With Power Apps or Microsoft Forms, you can create a user interface that collects the required information for creating a resource account, such as the name, description, phone number, and license. Then, you can use Power Automate to trigger a workflow that validates the input, creates the resource account using Entra ID Connectors or Graph API, and sends a notification to the Teams Phone administrator. The created resource account will appear in the Teams Admin Center and can be managed from there. To learn more about Power Apps and how to use it, see What is Power Apps? and Create an app from scratch.
  • Organizations may also decide to add Teams administrators to the User Administrator group.

 

We appreciate your understanding and cooperation as we work to enhance the security and compliance of Microsoft 365 services. For more information and guidance on this change, please refer to the Teams documentation.

Updated Jun 19, 2024
Version 2.0
  • Can you share the reason for this change? You state 

     to deliver secure solutions that meet the highest standards

    But isn't it less secure if Teams admins now need to have full User Management rights? They now need more rights than before, exposing a larger possible attack vector.


  • This is stupid. User management and auto attendants and queues have nothing to do with each other. It's time to stop making everything a 'user' and treat sevice account like these seperately (shared mailboxes is another example). If you are a teams admin that doesn't mean you should be a user manager, but you should be able to create and manage AA'S and queues. My 2 cents.

  • Andrew900's avatar
    Andrew900
    Copper Contributor

    I agree with Ruud_van_Strijp , creating an account for Teams phone resources should be granted by the new Teams phone administrator role. Additionally, resource accounts are created with access blocked and no one knows the password of that account.
    Considering that if now my account does not have the User Administrator role it is because it is too much for my role, It will hardly be granted to me in the future just to create a Teams Phone resource account, this introduces in my opinion a complexity especially during migration and for the User Administrators that are not familiar with Teams Admin Center.

  • brizjam's avatar
    brizjam
    Copper Contributor

    Hi ArjanCornelissen

     

    We can make a Graph call like so with an Access Token having User.ReadWrite.All API Permissions

    POST https://graph.microsoft.com/v1.0/users
    Content-type: application/json
    
    $body = @'
    {
         "userPrincipalName": "email address removed for privacy reasons",
         "displayName": "ResourceAccount.Jam",
         "accountEnabled": false,
         "department": "Microsoft Communication Application Instance",
         "mailNickname": "ResourceAccount.Jam",
         "passwordProfile": {
             "password": "xWwvJ]6NMw+bWH-d",
             "forceChangePasswordNextSignIn": false
         },
         "usageLocation": "GB"
    }
    '@

    to create what appears to be a Resource Account and it can even be assigned a Teams Resource Account license but is missing a the crucial OwnerUrn value which means it cannot be used with Teams.

     

    Get-CsOnlineUser -Identity email address removed for privacy reasons | Select-Object AccountEnabled,AccountType,Department,FeatureTypes,InterpretedUserType,IsSipEnabled,OwnerUrn,ServiceInstance
    
    
    AccountEnabled      : False
    AccountType         : ResourceAccount
    Department          : Microsoft Communication Application Instance
    FeatureTypes        : {VoiceApp}
    InterpretedUserType : PureOnlineApplicationInstance
    IsSipEnabled        : True
    OwnerUrn            :
    ServiceInstance     : MicrosoftCommunicationsOnline/EMEA-GB1-S4
    
    # compared to a working RA
    AccountEnabled      : False
    AccountType         : ResourceAccount
    Department          : Microsoft Communication Application Instance
    FeatureTypes        : {VoiceApp}
    InterpretedUserType : PureOnlineApplicationInstance
    IsSipEnabled        : True
    OwnerUrn            : urn:trustedonlineplatformapplication:11cd3e2e-fccb-42ad-ad00-878b93575e07
    ServiceInstance     : MicrosoftCommunicationsOnline/EMEA-GB1-S4

     

    That's something the New-CsOnlineApplicationInstance command is doing that I haven't been able to find how to achieve with Graph API. 

     

     

     

  • brizjam's avatar
    brizjam
    Copper Contributor

    For the automation angle, I have found its possible to create with Graph API what at first glance appears to be a Resource Account but it is missing the required association in the 'ownerurn' attribute for a CallQueue or AutoAttendant type.  Without this association, the account cannot be managed in TAC, as suggested in the Possible Path forward with Power Apps.  Is there a Graph API call that I am missing perhaps that can be used to set this and what would be the API permissions needed? Thanks.

  • Jan11185's avatar
    Jan11185
    Copper Contributor

    I share the views in multiple of the previous comments.

    I fail to see how it improves security. Quite the opposite, I think.

     

    We were surprised to learn Teams admins could create resource accounts, but since they were only that it was not really an issue to us.

    Requiring Teams admins now to be User administrators, especially if unscoped/global, makes this an issue it wasn't before.

     

    Can you (MS) please share with us:

    • How to make a custom role that can only create and manage these resource accounts?
      (not normal users)
    • How can we point Teams to an AU, so we can delegate scoped permissions?

     

  • SIMONSSS's avatar
    SIMONSSS
    Copper Contributor

    New-CsOnlineApplicationInstance is not a part of PAM available scopes?

    This cmdlet is a part of Teams module, and from what i found PAM offers only Exchange scope

  • I just spend over a day creating and debugging a API with application permissions to work around this upcoming change as the team that manages the Teams resources does not have User Admin.
    Found that the New-CsOnlineApplicationInstance cmdLet is not supported with Application Permissions.

    brizjam what Graph Calls did you make to get the user created for this?

    In the current documentation at https://learn.microsoft.com/en-us/microsoftteams/manage-resource-accounts it states that this can only be achieved with user admin or a custom role.

     

    DanielaChocron can there be an update to how to achieve the automation part