NMC Single Sign-On (SSO)

Introduction

Single Sign-On providers also support Multi-Factor Authentication (MFA) for login, requiring users to use MFA for login when configured.

Features of NMC SSO

Customers can log in to the NMC using accounts from their Identity Provider (IdP). NMC SSO was introduced in the 22.2 NMC release, and initially supports the Microsoft Entra ID IdP. Additional SSO IdP support is planned for future releases.

NMC SSO uses OAuth 2.0-based SSO for Authorization and OpenID Connect for authentication in order to meet requirements for security and MFA.

Edge Appliances work in conjunction with an SSO-enabled NMC to ensure that critical administrative actions are reserved for SSO users:

Note: A backend option can be configured by Nasuni that allows the Edge Appliance Admin UI to be used to leave NMC management even when managed by an SSO-enabled NMC. If you require this option, contact Nasuni Customer Support.

Centrally Managing Groups for Edge Appliance Administration

• SSO-enabled NMCs retain the ability to be joined to Active Directory so that the NMC can be used for the NMC Centralized Group Administration feature. When both the NMC and Edge Appliances are joined to the same primary Active Directory domain, Centralized Group Administration automatically distributes the Native and Domain Group configuration to Edge Appliances, allowing these accounts to access the Edge Appliance Management UI.

• Edge Appliances joined to a primary domain that differs from the NMC’s domain, or Edge Appliances not configured for a domain, do not participate in Centralized Group Administration, requiring administrators to log in using locally configured accounts.

Configuring NMC SSO

This section describes the procedure for configuring NMC SSO. NMC SSO uses Microsoft Entra ID, which is Microsoft’s cloud-based identity and access management service. Some of these procedures involve Microsoft Entra ID, and some involve the NMC.

Important: To manage settings for NMC SSO, the user must have the “Manage Single Sign-On Settings” permission.

Microsoft Entra ID procedure

This section details the steps needed to set up an Azure workspace for use with NMC SSO.

Note: Actions performed on Azure can have some latency, so allow those actions time to complete before proceeding to each new step.

Pre-Conditions

The following are assumed to be set up within Azure already:

• Microsoft Entra ID Premium Edition (P1 or P2). Nasuni's role- and scope-based security relies upon group membership to assign users to applications. For more information about Microsoft Entra ID licensing, see Microsoft Entra ID Pricing.

• The user must have access to the Azure portal.

• An Azure Tenant must be set up. A Microsoft Entra ID Tenant is a service that users can create in Microsoft’s cloud in order to control and manipulate their cloud-based services, such as configure Oauth/SAML and manage AD.
  The Azure Tenant must be able to generate new Enterprise Applications. To set up a Tenant, see Quickstart: Set up a tenant.

• Microsoft Entra ID Connect must be set up on a specified Tenant if you plan to use users and groups managed by Windows AD for Microsoft Entra ID authentication. This is a mechanism to sync Windows Active Directory users and groups to Microsoft Entra ID. For more information on Microsoft Entra ID Connect, see Microsoft Entra ID Connect sync: Understand and customize synchronization.

Setting up the Enterprise Application

To set up the Enterprise Application, follow these steps:

1. Navigate to the Azure portal: https://portal.azure.com/#home.

2. Go to Other → “App registrations” and click “New registration”.

   

3. This brings you to the “Register an application” page, where you initiate setting up your new Azure Web Application.

   

