Desktop devices

You can access the Marketplace Platform from a browser on a Windows, macOS, or Linux computer.

We support the following browsers:

• Google Chrome (latest version)

• Microsoft Edge (Chromium) (latest version)

• Mozilla Firefox (latest version)

• Apple Safari for macOS (latest version)

If you don't use a supported browser, you might not be able to access the platform or use all of its features.

Mobile devices

If you want to access the platform on a mobile device, ensure that your mobile browser meets the following minimum requirements:

• The screen resolution must be at least 1024 x 768 (when browsers are maximized).

• The cookies must be enabled.

• JavaScript must be enabled.

We support the following mobile browsers:

• Apple Safari for iOS (latest version)

• Android browsers (the default browser on Android 13+)

This article explains how the platform connects to your Azure environment, how data is collected, and what security measures are in place.

Why does the platform need an Access Token?

An Access Token is used to enable the platform to collect spend details about your Azure Subscriptions. Without this Access Token, we are unable to pull this detail and provide you with the analytics necessary to make decisions about your day-to-day spending.

What admin rights does SoftwareOne require for Cloud Spend Management and Cloud Cost Optimization?

The customer must be assigned the “Owner” role in the Azure subscriptions you wish to add to the Client Portal.

When adding Azure subscriptions, the SoftwareOne service principal is granted “Tag Contributor” access to those subscriptions. This level of access allows full access to the Azure subscription without managing security settings.

The Client Portal uses this access to retrieve a list of your resources (Virtual machines etc.) and the tags assigned to them. This role also provides a level of access to synchronize any user-assigned tags in the Client Portal back to the resources of the Azure subscription. Azure built-on roles reference.

What is 'Tag Contributor'?

Tag Contributor lets you manage tags on entities, without providing access to the entities themselves. For more information, see the Microsoft documentation.

Why does the platform require 'Tag Contributor' permissions?

Being established as a 'Tag Contributor' allows the platform to interact with customers' spending and resource data. Without this, we are unable to provide custom reporting, and consumption views and successfully implement other workstreams within Spend Management.

What happens when I perform consent?

When you perform consent, you are redirected to Microsoft to accept permissions required by the platform. As part of this process, the platform can “impersonate” the consenting user for a short period (1 hour).

The platform uses this impersonation to perform actions on behalf of the consenting user. This includes:

1. Assigning the Tag Contributor role to the platform for subscriptions owned by the consenting user during onboarding.

2. Assigning the Tag Contributor role to the platform for subscriptions owned by the consenting user during the addition of more subscriptions to the platform.

What are the security implications of activating my tenant?

When the consent process is performed, a “service principal” is created in your tenant. This is conceptually similar to adding a user dedicated to the Client Portal for the purposes of accessing your tenant and subscriptions.

Do I have options to not synchronize resources or tags?

Yes, the platform offers application-level rights that you can change, after adding your Azure Subscriptions. Those include:

• No Resources - No resources or tags will be synchronized from subscriptions marked with this setting.

• No Tags – Your resources will be synchronized from your Azure Subscription, but their tags will not be synchronized in either direction.

• Read Tags Only - Your resources will be synchronized from your Azure Subscription, including their Tags. Any changes to Tags in the platform will not be written back to Azure.

• Read and Write Tags (Default Role) – Your resources will be synchronized from your Azure Subscription, including their Tags. Any tag changes in the platform will be written back to Azure.

What can the platform write back to my cloud provider?

When the Read/Write permissions are enabled, the platform can write into a customer environment. Write permissions are restricted to Tags only.

How do I secure the platform from executing other functions within my cloud provider?

Role-based access control (RBAC) in the platform ensures that only a level of interaction that is acceptable to you is established between the platform and your cloud provider.

Encryption

The platform makes extensive use of data encryption for data in transit:

• Traffic from the platform is encrypted using HTTPS in their web browser.

• API traffic between the platform and Microsoft’s services is all encrypted. Traffic is natively encrypted since it is an HTTPs request.

What is PAL and what data does it collect?

Partner Admin Link (PAL) enables Microsoft to identify and recognize SoftwareOne as helping customers achieve business objectives and realize value in the cloud. Customers must first provide partner access to their Azure resources. Once access is granted, the SoftwareOne Microsoft Partner ID (MPN ID) is associated.

