"Failed To Connect To Service endpoint" in AWS Connector

Which IIQ version are you inquiring about?

Version 8.3

Please share any images or screenshots, if relevant.



com.amazonaws.util.EC2MetadataUtils.png

Share all details related to your problem, including any error messages you may have received.

“Failed To Connect To Service endpoint” in AWS Connector.

I’m configuring a AWS connector. Followed all the prerequisites as per connector guide.
When performing Test Connection getting Error - “Failed To Connect To Service endpoint”.

So, I thought a Firewall/Proxy is blocking the request. To figure out the AWS URL, enabled the DEBUG logs.
But unable to find the URL in IIQ logs.
So I did ‘strace’ and monitored the network.

During Test Connection I see only one request made to the IP ‘169.254.169.254’.
Traced the method calls as per the IIQ stack trace, Identified the method ‘getHostAddressForEC2MetadataService’ in EC2MetadataUtils class returning the IP for EC2 Metadata Service.

In the same method I see 2 system properties ‘com.amazonaws.sdk.ec2MetadataServiceEndpointOverride’ & ‘AWS_EC2_METADATA_SERVICE_ENDPOINT’ can be used to override this IP.

So, Here are my question,

  1. What should be provided in ‘com.amazonaws.sdk.ec2MetadataServiceEndpointOverride’ OR ‘AWS_EC2_METADATA_SERVICE_ENDPOINT’ variables to get the connector working?
  2. A quick google search shows 169.254.169.254 is a link-local address used by cloud environments to provide metadata to instances running in the cloud environment. But I’m not in any cloud environment, our IIQ servers are on a on-perm data warehouse. What is the correct way to resolve this issue?

Regards,
Shandeep

Hi @Shandeep,

Getting any IP that starts with 169.254. tells you that something isn’t working. These are obtained by devices when the device can’t get a valid IP from the router’s DHCP server. The device automatically assigns itself a 169.254 IP address using the APIPA protocol. To assign itself an APIPA address, the device generates a random IP in the 169.254 range and then checks to see if another device on the network is using the generated address. If there is another device using it, then your device will continue the process until it finds an available address.

Verify if DHCP is enabled and configured. Try assigning a static IP if troubleshooting the DHCP isn’t fruitful.

@sreeram thanks for your response.

I don’t think we have problem with IP or DHCP.

The IIQ servers have static IP configured and running for around 2 years, And we have Azure and many more webservices applications are fetching data from internet.
And we have few systems using IIQ’s SCIM API for operational activities.
If we have any problem with IP we would have noticed by now, Other application & Integrations are working as expected.

Hi @Shandeep,

These IPs are not routable since they are local addresses, I am not sure having making calls to this IP is going to be fruitful.

Usually these IP’s are self assigned due to erroneous network configs. Please loop us in as well when you resolve this.

Thanks,
Sreeram

Hi @Shandeep and @sreeram,

Any solution to this issue so far? We are facing same issue at our end as well with IdentityIQ 8.4

Hi @ndd_sunpower,

After going through the connector docs one more time I found out that

IAM Role based Authentication can be used when SailPoint is hosted on the AWS EC2 instance

See here,

Here is the guide - IAM Role Authentication Method

So we went with IAM User Authentication Method

If your instance is also on-prem switch to IAM User Authentication Method.

Regards,
Shandeep