SAML and Single Sign On Known Issues
Azure AD SAML Test Fails
Description
When using the "Test this application" utility in SAML-based sign-in, the authentication process succeeds. However, after redirecting the user to Cerberus FTP Server, an error occurs: "SSO authentication failed. Try again or contact the administrator." The Cerberus FTP Server logs show a warning message stating, "A request ID was expected but not provided in the assertion."
Explanation
Cerberus currently requires each authentication response to match a recent authentication request initiated with Cerberus. Azure AD's SAML test generates an independent authentication response, which Cerberus rejects since it hasn't received a prior authentication request.
Work-Around
Use the SSO button on the Cerberus FTP Server login page for testing.
Users Column is Empty
Description
The Users tab appears empty in the SSO configuration. This is likely because provisioning has not been configured or completed. Automated provisioning must be enabled in the Enterprise App, and a provisioning cycle must be completed for users and groups to appear in the Cerberus FTP Server admin console.
Fixes
-
SCIM Provisioning must be set up and functioning correctly
See SCIM Provisioning between Azure AD and Cerberus FTP Server for detailed instructions. - Users and groups must be granted access to adding them to the Enterprise Application
- Users and groups must be provisioned from Azure AD to Cerberus. Azure AD schedules provisioning updates every 40 minutes.
Once SCIM Provisioning is configured correctly, you can use Provision on Demand to see immediate feedback in Cerberus
SCIM Known Issues
You can view Azure AD’s list of known issues; below we outline a few that may be common with Cerberus FTP Server.
Root Certification Authority
Azure AD requires that the public certificate for the endpoint listener used in the Tenant URL be issued by one of a specific set of root certification authorities. At the current time, this includes:
- CNNIC
- Comodo
- CyberTrust
- DigiCert
- GeoTrust
- GlobalSign
- Go Daddy
- VeriSign
- WoSign
-
DST Root CA X3
Error Saving Provisioning
Azure AD in 2020 had a limit of 1 KB for configuration data. This has been reportedly increased as of 2021, but in 2023 we are still on occasion seeing issues where the SAML certificate plus Provisioning data (Tenant URL, Secret Token, Notification email, etc) are too large to save.
There are a few options to by-pass this issue. Reduce the number of custom Mapping fields you may have created, disable the Notification Email in Settings (long email addresses take space), or use one Enterprise App for SAML and another for Provisioning User Accounts.
None of these are great solutions, and we’re continuing to follow up with Microsoft for a better long-term solution.
Error code
"SystemForCrossDomainIdentityManagementCredentialValidationUnavailable"
Encountering the "SystemForCrossDomainIdentityManagementCredentialValidationUnavailable" error can be challenging to troubleshoot, and several reasons may lead to this message:
-
Invalid Certificate:
- Ensure you possess a valid certificate obtained from a Certificate Authority. Self-signed certificates are not compatible.
- The certificate must be issued by one of the specified authorities (CNNIC, Comodo, CyberTrust, DigiCert, GeoTrust, GlobalSign, Go Daddy, VeriSign, WoSign, DST Root CA X3) and include a valid intermediary certificate in the CA Certificate Path under Server Manager > Security > TLS Server Key Pair.
-
TLS 1.2 Disabled:
- Check Cerberus settings at Server Manager > Security > Advanced TLS.
- Microsoft specifies that TLS 1.2 is the only acceptable protocol version allowed for SCIM.
Cannot Remove Provisioning
Once you have configured provisioning and saved, you cannot delete it. Microsoft recommends disabling Provisioning as a workaround.
Comments
0 comments
Please sign in to leave a comment.