The PAL association to existing credentials provides no new customer data to Microsoft or SoftwareOne. For more information, see the Microsoft documentation.

Why is my access token invalid?

An access token may be invalid due to the following reasons:

• The token is incomplete: If your access token is incomplete, sign in to the Azure Portal and copy your access token again.

• The token is complete but has expired: If your access token has expired, you must generate a new token.

• The token is complete but has been revoked: If your access token has been revoked, you must generate a new token.

What happens after I grant consent?

When you perform consent, you are redirected to Microsoft to accept permissions required by the Client Portal. As part of this process, the Client Portal is able to “impersonate” the consenting user for a short period (1 hour).

The Client Portal uses this impersonation to perform actions on behalf of the consenting user. This includes:

1. Assigning the Reader role to the Client Portal for subscriptions owned by the consenting user during onboarding.

2. Assigning the Reader role to the Client Portal for subscriptions owned by the consenting user during the addition of more subscriptions to the Client Portal. For more information, see Adding more subscriptions.

3. Modify the default Reader role to the Tag Contributor role (and vice versa) during the Change Access process. For more information, see Sync your tags to Azure.

What are the security implications of activating my tenant in the Client Portal?

When the consent process is performed, a “service principal” is created in your tenant. This is conceptually similar to adding a user dedicated to the Client Portal for accessing your tenant and subscriptions.

Azure Subscriptions

When adding Azure subscriptions, the service principal is granted “Reader” access to those subscriptions. This is a built-in role in your Microsoft tenant that allows read-only access to your resources. The Client Portal uses this access to retrieve a list of your resources (virtual machines, websites) and the tags assigned to them.

If you change the level of access to a setting that allows the write-back of tags, the Client Portal requires the “Tag Contributor” role. This level of access allows full access to your subscription with the notable exception of managing security settings in the subscription. The Client Portal uses this access to retrieve a list of your resources (virtual machines, websites, etc.) and the tags assigned to them. It also requires this level of access to synchronize the tags you assign in the Client Portal back to the resources of your Azure subscription.

For more information, see Microsoft documentation - Azure built-on roles reference.

Office 365 Subscriptions

When adding Office 365 subscriptions, the service principal is granted permission to the Microsoft Graph API in your Microsoft tenant. Those permissions include:

• Read all usage reports: Allows an app to read all service usage reports without a signed-in user. Services that provide usage reports include Office 365 and Azure Active Directory.

• Read all groups: Allows the app to read memberships for all groups without a signed-in user. Note that not all group API supports access using app-only permissions.

• Read all users’ full profiles: Allows the app to read the full set of profile properties, group membership, reports, and managers of other users in your organization, without a signed-in user.

For more information, see the Microsoft Graph API permissions reference.

The platform uses several Microsoft APIs to pull data that allows you to create Spend reports, Budgets, and Chargebacks. In some cases, it can take up to 24 hours for the resource cost to be accessed through the interface.

As the platform synchronizes your Azure billing data only once a day, sometimes, it might take 48 hours for the data to refresh.

Additionally, the reconciliation files are available no later than the 8th day of every month. Microsoft invoices partners based on this file. Therefore, we recommend that you send chargebacks after the 8th day of the month.

For more information, see Reconciliation file availability and Microsoft Partner Center data delay.

365 Analytics Reporting uses a service account to collect data from O365 tenants. Service accounts are used to collect data via PowerShell in cases where data can’t be collected via GraphAPI. You can create service accounts using PowerShell and Microsoft 365 Admin Center.

Your organization will not be charged by Microsoft for this account as it does not require an Office 365 license.

Creating a Service Account using PowerShell

We recommend that you use PowerShell to create service accounts because this method contains fewer steps.

    $Office365credentials = Get-Credential
    Import-Module MSOnline
    Connect-MsolService -Credential $Office365credentials

Follow these steps to create a service account:

After your account is connected to Office 365 in PowerShell, follow these steps to create a service account:

1. Modify the following line and set company.onmicrosoft.com to match your own Office 365 .onmicrosoft.com domain.

New-MSolUser -DisplayName "Service Account for 365 Analytics" -UserPrincipalName "365Analytics@company.onmicrosoft.com" -Password "Password123" -PasswordNeverExpires $true -ForceChangePassword $false

