Single Sign-On for Java 3.3.2 - Administration Guide

Service unavailability

If a host (for example, the domain controller indicated by a DNS SRV query) becomes unavailable, Single Sign-on for Java processing may be suspended until a timeout expires. Note that Single Sign-on for Java maintains an internal database of unavailable hosts, and subsequent requests ignore (for a time) any hosts that are known to be unavailable. If no hosts are available for a given service, Single Sign-on for Java indicates an error. Any subsequent Single Sign-on for Java operations that must communicate with the host will timeout until such time as the host becomes available.

If a service (such as DNS) becomes unavailable, Single Sign-on for Java processing may be suspended until a timeout expires. After this, Single Sign-on for Java indicates an error. Any subsequent Single Sign-on for Java operations that rely on the service will timeout until such time as the service becomes available.

Time synchronization

If the internal clocks of two machines or services are sufficiently out of skew, then a Kerberos ticket which is valid on one machine may not be valid on the other machine. Thus, unsynchronized time services may lead to denial of service for otherwise-valid Kerberos tickets.

Replication interruptions

Single Sign-on for Java supports replicated domain controllers and global catalogs, and assumes that information is replicated across the network topology in a timely and consistent manner. Failure to replicate security information (such as group membership, SIDs, etc.) accurately may result in authentication or authorization failures.

Resource security

Single Sign-on for Java relies on sensitive data (such as Kerberos keytabs, passwords, and Active Directory account information). Such data must be physically and logically secure. Typically, only the Active Directory administrator should have access to Active Directory configuration, and a keytab should be readable only by the principal represented by that keytab.