Identity Source sync issue either timeout or not able to retrieve

[SFDCIT1]

Hello,

We are getting AD sync issue on regular interval and showing below error:

There was a problem processing your request.
Failed to connect to the identity source. Possible reasons include invalid user name or password, connection refusal, connection timeout, or failure to resolve host name.

Test connection is working successfully and when we click save and finish it's updated the identity source and make connection successfully but after some time it's again got disconnected.

And this is happening continuously.

Any help will most appreciated.

Thanks...

[JayGuillette]

These type of LDAP connection errors could happen for a couple of different reasons so you may need to try a few things to see if they go away.

The first change if you have not already configured it this way, is to configure the LDAP connection to the exact IP address of the Domain Controller of LDAP server instead of to a name.  This would rule out DNS or name resolution problems, especially server names that map to more than one IP address as in DNS round robin entries.  Or Load balancers between AM and LDAP.

If you still have the problems with an IP address configured, then you may need to run some TCPdump or wireshark network packet captures between the AM primary/replica and the LDAP Server/Domain Controllers, filtered on the TCP port used for the connection; 389 for LDAP and 636 for LDAPS.

[TedBarbour]

Hi SFDC IT - can you confirm if you are referring to an Authentication Manager or Cloud Authentication Service Identity Source?  I suspect an intermittent problem like this will require more information and deeper troubleshooting so recommend that you open a support case.

Thanks,

Ted

[SFDCIT1]

Hi Ted,

I am referring to an authentication manager not an Cloud Authentication Service Identity Source.

[EdwardDavis]

One idea...

If you recently had an ldap connection and changed the password for the account used to make the connection, the RSA server may still have some running processes in the ldap pool using the old password in cache. If the case is you did change a password for the connection account, restart the RSA server so it drops all old pools and the possibility it is using a stale password.

[StevenSpicer]

I've seen it happen that a customer who was connecting to ldap via a VIP accidentally used a service account that was not being synched across the copies and had a different password for the same userid on different boxes.

[SFDCIT1]

Hi Jay,

I have captures wireshark network packet between the AM primary/replica and the LDAP Server/Domain Controllers And it's giving me the error: unbindrequest  in regular interval.

You have any idea about this.

Thanks For your help.

[JayGuillette]

does the unbindrequest have a number after it?  It might be some constraint that caused AM to send the unbindrequest (#), including Ed' idea that an old LDAP service account password is cached.  If the AM server, who is the client here, does not close the connection after the unbindrequ, the LDAP server side will, which is why you see the RST 

Either the # on the unbindrequest or what happened before it is significant here.

[SFDCIT1]

Hi Jay,

Thanks for your help on this..

We do get unbindrequest(3) and LDAP server pwd set to never expired so i don't think so that it could be cached anywhere but why is the source from RSA AM server.

Could you please suggest.

[SFDCIT1]

Hi Folks,

Any solution for above unbindrequest(3) as we still are in the issue.