Windows Integrated Authentication
Windows Integrated Authentication for web applications relays on SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). SPNEGO is most commonly used by client browsers to negotiate authentication information with web servers using Kerberos. This is how WIA is basically realized. The current guide will show you how to configure WIA using JOSSO.
In the following sections, the name foo.com / FOO.COM is used as an example only. Replace this name with the appropriate domain name.
SSO overview
The SSO authentication mechanism works as follows:
The browser takes the client ticket from the local ticket cache, and uses that ticket to request a service ticket for jossosrvr01@FOO.COM from the domain controller.
The domain controller validates the client ticket and returns the service ticket.
The browser sends a login request to the service (JOSSO server)
JOSSO sends the service ticket to the domain controller for validation.
If the ticket validates, the JOSSO server logs in JOSSO.
Prerequisites and Requirements
As mentioned above, Windows Integrated Authentication relays on Kerberos for user authentication. Kerberos is built on trust relationships that involve the Windows Domain Controller server (DC), the SSO server (JOSSO) and end-user’s the web browser. It is important to properly configure the DNS server since the SSO server name is used when negotiating authentication information. It is also recommended that JOSSO web server is configured using the standard HTTP ports in order to avoid browser related issues. A reverse proxy can be used when these ports are not available for JOSSO.
• A fully configured and working Kerberos security realm is required.
• The expected realm name convention is all uppercase, e.g.: *FOO.COM*.
• The expected domain name convention is all lowercase, e.g.: *foo.com*.
• A domain user with administrator’s rights on the domain controller must be available.
• The domain’s expected domain controller name is: *dc01.foo.com*
• The server hosting the JOSSO server is expected to be named: *jossosrvr01.foo.com*.
• The domain controller and the JOSSO server host are known in the local DNS.
• The end users for the JOSSO server are known as domain principals. Consequently, user John Doe with a domain login name of *jdoe* must have a login identity of *jdoe@foo.com*
• The domain controller needs to be accessible on TCP/IP port *88* by the JOSSO server
• The Active Directory service instance needs to be accessible on TCP/IP port *389*
These settings are provided as reference, your AD setup may require different options. Make sure that your AD Administrator is familiar with WIA and SPNEGO/Kerberos configuration options.
DNS Settings
Users may be accessing SSO services and applications using different host names but run on the same server; in that case aliases should be configured in the DNS server for the proper domain zone. In our example different hosts are assigned to each component. Let’s take a look at our sample configuration; the following entries represent the JOSSO server, the Application server and the Domain Controller respectively.
JOSSO Windows Account Definition
On the domain controller server, create a new account for JOSSO. The key aspects to keep in mind when creating the account name are: * The Service principal name must match the appliance location’s hostname, in this case (the value is case sensitive): HTTP/jossosrvr01.foo.com@FOO.COM * User’s account and password must be set to never expire. * Account must be enabled. * The account name in our example is set to josso, but any value can be used.
Let’s take a look at a sample account definition, the key value here is the Universal Principal Name (UPN). It will be used later to generate a Kerberos keytab file for JOSSO:
JOSSO Server Keytab File Generation
Once the windows account has been defined, we need to create a Keytab file that will be used by JOSSO when during windows session validation. On the domain controller server (DC2-TEST), run a command line terminal as administrator and type the command bellow. The highlighted values must match JOSSO’s windows account attributes, for instance the pass attribute value is the actual password we set for the josso account.
C:\> ktpass -out JOSSO.keytab -kvno 0 -princ HTTP/jossosrvr01.foo.com@FOO.COM -mapuser josso@FOO.COM -pass @WSX3edc -ptype KRB5_NT_PRINCIPAL
The ktpass utility is a Windows tool part of the AD distribution. Keep in mind that every time you generate a Keytab, the previous one is invalidated thus it needs to be replaced in JOSSO.
JOSSO Configuration
Configuring the Identity Provider
In order to enable WIA in JOSSO we need to configure the Windows Domain mechanism along with an LDAP Identity Store, optionally if basic authentication must be also enabled, we can configure a Directory Service Authentication scheme. We can see a sample identity appliance configured using the elements mentioned above. Highlighted in red are the authentication scheme elements, and in blue the identity store element.
Defining the LDAP Identity Store element
When working with Windows Integrated Authentication, user information is normally stored in the Domain Controller’s Active Directory instance. You need to configure an LDAP Identity Store that points to the AD server. Additionally, if you’re planning on enabling basic authentication (username/password) for users outside your Windows network, you must also add a Directory based authentication scheme. Although Active Directory is basically an LDAP server, there are some unique attributes that must be considered when configuring JOSSO. * Security Principal, it must be set to JOSSO’s account distinguish name (DN), i.e. CN=josso,CN=Users,DC=foo,DC=com * User DN, this is the parent node for all SSO users, by default Windows uses the Users entry whose distinguish name would look like CN=Users,DC=mycompany,DC=com * Principal UID attribute ID, when using AD it must be set to sAMAccountName, it is the user attribute that stores the username. * UID Attribute ID, when using AD it must be set to member, is the attribute that stores those DNs that are associated to a given group or role. * Roles DN, same as User DN but for storing groups. * Role Attribute ID, when using AD it must be set to sAMAccountName, it is the group attribute that stores the group name.
Defining the Directory Service Authentication element
This element represents a basic authentication scheme that will use AD to validate credentials. It is required because AD does not allow password retrieval, therefore the validation must be delegated. It has a subset of an LDAP Identity Store, so the configuration is the same for both elements.
Defining the Windows Domain Authentication element
This element holds the configuration required by JOSSO to authenticate users based on Windows Session information. The configuration requires a valid Windows account specifically created for JOSSO and the corresponding Kerberos keytab file as described above.
The element’s main properties are:
Name, the name of the element (i.e. dc-foo)
Protocol, Kerberos (default value)
Windows Domain, the windows domain name, in uppercase. (i.e.FOO.COM)
Service Class, HTTP (default value)
Host, host name used by JOSSO, as end-users will access.
Domain Controller, the domain controller host name, in upper case (i.e. DC01.FOO.COM)
Keytab file, JOSSO keytab file.
Sorting Authentication Mechanisms
The final step requires that we sort how authentication will be handled. On the IdP element access the Authentication section and disable the Basic Authentication option. This is because when using AD the basic authentication is delegated to the directory server. Sort the Authentication schemes list and move the windows authentication element to the top of the list.
Configuring the Client Browser
The final step to enable WIA is to configure the user browser. This step varies from browser to browser and is something that is not JOSSO specific, but related with SPNEGO. We need to tell the browser to trust the SSO server, so that when the authentication negotiation is requested by JOSSO, the browser accepts the request and negotiates the information.
Internet Explorer
IE WIA Support Enabling Internet Explorer to use WIA depends a lot on your domain settings, network environment and IE version. This is just one way of configuring WIA. Make sure to contact your Network/AD Administrator to use the proper configuration.
Open Internet Explorer.
In the Internet Explorer window, click Tools > Internet Options > Security tab.
Select the Local intranet icon and click Sites.
In the Local intranet window, ensure that the "check box" to include all local (intranet) not listed in other zones is selected, and then click Advanced.
In the Local intranet window, fill in the Add this Web site to the zone field with the Web address of the host name so that the single sign-on (SSO) can be enabled to the list Web sites shown in the Web sites field. Your site information technology staff provides this information. Click OK to complete this step and close the Local intranet window.
On the Internet Options window, click the advanced tab and scroll to Security settings. Ensure that the Enable Integrated Windows Authentication (requires restart) box is selected.
Click OK.
Restart your Microsoft Internet Explorer to activate this configuration.
Firefox
Open Firefox.
At the address field, type about:config.
In the Filter, type network.n
Double click on network.negotiate-auth.trusted-uris. This preference lists the sites that are permitted to engage in SPNEGO Authentication with the browser. Enter a comma-delimited list of trusted domains or URLs.
Note: You must set the value for network.negotiate-auth.trusted-uris.
If the deployed SPNEGO solution is using the advanced Kerberos feature of Credential Delegation double click on network.negotiate-auth.delegation-uris. This preference lists the sites for which the browser may delegate user authorization to the server.
Enter a comma-delimited list of trusted domains or URLs.
Click OK. The configuration appears as updated.
Restart your Firefox browser to activate this configuration.