Aruba New Central Integration

1. Introduction

This guide describes how the UnDesked and HPE Aruba New Central integration works, what is supported, and how to configure, validate, and troubleshoot it.

'New Central' refers to the HPE Aruba Networking Central experience on the HPE GreenLake platform; 'Central NAC' is its built-in network access control service that provides the guest captive portal and visitor stores. A companion guide covers the Classic Central edition.

2. Solution Overview

UnDesked is a cloud visitor management platform (kiosk check-in, pre-registration, notifications, badges, check-out). This integration adds automated guest Wi-Fi onboarding: at check-in, UnDesked creates a temporary guest account in a Central NAC visitor store on the customer's New Central workspace.

How the visitor experiences it

1. The visitor checks in at a kiosk or by contactless check-in (a pre-registered visitor completes check-in on arrival) and provides a mobile number. Pre-registration by itself does not issue credentials.

2. An SMS arrives with the SSID, a username, and a password.

3. Visitor joins the guest Wi-Fi and signs in on the captive portal.

4. Access stays valid for the visit (per the kiosk's check-out settings).

5. At check-out, the account is removed automatically.

Benefits

• Zero-touch: no manual creation, hand-out, or cleanup of guest credentials.

• Unique credentials per visitor, per visit.

• Traceable: every guest account is linked to a visitor record.

Technical approach

• Uses the New Central Configuration APIs (HPE GreenLake OAuth 2.0 client credentials) and the Central NAC visitor API to create, verify, and delete guest accounts.

• Accounts live in a Central NAC visitor store; the guest SSID uses the Central NAC captive portal, whose Authentication Profile validates sign-ins against that store.

• UnDesked does not manage APs, WLANs, or policy, and needs no BLE, IoT Connector, or on-premises components.

• Network access control stays on the Aruba side: the APs assign each guest a role and enforce its access policies (see section 3.5).

3. Solution Architecture

Figure 1. Solution architecture and integration points.

Flows, matching the numbered badges:

1. Check-in at a kiosk (HTTPS to the UnDesked cloud).

2. UnDesked calls the regional New Central API to create the guest account at check-in, reuse it on a repeat check-in, and delete it at check-out.

3. Visitor receives the SMS credentials.

4. Visitor's device joins the guest SSID; the AP redirects to the Central NAC captive portal.

5. The portal validates the sign-in against the visitor store account from step 2.

All integration traffic is outbound HTTPS from the UnDesked cloud: no inbound access, no firewall changes.

3.1 Components and Roles

Component	Role	Communication
UnDesked Cloud Platform (SaaS)	Visitor management; Aruba Central integration; SMS notifications	Outbound HTTPS 443 to HPE GreenLake sign-on and the regional New Central API endpoint; SMS via messaging provider
HPE Aruba Networking Central (New Central, on HPE GreenLake)	Hosts the Configuration APIs and the Central NAC service	Receives REST calls; manages the customer's APs
Central NAC captive portal and visitor store	Guest sign-in page; the visitor store holds the guest accounts	Validates guest Wi-Fi sign-ins against the visitor store
Aruba access points (New Central managed, AOS 10)	Broadcast the guest SSID with Central NAC captive portal security; enforce guest access policies (built-in stateful firewall)	Managed by Central
Visitor's mobile phone	Receives the Wi-Fi credentials	SMS

3.2 Deployment Models

Any AOS 10 access point managed under New Central is supported, using the built-in Central NAC captive portal on the guest SSID. An AP still configured through a Classic Central group must be moved to New Central management first (section 4.1).

Deployment model	Status	Notes
AOS 10 – New Central managed, Central NAC captive portal	Supported	Validated model.
Classic Central – Cloud Guest external captive portal	Supported separately	Covered by the companion Classic Central SIG; the platform is selected per organization in UnDesked; one platform is active at a time.
AOS 8 – Controller Managed	Not supported	Controller-hosted / ClearPass portals are not supported.

3.3 Support Matrix

Component	Version(s) supported	Notes
UnDesked Visitor Management	Current SaaS release	Continuously delivered
HPE Aruba Networking Central	New Central (HPE GreenLake, current SaaS release)	New Central UI and Configuration API framework
Central NAC visitor API	network-config v1alpha1	A visitor store (identity store of type LOCAL) is required
Access points / AOS	AOS 10.x, New Central managed	AP models per the customer's Central subscription
SMS delivery	UnDesked notification service	Visitor mobile number required

• Long Supported Releases (LSR) and Short Supported Releases (SSR) are both supported. Check the HPE Networking Support Portal (Software End of Life) for current software status.

3.4 REST API Usage

Visitor and store calls target the customer's regional New Central API endpoint with an Authorization: Bearer header. Access tokens are minted from HPE GreenLake single sign-on using the API client credentials; there is no refresh token, no token file, and no X-Customer-ID header.

Endpoint	Purpose	When called
POST https://sso.common.cloud.hpe.com/as/token.oauth2 (grant_type=client_credentials)	Mint a short-lived access token (about 2 hours), cached until near expiry	On demand; tokens are never persisted
GET /network-config/v1alpha1/identity-stores	List visitor stores (identity stores of type LOCAL)	Setup ('Fetch Visitor Stores')
POST /network-config/v1alpha1/cnac-visitor	Create the guest account (username, fixed password, absolute expiry)	Check-in
GET /network-config/v1alpha1/cnac-visitor?search=	Find existing or stale accounts by username (paginated; exact-name matched)	Repeat check-in; dedup
DELETE /network-config/v1alpha1/cnac-visitor/{id}	Delete the guest account	Check-out; dedup

• New Central enforces an account-wide limit of 10 API calls per second. UnDesked stays well below it (a few calls per check-in); for throttling (HTTP 429) see section 4.4.

3.5 Guest Network Security

This integration creates the guest credentials; network enforcement happens on the Aruba side. Every client that joins the guest SSID is assigned a role, and the AP's built-in stateful firewall (up to Layer 7) enforces the policies attached to that role, applying security at the source before guest traffic reaches the rest of the network.

Recommendations for the guest SSID

• Segment the guest network: put the guest SSID on a dedicated guest VLAN/subnet, separated from internal networks. Never expose internal subnets to guests.

• Apply an explicit rule set. Creating the guest WLAN auto-creates a default role for the WLAN and Allow All rules in two system policies (see System-generated roles and policies below). Edit the role's rules under Library > Roles & Policies > Security Policies > Role-based Policies, and never leave the guest role unrestricted.

• One Authentication Profile per SSID: every client on an SSID signs in through the same profile and receives the same access. Give each privilege level (for example, guests and contractors) its own SSID, Authentication Profile, and visitor store, then assign the matching store per workflow in step C.

• Isolate guest clients: enable Client Isolation (WLAN profile > Captive Portal > Advanced) so guests cannot reach each other on the SSID.

• Keep portal self-registration off: leave Allow users to register an account disabled in the Authentication Profile (step A4). If it is enabled, anyone on the SSID can create a guest account and bypass visitor check-in.

System-generated roles and policies

Creating the WLAN and the Authentication Profile generates the following objects under Library > Roles & Policies. Know them before hardening the guest role.

Object	Created by	What it is and what to do
sys_cnac_<profile name> (role)	Saving the Authentication Profile (step A4)	Pre-authentication role for clients that have not signed in yet; the name follows the Authentication Profile name (profile Guest Portal creates sys_cnac_guest_portal). Set it as the WLAN's Assign Pre-Authentication Role (step A4).
sys_central_nac (role-based policy, Campus Access Point / Global)	Central NAC	Walled garden for the pre-authentication role: allows TCP 80 to symcb.com, symcd.com and digicert.com so client devices can run certificate revocation checks while the portal loads. System generated: do not edit or delete.
Default role for the WLAN (named after the WLAN)	Creating the WLAN (step A2)	Role applied after a successful sign-in. Give it the explicit rule set from the example baseline below.
System Default GW Policy (role-based policy, not assigned)	Creating the WLAN (step A2)	Holds an Allow All rule for the WLAN's default role. Not assigned to a device function by default; remove the rule for hygiene once the baseline policy is in place.
sys_allow_all (role-based policy, Campus Access Point / Global)	Creating the WLAN (step A2)	'Default policy to allow role to role traffic': holds an Allow All rule for the WLAN's default role, enforced on every AP. Remove that rule once the baseline policy is assigned and a test sign-in has succeeded; left in place it bypasses the denies in the baseline.

Example baseline

A minimal rule set for the guest SSID's default role. Every rule uses the role as its source; rules are processed top to bottom: service allows first, then internal-network denies, then a final allow for the internet.

• Build the rule set as a role-based policy and assign it to Campus Access Point at Global scope; an unassigned policy is not enforced.

• Remove the Allow All rule for the WLAN's default role from System Default GW Policy and from sys_allow_all only after the baseline policy is assigned and a test sign-in has succeeded (section 4.3). While the sys_allow_all rule remains, it bypasses the deny rules above.

#	Rule	Purpose
1	Allow svc-dhcp to any destination	IP address assignment on the guest VLAN
2	Allow svc-dns to any destination	Name resolution
3	Deny any to network 192.168.0.0/16	Blocks internal (RFC 1918) addresses
4	Deny any to network 172.16.0.0/12	Blocks internal (RFC 1918) addresses
5	Deny any to network 10.0.0.0/8	Blocks internal (RFC 1918) addresses
6	Allow any to any destination	Outbound internet access

Figure 2. Role-Based Policies: example rule set on the guest SSID's default role, Aruba Network (each Source cell shows 'Role: Aruba Network' and, on a second line, the rule's Source Role Options value).

