Apache Kerberos auth prompts user for password

active-directoryapache-2.4kerberos

I am trying to setup single-sign on against our Active Directory server for my Apache using the mod_auth_kerb module.

I have the following configuration in Apache:

AuthType      Kerberos
AuthName      "Test"
KrbAuthRealms COMPANY.LOCAL
Krb5Keytab    /etc/apache2/http.keytab

The keytab was created with the following command:

ktpass -out http.keytab \
       -princ HTTP/myserver.company.local@COMPANY.LOCAL \
       -pass <REDACTED> \
       -mapuser COMPANY\myserver-HTTP \
       -crypto AES256-SHA1 \
       -ptype KRB5_NT_PRINCIPAL

I have verified that the principal in the keytab is also added to the account name.

I have another server with similar configuration where it works; the users are authenticated without a password prompt.

Any ideas on how to further troubleshoot this problem?

Best Answer

You need to set KrbMethodK5Passwd off in your apache conf file

Related Solutions

Linux – Apache SSO through Kerberos using Machine Account

I don't have extended experience setting up kerberos delegation in Apache, but I'm pretty sure the service name defined in apache needs to match the service name in the keytab file.

Set the service name explicitly like this:

<Location /secured>
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbAuthRealms DOMAIN.COM
Krb5KeyTab /etc/krb5.keytab
KrbLocalUserMapping On
KrbServiceName HTTP/apache_server.DOMAIN.com
require valid-user
</Location>

The machines account in AD will need to have the HTTP/apache_server.DOMAIN.com SPN set, but it sounds like you already have this in place

Linux – Kerberos service login only possible for 30 minutes after running ktpass.exe

Thanks for all your input, guys. We got Microsoft on board, and they helped us debug the authentication process on the AD side. Everything worked as it was supposed to, but failed after thirty minutes.

While we were doing a remote debugging session, on of the participants noticed that the UPN/SPN of the service account was suddenly resat from HTTP/mysite.mycorp.com@MYCORP.COM to service-account@mycorp.com. After a LOT of digging around, including debugging AD replication, we found the culprit:

Someone had made a script that ran periodically (or probably by event, since it was exactly thirty minutes after running ktpass.exe), which updated the UPN/PSN to "ensure cloud connectivity". I do not have any supplemental information on the reasons for doing this.

The script was changed to allow existing UPN/SPN values ending in @mycorp.com, effectively solving the problem.

Tips for debugging issues like this:

Ensure all the participants in the authentication supports the same encryption types. Avoid DES - it's outdated and insecure.
Make sure to enable AES-128 and AES-256 encryption on the service account
Be aware that enabling DES on the service account means "use ONLY DES for this account", even if you enabled any of the AES encryptions. Do a search for UF_USE_DES_KEY_ONLY for details on this.
Make sure the UPN/SPN value is currect and matches the value in the issued keytab file (i.e. through an LDAP lookup)
Make sure the KVNO (Key Version Number) in the keytab file matches the on on the server
Inspect traffic between server and client (i.e. with tcpdump and/or WireShark)
Enable debugging of authentication on the AD side - inspect logs
Enable debugging of replication on the AD side - inspect logs

Again, thank you for your input.

Best Answer

Related Solutions

Linux – Apache SSO through Kerberos using Machine Account

Linux – Kerberos service login only possible for 30 minutes after running ktpass.exe

Related Topic