This guide is intended for IT administrators or individuals configuring Web Access for single sign-on (SSO).
For end user documentation on SSO, see Signing In and Signing Out.
Overview
Web Access offers SSO integration with Okta or with Microsoft Entra ID. SSO integration allows organizations to centralize authentication, enforce security policies, and implement multi-factor authentication (MFA).
When SSO is not configured, users must sign into Web Access using a username and password, typically their Active Directory credentials.
With SSO enabled, users see a “Log in with SSO“ button on the Login page. This button directs them to their identity provider (either Microsoft Entra ID or Okta), where they can authenticate using the credentials and methods established by their organization. After authentication, users' browsers are redirected back to Web Access, where they enter their Active Directory credentials to access Nasuni storage. On subsequent sign-ins via SSO, users do not need to input their Active Directory credentials again.
Alternatively, users can start at their identity provider's portal (Microsoft MyApps or the Okta dashboard). From there, they can click on the Web Access application icon or tile to be logged directly into Web Access.
SSO Configuration
Enabling SSO
SSO for Web Access is enabled and configured through the Nasuni Portal.
Configuration information applies to all Web Access instances within your account. After enabling, all users log into any Web Access instance by first authenticating with their configured identity provider.
When SSO is enabled for an existing instance, all users sign in via the “Sign In with SSO“ button.
The first time a user successfully signs in through SSO, they are prompted to enter their Active Directory credentials. This connects, or links, their SSO identity with the account they use to access Nasuni data.
Anonymous logins through Web Access are denied.
Disabling SSO
When SSO is disabled, users sign in using their Active Directory credentials. They continue to have access to any shared links they created through that Active Directory user when they were signing in through SSO.
Changing SSO Settings
SSO can be enabled and disabled at any time. The identity provider can also be changed at any time.
If SSO settings are changed, in particular if the Client or application ID has changed, the SSO user also changes. The next time the user signs in, they are prompted to enter their Active Directory credentials to link this new SSO user to their Active Directory account.
Linked Users
Multiple SSO users cannot share the same Active Directory credentials. If this happens, the user sees an error message such as:
“These credentials are linked to another user. Please contact your system administrator. (Error WA-1200, Ref ID <uuid>)”
If you believe this is happening in error, contact Nasuni Support.
Nasuni Data API and SSO
Nasuni Data API authentication, which uses the Web Access platform, is not affected by Web Access SSO.
Network requirements
Web Access-enabled appliances must have access to your configured identity servers (HTTPS outbound). If needed, you can configure the appliance to use an HTTPS proxy server. For more information, see HTTPS Proxy Configuration.
No inbound access is required.
SSO Authentication Flow
Web Access SSO uses the OpenID Connect (OIDC) “Authorization Code” flow. When SSO for Web Access is enabled, the login page displays a button titled “Sign in with SSO”. The title of this button can be customized.
When the user clicks the “Sign in with SSO” button, the web browser is redirected to the configured Identity Provider, where the user authenticates. This requires the user to enter their work credentials and typically complete a multi-factor authentication challenge.
A successful SSO authentication redirects the browser back to Web Access. Web Access verifies that the response is legitimate and looks up the authenticated SSO User.
If the SSO user is not linked to an Active Directory user or if the linked Active Directory user credentials are invalid, the user is presented with a page to enter their Active Directory credentials. These are then linked to that SSO user for future sign-ins.

Configuring SSO with Microsoft Entra ID
This section describes the procedure for configuring single sign-on for Web Access using Microsoft Entra ID. This procedure requires configuration steps in both the Microsoft Azure portal and the Nasuni Portal.
For more information on creating a Microsoft Entra application, see Quickstart: Add an enterprise application
System Requirements / Prerequisites
Before getting started, ensure that each of the following requirements has been met.
Requirement | Details |
|---|---|
Nasuni Edge Appliance (NEA) version 10.1.x or above. | Required for Web Access SSO support |
Fully Qualified Domain Name (FQDN). | Required to configure the SSO callback with Microsoft Entra ID. (Can be changed; and multiple names and IP addresses can be supported.) |
Access to a Microsoft Entra tenant with at least Cloud Application Administrator access. | See Create a Microsoft Entra tenant - Microsoft identity platform. |
Administrator access to Nasuni Portal. | To configure Web Access SSO. |
Square logo image. | Optional for My Apps. Recommended image dimensions of 215 x 215 pixels with central image dimensions of 94 x 94 pixels. Uses file type .bmp, .jpg, or .png. File size less than 100 KB. |
Registering an Enterprise Application in Azure Portal
Settings Required
Record the following information to complete the Web Access SSO Configuration through the Nasuni Portal.
Name | Description |
|---|---|
Application (client) ID | The Microsoft Entra ID Application ID. This is obtained as part of creating a new App in the Azure portal. |
Tenant ID | The Tenant ID for your Microsoft Entra directory. |
Client secret value | The Microsoft Entra ID client secret. This is obtained as part of the creation of a new App in the Azure portal. |
Starting the application registration
To register an Enterprise Application, follow these steps:
Sign in to the Microsoft Entra admin center.
Navigate to Entra ID → Enterprise apps → All applications.
Click New application.
On the Browse Microsoft Entra Gallery page, click Create your own application.
Creating your own application
Enter a name for the application, such as “Nasuni Web Access”. This name is used with My Apps, but it is not used by Nasuni otherwise.
Click “Register an application to integrate with Microsoft Entra ID“ (app you are developing).
Click Create.
Registering an application
Select one of the following two choices, which controls who can access the application:
- Accounts in this organizational directory only.
- Accounts in any organizational directory (Any Microsoft Entra ID directory – Multitenant).
Enter the Redirect URI for the platform. The Platform Type is Web. The URI is in the form:
https://<WEB_ACCESS_FQDN>/fs/auth/openid/callback
For example,
https://webaccess.example.com/fs/auth/openid/callback
Click Register to complete the application registration.
Managing single sign-on
The new Azure application is created.
Return to the home page.
Locate the application via Entra ID → Enterprise apps → All applications.
From the enterprise application you created, browse to Manage → Single sign-on.
Under Configure application properties, click Go to application.
Overview Essentials
Copy and note the following details:
Application (client) ID
Directory (tenant) ID
Adding a client secret
Navigate to the Manage → Certificates & secrets tab and click New client secret.
Enter a Description such as “Web Access SSO”.
Configure the Expiration. Set a reminder for the expiration date, because you must generate a new client secret and provide it to the Portal Web Access SSO User Interface before expiration.
Click Add. The secret is created and displayed.
Make note of the secret Value before leaving the page.
Important: Azure only shows the secret value upon creation. You must copy and save the client secret value for this application now.
Important: 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 Web Access.
The next step is to add the application to the My Apps portal.
Alternatively, you can skip straight to the last step: Nasuni Portal Configuration.
My Apps Portal (optional)
My Apps (myapps.microsoft.com) is a web-based portal for launching applications that use Microsoft Entra ID. You can add Web Access to the portal so that users in your organization can easily find and open it. When a user clicks the application icon, Web Access is launched directly, skipping the Login page.

