Setting up and configuring Windows Single Sign On (SSO) authentication
How do I setup and configure Windows SSO?
In a Windows SSO realm, the client is never challenged for authentication. Instead, the BCAAA agent collects information about the current logged on user from the domain controller and/or by querying the client workstation. Then the IP address of an incoming client request is mapped to a user identity in the domain. If authorization information is also needed, then another realm (LDAP or local) must be created.
NOTE: The Windows SSO realm works reliably only in environments where one IP address maps to one user. If an IP address cannot be mapped to a single user, authentication fails. Those with NAT systems, which uses one set of IP addresses for intranet traffic and a different set for Internet traffic, should use a different realm for authentication.
First the BCAAA agent will be installed onto a Windows server. The SSO.INI file will be modified. Next, the ProxySG will be configured so the Windows SSO realm is created and configured. Lastly, policy will be installed using the Visual Policy Manager to take advantage of the Windows SSO realm.
STEP I: Installing the BCAAA agent onto a Windows server.
STEP II: Modifying the SSO.INI file on the Windows server
The BCAAA agent in a Windows SSO environment must query a domain controller or a client workstation for the IP address to user name mapping. There are three choices to use. They are, query the domain controller only; query the client only; or query the domain controller first and then fall back to client query. For further information see the Administration Guide for your version of SGOS.
Configuring Windows SSO for domain controller querying:
Configuring Windows SSO for client querying:
(Optional:) Configuring the SSO.INI file for synchronization:
Optionally, when using Domain Controller Querying, you can configure a BCAAA service to use another BCAAA service as a synchronization server. Whenever a BCAAA service restarts, it contacts its synchronization server and updates the logon state. Two given BCAAA services can use each other as their synchronization server. Thus, each BCAAA service can act as a synchronization server to provide logon state to other BCAAA services, as well as acting as a synchronization client to update its logon state from another BCAAA service.
Each BCAAA service has a synchronization priority that determines synchronization behavior. If the client BCAAA has the same or higher priority than the server BCAAA, synchronization is done once at restart to update the client state. Once synchronization is complete the client BCAAA drops the synchronization connection and begins querying the domain controllers.
However, if the server BCAAA has higher priority, then the client BCAAA keeps the synchronization link open and continuously updates its logon state from the higher priority BCAAA. The client BCAAA does not query the domain controllers itself unless the synchronization link fails.
This makes it possible to manage the query load on the domain controllers. If there is no issue with load, then the default configuration (without synchronization), with all BCAAA agents querying the domain controllers is acceptable. However, if load on the domain controllers is an issue, synchronization can be used to minimize this load while still providing fail-over capabilities.
By default, all BCAAA agents have the same synchronization priority, meaning that they synchronize on startup and then do their own domain controller querying. Here are the steps necessary if you wish to synchronize your BCAAA agents:
STEP III: Configuring the Windows SSO authentication realm on the ProxySG.
STEP IV: Configuring policy