1. Replace the password with a secure password. We recommend a password of 10 characters or more and including capital and lowercase letters, numbers, and special characters.

2. Add the new account to the ‘Global reader’. You can do this by copying and pasting the following line into the PowerShell window.

Add-MSOLRoleMember –RoleName "Global reader" –RoleMemberEmailAddress 365Analytics@company.onmicrosoft.com

1. Check if the service account was set correctly by running the following PowerShell commands:

$role = Get-MsolRole -RoleName "Global reader"
Get-MsolRoleMember -RoleObjectId $role.ObjectId

Creating a Service Account using the Microsoft 365 Admin Center

You can create a service account via the Microsoft 365 Admin Center, however, you'll still need to run a final PowerShell cmdlet to ensure that the password doesn't expire.

To create a Service Account using the Microsoft 365 Admin Center

1. On the Admin home page, go to Users > Active users and select Add a user.

2. Enter the display name as Service Account for 365 Analytics and the user name as 365Analytics.

3. Ensure that the domain is the company.onmicrosoft.com.

4. Select Let me create a password and enter the new password.

5. Ensure that the Require this user to change their password when they first sign-in option is not selected.

6. In the Product Licenses page, choose Create user without product license.

7. In the Optional settings page, choose Admin Center access and select Global Reader.

8. Review the data and select Finish adding on the last page.

If your company policy allows passwords to never expire, you can do so using the following PowerShell command:

Set-MsolUser -UserPrincipalName 365Analyitcs@company.onmicrosoft.com -PasswordNeverExpires $true

Connecting your tenant

365 Analytics requires a Microsoft Application consent. 365 Analytics Reporting uses application consent to collect data from your Office 365 tenant. Application consent is used to collect data via Graph API.

For information on how to authorize the 365 Analytics Application for read-only access to your Office 365 tenant, see How to connect your 365 tenant for data collection.

If your report is empty and you receive this message There is no data for this chart, there are a few reasons for this, including:

• The data is being filtered in a way that no data is returning. You might need to edit your report and modify the filters.

• The data might require access to the Security and Audit Logs that may not have been configured. Check your 365 Analytics settings.

• The data has not been collected as the data collection needs to be authorized.

• You may need to reauthorize your tenant. For information, see How to connect your 365 Tenant for data collection.

If you've completed these steps and still have the notification or the report is empty, contact our Support team.

Delegation and Policy Control allows a variety of user types to do their jobs more productively, in a secure fashion, and without requiring elevated administration credentials.

Office 365 Delegated Administration

Delegation and Policy Control (DPC) for Office 365 helps organizations become more productive by enabling granular roles and responsibilities to be assigned to selected users, such as help desk operators, country-level administrators, or even end-users, setting clear boundaries on all delegated permissions.

Providing more granular delegation than the default Microsoft administrator roles is especially important for larger enterprises, companies that have multiple operating entities or business units, universities, and any organization that needs to delegate access widely across the organization.

The benefits of 365 Analytics DPC

Delegation and Policy Control allow a variety of user types to do their jobs more productively, in a secure fashion, and without requiring elevated administration credentials:

• Helpdesk teams are able to support users by setting passwords, resetting MFAs, adding a user to a group, enabling access to mailboxes, or creating new mailbox aliases

• Business unit owners or procurement can assign licenses to people in their part of the organization

• Business owners can manage their own teams whilst ensuring that naming conventions are adhered to

• Office managers can set out-of-the-office notifications for users within a specific geography or business unit

• HR personnel can correct data for users in AD or AAD and create mailbox aliases or set forwarding.

Office 365 Delegated Admin Access

Without a toolset such as 365 Analytics DPC, Office 365 delegated administration is difficult to achieve as there are limited native capabilities for delegating administrative tasks. Many organizations solve this by increasing the number of Global Administrators (GAs), even though this is known to substantially increase security risks.

365 Analytics DPC resolves this dilemma by ensuring designated administrators can see and act on only the users that they are responsible for in a fashion that aligns precisely with their defined administrative role. This enables administrative tasks to be conducted where they are most effective and increases the productivity of the organization.

Having a member of the HR team raise a ticket to change an incorrect detail in AD, or an office manager raise a ticket to set an OOO notification for a user who has departed for vacation without doing so are both examples of how both help desk teams and business users’ productivity can be impacted by the absence of effective delegation.