Adjust the internal ranges to your addressing plan, and add content filtering or deep packet inspection per company policy.

IMPORTANT: this integration automates guest accounts only; UnDesked never changes Aruba-side network policy. The example above is a starting point, not a complete policy: define the actual rule set for the guest SSID with your network or security team.

4. Solution Configuration – Config/Verification/Troubleshooting Workflows

4.1 Prerequisites

• HPE GreenLake workspace with the New Central experience and administrator access.

• Central NAC available in the workspace. Visitor accounts and captive portal authentication are core Central NAC capabilities included with Central Foundation or Advanced device subscriptions; no separate NAC subscription is required. Central NAC appears in the Central menu once the tenant is provisioned.

• A guest SSID broadcast by the Aruba APs, captive portal type Central NAC (step A2).

• APs managed by New Central and running AOS 10. Each AP that broadcasts the guest SSID needs an active AP subscription (HPE GreenLake > Devices > Subscriptions) and must show Device Function Campus Access Point, a Site, and Provisioning State Yes in Device Inventory. An AP still configured through Classic Central never receives Library profiles (see the next item).

• Moving an AP out of Classic Central. In Classic Central, create an ArubaOS 10 Campus/Branch group with Allow New Central to overwrite all configurations enabled (never an ArubaOS 8 group) and move the AP into it. Assign the AP's site from Classic Central > Organization > Network Structure > Sites; site assignment is not available from New Central. Then confirm that the AP page shows Configuration Status Synchronized.

