Using Kerberos (Windows authentication) with more than one server
|Date:||4 October 2013|
|Product/Release:||Visual LANSA - Supported Versions|
|Abstract:||Specific steps must be taken to configure kerberos on a server which then accesses data/files on another server - also known as multi-hop|
|Submitted By:||LANSA Technical Support|
Specific configuration is required when setting up a server to use Kerberos (also known as Windows authentication), which connects to another server for the database or a shared drive (multi-hop). Basically, Server B (the server hosting the database/shared drive) must list Server A (the server where LANSA is installed and the LANSA listener is runnning), with either of the following trust settings:
- Trust whole computer to *any* services
- Trust a specific domain user to *any* services – This requires setting up listener properly to run as a specific user (see below).
A basic overview of how to implement these is listed below:
1. Trust whole computer to *any* services
The following screenshot shows how to assign this setting (on Server B)
2. Trust a specific domain user to *any* services
The following screenshot shows how to assign this right (on Server B)
To run the LANSA listener with a specific domain user (non administrative account), the following setup is required:
- The following rights must be granted to the domain user for the computer where the listener is running.
- Act as part of the operating system
- Create a token object
- Impersonate a client after authentication
- Log on as a service
- Replace a process level token
Note that the extended privileges are limited only to the computer where the listener is running and so the domain user is still unprivileged on other computers.
- Currently WINDTM must be disabled
With these changes, we can then change the listener to run as the specific domain user in Services Manager.
Once these setup steps have been completed, you should use the lcoecho utility in the connect folder to confirm connection: