SSH fails through ZTNA when using local account mapping in SSH Policy

Products

• Symantec ZTNA

Issue/Introduction

ZTNA used to provide network admin's SSH access to back end bastion hosts.

An Okta SAML server is enabled for ZTNA authentication.

SSH server authenticates users via LDAP.

SSH policy is setup to map ZTNA authenticated users to accounts for these users on the back end SSH servers.

SSH temporary tokens used as part of the ZTNA configuration.

After authenticating to the ZTNA Portal and copy'ing the SSH username and token, the user fails to SSH into the back end.

Changing the SSH policy user mapping to use a single 'root' shared account allowed the SSH session to complete successfully. 

Environment

ZTNA.

Closed loop network.

 

Cause

SSH Server could not communicate with LDAPS server to validate Okta user information.

Resolution

Open up firewall to allow DNS and LDAPS traffic.

In above case, DNS remained blocked but HOSTS file was updated to include IP address of LDAPS server. TCP 636 was also opened on the firewall.

Additional Information

The authlog on the SSH server showed invalid user message:

Mar  1 11:29:12 sjs-gray-jumphost sshd[157942]: Connection closed by invalid user user1 192.168.1.1 port 55722 [preauth]

This 'invalid' user existed in LDAP and checking the system logs, the following entries indicated that LDAPS servers were not working and also likely blocked.

(2024-03-01 13:58:12): [be[BSNSERVICE]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: ../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1633
(2024-03-01 13:58:12): [be[BSNSERVICE]] [fo_set_port_status] (0x0100): Marking port 636 of server '### ldap_server_hostname###' as 'not working'
(2024-03-01 13:58:12): [be[BSNSERVICE]] [fo_set_port_status] (0x0400): Marking port 636 of duplicate server '### ldap_server_hostname###' as 'not working'

Resolving the LDAP servers via a host file and allowing TCP 636 (LDAPS) addressed the issue.