• A working guest network topology: DHCP and DNS on the guest VLAN/subnet, routing to the internet, and access rules per section 3.5.

• A Central NAC visitor store and an Authentication Profile of type Captive Portal linking the store, the portal, and the guest SSID (steps A3 and A4).

• An UnDesked user with Admin permission on Integrations at the organization level. The Aruba Central card appears under Settings > Integrations only while the organization, not a location, is selected.

• Check-in captures the visitor's mobile number (credentials are delivered by SMS).

Values collected from HPE GreenLake and New Central during Step A:

#	Value	Where to find it
1	GreenLake Client ID	HPE GreenLake > Manage workspace > Personal API clients (step A5)
2	GreenLake Client Secret	Shown once when the API client is created (step A5)
3	Region	Your Central workspace region (step A6)
4	SSID	The ESSID Name of the guest WLAN profile (step A2)
5	Visitor store	Central NAC > Configuration > Identity Management (step A3)

4.2 Configuration Workflow

4.2.1 Step A: Prepare HPE GreenLake and New Central

A1. Sign in and open New Central

• Sign in at common.cloud.hpe.com; launch HPE Aruba Networking Central from 'My services'.

• Use the New Central experience (leave the Classic Central toggle off).

Figure 3. Launching HPE Aruba Networking Central from the HPE GreenLake workspace.

A2. Configure the wireless network (SSID)

• In Library > Wireless > WLAN, create or open the guest WLAN profile (Type Access) as a shared Library profile: leave Save as a local profile unchecked, because Central NAC does not work with local profiles. Note the exact ESSID Name.

• In the VLAN section, use Traffic Forwarding Mode Bridge with the guest VLAN; that VLAN must provide DHCP, or the captive portal redirect fails.

• Set Security Level Open with Key Management Enhanced Open. The guest joins the SSID without a Wi-Fi passphrase and then signs in on the captive portal with the SMS credentials.

