In versions of Active Directory that support constrained delegation, delegation can be refined so that it works through the use of a series of “service tickets” instead of the transmission of the user's TGT. Using these tickets, it permits delegation of the client’s identity directed to one or more servers, but only to those specifically selected by configuration as being permitted to be authentication delegates.
In constrained delegation, the client does not send the TGT, it simply sends the service ticket. The server can then present this service ticket, along with the server's own TGT, to Active Directory in order to request a service ticket using constrained delegation to another service. Active Directory will only grant service tickets from the server to a specific list of services that have been previously configured.
Constrained delegation may be repeated through multiple tiers. For each tier, a domain controller is responsible for issuing a new service ticket and checking whether the authenticated server is permitted to perform constrained delegation to the next server.
The following graphic shows you a simplified summary of the sequence of events involved in the Constrained delegation (S4U2Proxy) processes.
Figure 2: Constrained Delegation with S4U2Proxy
Clients that need access to Active Directory services can include external clients, which for a variety of reasons do not have immediate access to facilities for a full exchange of credentials under Kerberos.
Some clients may use alternative authentication methods such as SSL client certificates, HTTP digest authentication, or NTLM authentication.
Some external clients may operate through a firewall, where Kerberos operations are generally considered inappropriate, but where the client is still required to authenticate, and there is a need for Single Sign-on access to internal services.
However, this is not a preferred approach, and on a strict application of security principles, might be seen as serious breach of the trust rules for a secure system.
For Windows Server 2003 and higher domain function levels, the solution for this is the “protocol transition” (S4U2Self) extension.
This allows the server itself to collect sufficient information about the client to establish a logon token which clears it for access without the need for a user password.
Under this arrangement, the server, rather than the client, requests a Kerberos ticket for itself, on behalf of the “otherwise-authenticated” client.
The following figure illustrates the event sequence involved (in simplified terms).
Figure 3: Protocol transition and S4U2Self
The ticket returned to the server is a service ticket for the server concerned, but it contains the user's authorization data, and it is of a form capable of being used for the S4U2Proxy extension — that is, a ticket to be used for delegated credentialing on other servers.
Single Sign-on for Java now provides support for S4U2Self as well as S4U2Proxy, and for the use of both extensions in conjunction with each other.
In Single Sign-on for Java Standard Edition, Single Sign-on for Java is implemented as a Java servlet filter.
On initialization, the Single Sign-on for Java servlet filter uses the given configuration parameters to determine:
If no access policy has been set, access is automatically granted.
If an access policy has been set:
If such information is not already available, it is obtained via LDAP queries on the domain controller or information in the service ticket.
If NTLM is used, all information is obtained via LDAP queries on the account of the user@domain. Otherwise, the service ticket contains Microsoft authorization data (a Privilege Attribute Certificate or PAC).
The PAC contains information such as last login time, group membership, etc. Active Directory may be queried via LDAP to convert information in the PAC to other forms (specifically, to convert a SID in the PAC to a name or vice-versa).
Single Sign-on for Java supports complex Active Directory environments with multiple domains including both cross-realm and cross-forest scenarios.
However, the examples in this manual illustrate a single Active Directory domain called EXAMPLE.COM, whose DNS domain is example.com.
The example application servers in this domain have the hostnames appservhost1 (with fully qualified domain name appservhost1.example.com), appservhost2, etc.
as a convention we will use vsj_appservhost1 as the name of the service account for Single Sign-on for Java running on the host appservhost1
HTTP/appservhost1.example.com is an SPN for appservhost1
Single Sign-on for Java's idm.principalAtRealm configuration parameter should be set to the value vsj_appservhost1@EXAMPLE.COM
The following figure shows points where these names apply.
Figure 4: Overview: Active Directory and Single Sign-on for Java configuration and terminology
The following figure illustrates a simplified version of the initial process involved when a client requests a URL from a service under Single Sign-on for Java, showing the use of naming conventions outlined above.
Figure 5: Access to a URL via Single Sign-on for Java (simplified)