- Specific problems
- Internet Explorer keeps prompting
- Segmentation fault with Red Hat Apache
- "establish_cred_keytab failed, err = VAS_ERR_NOT_FOUND"
- Cannot create HTTP service account: Entry already exists
- Size of a request header field exceeds server limit
- 'A token was invalid'
- Cannot load libphp4.so into server: libgcc_s.so.1 version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
- KRB5_KT_NOTFOUND (-1765328203): Key table entry not found
- Decrypt integrity check failed
- sending initial negotiate headers
- Generic problems
Internet Explorer keeps prompting
You've logged into your workstation, you've set up mod_auth_vas, and a Quest Authentication Services-protected directory under Apache, but Internet Explorer still keeps asking you for a password.
1. First, it may be that your browser is too old. Check the version using the Help menu. SPNEGO integration for the Internet Explorer browser requires the following client configuration:
- Microsoft Windows XP, Windows 2000 SP2, Windows Server 2003, or later.
- Internet Explorer 5.01, 5.5 SP2, 6.0 SP1, or later.
2. If Internet Explorer is prompting you for a password, or telling you that authorization failed, it is likely that it hasn't been configured properly to use SPNEGO for the web site you're trying to browse. By default, Internet Explorer restricts the use of SPNEGO ("Automatic logon") to sites in your Local intranet zone.
When visiting the protected page, the Local intranet icon should be displayed at the bottom right of the browser window. Note that it should read Local intranet, and not Internet or even Unknown Zone.
If it doesn't read Local intranet, please refer to the illustrated, step-by-step guide to configuring Internet Explorer on how to remedy this.
3. The problem may be caused by a web proxy. You may also need to disable/tune your web proxy settings.
Segmentation fault with Red Hat apache
This section applies only to mod_auth_vas running with Quest Authentication Services 2.6 on Red Hat systems.
The Apache package distributed by Red Hat is linked against the system's Kerberos library. This can causes problems as mod_auth_vas tries to use the Quest Authentication Services Kerberos implementation in the same process.
The mod_auth_vas packages for Red Hat patches the apache init script and provides a sysconfig file that overcomes this problem. The rest of this section explains the problem and how it can be addressed.
Your apache executable is incompatible with modules that use Quest Authentication Services if it is already linked against MIT Kerberos libraries. You can check for this on Red Hat systems by running the command
$ ldd /usr/sbin/httpdand looking for references to /usr/kerberos.
One effective workaround is to have the dynamic loader look at Quest Authentication Services earlier than the system Kerberos library. This is done by setting the LD_PRELOAD environment variable to point to the Quest Authentication Services shared library. Making the Apache web server set this variable up only for server startup requires the following steps:
- Create/edit the file /etc/sysconfig/httpd,
and insert the line
HTTPD="env LD_PRELOAD=/opt/vas/lib/libvas.so /usr/sbin/httpd"
- Edit /etc/init.d/httpd and change
the two occurrences of
- Restart the server with the command
# /etc/init.d/httpd restart
This change can be reversed by commenting out the
line and restarting the server.
It is possible that overriding the krb5 library with
means that some of the built-in modules of Apache may no longer work.
In particular, this means mod_auth_krb5, and (theoretically)
Only mod_ssl has been tested at the time of writing,
kssl code is not exercised by the module).
A future release of Quest Authentication Services will address this problem.
"establish_cred_keytab failed, err = VAS_ERR_NOT_FOUND"
If you see the message
[error] establish_cred_keytab failed, err = VAS_ERR_NOT_FOUND: Could not find keytab file: /etc/opt/quest/vas/HTTP.keytab
then it means the file /etc/opt/quest/vas/HTTP.keytab was not created, nor readable by the web server. Permissions on the file should be set so that only the web server can read it (not change it). Be aware that if users are allowed to run scripts from the web server then there is the possibility the keytab can be read by those users, reconstructed and used with DNS spoofing to masquerade as your web server.
Run this command to check the file ownership and permissions:
Cannot create HTTP service account: Entry already exists
If you lost your HTTP.keytab file, and you try to create a new one, you should remove the old account entry from Active Directory, manually, with this command:
# /opt/quest/bin/vastool -u Administrator service delete HTTP/
Size of a request header field exceeds server limit
GSSAPI tokens exchanged between the client and server may exceed Apache's default request field limits. By default this limit is 8190 bytes. If the tokens sent by the browser to the server exceed the limit, you will see this error:
Size of a request header field exceeds server limit
If you have Apache 2.0.53 or higher, you can increase the field limit with the LimitRequestFieldSize directive in httpd.conf:
When this option is not available, you can instead try reducing the size of the tokens the client is sending. Configure Active Directory not to include extraneous data in the tickets it gives to the client with one or both of the following:
- Disable delegation trust for the web server. When a service account is trusted for delegation, Active Directory will include a copy of the user's TGT in the service ticket (token). Disabling the delegation trust should stop that, making the service tickets smaller.
- Disable PAC inclusion for the HTTP service account. The PAC contains pre-computed authorization information and can also be large under certain circumstances. See Microsoft KB 832572 for information on how to selectively disable PAC inclusion.
'A token was invalid'
The following error indicates that the browser sent an NTLM negotiate token:
vas_gss_spnego_accept: VAS_ERR_INTERNAL: First call to gss_accept_sec_context() failed, minor_status = 0, result = 589824, display_status = A token was invalid
The solution is to make your client use Kerberos (Windows Integrated Authentication). For Internet Explorer, go through the IE configuration instructions.
If you are convinced that Kerberos tokens should be being sent from the browser, you can confirm this by enabling 'LogLevel debug' in your httpd.conf file and then watch the logs. NTLM tokens sent from the browser will start with "TlRM" while GSSAPI (Kerberos) tokens will start with "YII":
do_gss_spnego_accept: line='TlRMTVNTUAABAAAA...' do_gss_spnego_accept: line='YIIExAYGKwYBBQUC...'
Cannot load libphp4.so into server: libgcc_s.so.1 version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
One of Quest Authentication Services' supplementary libraries (libgcc_s) can intefere with the loading of other modules, most often PHP. It will produce an error similar to the following, and fail to start the Apache web server:
Cannot load /etc/httpd/modules/libphp4.so into server: /opt/quest/lib/support/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
To solve this problem, rename Quest Authentication Services' libgcc_s so that it will not be used:
# mv /opt/quest/lib/support/libgcc_s.so.1 /opt/quest/lib/support/libgcc_s.so.1.old
The system's libgcc_s will automatically be used instead.
KRB5_KT_NOTFOUND (-1765328203): Key table entry not found
This is often caused by the keytab file being unreadable by the Apache
process. Make sure the keytab file (usually
/etc/opt/quest/vas/HTTP.keytab) has the permissions
0640 root:apache (
is the user the web server runs as.
Decrypt integrity check failed
This is the result of a client using a service ticket that does not match the server's service keytab. The most common cause is re-creating the service account - leaving clients with unexpired but non-matching tickets. The only way to solve this is to wait for the client tickets to expire (usually about 10 hours)
On Unix, remove them manually with this command:
$ vastool kdestroy $ vastool kinit
On Windows, use Ctl-Alt-Del and then choose "Lock computer". Then, unlock the machine. This lock-and-unlock process will flush the local ticket cache.
sending initial negotiate headers
When the only log messages you get are "sending initial negotiate headers" and "auth_vas_check_user_id: auth_type=VAS" (both at debug level), it means the browser is not trying to authenticate with Negotiate (SPNEGO/Kerberos) at all. See the browser configuration instructions.
This section is for advanced users who want to dig into mod_auth_vas's operation in detail.
Testing what happens when a browser tries NTLM authentication
There are two ways to test mod_auth_vas's behavior when it receives an NTLM authentication token. The first is to configure Internet Explorer for integrated authentication but without adding the server to any trusted zones (ie. leave it in the Internet zone). Ensure you don't have a kerberos service ticket for the service either by logging off and back on, or by purging the ticket cache with a tool like Kerbtray, then access the protected resource and enter the wrong password.
The second method is to use the http-get tool (in the mod_auth_vas source directory under test/http-get) with the -f flag to send a fake NTLM token.
Apache will log detailed diagnostics to its error log when it is run
with the extra arguments
or if the directive
LogLevel debug is specified in the
On SuSE systems, debugging can be quickly enabled by running
# OPTIONS='-e debug' /etc/init.d/httpd restart
After this, debugging messages are available in the error log file (/var/log/httpd/error_log, depending on the configuration of your web server.)
Please note that the mod_auth_vas module must have been compiled with debugging enabled for this to work. (This is the default.)
Using a debugger
The easiest way I've found to debug mod_auth_vas is to find out what command line arguments your web server is given when run, stop it, then invoke it directly from a debugger (such as gdb) with those arguments. I use something like this (on SuSE):
# tail -f /var/log/apache2/error_log & # gdb (gdb) file /usr/sbin/httpd2-prefork (gdb) run -X -e debug -f /etc/apache2/httpd.conf
Besides debugging a single-threaded server, this allows me to make and make install from inside gdb, and then invoke run without arguments to re-start the server.
The source package for mod_auth_vas comes with a small testing tool called http-get that makes SPNEGO, basic and unauthenticated requests on web servers with detailed debugging.
To build the tool, configure the mod_auth_vas package with --enable-tests (on by default since 3.5.0), make, and read the documentation in the directory test/http-get.
A simple test of your server configuration can be done by running
$ test/http-get/get -n http://server.example.com/This will make an SPNEGO/Negotiate request (-n) to the server using your current credentials.
Similarly, you can test Basic (password) authentication by running
$ test/http-get/get -b username:password http://server.example.com/This will only work if you have Basic authentication enabled (
AuthVasUseBasic On). It does not support HTTPS.
— David Leonard