Nagios single sign-on authentication with Active Directory

Do you wonder if it is possible to implement Active Directory based single sign-on for Nagios ? The answer is yes. Many sysadmins and users would be interested in an integrated environment, where the users are prompted for credentials only once during their initial logon.

 Key components in this context are Kerberos, LDAP, Active Directory, Apache web server with mod_auth_kerb module. So, where is the Nagios itself actually ? Just behind the webserver which provides authentication services. In other terms, all single sign-on integration is done at the webserver level, and you can easily use the recipe below for other similar systems:

 

 

Where  

Apache webserver

Make sure that you have an up-to-date Kerberos implementation. Recent versions have many relevant bug fixes in comparison to earlier ones. Experiments with Kerberos V 1.5-6 or 1.5-23 on Fedora 6 were not successful. However, upgrading to version 1.6.3 solved my problems at the webserver side.

Apache webserver

Install httpd-devel package as the installation of mod_auth_kerb depends on tools from it (for Fedora):

yum install httpd-devel

Download and install the latest version of mod_auth_kerb. Remember to turn off Kerberos 4 as Active Directory has no support for it:

./configure --with-krb4=no --with-krb5=/usr/kerberos

make

make install

Append the line below to the Apache configuration file (The default location is /etc/httpd/conf/httpd.conf):

LoadModule auth_kerb_module modules/mod_auth_kerb.so

Apache webserver

 Configure the Kerberos configuration file (/etc/krb5.conf) for Active Directory interaction (a minimal one!):

[libdefaults]
 default_realm = DOMAIN.COM

[domain_realm]
 apache.webserver.com = DOMAIN.COM

[realms]
 DOMAIN.COM = {
  kdc = dc1.domain.com
  kdc = dc2.colorline.com
 }

where

DOMAIN.COM is FQDN of your Active directory domain (must be UPPERCASE!)

apache.webserver.com is FQDN of your apache webserver (no aliases here, use hostname),

dc1.domain.com and dc2.domain.com are FQDNs of two domain controllers serving your domain.

Apache

webserver

Time to test Active Directory authentication via Kerberos for user myuser:

kinit myuser

enter the password for myuser@DOMAIN.COM

klist

will display details about the ticket obtained.

kdestroy

destroys the ticket obtained.

Active Directory Domain Controller

Now we can create a service principal, map it to a dedicated user and save this relationship in a Kerberos keytab file. Make sure that Support tools for Windows Server are installed and you've created a user with no password expiration (all in one line!):

ktpass -princ HTTP/apache.webserver.com@DOMAIN.COM -mapuser aduser -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass password -out webserver.keytab

where

apache.webserver.com is FQDN of your apache webserver,

DOMAIN.COM is FQDN of your domain,

aduser is a user dedicated for service principal mapping

password is the password belonging to the user above

webserver.keytab is the Kerberos keytab file which will be produced.

Apache webserver

Transfer webserver.keytab file from the previous step and place it on a permanent location (/etc/httpd/conf for example). Make it owned and readable only by the user running Apache daemon.

Apache webserver

Add following directives to your Apache configuration file (/etc/httpd/conf/httpd.conf by default):

<Directory ...>

AuthType Kerberos

KrbAuthRealms DOMAIN.COM

KrbServiceName HTTP

Krb5Keytab /etc/httpd/conf/webserver.keytab

KrbMethodNegotiate on

KrbMethodK5Passwd on

require valid-user 

</Directory>

where

DOMAIN.COM is FQDN of your Active directory domain

/etc/httpd/conf/webserver.keytab is the Kerberos keytab file

Apache webserver

Restart your webserver:

service httpd restart

Your webserver is now ready for single sign-on authentication with Active Directory.

Windows clients

Make sure that you have an updated version of kerberos.dll in windows' system32 directory. I had problems with the versions packaged in XP SP1 and SP2, while the SP3 version worked perfectly.

For Internet Explorer users: make your webserver (apache.webserver.com in our example) a member of trusted sites and Integrated Windows Authentication is enabled (default). Expect a similar reconfiguration for other browsers as well.

Apache webserver (optional)

You may be interested in introducing authorization based on AD groups. AFAIK, there is no Kerberos support for this scenario. However, you can use LDAP with Active Directory (See a previous blog entry about LDAP based AD authentication):

<Directory />

AuthType Kerberos

KrbAuthRealms DOMAIN.COM

KrbServiceName HTTP

Krb5Keytab /etc/httpd/conf/webserver.keytab

KrbMethodNegotiate on

KrbMethodK5Passwd on

AuthLDAPURL "ldap://dc1.domain.com:3268 dc2.domain.com:3268/dc=domain,dc=com?userPrincipalName?sub" NONE

AuthLDAPBindDN aduser@domain.com

AuthLDAPBindPassword password

require ldap-group CN=Nagios Users,OU=Users,DC=domain,DC=com

</Directory>

where

dc1.domain.com and dc2.domain.com are two domain controllers serving your AD domain,

aduser@domain.com is the user for LDAP lookup (It has been used before for Kerberos keytab file generation)

password is the password belonging to aduser,

CN=Nagios Users,OU=Users,DC=domain,DC=com is the distinguished name of the AD group for authorization, meaning that members of that group can access Nagios.

Trouble-shooting

Make sure that you have up-to-date software components.

Make sure that kinit/klist test above produces expected results

Set LogLevel directive in Apache configuration file to debug and check the contents of the error_log file.

Links

Using mod_auth_kerb and Windows 2000/2003 as KDC / Apache Active Directory Sigle-Sign-On (excellent article with many details and links)

Providing Active Directory authentication via Kerberos protocol in Apache (somewhat outdated, useful anyway)

Error message when you try to connect to a remote share by using NTLM authentication on a Windows XP-based computer: "Logon failure: unknown user name or bad password"

Nagios authentication with Active Directory

 

 

Contribution from Axel Eble (17.10.2008):

what should be noted is that the Domain names in the krb5.conf have to be in uppercase. You've written yours like that, but it wasn't explicitly mentioned that the names have to be uppercase no matter what. Otherwise, the kinit fails.

Newsletter: