Kerberos authentication on Windows client hosts

From Windows client hosts, log on to your cluster as an AD user and run workload as the AD user or the Kerberos principal.

About this task

On Windows client hosts, you can submit application workload with or without single sign-on:

With single sign-on, a Kerberos user can run workload as the current Windows user without entering the user principal and password; the current logged-on Windows user is the logon user.
Without single sign-on, a Kerberos user can run workload as a specified user, by entering a user principal and password that differs from the current Windows user.

The following steps outline sample usage for Kerberos authentication:

Run the symping command as the Admin user. For example:
```
symping –u Admin –x egoadminAD
```
Run symping as AD users that were added to the EGO database:
1. Run symping as an AD user without the AD domain. For example:
```
symping –u userAD –x passAD
```
2. Test user access with the AD domain in the user name. Also, use the domain name separated by @ and by \. For example:
```
symping –u userAD@EXAMPLE.AD.COM –x passAD
symping –u EXAMPLE.AD.COM\userAD –x passAD
```
With the AD user logged on, test user access for single sign-on. For example:
```
symping –u "" –x ""
```
To use single sign-on with applications other than the built-in ones, set the user name and password to when initializing the security callback with the callback functions. For example, the callback function for C++ applications is DefaultSecurityCallback.
Run symping as a Kerberos principal. To run workload as a Kerberos principal from a Windows client host, you must include the realm. For example:
```
symping –u userKDC@EXAMPLE.COM –x passKDC
```