• Keep WPA3 Transition (Captive Portal > Advanced) enabled. With Enhanced Open this acts as Enhanced Open transition mode, so devices that do not support Enhanced Open can still join the same SSID.

• Set Captive Portal Type to Central NAC. The WLAN profile has no visitor-store field; the store is linked through the Authentication Profile in step A4, and the WLAN is not enabled until that profile references it.

• Leave Assign Pre-Authentication Role (Access > Advanced, Figure 4) empty for now: Central NAC generates that role when the Authentication Profile is saved, and you set it in step A4. After sign-in, the WLAN's default role applies and carries the access rules from section 3.5.

Figure 4. WLAN security: Captive Portal Type 'Central NAC' and the Pre-Authentication Role field (the role name follows your Authentication Profile name).

• Keep the auto-created default role (Access section) and give it an explicit rule set; recommendations and an example baseline are in section 3.5.

• Assign the WLAN profile: profiles in the Library are templates and are not broadcast until assigned. In the WLAN list, open the profile's row menu and select Assign (Figure 5).

Figure 5. Assign from the WLAN profile's row menu.

• In Assign Profile, select Device Function Campus Access Point and add one or more Scopes; levels run broadest to narrowest: Global, Site Collections, Sites, Device Groups, Devices (Figure 6). Pick the narrowest scope that covers the APs that should broadcast the guest SSID.

Figure 6. Assign Profile: the Device Function and the available scope levels.

• Until assigned, the WLAN list shows '-' under Assigned Device Function and Assigned Device Scope, and no AP broadcasts the SSID even with Status Enabled; once assigned, both columns show the selection (Figure 7).

Figure 7. The guest WLAN profile assigned to Campus Access Point at Global scope (Library > Wireless > WLAN).

A3. Create or confirm the visitor store

• Go to Central NAC > Configuration > Identity Management; create a visitor store (or confirm one exists) and note its name.

• Built-in stores (the MAC Address Store and the Wi-Fi Easy Connect Registration Store) cannot hold guest accounts; UnDesked lists visitor stores only.

Figure 8. Identity Management: the visitor store beside the built-in stores.

A4. Configure the Authentication Profile

• Go to Central NAC > Configuration > Authentication Profiles; create or open the profile for the guest SSID.

• Authentication Type: Captive Portal. Authentication: Users sign in with an account (username and password).

• Leave Allow users to register an account off (section 3.5). Enable MAC Caching and Limit Concurrent Clients Per Account are optional; keep them off while validating.

• Identity Stores: include the visitor store from step A3.

• Portal Profile: the branding of the sign-in page. If none exists, create one under Central NAC > Configuration > Portal Customization > Portal Profiles and select it; the defaults are fine, and the Custom SMS/Email Messages there are not used by this integration. The Portal URL is generated when the profile is saved.

• Assigned Network: the guest SSID from step A2.

Figure 9. Authentication Profile linking the guest SSID (Network) and the visitor store (Identity Stores).

• Saving the profile generates the pre-authentication role sys_cnac_<profile name> (for example sys_cnac_guest_portal for a profile named Guest Portal) and adds it to the sys_central_nac walled-garden policy.

• Return to the WLAN profile (Library > Wireless > WLAN), open Access > Advanced, set Assign Pre-Authentication Role to that role, and Save.

IMPORTANT: for every guest SSID, the Authentication Profile's Identity Stores list must include the visitor store selected in UnDesked (steps B3 and C). A mismatch creates guest accounts in a store the SSID does not authenticate against, and visitors cannot sign in even with correct credentials.

A5. Create the GreenLake API client credentials

• In HPE GreenLake, open Manage workspace > Personal API clients and create a client named for UnDesked. For Service, select HPE Aruba Networking Central, not GreenLake Cloud Platform; the latter scopes the client to platform APIs and issues 15-minute tokens. The client is scoped to that one service, and each user can hold up to seven personal API clients per workspace.

• Copy the Client ID and the Client Secret. The secret is shown once at creation; store it securely. The credentials have no expiry date: they stay valid until the client is deleted, its secret is reset, or the GreenLake user who created it is removed from the workspace.

• The client inherits the roles of the GreenLake user who creates it, so create it from a dedicated, least-privileged user rather than a personal administrator account.

• To rotate credentials, create a new client, update UnDesked, then delete the old client; deleting or resetting a client invalidates its tokens immediately. Delete the client when the integration is decommissioned.

