Overview
Prior to Access Coins 12.05, authentication to Azure Active Directory (AAD) was limited to a single registered Azure AD Application per environment. This restriction could create security risks because different areas of Access Coins ERP+ may require different types or levels of access into a customer’s Azure services.
From release 12.05 onwards, multiple Azure AD Applications can be registered within Access Coins and associated with specific areas of functionality — similar to the ESB Systems capability. Access Coins determines the correct Azure AD App to use based on the functionality being executed. For customers hosted on Access Cloud – you can ignore reference to parameter INI files.
Key Changes in Release 12.05
The following changes were introduced from release 12.05:
AAD Application configurations are now named records managed via the Azure Applications function in the SY module.
All AAD configurations must be created in the LIVE environment. They are automatically refreshed to non-live environments (e.g. TEST, CPLIVE) as part of the normal data refresh.
Each environment references its AAD SSO configuration by name, via the SY/AAD_APP parameter in the environment’s param.ini file.
Multiple AAD Apps can be defined, allowing different Azure AD registrations for different functional areas (e.g. single sign-on, document management, integrations).
The legacy SY/AAD_CLIENT_ID and SY/AAD_SECRET parameters are retired. Existing configurations are auto-migrated on upgrade and appear as a record named AAD_CLIENT.
Azure Applications Screen
AAD Application records are managed at:
SY Module → System Setup → Azure Applications
Each record contains the following fields:
Field | Description | Example |
Code | Unique name for this AAD App configuration. This value is referenced in param.ini. | AAD_CLIENT_CPLIVE |
Description | Human-readable label for the configuration. | CPLIVE ERP Single Sign On |
Application ID | The Application (Client) ID from the Azure AD App Registration (GUID). | aaf675e0-383e-47cb-... |
Tenant ID | The Azure AD Tenant ID (GUID or verified domain name). | 5ad6a753-beb7-4761-... |
Permissions Type | Delegated or Application, matching the App Registration configuration. | Delegated |
Client Secret | The client secret value from the Azure App Registration. | (secured) |
Secret Expiry Date | Record the expiry date of the client secret for automated reminders. For more information, see section 7.1. | 01/10/27 |
In Use | Tick indicates this configuration is actively referenced by at least one environment. | ✓ |
Note: For AAD SSO, the code field is the value referenced in SY Parameter SY/AAD_APP and referenced in param.ini for environment refreshes.
In general, use names that clearly identify the environment and purpose, for example AAD_CLIENT_CPLIVE, AAD_SSO_CPTEST, or AAD_DOC_M1XLIVE.
When updating an existing record, the user must always re-enter the secret value to prevent the original from be blanked out.
Prerequisites
Access Coins ERP+ is at release 12.05 or later.
You have the Azure AD App Registration details (Application ID, Tenant ID, Client Secret) from the customer’s Azure AD tenant.
You understand which environments are affected (e.g. Live, CPLive, Test).
Configuration Steps
Follow these steps in order. All AAD configuration records must be created in LIVE — they sync to non-live environments through refresh and params.ini overrides.
Create AAD Application Records in LIVE
Log in to the LIVE Access Coins environment using an account with appropriate access.
Navigate to: SY Module > System Setup > Azure Applications.
Create a new record. Recommended naming pattern:
AAD_<PURPOSE>_<ENV>
Examples: AAD_CLIENT_CPLIVE, AAD_SSO_CPLIVE, AAD_CLIENT_M1XLIVE
Enter the Application ID and Tenant ID from the Azure AD App Registration.
Set Permissions Type to match the App Registration (Delegated or Application).
Enter the Client Secret. Optionally record the Secret Expiry Date for automated reminders to administrators.
Save the record. Repeat for each environment that requires a distinct AAD configuration.
Reference the Configuration in param.ini (on-premises clients)
For each Access Coins environment (on-premises clients only), add or update the following parameter in the environment’s param.ini file:
0 SY AAD_APP "AAD_CLIENT_CPLIVE"
Where the quoted value matches the Code of the record created in LIVE. Examples:
Environment | AAD Config Code | param.ini entry |
CPLIVE | AAD_CLIENT_CPLIVE | 0 SY AAD_APP "AAD_CLIENT_CPLIVE" |
TEST | AAD_CLIENT_TEST | 0 SY AAD_APP "AAD_CLIENT_TEST" |
LIVE | AAD_CLIENT_LIVE | 0 SY AAD_APP "AAD_CLIENT_LIVE" |
Note: Raise a support ticket containing the Azure Application Codes to facilitate Access Coins teams to update the environment refresh configuration.
Verify the Configuration
After restarting the affected environment, log in and exercise the functionality that uses Azure AD (e.g. SSO login, Document Management).
Confirm the authentication flow completes successfully and no AAD-related errors appear in the event log.
Return to SY > Azure Applications in LIVE and confirm the “In Use” tick is shown against the configuration record.
Upgrading to 12.05
On upgrade to 12.05, Access Coins automatically migrates the previous single-app configuration:
The existing SY/AAD_CLIENT_ID and SY/AAD_SECRET parameter values are used to auto-create a new Azure Applications record named AAD_CLIENT.
The SY/AAD_CLIENT_ID and SY/AAD_SECRET parameters are then retired.
No immediate action is required — the migrated record functions identically to the previous configuration.
To use multiple AAD Apps, create additional records and update the relevant param.ini files as described in Section 5.
Considerations
Secret Expiry Tracking
Client secrets in Azure AD expire. The Secret Expiry Date field should be populated - this will send reminders to administrators before it expires. Expired secrets cause authentication failures across any environment referencing that configuration.
Reminders are sent 30, 7 and 1 day before expiry.
Secret rotation requires updating the Client Secret in the Azure Applications record in LIVE; the change syncs to non-live environments.
Permissions Type
Access Coins supports both Delegated and Application permissions types:
Delegated: used for Single Sign-On (SSO) flows where the signed-in user’s identity is passed through.
Application: used for background service-to-service calls with no user context (e.g. scheduled integrations, workflow exchange integrations, OCR mailbox extraction).
Note: Match the Permissions Type in the Access Coins record exactly to the App Registration type in Azure AD. A mismatch will cause authentication errors.
Case Sensitivity
The SY AAD_APP value in param.ini is case-sensitive and must exactly match the Code field. Differences in capitalisation will result in Access Coins being unable to locate the configuration.
LIVE-Only Creation
Azure Applications records must always be created in the LIVE environment. Records created in LIVE are pushed to all associated non-live environments as part of the standard configuration sync. Creating records directly in non-live environments will work until those environments are refreshed as the records will be overridden.
Troubleshooting
Symptom | Likely Cause / Action |
AAD authentication fails after upgrade | Check that AAD_CLIENT record was auto-created in LIVE. Verify SY AAD_APP is set in param.ini. |
AAD_APP parameter not recognised | Confirm param.ini syntax: SY AAD_APP "Code". Check for typos or trailing spaces. |
Non-live environment not picking up config | Records must be created in LIVE first. Trigger or wait for the standard config sync. |
Authentication error — invalid secret | Client secret may have expired. Check Secret Expiry Date and rotate in Azure AD, then update the record in LIVE. |
Permissions error — AADSTS errors in log | Verify Permissions Type in the record matches the App Registration type in Azure AD. |
In Use tick not showing | SY AAD_APP value in param.ini may not match the Code exactly. Check case and spacing. |