DPC also provides a Virtual Organizational Unit (OU) which provides a way to group users, teams, or other elements into logical units which can then again be used to delegate rights to those who need to operate on these groups or teams.

All DPC actions are recorded in a 365 Analytics read-only log file, which enables the organization to track which actions were taken, by whom, and at what time.

Authorization, Licensing, and Configuration Policies

Authorization Policies

Authorization policies allow a delegated administrator to perform a predefined action against a specific set of users. The actions defined in the authorization policy provide the ability to granularly restrict what the delegated admin can see or do.

The policy applies to objects such as Office 365 or on-premise users, a Teams team, or a Mailbox. Over 100 actions can be taken, such as setting a password, creating a Teams channel, adding a user to an AD group, or setting an OOO notification.

License Policies

License Policies enable organizations to delegate the function of assigning O365 licenses. As an example, a delegated license administrator can be given a quota of licenses that are both E3 and E5 with a quantity of PowerBI and Visio.

The E3 licenses may be restricted to only Exchange, OneDrive, SharePoint, and Teams. The E5 licenses could be unrestricted. When a request is made for a license, the delegated license administrator would assign the appropriate license and that would be removed from their quota.

Configuration policies

Configuration policies apply rules to users in a Virtual OU. For example, to ensure that all users have MFA enabled, have a specific Microsoft usage location, or assign a specific license type. This ensures the configuration for users, groups, and other AD objects is correctly configured according to what has been determined appropriate for that group of users.

Configuration Policies ensure standard configurations are applied to particular groups or departments by standardizing objects wherever the policy is applied. For example, if you have a virtual organizational unit for the Sales department, all users in this container will have their Department attribute equal to ‘Sales’. Once a user is moved into this container, he or she will be brought into compliance with the configuration policy for Sales.

Our platform has an SSO Authentication framework that integrates with existing Identity provider tools (such as Azure AD and ADFS) and SAML-based tools (such as Okta and Ping).

Setting up SSO with SAML

Setup process

1. The customer provides SoftwareOne with basic metadata about their IdP. If your SSO tool requires the Assertion Consumer Service URL and Entity ID, please contact SoftwareOne.

2. SoftwareOne proceeds with a basic setup on the Client Portal IdP and provides the customer with {connection_name} that'll be used for further configuration.

3. The customer proceeds and finalizes the setup from their side.

4. All logins to the Client Portal for any of the specified IdP domains will be federated out to the customer's SAML-based IdP.

Setup information required by the Client Portal

1. IdP Domains: List of email domains, for example @user.org, for which authentication should be federated out to the customer's IdP.

2. Sign In URL: HTTP-POST or HTTP-Redirect binding.

3. Sign Out URL

4. X509 Signing Certificate: In the .pem or .cer format.

Technical specification

Capabilities

We support the items listed in the following table:

Settings

{connection_name} is a verbatim string that SoftwareOne will provide after receiving the initial configuration settings from you.

Attribute Mappings

The Client Portal requires the following attributes via the specified mappings:

The attributes must satisfy at least one mapping for all properties above. If your IdP provides values for the required attributes in different claims/namespaces, please provide a list of claims to be used for all attributes above.

Please make sure to provide the attribute values as they are without any modifications. URLs are sometimes changed by security software, for example, Proofpoint’s Targeted Attack Protection adds urldefense.com at the beginning of links.

Setting up SSO with Azure AD

To set up SSO with the Client Portal via Azure AD, you must complete the following steps. After you've completed these steps, SoftwareOne will enable SSO with your Azure AD.

1. Register the Client Portal with Azure AD

2. Create a client secret

3. Add API permissions

4. Collect and forward the information to SoftwareOne

Setup Process

Step 1: Register the Client Portal with Azure AD

Follow these steps to register the Client Portal as an application inside your Azure subscription:

1. Sign in to the Microsoft Azure Portal. If you have access to more than one tenant, select your account from the upper right corner. Set your portal session to the Azure AD tenant that you want.

2. Search for and select Azure Active Directory.

3. Under Manage, select App registrations.

4. Select New Registration.

5. In Register an application, enter a meaningful application name to display to the users, for example, Client Portal.

6. In Supported account types, select Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant).