Figure 10. Creating the personal API client: Service set to HPE Aruba Networking Central.

IMPORTANT: New Central needs no token file and no Customer ID. UnDesked mints short-lived access tokens automatically from these client credentials; there is nothing to download or rotate manually.

A6. Identify the region

• The workspace region appears in the API client's service name; for example 'HPE Aruba Networking Central ( US West )' corresponds to Region US-1 in UnDesked. Fetch Visitor Stores (step B3) validates the choice: with a wrong region it fails immediately, so correct the region and fetch again.

Figure 11. GreenLake API client: workspace region and token issuer URL.

4.2.2 Step B: Configure the Integration in UnDesked

B1. Open the Aruba Central integration

• Sign in to UnDesked as an organization administrator.

• Open Settings > Integrations with the organization selected. On the Aruba Central card, click Configure; the Aruba Central Details dialog opens.

Figure 12. Organization-level Settings > Integrations with the Aruba Central integration card.

• The dialog opens on the Credentials tab. Under Aruba Central Platform, select NEW CENTRAL, the default for new integrations.

• Each platform keeps its own credentials; switching the toggle never discards the other platform's saved values.

• Only one platform can be active per organization. The selected platform issues Wi-Fi credentials for every location and workflow, and switching the toggle and saving moves the whole organization to the other platform.

• After you switch the toggle on a saved integration, UnDesked shows the notice 'On Save, New Central becomes the active platform for every location in this organization.' (Figure 14). If the platform you are leaving has unsaved changes, UnDesked first asks 'Unsaved changes detected' and offers Discard Changes or Cancel.

Figure 13. Credentials tab with the Aruba Central Platform toggle on NEW CENTRAL.

Figure 14. Notice shown after switching the platform on a saved integration; it stays until Save or until the toggle is switched back.

B2. Fill in the Credentials tab

Field	What to enter
Aruba Central Platform	NEW CENTRAL (default for new integrations).
Activate for new locations	ON to auto-enable future locations.
GreenLake Client ID / Client Secret	From step A5.
Default Region	US-1 is pre-selected for a new integration; click + to change it to the region from step A6.
Default SSID	Exact SSID from step A2 (shown to visitors in the SMS).
Visitor Store	Selected in step B3.
Default Message	SMS template; personalize in step B4.

• Secrets are stored encrypted on the UnDesked servers and masked in the UI. Access tokens are requested from HPE GreenLake on demand using the client credentials and are never stored.

B3. Fetch and select the visitor store

• Click Fetch Visitor Stores. The button becomes active once the client credentials and the region are filled in.

• Click + next to Visitor Store and select the store from step A3.

• Nothing is pre-selected. The field is required, and Save reports 'This field is required' while it is empty.

• Guest accounts are created in this store; the captive portal configured in step A4 authenticates against it.

• If the list fails to load, re-check the credentials and region (see section 4.4).

Figure 15. Fetching and selecting the visitor store in UnDesked.

B4. Personalize the default message (optional)

Placeholders (insert via Insert Info, or type %): %wifi-ssid%, %wifi-user-name%, %wifi-password%, %organization-name%, %location-name%, %visitor-name%, %host-name%, %checkpoint-name%, %cellnum%, %additional-info-(company)%.

IMPORTANT: always keep %wifi-ssid%, %wifi-user-name%, and %wifi-password% in the message; without them visitors do not receive their login details.

B5. Save

• Click Save.

• If GreenLake Client ID, GreenLake Client Secret, Default Region, or Visitor Store is empty, that field is marked 'This field is required' and nothing is saved.

• The card's status button now reads Connected (Figure 16).

• That button is also the integration's on/off switch. Clicking it changes it to Disabled and stops guest-account creation and check-out deletion for every location; saving this dialog sets it back to Connected. To pause a single site, use that location's Enabled switch (step C) instead.

Figure 16. The Aruba Central integration card showing Connected after saving.

4.2.3 Step C: Per-Location Settings

• Reopen the integration (Configure) and switch to the Visitor Configuration tab, which appears only after the first Save. The tab lists one location per line; search by location name and page through the list (25 locations per page by default, 10 to 100 selectable).

• Toggle Enabled for each location (the switch in the column header toggles every location on the current page).

• Optionally override SSID, Visitor Store, or Message per location; empty fields inherit the organization defaults.