Microsoft My Apps
This is called an Identity Provider-initiated (IdP-initiated) login because the user logs into the identity provider first and launches the app from the identity provider portal.
For more information, see My Apps portal overview - Microsoft Entra ID.
Adding Web Access to the Microsoft My Apps Portal
For a user to see an application in the portal:
The application must be set to be visible in its properties.
The application is assigned to the user or group.
The application must have a Home page URL.
Setting “Visible to Users” property
Return to your application under Entra ID → Enterprise apps.
If you have signed out:Open the Microsoft Entra admin center.
Browse to Entra ID → Enterprise apps → All applications.
Open your enterprise application.
Change the property:
Browse to Manage → Properties.
Select “Visible to users?” to Yes.
Click Save. The setting turns blue after being saved.
Adding Users
Browse to Manage → Users and groups.
Click Add user/group to open the Add Assignment page.
Under “Users and groups”, select None Selected to open a “Users and groups” dialog.
Select the users and/or groups desired. For example, “All Company”. Note the caveat “When you assign a group to an application, only users directly in the group have access. The assignment does not cascade to nested groups.”
Click Assign.
Adding the home page URL
Return to Single sign-on settings.
Open the Microsoft Entra admin center.
Browse to Entra ID → Enterprise apps → All applications.
Open your enterprise application.
Click Manage → Single sign-on.
Under Configure application properties, click Go to application.
After navigating to the application, click the Manage → Branding & properties tab.
Add a Home page URL of the form:
https://<WEB_ACCESS_FQDN>/fs
For example,
https://webaccess.example.com/fs
Adding a logo (optional)
You can also upload a logo for the My Apps tile.
The recommended image dimensions are 215 x 215 pixels with central image dimensions of 94 x 94 pixels. The file type can be .bmp, .jpg, or .png. The file size must be less than 100 KB.
Verification
Navigate to myapps.microsoft.com to verify that the application is visible.
Click the icon to open the application.
Verify that the Home URL is correct.
Nasuni Portal Configuration for Microsoft Entra
Configuration information for SSO is entered through the Nasuni Portal.
To enter this information:
Log in to the portal portal.nasuni.com as a user with Administrator permission.
Navigate to Appliance Services → Web Access → Single Sign-On.
For SSO Provider, select “Microsoft”.
For Client ID, enter the Microsoft Entra ID Application ID you collected above.
For Client Secret, enter the Client Secret you created above.
You need this again to make changes to these settings.If you are using single-tenant Active Directory, enter your Azure tenant GUID. Otherwise, leave Azure tenant GUID blank. (Enter a single space if you cannot leave the field blank.)
(optional) Enter a Login Button label.
Click Save.
Portal changes are pulled by the appliances once an hour, so it might take up to an hour for the settings to be reflected on the appliance. To force this step, an administrator can log into the NMC, navigate to the Refresh License page on the Filers tab, select the appliance, and click Refresh subscription license.
Configuring SSO with Okta
Introduction
This section describes the procedure for configuring single sign-on for Web Access using Okta. This procedure requires configuration steps in both the Okta Admin Console and the Nasuni Portal.
System Requirements / Prerequisites
Before getting started, ensure that each of the following requirements has been met.
Requirement | Details |
|---|---|
Nasuni Edge Appliance (NEA) version 10.1.x or above. | For Web Access SSO. |
Fully Qualified Domain Name (FQDN). | Required to configure the SSO callback with Okta. (Can be changed; and multiple names and IP addresses can be supported.) |
Access to the Okta Admin Console with permission to:
| |
Administrator access to Nasuni Portal. | To enable Web Access SSO. |
Logo for application. | For best results
|
Creating an Okta App Integration
Okta app integrations are registered connections between the Okta Universal Directory and external apps such as Web Access. App integrations on the Okta End-User Dashboard are sometimes referred to as tiles or apps.
Settings Required
As part of the app integration process, record the following information. This is required to complete the Web Access SSO Configuration through the Nasuni Portal.
Name | Description |
|---|---|
Client ID | The Okta Client Identifier obtained during the configuration of the new Okta App Integration. |
Okta base URL | Your Okta base URL is typically <your-subdomain>.okta.com. You can find it by signing into your Okta administrator console and looking for your organization's name or domain in the upper-right corner. |
Client Secret | The Okta Client Secret obtained during the configuration of a new Okta App Integration. |
Creating a new App Integration in the Okta Admin Console
To create and configure a new Okta App Integration, follow these steps:
Log in to the Okta Admin Console. You might need to select [Admin] after logging into Okta.
Using the navigation bar, click Applications → Applications.
Click Create App Integration. The following dialog is displayed.

For the Sign-in method, select OIDC - OpenID Connect. The Application type panel is displayed.
For Application type, select Web Application and click Next. The Application editor is displayed.
Click Next. A New Web App Integration page is shown.

Enter the App Integration name; for example Nasuni Web Access. The name cannot be changed later, and is not used by Nasuni.
(Optional) You might choose to set a Logo. This is optional and is not required.
For the Grant Type, select Authorization Code and leave Refresh Token unselected.
Sign-in redirect URIs:
https://webaccess.example.com/fs/auth/openid/callbackSign-out redirect URIs:
https://webaccess.example.com/fs/auth/loginIn the Trusted Origins section, leave the Base URIs empty.

In the Controlled access section, select whether to assign the app integration to:
- Allow everyone in your organization to access. If you select this option, leave the “Enable Access with Federation Broker Mode” option selected.
- Limit access to selected groups.
Note: You can assign this option after you create the Okta App Integration.
Click Save. A message appears indicating that the Application was created successfully and the wizard closes.
Nasuni Web Access Application
The Application “General” tab is selected for the newly created Application.
From “Client Credentials”, record the “Client ID”.
From “Client Secrets”, click the eye icon to reveal the secret. Record the secret.

The configuration steps in the Okta Admin Console are now complete.
Adding to Okta Dashboard (optional)
The Okta Dashboard is a web-based portal for launching applications that integrate with Okta. You can add Nasuni Web Access to the portal, so that users in your organization can easily find and open it. When a user clicks the application icon, Web Access is launched directly, skipping the Login page.
This is called an Identity Provider-initiated (IdP-initiated) login, because the user logs into the identity provider first and launches the app from the identity provider portal.
Locate your app integration under the Okta Admin Console → Applications.
Under the General tab, scroll down to General Settings and select Edit.
Scroll further down in edit mode:
Change Login initiated by to Either Okta or App.
For Initiate login URI, enter your
https://FQDN/fsClick Save.

