Some more logging info...

<amLogEntry> 2023-10-16T16:08:33Z VERBOSE NIDS IDFF: Processing ProxyLoginProfile login agAppNa=idm&c=secure/name/password/uri&target=%22https://netiq-iam.acme-test.com/idmdash/%22 </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z INFO NIDS Application: AM#500105005: AMDEVICEID#esp-532EDD8C1C52FEAF: AMAUTHID#c0db3e2d06f86a966d9c8e3ed402d46fcf4478b818c5732aa272793750c7b247:  Processing proxy request for login using contract secure/name/password/uri and return url https://netiq-iam.acme-test.com/idmdash/ </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z DEBUG NIDS Application: 
Method: CacheMap.A
Thread: ajp-nio-127.0.0.1-9009-exec-24

Retrieval of object com.novell.nidp.servlets.NIDPServletSession@3b5668a7 from cache session succeeded using key c0db3e2d06f86a966d9c8e3ed402d46fcf4478b818c5732aa272793750c7b247.  Cache size is 1
 </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z INFO NIDS Application: AM#500105024: AMDEVICEID#esp-532EDD8C1C52FEAF: AMAUTHID#c0db3e2d06f86a966d9c8e3ed402d46fcf4478b818c5732aa272793750c7b247:  ESP is requesting metadata from IDP https://netiq-iam.acme-test.com:8443/nidp/idff/metadata </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z VERBOSE NIDS Application: Attempting to connect to URL: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata via GET </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z DEBUG NIDS Application: 
Method: URLUtil.connectToURL
Thread: ajp-nio-127.0.0.1-9009-exec-24
Error connecting to URL No subject alternative DNS name matching netiq-iam.acme-test.com found. </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z WARNING NIDS Application: SSL Exception encountered: No subject alternative DNS name matching netiq-iam.acme-test.com found.. The connection attempt was made using protocol version:TLS </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z INFO NIDS Application: Attempting to connect again to url: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata - this time using protocol: TLS </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z VERBOSE NIDS Application: Attempting to connect to URL: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata via GET </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z DEBUG NIDS Application: 
Method: URLUtil.connectToURL
Thread: ajp-nio-127.0.0.1-9009-exec-24
Error connecting to URL No subject alternative DNS name matching netiq-iam.acme-test.com found. </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z SEVERE NIDS IDFF: AM#100106001: AMDEVICEID#esp-532EDD8C1C52FEAF: AMAUTHID#803e9573e589a59df8f71f14a4ddd2a4842828c71ef9195ad3374863a402ed02:  Unable to load metadata for Embedded Service Provider: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata, error: No subject alternative DNS name matching netiq-iam.acme-test.com found. </amLogEntry>

Hi Philipp!

Something here does not add up and I think we need more information to help you out.

pborenich said:

single box (demo environment)

What do you mean by that?

Single box as (1) Access Manager Appliance or (2) Access Manager Admin console and IDP installed as service on single server?

If this is #1 (Appliance) I wonder how you got port 8443 in metadata URL, since with appliance IDP is automatically hidden behind Access Gateway (NAM-Service proxy service) which most of the time runs on port 443.

If this is #2 (AC and IDP installed as service on a single server), is Access Gateway you mention in proxy configuration installed on separate server?

Also this error is quite strange:

pborenich said:

Unable to load metadata for Embedded Service Provider: https:// netiq-iam.acme-test.com:8443/nidp/idff/metadata

It talks about loading metadata for Embedded Service Provider, which url is not .../nidp/... but .../nesp/...

/nidp/ path is used for IDP metadata, not ESP metadata.

Kind regards,

Sebastijan

I just read additional logging you've provided and error does make sense. ESP is trying to load IDP metadata.

If this is an appliance, have you maybe set IDP base URL to use port 8443? It should be 443 and then you should make sure Access Gateway's NAM-Service actually listens on port 443.

Kind regards,

Sebastijan

Hi Sebastijan,

thanks for your detailed feedback!

This is a native installation on SLES 15.4 (not the appliance).

Gateway, IDP and Admin Console are installed on a single box. Which is probably not a smart move for production environmets and I know it is not recommended in the documentation, but I was hoping it would be sufficient for a demonstration environment.

My "goal" would be to have a single published URL netiq-iam.acme-test.com to access multiple protected ressources.

First, IDP: /nidp/*

Second, IDM (/idmdash/*, /osp/*, etc.)

"Published" URLs via gateway would then be

https://netiq-iam.acme-test.com/nidp/*

https://netiq-iam.acme-test.com/idmdash/*

https://netiq-iam.acme-test.com/osp/*

etc.

That said, the IDP proxy for https://netiq-iam.acme-test.com/nidp/* is working so far, I can log in to the proxied IDP portal netiq-iam.acme-test.com/.../portal (which is the published DNS entry/URL) with a user stored in the configured LDAP user store (using secure name/password form contract).

But, I run into the error mentioned above, as soon as I want to access the protected ressource "IDM" via https://netiq-iam.acme-test.com/idmdash/*

<amLogEntry> 2023-10-16T16:08:33Z DEBUG NIDS Application: 
Method: URLUtil.connectToURL
Thread: ajp-nio-127.0.0.1-9009-exec-24
Error connecting to URL No subject alternative DNS name matching netiq-iam.acme-test.com found. </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z WARNING NIDS Application: SSL Exception encountered: No subject alternative DNS name matching netiq-iam.acme-test.com found.. The connection attempt was made using protocol version:TLS </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z INFO NIDS Application: Attempting to connect again to url: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata - this time using protocol: TLS </amLogEntry>

<amLogEntry> 2023-10-16T16:08:33Z VERBOSE NIDS Application: Attempting to connect to URL: https://netiq-iam.acme-test.com:8443/nidp/idff/metadata via GET </amLogEntry>

Which "seems" to be an SSL/TLS communication issue between ESP and IDP, but maybe I am missing something else here...

The error is also visible in the gatway server health page:

Best regards,
Philipp

pborenich said:

Gateway, IDP and Admin Console are installed on a single box

I don't think it is allowed to install AGW and IDP on same box, probably because AGW and IDP use some of the same processes/ports (like jcc) so there would be a collision between them.

pborenich said:

Which "seems" to be an SSL/TLS communication issue between ESP and IDP, but maybe I am missing something else here...

I would say that wrong component is responding on port 8443. Also if you would have IDP behind AGW (listening on 443), this url should not have port 8443.

If you need single box solution I would strongly suggest to go for appliance. Or maybe docker, since it is quite easy to set up all containers on single server (then you can also add all other IDM containers on same server )

Kind regards,

Sebastijan

Hi Sebastijan
Thank you very much for your valuable input!
I will then reconsider the setup and add another host to be on the safe (and supported) side or consider the container based approach you mentioned, sounds definitely promising.
At least I could gain some more insight into the product(s) and debugging "experience" during setup and configuration...
Best regards,
Philipp

pborenich said:

consider the container based approach you mentioned, sounds definitely promising

You could maybe use this article I wrote some time ago as a starting point for container setup:

 Setup Access Manager lab using plain docker 

This was written for AM version 5.0.1, but it should not be too hard to adjust procedures for latest version.

Kind regards,

Sebastijan

Hi Sebastian,

Sorry for the late reply, I was on holiday for a few weeks...

Thanks for the link! Will definitely give it a try...

Regards,
Philipp