• Inherited values appear dimmed, and an inherited visitor store shows as a chip that cannot be removed; clearing an override restores inheritance.

• A location that has never been saved on this tab starts Enabled when Activate for new locations is on. Once you save this tab, every location keeps its own setting, so later changes to Activate for new locations affect only locations created afterwards.

• Click Save.

Figure 17. Visitor Configuration tab: per-location settings.

Per-workflow overrides (optional)

• Click the icon in the Configure Workflows column to open that location's active check-in workflows (visitor types). Language variants of a workflow share the parent workflow's setting. You can search by workflow name and move between pages without losing edits; one Save applies every change.

• Each workflow defaults to Enabled and inherits the location configuration; override SSID, Visitor Store, or Message per workflow. Empty fields inherit the location, then organization values.

• Toggle Enabled per workflow to control which workflows issue Wi-Fi credentials (the header switch toggles all workflows on the current page).

• Click Save in the dialog. Workflow changes are saved immediately and do not require saving the integration again.

• Pair with one SSID, Authentication Profile, and visitor store per privilege level (section 3.5) to give different workflows different network access.

Figure 18. Workflow Configuration dialog: per-workflow overrides for a location.

Guest account behavior

• Username: the visitor's mobile number (digits only). If the visitor has no number but is linked to an employee, the employee's number is used; otherwise the visitor's name plus a short random suffix. The SMS is sent only to the visitor's own number.

• Password: an 8-digit numeric code, generated per visit.

• Validity: the kiosk's automatic check-out interval (Kiosk settings > Enable Check-out Text > Time Until Auto Check-out (Minutes)), or the workflow's Override Auto Checkout Time when one is set, rounded up to the next hour and stored as an absolute expiry on the account. Without a check-out interval, the account is valid for 24 hours.

• Repeat check-in: while the account is still valid, it is reused and the same credentials are sent again. After it expires, a new account replaces it and the earlier credentials stop working. If Central reports that the username already exists, the old account is deleted and a new one is created.

• Check-out: the guest account is deleted automatically, normally within a minute; allow up to 15 minutes under heavy load.

• Deletion is skipped if the integration, the location, or the workflow is disabled at check-out time, or if the account's validity period has already passed. If Central rejects the delete request, UnDesked does not retry it. In each of these cases, and when a visitor never checks out, the account still stops working when its validity expires.

4.3 Configuration Validation

In UnDesked

• Fetch Visitor Stores succeeding confirms the Client ID, Client Secret, and Region together (a live HPE GreenLake sign-on plus a Central NAC call).

• Save completes and the secrets are shown masked.

In New Central

• Guest WLAN profile has Captive Portal Type Central NAC and is assigned to Campus Access Point at a scope that covers the test AP (step A2).

• The Authentication Profile lists the visitor store and is assigned to the guest SSID (step A4).

• Device Inventory shows the AP with Provisioning State Yes; the AP page shows Configuration Status Synchronized and no active All Radios Disabled alert.

• After a test check-in, the account appears under Central NAC > Configuration > Visitors, filtered to that store (Figure 19).

Figure 19. Guest account created by check-in, listed in Central NAC.

End-to-end test (visitor device to Central NAC)

1. Check in a test visitor with a real mobile number.

2. Confirm the SMS arrives with the SSID, username, and password.

3. Confirm the account exists in Central NAC.

4. Join the guest SSID; confirm the captive portal redirect.

5. Sign in with the SMS credentials; confirm network access.

6. Check out the visitor in UnDesked.

7. Confirm the account is removed from the visitor store (normally within a minute; allow up to 15 minutes under heavy load).

If per-workflow overrides are set, repeat the test for each overridden workflow; confirm the SMS and captive portal sign-in use that workflow's SSID and visitor store.

Run the first pass with the system-generated Allow All rules still in place. Then apply the baseline policy from section 3.5, remove those rules, and repeat steps 4 and 5.

4.4 Troubleshooting

