Hi Hugh, it’s typically a challenge to authenticate servers without a user present and there’s a large likelihood of applications on the servers not supporting the required authentication mechanisms (transparency and cookies).
Here are the challenges that would need to be overcome:
- PAC file / GRE & IPsec tunnel methods use cookie-based authentication to remember the identity. IP Surrogacy can assist with mapping a user to an internal IP for X amount of time, but the authentication has to be able to occur first for surrogacy to kick-in.
- Client Connector doesn’t currently support server operating systems
- WIthout a user present, the authentication method implemented with Zscaler would need to support transparent authentication between the user and server and the applications on the server would need to support both the transparent authentication method (e.g. Kerberos) and store the authentication cookie - highly unlikely for anything except web browsers
If these challenges were overcome and servers were authenticated, they would be indistinguishable to Zscaler from a normal user, but a conversation with your account team and being able to provide a list of the server usernames should be helpful in ensuring they’re only billed under any server billing setup.
Our recommended best practice for servers is to use IPsec or GRE tunnels to forward the traffic, to not implement NAT within the tunnel so Zscaler can still see the internal IPs, and then building sub-locations around the internal server IP addresses and/or IP subnets, that way allowing granular policies and reporting on the IPs and subnets as needed.