...

Note that there is a rather large performance penalty (typically 60-70 milliseconds per request) for enabling SPNEGO between the Dispatcher and the backend web server, so you should avoid using it for heavy traffic.

How it

...

Works

Once enabled, PortalProtect Dispatcher will monitor the response from the backend webserver. If it returns HTTP response code “401 Authentication Required” with an “WWW-Authenticate: Negotiate” header, then the dispatcher will attempt to create a new SPNEGO token and resend the request with a new HTTP header added, “Authorization: Negotiate xxxxxxx” where xxxxxxx is the SPNEGO/Kerberos ticket.

...

Once the IIS returns a reply, the dispatcher is forced to close the persistent HTTP1.1 connection (if any) – otherwise if the connection is later reused for subsequent requests on behalf of other users, the IIS might incorrectly think the request belongs to an authenticated user.

Obtaining

...

Credentials

For the SPNEGO negotiation to work, the PortalProtect Dispatcher requires access to userid and password of either a technical user, or the real user.

...

This is required since Sun in their infinite wisdom requires a system property to point to the files, and there is no way of having more in the same process.

Important

...

Considerations

Hostname

SPNEGO/Kerberos is sensitive to using the correct hostname – make sure that if your hostname for a server is both e.g. www.mycompany.com and mycompany.com that both forms are registered on the AD server.

Case

...

Sensitivity in

...

Username

A Kerberos username is e.g. somebody@somewhere.com or somebody@SOMEWHERE.COM – whatever the domain name, it is important that it matches the configuration in the krb5.conf file or the authentication will fail.

...