Hi,
Looking for a bit of insight into what I am missing.
Setup: 1 VA, 1 IQ server, 3 AD connectors. All three connectors use the same IQserver credentials. 2 connectors work fine, the 3rd connector does not. and I get this error:
[ InvalidConfigurationException ] [ Possible suggestions ] Ensure that: a) SearchDN is valid. b) The user is active. c) The user is not locked. d) Domain certificate is available in trusted root folder on IQService machine if Domain Configuration TLS is enabled. [ Error details ] Exception occurred while executing the RPCRequest: Errors returned from IQService. "Failed to connect to the server for dc=1234,dc=123,dc=12,dc=net:The server is not operational. . HRESULT:[0x8007203A]"
I know that the VA/IQserver connection is fine as its working for the other 2 connectors.
I’ve used the ‘ldp’ command from the IQserver and checked the binding with the service account on the connector that is failing and it confirms the following:
The bind account is valid, active, and has permission to authenticate.
The SearchDN (dc=1234,dc=123,dc=12,dc=net) is valid and accessible.
The domain controller is operational, synchronized, and acting as a global catalog.
LDAPS is working end-to-end from the IQService host.
What blindingly obvious thing am I missing because I’ve been staring at the screen for too long?
Thanks
You’ve already ruled out firewall issues by your ldp test. The only thing I can think of is that something is missing on the Source Config.
Without knowing more about your source config, I can’t really help. What I can offer is a different approach to help you get past this stage (I’ve been there):
I suggest you pull one of the working sources and the non-working one off the API, then run the JSONs through a diff program (ideally, a side-by-side comparison of syntax-highlighted JSON, as you can get with VS Code or Notepad++'s Compare Plugin). Based on your workup so far, I agree it’s probably something blindingly obvious, like not pasting some values in the right field, or not enabling TLS. You’ve already ruled out firewall issues, and the error that IQService is returning is showing that the connection is failing before an incorrect password or missing SSL certificate even come into play.
ETA: technically, depending on which port you targeted with ldp, and how you’ve configured the Source, the ldp test might not have ruled out a firewall issue, so be sure about whether you targeted 389 or 636. If you have the ability to run Git Bash on the IQServer, I can give you an openssl s_client connect command to be 100% sure that firewalls aren’t affecting you.
I can also aggregate the source using the service account.
@vsandhu1 I’ve just compared them side by side in VSC and there is nothing different apart from AD specifics.
I’ve raised a request with our network team to check firewalls, and a different team to check the scope of the service accounts, just in case
That’s a doozy, then. What are you doing when you’re getting these errors - I’m guessing a test connection? Because putting everything together: Aggregation proceeds entirely via the LDAP interface (IDN → VA --LDAP/S–> DC)
And AFAIK, the testConfiguration method proceeds in two stages:
IDN → VA --LDAP/S–> DC [Same as aggregation]
IDN → VA → IQService --WIN/AD[RPC-XML]–> DC [For provisioning actions]
During a testConfiguration call, getting “Errors returned from IQService” implies the first test was successful, as does your aggregation. I think you’re on the right track looking for a network issue, but depending on what environment you’re in, have you tried bumping up the IQService logging? It’s a long shot, but it might show at which step the connection is failing, and allow you to compare to test connections to the working Sources.
Ok. My next thought would be DNS then. I’m guessing the IQService uses an SVR record to get the DC while LDAP is direct. Could check domain name resolution on the IQService server.
When you tested LDP, did you connect using domain name or server name?
DNS resolution is fine. Swapping out server names for IP addresses doesn’t make a difference.
I wondering about doing a clean install of the IQ service.
The IQservice.log is only getting written to intermittently. Nothing since yesterday afternoon, despite everything that I am doing inside of Sailpoint
Hi @phil_awlings - I’m not saying DNS for the DC, I’m saying DNS for the Domain. ie you should be able to connect LDP to 1234.123.12.net (or whatever the domain/forest name is) and windows in the background will resolve it to a DC address.
I think that I’ve found the answer.
I assumed that considering that they were the dev & qa environments of the same AD that trust was established between them, but it appears not.
5 other domains are trusted, but not the DEV one
