SPNs may be mapped to two different types of objects in Active Directory:
Computer Objects refer to computers which have been joined to a given Active Directory domain (for example, a Microsoft Windows machine joined using the Network Identification Wizard, or a UNIX machine joined using Authentication Services).
When the Computer Object is created, a corresponding SPN in the form HOST/<machine_name> is mapped to that computer object. It is also possible to map additional SPNs to the computer object if required.
An Active Directory User Object may refer to an actual physical person, or a Service Account which is an object created for the purposes of running a particular service. In the latter case, you would map the SPN to the service account using the setspn tool.
One service account of this kind is in an account set up for Single Sign-on for Java.
Single Sign-on for Java has been specifically designed to work optimally with Microsoft's Active Directory. It will use the default configuration to discover the services, hosts and port numbers necessary to integrate with Active Directory. To fine-tune your deployment you can configure Single Sign-on for Java to use Active Directory configuration for items such as sites and services, domain controller servers, etc.
In addition to support for Kerberos through its Active Directory service, Microsoft has also provided extensions to Internet Explorer that allow it to participate in a Kerberos-based SSO environment. When a Web server receives a request from an Internet Explorer browser, it can request that the browser use the SPNEGO protocol to authenticate itself. SPNEGO in effect is a way of negotiating what protocol is appropriate for Internet Explorer (and now, other browsers) to use to establish initial credentials with a server running a Kerberos-based service.
SPNEGO performs a Kerberos authentication which is tunneled over HTTP, allowing the browser application to pass a delegated credential (acting for the Windows user running the IE instance) so that a Web application can log in to subsequent Kerberized services on the user's behalf.
When an HTTP server wants to perform SPNEGO, it returns a “401 Unauthorized” response to the HTTP request with the “WWW-Authenticate: Negotiate” header. Internet Explorer then contacts the Ticket Granting Service (TGS) to obtain a service ticket. It chooses a special Service Principal Name for the ticket request, which is:
HTTP/webserver
The returned ticket is then used to construct an SPNEGO token which is encoded and sent back to the server in the HTTP headers. The token is unwrapped and the ticket is authenticated. If mutual authentication is required, the Web server can return an additional SPNEGO token for the client to verify. Once authenticated, the page corresponding to the requested URL is returned.
SPNEGO provides a useful mechanism for extending an SSO environment to Web applications. It is already supported in Microsoft IIS for authentication to ASP or Web pages. In addition, the ability to delegate credentials means that a Web application can log in to further services transparently on the user's behalf, providing full end-to-end authentication. Lastly, SPNEGO and HTTP can be used for authentication with Microsoft .NET SOAP clients, and the HTTP Negotiate extension of SPNEGO is supported in browsers such as Microsoft Internet Explorer, Mozilla Firefox, and Google Chrome.
Changes in Windows Server 2003 introduced extended features for the use of delegated credentials in Active Directory operations. These extensions, referred to as S4U2Proxy and S4U2Self, are also included in Windows Server 2008. They apply only if the Windows Server 2003 or higher domain functional level is applied to Active Directory and is supported in Single Sign-on for Java.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center