7. In Redirect URI, select the Redirect URI type as Web, and enter your callback URL: https://login.pyracloud.com/login/callback.

8. Click Register.

Step 2: Create a client secret

SoftwareOne will use the client secret to interact with your Azure subscription on behalf of the created application.

Follow these steps to create a secret:

1. From the Overview page of the app, select Certificates & secrets > Client secrets > New client secret.

2. Add a description for your client secret.

3. Set the expiration date for the secret.

4. Select Add.

5. Make a note of the client secret value. Note that the value will not be accessible again after you leave this page.

Step 3: Add API permissions

Follow these steps to add permissions that allow read access to users and the user directory:

1. From the app Overview page, select API permissions.

2. Under Configured permissions, select Add a permission.

3. Configure permissions for the Microsoft Graph API.

4. Once you've selected the API, you'll see the Request API Permissions page.

5. Enable the following permissions:

   • Users > User.Read

   • Directory > Directory.Read.All

6. Select Add permissions to complete the process.

Step 4: Collect and forward the information to SoftwareOne

Provide the following information to SoftwareOne. Once received, SoftwareOne can complete the setup and the Client Portal will automatically start forwarding all users of the specified IdP domains to your Azure AD for federated authentication.

Technical specification

Capabilities

We support the items listed in the following table:

Settings

Attribute Mappings

The Client Portal queries the following basic profile attributes from Azure AD:

• upn

• azure_id

• given_name

• family_name

• nickname

• tenantid

• oid

• email

• name

Setting up SSO with ADFS

Setup process

1. The customer configures their ADFS server according to technical requirements.

2. The customer provides ADFS Metadata/IdP domains to SoftwareOne.

3. SoftwareOne will complete the ADFS setup.

Setup information required by the Client Portal

Technical specification

Capabilities

We support the items listed in the following table:

Settings

Attribute Mappings

By default, the Client Portal expects the following attributes from ADFS via the specified mappings:

Setting up SSO with PingFederate

Setup process

1. The customer provides Signing Certificates/IdP domains to SoftwareOne.

2. SoftwareOne will complete the SSO setup.

Setup information required by the Client Portal

1. PingFederate Server URL.

2. X509 Signing Certificate in the .pem or .cer format.

3. IdP Domains: List of all email domains that should be authenticated through the federated ADFS server (for example, @customer.com). Usually just one, but can also be multiple.

Technical specification

Attribute Mappings

By default, the Client Portal requires the following attributes via the specified mappings:

The provided attributes must satisfy at least one mapping for all properties above. If your IdP provides values for the required attributes in different claims/namespaces, please provide a list of claims to be used for all attributes above.

Handling unknown or new users (Ad Hoc Provisioning)

If an email domain is federated out to the user's identity provider, it's possible that the Client Portal will receive sign-in attempts from users who are not set up as Client Portal users.

In such cases, if authenticated users from a federated connection are not Client Portal users, their login to Client Portal will fail with an error message stating that their account is not set up and they don't have access.

If you forget your password and can't sign in to the platform, you can reset your password using the Forgot password? link on the sign-in page.

You can also change your password through your profile page. To change your password, you must be signed in to the platform.

Reset your password

Follow these steps to reset your password:

1. On the Sign in page, enter your email address and select Continue.

1. Click Forgot password?.

1. In Forgot Your Password?, enter your email address and click Send Email. You'll receive an email containing a link to reset your password.

2. Click the link and follow the onscreen instructions to create a new password.

Change your password

Follow these steps to change your password:

1. Sign in to your account.

2. Select your account menu and click My profile. Your profile page opens.

1. Click the chevron in the upper right and select Change password. The Change password page opens.

1. Enter your new password and then confirm that your new password matches the one you entered in Confirm new password. As you start typing your new password, our password validation checks whether your new password meets the requirements.

2. Click Confirm to save your changes.

Related topics

When you terminate the last active subscription in an agreement or when subscriptions expire, the agreement status changes to Terminated. This termination is irreversible.

It means you can no longer use the terminated agreement for ordering new subscriptions and must either set up a new agreement when placing the order, or use an existing agreement in the Active state to attribute new subscriptions to that agreement.

See any of the related topic links for information on agreements and subscriptions.

Related topics

