Hello @farhan,

The client gets the info for the user in different ways depending on the deployment method and operating system.  The most common deployment method (Windows using the UPN of the logged on user) gets user info by reading the UPN of the user and making an API call to Netskope with this user info.  If a matching user is found in the Users table (provisioned from Active Directory or SCIM) then a "branding" file is downloaded with relative info.  This portion occurs via TLS between the client and the Netskope management plane for the tenant.  A similar process happens for other deployment methods such as IDP mode but in that case, the user is matched from the user ID provided in the SAML assertion as part of the client enrollment.  Hope this helps and certainly happy to answer any additional questions!  

Okay let take this method.

1) Email invite where my agent detects email (Netskope client)

2) Local AD or Azure AD ( Netskope Client)

3) Explicit Proxy (Ipsec or GRE Tunnel)

1.  The user identity is included in the email invite.  Regardless of who logs into the machine via AD or a local account, all traffic generated by the Netskope client is tied to the email invite.  Hence, email invite is typically only recommended in specific cases for this reason. 

2.  Local AD or AzureAD joined machines will follow the info I mentioned above where the client reads the UPN of the logged on user(s) and matches it against provisioned users.  this is the default behavior of the client but you can override it with IDP mode. 

3.  Explicit Proxy over Tunnel will most likely use SAML based authentication and then either IP or cookie based surrogate if you authenticate the users.  The exact authentication method in this case will heavily depend on if it's explicit proxy over tunnel, just tunnel based steering with a policy based route, or some of our other supported architectures for edge cases.