So I came across a client who has a domain ending with .local and stumbled across a weird issue with our SailPoint Linux VAs.
Now, I am no DNS / Linux expert and not saying that you will have this issue if you have a .local domain. So YMMY
The VA could do nslookup on the domain but couldn’t do ping / openssl and other such commands. Thus couldn’t connect to the server via domain name and SSL verification broke and connector didn’t work.
For example, the AD domain was call “abc.local” and after the VA setup, it could do a nslookup but couldn’t do openssl command. Which means the connector couldn’t connect via domain name and verify SSL certificate. Workaround was to connect via IP address but then the certificate didn’t contain IP address and thus SSL config didn’t work. This also affected all other servers we need to connect which are domain joined and had a .local in the end.
After doing some research, I found many articles which pointed to /etc/nsswitch.conf file and one particular line
hosts: files usrfiles resolve [!UNAVAIL=return] myhostname dns
This line needs to be changed to (remove [!UNAVAIL=return])
hosts: files usrfiles resolve myhostname dns
I won’t go into details on why and what it does – plenty of articles explaining DNS and Linux interactions – I am no expert on this.
Now previously we couldn’t edit the file directly in our VA due to the locked down nature of it. So I worked with our internal team and have finally got a fix out if you are in this situation.
For this to work charon version needs to be atleast 1624. You can check your charon version by running the following command
sudo docker images | grep charon
Note: If you don’t have the version, don’t worry – will get rolled out per standard updates in coming months.
Fix
Run the following commands
|
1 2 3 4 5 6 7 8 9 10 11 |
# Back up the nsswitch in home dir cp /etc/nsswitch.conf ~ sudo unlink /etc/nsswitch.conf sudoedit /etc/nsswitch.conf <Do the edit and remove the following [!UNAVAIL=return]> # If need be, restart the networking service as follows sudo systemctl restart systemd-networkd.service |
To revert the changes
|
1 2 |
sudo rm -f /etc/nsswitch.conf sudo systemctl restart setup-nsswitch.service |
That should re-create the original symlink.
NOTE: A wrong edit to this file can cause DOS. So please do be careful and test it in SB and have direct access to the box if needed. Please be careful and test this out before prod implementation and have direct access to VA to restore file if needed.
0 Comments