4. Set up your new Azure Application.

   1. Enter a user-facing name for your application. This name can be changed later, and is not used by Nasuni.

   2. When specifying the Supported account types that can access the application you should usually select “Accounts in this organizational directory only (Nasuni only - Single tenant)“. Depending on your directory topology “Accounts in any organizational directory (Any Microsoft Entra ID directory – Multitenant” can also be selected. Skype, Xbox and Personal Microsoft account types are not supported.

   3. Configure the redirect URI. The redirect URI is required for Nasuni SSO. Azure uses the redirect URI to redirect users to the application after they authenticate. The URL or IP address used for the redirect does not need to be publicly available, but does need to be reachable by clients accessing the application.
      

Note: You can get to this page by going to your application and selecting “authentication” as well.

The new Azure application is created, and the App registration Overview page is displayed.

5. Create the secret for this application by following these steps:

   1. Go to “Certificates & secrets”.

   2. Click “Client secrets”.

   3. Click “New client secret”. Enter a description and configure expiration. Set a reminder for the expiration date since you must generate a new client secret and provide it to the NMC before expiration.

   4. You MUST copy and save the secret value for this application now. Azure only allows access to the secret value upon creation.

   

Note: Secrets have a configurable lifetime. The Azure default is 6 months, and the maximum allowed is 24 months. When the client secret expires, users are not able to authenticate to the NMC. See Updating the Client Secret After Expiration  for more information.

6. Set up the Token ID Grant by following these steps:

   1. Go to Authentication.

   2. Select “ID tokens (used for implicit and hybrid flows)”.

   3. Click Save.

   

7. Set up Microsoft Graph API permissions by following these steps:

   1. Go to “App registrations” → “API permissions”. The API permissions page appears.

   2. Click “Add a permission”. The “Request API permissions“ page appears.

      

   3. Click “Microsoft Graph”. The “Microsoft Graph” dialog box appears.

      

   4. Click “Application permissions”. The “Select permissions” pane appears.

      

   5. In the “Select permissions” text box, type “Application.Read.All". The Application.Read.All permission appears.

      

   6. Select the Application.Read.All permission, then click "Add permissions”.

   7. The permission appears in the list of permissions.

      

   8. Use steps b - g to add the Group.Read.All permission.

   9. Use steps b - g to add the User.Read permission, if missing. (In most cases, this is pre-populated by Azure.)

The full list of permissions should look like this:

8. On the “API Permissions” page, select “Grant admin consent” for the permissions. Because these are application permissions, not delegated permissions, an admin must grant consent to use the app roles assigned to the application. For details, see Grant admin consent.

   

9. Set up the Application claims by following these steps:

   1. Go to “App registrations”, select your application from the list, then click “Token configuration”. Click “Add groups claim”.
      The “Edit groups claim” dialog box appears.

      

   2. Select “Groups assigned to the application”.

   3. For each type, specify “Group ID”.

      

   4. When done, click Add.

10. Add groups to the application by following these steps. These are the groups containing users that would be able to log in via SSO on the NMC.

    1. Go to “Enterprise Applications”. Select your application. Click Properties.

    2. Ensure that “Assignment Required” is set to “Yes”. Click Save.

    3. Go to “Enterprise Applications” → “Users and groups”.

    4. Add the groups that you want to be able to log in via SSO.

Assuming that Microsoft Entra ID Connect is set up, you should see your Windows Active Directory groups. Groups synced via Microsoft Entra ID Connect or groups natively created in Microsoft Entra ID are supported.

Note: Nasuni only supports Azure groups that are assigned to the Application. Assigning Microsoft Entra ID Users directly by using Assignment is not supported.

Note: Microsoft Entra ID only supports users that are direct members of a group. Users that are members of groups nested within the group cannot be authenticated. If users in nested groups require access, explicitly add the nested group.

This completes the Microsoft Entra ID procedure.

NMC procedure

This section details the steps needed on the NMC.

At this point, you should have configured the following:

• Azure Tenant is configured and set up.

• Azure Application registration is configured and set up.

• There is at least one user that is a member of the group assigned to the Application.

Tip: To access the NEA or NMC appliance using the serial console, instead of using the IP address obtained when installing the appliance, follow one of these procedures:

• If the appliance is running on Amazon EC2, see instructions in EC2 Serial Console for Linux instances.

• If the appliance is running on Google Cloud, see instructions in Troubleshooting using the serial console.

• If the appliance is running on Microsoft Azure, see instructions in Azure Seriasole.

All supported hypervisors include a serial console that works with Nasuni. For other hypervisors, consult your vendor’s documentation for connection instructions

The next set of steps are required for the NMC and Edge Appliance to work with Azure to enable SSO authentication:

1. In the NMC, on the Console Settings tab, click the “Single Sign-On” status to navigate to the “Single Sign-On” configuration page.

   

2. Enter the credentials as follows:

• Client ID
  Acquired from Azure. Navigate to “App registrations” → Overview.

  

• Client Secret
  Acquired from Azure during secret creation (see step 5 above).

• Resource URL
  Unless Microsoft makes a major change, accept the default: https://graph.microsoft.com.

• Tenant ID
  Acquired from Azure. Navigate to “App registrations” → Overview.

  

• Azure Group name
  Name of a Group that has been assigned to the Enterprise Application in Azure (see step 10 above).

  

3. Click “Enable Single Sign-On Configuration”. The “Single Sign-On Enabled” message should appear.

   

4. A new “SSO Administrator Group” superuser group is created as the initial administrator group for SSO.
   

Considerations:

• At this point, the user that configured SSO is still logged in using a native or domain account. This Administrative User, and any other users who are currently logged in, continue to have active and valid sessions.

• After any of those users logs out, they are required to use SSO login to log back in.

5. Log out and log in as an Azure user that is a member of the Azure group that you provided to the NMC in step 2 above.

6. You can create or edit NMC groups to specify the NMC SSO Group Association for the Azure Group you chose (requires the group to be assigned to the application first).

NMC SSO Operations

NMC SSO login depends upon a valid client secret that has not expired. Azure’s default validity for secrets is 6 months, and the maximum allowed is 24 months.

To ensure that the NMC always has a valid client secret, Administrators should track client secret expiration as part of their IT operations, using the same practice they use for tracking SSL certificate expiration.

Updating the Client Secret before expiration

1. Before the client secret for the NMC’s Azure App registration expires, create a new client secret in Azure and note the new secret value. Creating a new client secret does not invalidate existing secrets.

2. Use the NMC UI “Single Sign-On” page to input the new Client Secret and click “Update Single Sign-On Configuration” to complete the update. New logins to the NMC UI use the new client secret to authenticate.

1. When the client secret expires, users cannot authenticate to the NMC.

2. Use the steps for Disabling NMC SSO to restore login for native and AD users so that you can log in to the NMC.

3. Create a new client secret for the NMC’s App registration in Azure and make a note of the new secret value.

4. Use the NMC UI Single Sign-On page to input the required values for SSO to re-enable SSO. Existing NMC Groups and SSO Group Associations are preserved.

NMC API Usage

NMC SSO Troubleshooting

Common Issues

If some users cannot log in to the NMC when SSO is enabled, perform these steps:

• Reference the verbose errors returned by Azure or the NMC’s Login page. The error messages can be provided to Azure or Nasuni Customer Support for further troubleshooting.

• Ensure that the users are a member of a Microsoft Entra ID Group with a Nasuni SSO Group Administration. The users must be direct members of the Microsoft Entra ID Group and not members of a nested group.

• Repeat login using an incognito/private web browser connection to the NMC. SSO sessions from other providers can sometimes interfere with SSO login.

• Ensure connectivity between the NMC and Microsoft Entra ID, and confirm Microsoft Entra ID service health using Azure’s status dashboard.

If NMC SSO stops working for all users, perform these steps:

• Use the Azure Application registration to confirm that the Azure Client Secret is still valid. If it has expired, follow the instructions in Client Secret Expiration to update the secret.

• Ensure connectivity between the NMC and Microsoft Entra ID, and confirm Microsoft Entra ID service health using Azure’s status dashboard.

If the NMC API is not accessible, perform this step:

• Ensure you use a native or domain user account to obtain an NMC API token. The NMC API does not support SSO login.

Configuring Timeout for Inactive Sessions

After NMC SSO is enabled, the session timeout is configured to match what the Access Token timeout is in Azure. The default is 60 minutes.

For details on configuring Azure’s session timeout, see Configure token lifetime policies.

NMC SSO can be disabled, making it possible to log in to the NMC using a native or domain account. Disabling SSO could be required if the SSO identity provider is offline or unreachable, or if the client secret for SSO has expired and needs to be updated. Disabling SSO does not delete the established SSO group associations.

There are two methods for an administrator to disable NMC SSO:

• The NMC Service Console has a command to disable SSO: delete_sso_configuration

• Performing a Recovery operation on the NMC disables SSO on the newly deployed NMC. After recovery, SSO is not automatically re-enabled. Following recovery, a notification is raised that reminds the administrator to re-configure SSO.
  For more information on performing a recovery operation on the NMC, see NMC Recovery Guide.

Logging out of the NMC

Logging out of the NMC does not log the user out of Microsoft Entra ID. The user must log out of Microsoft Entra ID separately.