The landscape of B2B subscriptions and procurement processes is undergoing significant changes as businesses transition towards subscription-based models. As a result, there is a need to navigate the complexities of managing orders and invoices in the context of subscription-based procurement.

This topic aims to answer your questions about B2B subscriptions while providing an overview of how subscription-based models differ from traditional procurement processes. It also describes how the Marketplace Platform makes it easier for you to manage and streamline subscription-based procurement.

What is a subscription-based model?

In a subscription-based model, you pay a certain fee to access software or a service. You commit to a term and then pay a certain amount on a monthly or yearly basis.

This model differs significantly from the traditional purchasing model where you place a purchase order, the vendor processes it, and then issues an invoice after the license is allocated.

What are the challenges of a subscription-based model?

In traditional transactional procurement, the procurement process is linear, which means it involves placing a purchase order, processing of invoices, and reconciling them. In this model, each purchase order is directly linked to an invoice.

However, in a subscription-based model, the relationship between orders and invoices is complex. Unlike traditional procurement, where orders and invoices have a one-to-one relationship, in the subscription-based model, orders and invoices can have a many-to-many relationship.

For example, you might place multiple orders for additional licenses in a month, but receive only one invoice at the end of the month. Alternatively, you might not place any order, yet receive an invoice for subscription renewal. In these scenarios, orders don't directly match the invoices.

This causes an issue during reconciliation due to a mismatch between the number of orders and invoices.

How do enterprise procurement systems support a subscription-based model?

Many enterprise procurement systems support subscription-based models through various mechanisms, such as recurring purchase orders, standing orders, blanket purchase orders, open purchase orders, contract management, and more.

Unlike traditional purchase orders, where each purchase order is linked to a single invoice, mechanisms (such as recurring purchase orders) represent long-term agreements, allowing multiple invoices to be associated with a single purchase order. This approach is useful in environments where regular, repeated purchases are common, such as in subscription-based billing systems.

How does the Marketplace Platform support a subscription-based model?

To explain how our platform supports this process, it's important to understand the key elements of our platform.

The Marketplace Platform facilitates transactions between clients and vendors in various countries where SoftwareOne operates. We deal with objects such as orders, subscriptions, and agreements, which represent a relationship between the SoftwareOne entity and the client in specific regions.

• Business transactions are represented by orders, which can be of different types, such as purchase orders, change orders, and termination orders.

• Subscriptions are linked to agreements and represent the provision of service over a period of time. It's common for our clients to have multiple subscriptions within the same agreement.

To modify subscriptions, an order needs to be placed. It’s not possible to modify a subscription directly without placing an order.

Placing an order establishes a relationship at the recurring purchase order level on the procurement system's side and the agreement on the marketplace platform's side. This simplifies the reconciliation process when invoices are received because each invoice has links to the agreement, recurring purchase order, and subscriptions.

How can I enter a purchase order number?

You can provide your recurring purchase order number in the Additional ID field when placing your order. This number will be used for reference in all consolidated invoices in the scope of each agreement in the platform.

After you've provided the number, it'll be displayed on the invoice as follows:

If a recurring purchase order number needs updating or changing during the subscription term, you can modify the Additional Agreement ID in the scope of the agreement. The updated number will then be reflected in your next invoice.

365 Analytics reporting uses application consent to collect data from your Office 365 tenant. Application consent is used to collect data via the Graph API.

To learn why this is important, what data is collected, and what security measures are in place, What data do you collect for 365 Analytics?

Follow these steps to connect your 365 tenant:

1. Browse to the URL that SoftwareOne provided. You'll either receive the URL from the SoftwareOne support team or you'll see a banner in 365 Analytics stating that the data collector requires additional permissions.

2. Sign in to PyraCloud with the agreed global administrator account. Use the password that was set in PyraCloud, not your Office 365 account password.

3. Select Connect Tenant.

1. Enter your Office 365 Tenant ID.

1. Enter your Office 365 global administrator account username and password. Use your Office 365 Azure AD account, not your PyraCloud credentials. The user must be a Global Admin for authorization to work.

1. Authorize 365 Analytics access to read your Office 365 Tenant. Select Accept.

1. Notify your SoftwareOne representative.

Microsoft has released a preview feature to support allowing access to service providers (like SoftwareOne) through Conditional Access policies. To learn about Conditional Access, see the Microsoft documentation.

