WEBTHORITY HOW TO
Configuring Webthority to use Kerberos
This guide describes the configuration required to use Kerberos authentication with Webthority via the
Quest Single Sign-On for Java (formerly Vintela Single Sign-On for Java) libraries.
Kerberos can be used to provide both front and back-end authentication within Webthority:
1.
Front-end, via the VSJ Authentication Service (a.k.a. Windows Domain SSO or Integrated Windows
Authentication).
2.
Back-end authentication, via one of three modes:
a) Delegation (if using the front-end VSJ Authentication Service in Kerberos mode)
b) Generation from Active Directory password (if a front-end Authentication Service is being used
that provides the AD domain username and password e.g. Defender/LDAP Microsoft AD)
c)
Generation from AD username only (requires configured AD service account).
1. Front-end VSJ Authentication Service (using
Kerberos)
Webthority integrates with Quest Single Sign-On for Java to provide single sign-on within a Windows
domain to applications managed by Webthority. Webthority uses the Kerberos credential, cached by
Windows during domain login, as proof of identity; this means that a user who has previously
authenticated to Windows is automatically accepted by Webthority. If the Kerberos authentication fails
then this Authentication Service will fallback to a forms based login using your AD credentials.
Prerequisites in AD
An AD domain controller and a member workstation. The VSJ Authentication Service does not
have to be installed on a member of the domain, but the domain must be DNS resolvable. The
clocks on all machines in the configuration must be synchronized to within 5 minutes of each other
for the Kerberos protocol to function correctly.
setspn command line tool, available as part of Windows 2008R2.
For VSJ authentication and authorization using Integrated Windows Authentication, you will need
to create a service account. Refer to Creating an AD Service Account for instructions on how to
create a service account.
Configuring Quest Single Sign-On for Java (using Kerberos with Webthority)
Setting Up Webthority for VSJ Kerberos
Add a VSJ Authentication Service to the Webthority configuration
Open the Webthority Administration Console and configure the VSJ Authentication Service
Authentication tab as follows:
o
Authentication mode: Kerberos
o
Service account: vsj-service (this is the equivalent of the idm.princ VSJ
configuration setting)
o
Domain: EXAMPLE.LOCAL (equivalent to idm.realm)
o
Check use plaintext password and type the service user’s password (equivalent to
idm.password) or use a Keytab file.
On the VSJ Authentication Service Groups tab, manually enter the Active Directory groups you
want to use (e.g. Domain Users)
Configure a Proxy Service for the VSJ Authentication Service so that its public host name matches
the VSJ Authentication Service’s Service Principal Name, for example,
wth.proxy.local
Configure the Proxy Service and create content mappings using the FQDN of the Proxy Service so
that the hostname matches that in the VSJ’s Service Principal Name
Configure Web Roles as required
Restart Webthority to ensure that the configuration changes take effect.
Verifying the Configuration
Log on to the domain workstation as a user who is authorized to access the VSJ-protected role
For Internet Explorer, ensure that the URL for the Proxy Service is in the Local Intranet zone,
and that Integrated Windows Authentication is enabled (on the Advanced tab)
For Firefox, go to about:config and add your domain name to network.negotiate-
auth.trusted-uris (the value is a comma-separated list of URLs or domain names).
network.negotiate-auth.trusted-uris lists the sites that are permitted to engage in
SPNEGO authentication with the browser
Browse to the protected URL (again with FQDN). If you are included in one of the authorized
groups, the content is displayed immediately.
If the protected content server requires authentication you will need to configure back-end
authentication, using one of the three methods described below, before the content can be
displayed. If you are not included in one of the authorized groups, a not authorized VSJ
Authentication Service page is displayed
Enabling PI adds username and group information to the payload headers. Arbitrary Active
Directory attributes (e.g. physicalDeliveryOfficeName) can be mapped to payload names on
the VSJ Payload tab.
Page 2
Configuring Quest Single Sign-On for Java (using Kerberos with Webthority)
2.
Kerberos Back-end Authentication
Setting up Webthority for Back-end Kerberos Authentication via SPNEGO
The Proxy does not have to be installed on a member of the domain, but the domain must be DNS
resolvable. The clocks on all machines in the configuration must be synchronized to within 5 minutes of
each other for the Kerberos protocol to function correctly:
Ensure that Auto back-end auth is checked for the Proxy’s content mapping
For the relevant Web Role, on the Back-end Auth tab, ensure that the Kerberos checkbox is
checked and that the Default to this Windows Domain field is set to the target domain name.
The target domain name must be fully qualified, for example, democorp.local
Select the required Kerberos mode from:
o
Delegation
o
Generation from AD password
o
Generation from AD username (requires configuration of service account).
Optionally specify a server alias for the Kerberos servername
a)
Delegation (after Front-end VSJ Authentication)
This mode is only available when using the VSJ Authentication Service in Kerberos mode. It makes use of
unconstrained delegation. For this setup there are some additional configuration steps required:
In Active Directory Users & Computers, go to Properties on the vsj-service user created
above and select:
o
Account tab: Account is trusted for delegation (Windows 2000 Server)
o
Delegation tab: Trust this user for delegation to any service (Kerberos only)
(For Windows Server 2003 and above, the Delegation tab is only available for accounts
with an SPN mapped).
For Firefox (on the domain workstation), add the domain name to network.negotiateauth.delegation-uris. network.negotiate-auth.delegation-uris lists the sites for
which the browser may delegate user authorization to the server.
b)
Generation from AD password
This mode requires no additional configuration and does not rely on an AD service account. It allows
Webthority to use Kerberos for back-end authentication with a front-end authentication service that
provides the Active Directory username and password. If you use the Defender Service, the Active
Directory password must be included in the Defender Policy.
Page 3
Configuring Quest Single Sign-On for Java (using Kerberos with Webthority)
c)
Generation from AD username
This mode makes use of the protocol transition (S4U2Self) and constrained delegation
(S4U2Proxy) extended features of Windows Server 2003 and Server 2008 (domain functional level
Server 2003 is required) for the use of delegated credentials in Active Directory operations. For this mode,
a service account must be configured on the role Back-End Auth tab and it must have the following AD
configuration:
Set up a service account that maps to the SPN of the Proxy. Refer to Creating an AD Service
Account for instructions on how to create a service account
In Active Directory Users & Computers, go to Properties, then configure the Delegation tab
as described below:
o
Select Trust this user for delegation to specified services only (S4U2Proxy)
o
Select Use any authentication protocol (S4U2Self or Protocol Transition)
o
Add the content server computer as the service to which this account can present
delegated credentials. Enter the Service type as HTTP and the content server computer
(for example mycontentserver.mydom.local).
Creating an AD Service Account
1.
Create a new domain user called, for example, vsj-service.
2.
If the Domain Controller you are configuring is running at the Windows Server 2008 domain
functional level, turn on the strongest available encryption mechanism by enabling AES 128 bit and AES
256 bit support. You can do this via the This account supports Kerberos AES 256 bit encryption
option on the Account tab for the vsj-service.
3.
Assign the service principal name to the service account as described below:
>setspn –A HTTP/wth.proxy.local vsj-service
where wth.proxy.local needs to match the FQDN of the proxy, and vsj-service is the VSJ
service user account. You can assign multiple SPN’s to a service account e.g.:
>setspn –A HTTP/wth2.proxy.local vsj-service
and check the SPN’s that are assigned to a user:
>setspn vsj-service
Registered ServicePrincipalNames for CN=vsj-service,CN=Users,DC=proxy,DC=local:
HTTP/wth.proxy.local
HTTP/wth2.proxy.local
4.
Reset the user’s password and set to never expire.
Page 4
Configuring Quest Single Sign-On for Java (using Kerberos with Webthority)
Troubleshooting Kerberos
In the file WEBTHORITYHOME\classes\log4j.xml, change the priority values for the VSJ appenders to
DEBUG as below, these messages will then gather in WEBTHORITYHOME\logs\vsj.log.
<category name="com.dstc">
<priority value="DEBUG"/>
<appender-ref ref="VSJ"/>
</category>
<category name="com.wedgetail">
<priority value="DEBUG"/>
<appender-ref ref="VSJ"/>
</category>
The SPNEGO conversation on the backend can also be viewed by changing the priority values for the
Webthority appender to DEBUG as below, these messages will then gather in
WEBTHORITYHOME\logs\questwth.log.
<category name="com.quest.webthority.httpclienthelper">
<priority value="DEBUG"/>
<appender-ref ref="QWTH"/>
</category>
If you are having problems with Webthority finding its Kerberos KDC's for proxy backend authentication
then the Webthority Kerberos Config properties file WEBTHORITYHOME\classes\wthkerbcfg.properties, can be used.
Quest, Quest Software, the Quest Software logo and Webthority are trademarks and registered trademarks of Quest
Software, Inc. in the United States of America and other countries. Other trademarks and registered trademarks are
property of their respective owners.
Page 5