Symptom	Likely cause	Action
Fetch Visitor Stores shows 'Authentication with Aruba Central failed. Please verify your credentials.' (a 'Session expired! Please login again' message may appear as well; your UnDesked session is fine, ignore it)	Wrong Client ID / Secret / Region; or the GreenLake API client was deleted, its secret was reset, or the user who created it was removed from the workspace	Re-check the three values; after a secret reset paste the new secret; if the client was deleted or its owner removed, recreate it (step A5)
Fetch Visitor Stores shows 'Access denied to Aruba Central. Please check your permissions.'	The access token carries the permissions of the GreenLake user who created the API client; that user lacks the Central permissions needed to manage Central NAC visitor stores and accounts	Raise that user's Central role, or recreate the API client (step A5) from a user who has the permissions, then update UnDesked
Visitor store list is empty	No visitor store exists (built-in stores are not listed)	Create a visitor store (step A3)
'Too many requests to Aruba Central. Please wait a moment and try again.'	Account-wide API rate limit (HTTP 429): 10 calls per second across all tokens issued to the account	Fetch Visitor Stores: wait a moment and retry. Check-in: the provisioning job retries automatically after a short delay, up to three attempts
No SMS received	Any of: no mobile number captured; integration card shows Disabled; location Enabled off (or the location was created while Activate for new locations was off); workflow Enabled off in Configure Workflows; no visitor store resolved at any level; SMS not configured; three failed attempts (throttling or Central outage)	Capture the number at check-in; set the card back to Connected; enable the location and the workflow; select a visitor store (organization default or override); verify SMS settings; retry after Central recovers
No SMS at any location; the card shows Disabled	Integration deactivated by clicking the status button	Click Disabled to set it back to Connected, or open Configure and Save
Visitor gets the SMS but cannot see the network	SSID disabled or unassigned, AP offline, or the SSID name does not match	In New Central check the AP and WLAN status; confirm the SSID is enabled, the WLAN profile is assigned (Assigned Device Function and Assigned Device Scope must not show '-'), and the name matches the Default SSID in UnDesked exactly
SMS ok, sign-in rejected	The SSID's Authentication Profile does not include the selected visitor store; validity passed; typo	Align the profile's Identity Stores with the store selected in UnDesked (step A4); then check the visitor in again
Account not created at check-in	Integration Disabled; the API client was deleted or reset in HPE GreenLake; the user who created it was removed from the workspace or lacks the required Central permissions, or the visitor store was deleted	Verify Fetch Visitor Stores; recreate the API client (step A5) or reselect the store (step B3)
Account remains after the visit	Visitor never checked out; or Central rejected the check-out deletion (for example, throttled), so the account stays until its expiry; or the integration, location or workflow was disabled between check-in and check-out; or check-out happened after the validity period, so UnDesked's stored reference had already expired. Rejected deletions are not retried	None needed: it expires automatically; or check out / delete manually
One location behaves differently from the others	A per-location override on the Visitor Configuration tab	Open Visitor Configuration; check that location's Enabled switch, SSID, visitor store, and message. Empty fields inherit the organization default
One workflow behaves differently at a location	A per-workflow override in the Configure Workflows dialog	Open the location's Configure Workflows dialog (step C); check that workflow's Enabled switch, SSID, visitor store, and message. Empty fields inherit the location, then organization values
SSID not broadcast; Device Inventory shows Provisioning State No or Site Unassigned, or the AP raises an All Radios Disabled alert	AP still configured through a Classic Central group, no AP subscription applied, or no site assigned	Apply the AP subscription in HPE GreenLake; move the AP to a New Central compatible group and assign its site from Classic Central (section 4.1); confirm Configuration Status Synchronized on the AP page
Sign-in page never appears after joining the SSID	Guest VLAN has no DHCP, or the AP has not synchronized the WLAN yet	Verify DHCP on the guest VLAN; check Configuration Status on the AP page
Opening the Portal URL from a browser shows 'No capture parameters provided'	The portal was opened outside a captive-portal redirect	Expected; test only from a device joined to the guest SSID

5. Appendices

5.1 Support Model

Area or issue	Contact	How to reach
Integration setup, UnDesked configuration, SMS delivery, guest account creation or deletion	UnDesked Support	Call +1-855-622-9369 or email support@undesked.com
New Central access, AP hardware, wireless coverage, Central NAC platform, HPE GreenLake account	HPE Aruba Networking Support	HPE Networking Support Portal (networkingsupport.hpe.com), or your Aruba reseller
Unclear which side the issue is on	Start with UnDesked Support	We triage and coordinate with HPE where needed

• For no SMS, wrong message content, or guest accounts not created or deleted, contact UnDesked Support.

• SSID not broadcasting, captive portal not loading, or New Central unreachable: contact your network administrator or HPE Aruba Networking Support.