Prerequisites

To exclude SoftwareOne and the Client Portal from your blocking Conditional Access policies, you'll need the Microsoft Tenant IDs of SoftwareOne’s reseller tenants that relate to you.

Even though SoftwareOne has over one hundred of these reseller tenants, only one or two will apply to you. The only way to find out the reseller tenant IDs you need to use is to log a support ticket with our Support team.

Configuring conditional access policies

For configuring conditional access policies, determine which Conditional Access policies are blocking SoftwareOne and the Client Portal.

Before you can exclude Client Portal and SoftwareOne from your policies, you need to know exactly which policies are affecting access. You can do this using the What If capability of Conditional Access.

Follow these steps to configure conditional access policies

1. In the Azure portal, navigate to Azure AD Conditional Access.

1. Select What If in the top navigation bar.

1. On the What If page, select No user or service principal selected and then choose the following settings:

   1. Select identity type: User

   2. Select: Guest or external users

   3. Select: Service provider users (preview)

   4. Select organization (preview)

      • Click No Tenant selected.

      • Enter the Tenant ID you obtained from our Support team.

      • Click the tenant that is found.

      • Click Select.

1. Select What If.

At the bottom of the page, you will see the list of Policies that will apply. Make a note of these policies as these are the ones you will need to modify to exclude the Client Portal and SoftwareOne.

Excluding the Client Portal and SoftwareOne from the policy

1. In the Azure portal, navigate to Azure AD Conditional Access.

1. In the list of policies, select one of the policies that you applied.

1. Under Assignments, select the Users section.

1. Select Exclude.

1. Select the Guest or external users checkbox.

1. Choose Select.

1. Click 0 Azure AD organizations selected.

1. Enter the Tenant ID you obtained from our Support team, and then select the checkbox next to the SoftwareONE reseller tenant.

1. Click Select and then select Save.

Repeat the steps in this section for each policy that you noted in the previous section.

The Client Portal downloads AWS recommendations from AWS Trusted Advisor and AWS Cost Explorer.

If the Client Portal is unable to download recommendations, a message is displayed in the health check for the AWS accounts on the Cloud Cost Optimization page.

The following image shows the AWS synchronization error:

This error means that the AWS Trusted Advisor or Cost Explorer is not configured correctly for at least one AWS account.

To resolve this issue:

1. Select Fix.

2. On the Synchronization Information page, review the details and follow the solution to resolve the error.

The following are the possible issues and their description:

If you've enabled the Cost Explorer and AWS permissions, but the Client Portal is still showing an error, ensure that the Amazon EC2 rightsizing recommendations are enabled. For information on how to enable rightsizing recommendations, see Optimizing your cost with Rightsizing Recommendations in AWS documentation.

The platform imports information from your Microsoft 365 tenant daily. The data is used in the following features:

1. Tag & Resource Manager - Used to allocate resource costs to business units (custom groups), Tag & Resource Manager (TRM) imports information about Azure AD user accounts including (but not limited to) usernames, display names, departments, managers, addresses, and extensionAttributes. This information is used to help the user allocate license costs to the correct business unit. TRM also imports information about specific Microsoft 365 licenses assigned to users.

2. Consumption - Used to report on resource usage and cost, Consumption imports information about overall Microsoft 365 license quantities and assignments. This includes total purchased licenses, total assigned licenses, and total unassigned licenses for each subscription.

The Marketplace platform does not access a customer's tenant on an ad-hoc basis for any reason related to Microsoft 365.

Authentication

The platform uses an account called mfa.setup to access the Partner Center API for CSP customers. In some instances, the platform also 'double hops' into a customer's Microsoft tenant to get information about users and license assignments.

This account is used to access the Microsoft Graph API, specifically, the users and SubscribedSkus endpoints that provide the Client Portal with information about Azure AD users. It also provides information such as, how many licenses from each Microsoft 365 subscription are assigned and how many are free. To learn more about these APIs, see the Microsoft documentation on and .

To authenticate and consume these APIs, the platform uses app+user authentication. It means that when the platform authenticates, it uses a combination of both an Enterprise Application and a User Account (which is a service account, the aforementioned mfa.setup user).