Nasuni Portal Configuration for Okta
Configuration information for SSO is entered through the Nasuni Portal.
To enter this information:
Log in to the portal portal.nasuni.com as a user with Administrator permission.
Navigate to Appliance Services → Web Access → Single Sign-On.
For SSO Provider, select Okta.
For Client ID, enter the Application Integration Client ID you collected above.
For Client Secret, enter the Client Secret you created. You need this again to make changes to these settings.
Enter your Okta Base URL. You can find it by signing into your Okta administrator console and looking for your organization's name or domain in the upper-right corner.
Enter a Login Button label (optional).
Click Save.
Portal changes are pulled by the appliances once an hour, so it might take up to an hour for settings to be reflected on the appliance. To force this step, an administrator can log into the NMC, navigate to the Refresh License page on the Filers tab, select the appliance, and click Refresh subscription license.
Troubleshooting
The purpose of this section is to help you diagnose and remediate uncommon issues with the setup or operation of single-sign on for Nasuni Web Access.
Overview
Web Access SSO uses the OpenID Connect (OIDC) “Authorization Code” flow. The Authorization Code flow is an OAuth 2.0 grant type used by web and native applications to obtain access tokens. It is a secure two-step process that involves redirecting the user to an authorization server, obtaining an authorization code, and then exchanging that code for an access token.
IT administrators register Web Access as a client application through Microsoft Entra or Okta, yielding configuration settings including a client ID and secret. The IT administrator then enters these into Nasuni Portal’s “Web Access SSO” configuration page. These settings are then sent securely to all of an organization’s Nasuni Edge appliances.
If SSO configuration information is present, Web Access offers an SSO Sign-In option rather than a username/password sign-in page. After a user has been “authenticated” through their single sign-on provider, they enter their AD credentials in order to access their CIFS/SMB through Web Access.
SSO Protocol Errors
These errors might be seen during the SSO Login flow.
Error Code | Short Banner Text | What it Means | Typical Root Causes | How to Fix |
WA-1100 | “Sign in failed. Try again, or contact your system administrator if this issue continues. (Error WA-1000, Ref ID <uuid>)” | Web Access could not exchange the authorization code for an ID token. |
|
|
WA-1101 | “Sign in could not be verified. Please start again. (Error WA-1001, Ref ID <uuid>)” | Returned state parameter did not match the one stored in session. |
| Ask user to close extra tabs and start again. |
WA-1102 | “Your sign-in session expired. Please try again. (Error WA-1002, Ref ID <uuid>)” | Nonce (request token) in ID-token mismatched. |
| Ask user to restart login promptly. Check appliance clock sync (NTP). |
WA-1103 | “We could not confirm your identity. Try again later. (Error WA-1003, Ref ID <uuid>)” | /userinfo endpoint returned error or could not be reached. |
| Test /userinfo URL with curl. Verify token endpoint scopes include openid profile. |
WA-1104 | “Could not contact your organization’s sign-in service. Check your network or try again later. (Error WA-1004, Ref ID <uuid>)” | Network or DNS failure when calling IdP token or user-info endpoints. |
|
|
WA-1105 | “Sign-in session not found. Please start again. (Error WA-1105, Ref ID <uuid>)” | No SSO-workflow session on callback. |
| Ask user to restart login. |
WA-1106 | “Single Sign-On is no longer available. Contact your administrator. (Error WA-1106, Ref ID <uuid>)” | SSO was disabled. | • Admin turned off CIFSWEB_SSO_ENABLED. | Re-enable SSO or fall back to username/password. |
WA-1107 | “Could not fetch access token. <<Error Detail>>. (Error WA-1202, Ref ID <uuid>)” | An error fetching an access token from the SSO Identity Provider. Might be permanent or temporary. Error Detail provides error message from Identity Provider if received. |
| Review error detail. Look up error on Identity Provider’s site (Microsoft Entra or Okta). |
SSO User Access Codes
Error Code | Short Banner Text (seen by user) | What it Means | Typical Root Causes | How to Fix |
WA-1200 | “These credentials are linked to another user. Please contact your system administrator. (Error WA-1200, Ref ID <uuid>)” | Different SSO identity tried to map to an AD user already mapped. |
| Use correct AD credentials or contact support to unlink the old mapping with webaccess-cli sso-unlink-user. |
WA-1201 | “You do not have permission to access any shares in Web Access. Contact your administrator. (Error WA-1201, Ref ID <uuid>)” | AD user has no Web-Access-enabled shares. |
| Enable at least one share or adjust NAS permissions; user must re-login. |
WA-1202 | "Active Directory credentials could not be verified. Please try again or contact your administrator." | AD user is not valid or AD service is not accessible. |
|
|
SSO Generic Errors
Error Code | Short Banner Text (seen by user) | What it Means | Typical Root Causes | How to Fix |
WA-9999 | An unexpected error occurred. Please try again, or contact your administrator. (Error WA-9999, Ref ID <uuid>)” | An exception appears that is not already mapped to WA-11xx / WA-12xx | Identify the actual problem in the logs. |
Microsoft Entra Troubleshooting
Error Message | Possible cause | Remediation |
Validation failed for the provided input in the Portal Web Access SSO User Interface Please ensure all fields meet the required format and constraints. | 1. Incorrect Format: Ensure that all fields meet the required format and constraints. 2. Unexpected Characters | When portal interface is available: 1. Incorrect Format: Ensure that: o Application ID and Tenant ID are valid UUIDs o Client Secret follows the expected format (typically a long alphanumeric string). 2. Missing or Empty Fields: Double-check that none of these fields are empty or incorrectly populated. 3. Unexpected Characters: Ensure no extra spaces, line breaks, or hidden characters are included. 4. Nasuni Web Access SSO backend Model Constraints: If the model has regex or strict type validation, verify the expected patterns. |
Sorry, but we’re having trouble signing you in. AADSTS700016: Application with identifier <IDENTIFIER> was not found in the directory 'Nasuni'. | This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
| Application ID Is Incorrect or Not Registered
o Ensure you are in the correct tenant (check the directory switcher at the top right). o If missing, re-register the application. The Application Is Not Assigned to the Tenant
Admin Consent Is Required
Verify Redirect URIs
|
Sign in failed. Try again, or contact your system administrator if this issue continues. (Error WA-1100) Logged information: invalid_client - AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app. |
| Ensure you're using the Client Secret Value, not the Client Secret ID:
|
Sorry, but we’re having trouble signing you in. AADSTS90002: Tenant '7e41ac00-3a40-446c-92f5-5885309a22c5' not found. Check to make sure you have the correct tenant ID and are signing into the correct cloud | The Tenant ID provided in the Nasuni Web Access SSO Configuration is incorrect or does not match the value configured in Microsoft Entra ID.
| Verify that the Tenant ID is correct
Verify That the Tenant Exists and Is Active
Check If the Application Is Assigned to the Correct Tenant
|
Entra validation succeeded during the Nasuni Web Access SSO set-up but the user cannot login | Configure allowed groups. | Configure allowed groups:
|
Nasuni Sign-in error page displayed when user logs in to Nasuni Web Access Dashboard | The sign-in/sign-out redirect URL is incorrect in the Microsoft Entra ID Admin User Interface. | Fix the Redirect URLs in the Microsoft Admin UI. |
Okta Troubleshooting
Error Message | Possible cause | Resolution |
Okta validation failed | Okta redirect URL is not set correctly. | You need to access the Okta Admin Console and configure the redirect URL with the Nasuni Web Access FQDN. Expected sign-in redirect URI is: https://WEBACCESS_FQDN/fs/auth/openid/callback For more information, see Sign users in to your web app using the redirect model | Okta Developer |
400 Bad Request - Your request resulted in an error. | The provided Client ID or Tenant ID is incorrect in the Nasuni Web Access SSO Configuration. | 1. Verify that the Client ID and Tenant ID configured in the Nasuni Web Access SSO settings match the values in the Okta application settings. 2. Check for typos or missing characters in the credentials. 3. Ensure the Okta application is correctly assigned to the users attempting to log in. |
Sign in failed. Try again, or contact your system administrator if this issue continues. (Error WA-1100) Logs: SSO callback failed 400: Could not exchange authorization code for tokens. | The Client Secret provided in the Nasuni Web Access SSO Configuration is incorrect or does not match the value configured in Okta. | 1. Verify the Client Secret: o Go to the Okta Admin Console → Applications → Select your application. o Navigate to Client Credentials and ensure the Client Secret matches the one configured in Nasuni Web Access SSO Okta configuration settings. 2. Regenerate the Client Secret (if necessary): o If unsure, regenerate a new Client Secret in Okta and update the Secret Value in the Nasuni Web Access Single Sign-On configuration UI. |

