NetIQ Access Manager 3.2 installed on Microsoft Azure platform
NetIQ Access Manager 3.2 Identity Server running on SLES11 SP2
NetIQ Access Manager 3.2 Identity Server component configured as SAML2 Service Provider
Users authenticating against 3rd Party SAML2 Identity Server
If users with extended characters (e.g. Ã¦, Ã¸, Ã¥ and Ã¶) are registered in AD, and the assertion authentication or attribute statement includes these extended characters, SSO to the NAM SAML2 SP server fails with the following error presented on the browser:
"Error on session id xxxxxxxxx,
error 300101017 -yyyyyyyyyyy, An Identity Provider response was received that failed to authenticate this session."
xxxxxx is the users JSESSIONID cookie value assigned by NAM and
yyyyyy is the device ID of the NAM server generating the error
The catalina log file on the NAM SAML2 SP server also indicates the following Signature validation problem:
<amLogEntry> 2013-12-04T12:48:46Z INFO NIDS IDFF: AM#500106006: AMDEVICEID#B27B49C42713A62D: Validation failure on message from https://alta.novell.com/svc/trust : Signature validation failed </amLogEntry>
If a user authenticating at the remote IDP server did not have any extended characters, no errors would be reported and SSO would succeed without issues. In the example below, the user netiq2 had a surname of TÃ¸ster ... simply changing that to Tester would cause the SSO to succeed.
// sample AttributeStatement from Assertion when failing shows:
The same NAM setup going to the same SAML2 Identity Server has no issues when the NAM SAML2 Service Provider is configured on a local VMware host, and not Azure.
Customer installed the standard SLES11SP2 image provided in Windows Azure, where Northern Europe region set to Norwegian layout. There are some strange default settings in this image.
the /etc/sysconfig/language and changed from LANG=âen_USâ to
âLANG=en_US.UTF-8â and problem went away.