For CSP, both these principles exist in SoftwareOne's Azure AD rather than in the customer's Microsoft tenant. For more information, see the Microsoft documentation on .

Note that even under the new secure application model, app+user authentication is still used.

Conditional Access policies

Unless configured, the Conditional Access policies (CAP) don't block authentication attempts by the enterprise applications. On the other hand, user account access can be actively blocked by CAP unless an exception is configured.

Historically, it has been challenging to configure exceptions for the user accounts in partner (SoftwareOne's) Microsoft tenants because they don't exist in the customer's Microsoft tenant.

Recently, Microsoft has added functionality to CAP to allow narrow (least privilege) exceptions to be configured for partner Microsoft tenants. For information, see and .

Imported data fields

The following fields are downloaded for each user in the customer's Azure AD and Microsoft 365 subscriptions.

What are service accounts and what do they do?

Microsoft offers two primary API sets for accessing M365 services called PowerShell and Microsoft Graph.

• PowerShell access requires the 365 Analytics application to authenticate to the service using a named credential instead of the enterprise application registration. That’s where the service accounts come in. 365 Analytics supports Reporting Service Accounts.

• Graph API access is managed through the Azure AD enterprise applications deployed as part of 365 Analytics provisioning in a tenant.

Reporting Service Accounts

The Reporting Service Account is used to gather data from the target tenant using both PowerShell and Microsoft Graph. It is a read-only account and is required for all tenants. We recommend and have tested assigning the Global Administrator role to this account.

To learn about creating service accounts for 365 Analytics reporting, see .

Encryption

365 Analytics makes extensive use of data encryption for data in transit and at rest:

• Traffic from 365 Analytics users is encrypted using HTTPS in their web browser.

• API traffic between the 365 Analytics application and Microsoft’s services is all encrypted. Graph traffic is natively encrypted since it’s just HTTP requests; other protocols, such as remote PowerShell, are tunneled over HTTPS.

• All 365 Analytics data is encrypted at rest.

Service account credential storage

All service account credentials held by 365 Analytics for reporting are stored and encrypted in two places:

• The Service Account password is encrypted before it leaves the client machine setting the password; whether that is via the User Interface or PowerShell script. It is therefore sent in an encrypted form to our backend servers. Only our job collection servers have the private key to decrypt this password.

• The encrypted service account password is then further protected by being stored in Azure Key Vaults, where only our ‘job engines’ (those services that collect data) have access to the key vault to obtain the data.

Multi-factor authentication and conditional access

As of May 2020, Microsoft does not support the use of multi-factor authentication (MFA) for accounts used as service accounts in Office 365. This is not a 365 Analytics limitation, it’s a restriction imposed by Microsoft.

The default policies applied by the service will break 365 Analytics service account access because they require MFA for accounts that hold the Global administrator role.

Microsoft’s recommended solution is to enable conditional access whitelisting for the IP addresses used to access M365 services using these service accounts.

In some cases, the consumption data for your Azure Reserved Instances might be unavailable in the Client Portal.

If you are not able to view the data, you must update your permissions and assign the Reservations reader role to each tenant through the Azure Portal.

To learn about the Reservation reader role and how to assign it, see Permissions to view and manage Azure reservations. You can also assign the role by following the steps in this topic.

Before you begin

You can assign the Reservations reader role only if you have the User Access Administrator or Owner role in Azure. If you need to elevate your access, see Elevate access to manage all Azure subscriptions and management groups.

Assign the Reservations Reader role through Azure

Follow these steps to assign the role:

1. Sign in to the Azure Portal and search for Reservations.

2. Select Role Assignment.

3. On the Access Control page, click Add > Add role assignment. The Add role assignment page opens.

1. On the Role tab, select Reservations Reader as the role and click Next.

1. On the Members tab, do the following:

   1. Select User, group, or service principal if it's not selected by default, and then click Select members.

   2. In the Select members panel, type PyraCloud and then select PyraCloud (Azure) from the search results.

   3. Click Select.

1. Click Review + assign.

2. On the Review + assign tab, review the details and click Review + assign to confirm the role assignment.

After you've completed these steps, the Reservations Reader role is assigned and displayed on the Role assignments tab.

Once the role is assigned, it might take up to 24 hours for your consumption data to become available in the Client Portal. If you are not able to view the data after 24 hours, contact us for help.