-
Notifications
You must be signed in to change notification settings - Fork 1
mod_auth_vas4 Troubleshooting
You've logged into your workstation, you've set up mod_auth_vas, and a Authentication Services-protected directory under Apache, but Internet Explorer still keeps asking you for a password.
-
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.
-
The problem may be caused by a web proxy. You may also need to disable/tune your web proxy settings.
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 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 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/httpd
and looking for references to /usr/kerberos.
One effective workaround is to have the dynamic loader look at Authentication Services earlier than the system Kerberos library. This is done by setting the LD_PRELOAD environment variable to point to the 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
killproc $httpdtokillproc "$httpd". -
Restart the server with the command
# /etc/init.d/httpd restart
This change can be reversed by commenting out the HTTPD= line and restarting the server.
Note: It is possible that overriding the krb5 library with LD_PRELOAD means that some of the built-in modules of Apache may no longer work. In particular, this means mod_auth_krb5, and (theoretically) mod_ssl. Only mod_ssl has been tested at the time of writing, and works (because OpenSSL's kssl code is not exercised by the module).
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:
# /opt/quest/sbin/setup-mod_auth_vas
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/
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:
LimitRequestFieldSize 16382
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.
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 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 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.
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 (-rw-r-----) where apache is the user the web server runs as.
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.
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.
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 klist, 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 -e debug, or if the directive LogLevel debug is specified in the httpd.conf file.
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.)
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.