Integrating apache with Active Directory

  Security
 

In this article I will show how to integrate apache web server with active directory for having a single sign on authentication to allow a windows user to login to a web gui.

The web server is running in a linux system in join with a freeipa domain trusted with a active directory domain. The authentication and the authorization is performed by the active directory; the service principal is instead created on the freeipa domain. The service principal could instead be created in the Active Directory.

The architecture implemented in this case is:

Apache integration with AD

Apache integration with AD

Before starting the discussion, it’s necessary in order to have a SSO authentication trusting the AD with freeipa. For that you can read my article http://www.securityandit.com/security/freeipa-active-directory-integration/.

Let’s start with the changes on freeipa server for provisioning the service.

Freeipa Configuration for GSSAPI authentication

In this laboratory I suppose to have a linux domain linux.com (REALM is LINUX.COM) in trust with a windows domain windows.com (REALM is WINDOWS.COM). The freeipa server is ipa.linux.com; the active directory server is ad.windows.com.

The single sign on authentication is provided by GSSAPI/Kerberos.

GSSAPI is a abstract protocol layer that permit to encapsulate kerberos data for authentication scope. The GSSAPI can be used on top of different application layer like ldap and http.

In this case the protocol will be used on top of http for sending to apache server the AP-REQ kerberos message. The AP-REQ message permits to web server to authenticate the client using a key shared between ipa server and apache web server. Only the client authenticated in the domain (linux.com or in that trusted windows.com) are able to have a service ticket ciphered with the shared key: this is the core of authentication process.

The mechanism is better explained in my article http://www.securityandit.com/network/kerberos-protocol-understanding/.

After this introduction, I will create the service principal for the web server. The service principal is a unique identifier of the service used by client for requesting the authentication to service. The kerberos authentication is triggered from client when the web service name requested is equal to service principal identifier. Following the commands to execute on freeipa:

[root@ipa ~] kinit admin
Password for admin@LINUX.COM:
[root@ipa ~]# ipa service-add HTTP/server.linux.com@LINUX.COM
————————————————————-
Added service “HTTP/server.linux.com@LINUX.COM”
————————————————————-
Principal name: HTTP/server.linux.com@LINUX.COM
Principal alias: HTTP/server.linux.com@LINUX.COM
Managed by: server.linux.com

With the service principal, the kerberos server creates a service key that will be shared only with the owner of the service: in this case the web server that will be configured next.

Apache Configuration for GSSAPI authentication

The first thing to do on apache server is to install the service key already created on ipa server. The key can be imported in this way:

[root@server conf.d]# ipa-getkeytab -s ipa.linux.com -p HTTP/server.linux.com -k /etc/httpd/conf.d/http.keytab
Keytab successfully retrieved and stored in: /etc/httpd/conf.d/http.keytab

Another information to import in the apache server is the CA of active directory ldap server. This why I want to configure ssl over ldap for the comunication beetween the apache server and the ldap. This is how to import it:

[root@server conf.d]# echo -n | openssl s_client -connect ad.windows.it:636 | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > ad_cert.pem

For providing the kerberos authentication over http, the apache has needed of a module called mod_auth_kerb.x86_64. This is how to install it in the Centos 7 used in my laboratory.

[root@server conf.d]# yum install mod_auth_kerb.x86_64

The final configuration of apache now can be showed:

LDAPTrustedGlobalCert CA_BASE64 /etc/httpd/conf.d/ad_cert.pem
<Location /protected>
AuthType Kerberos
AuthName “Kerberos Login”
KrbMethodK5Passwd On
KrbAuthRealms WINDOWS.COM
KrbMethodNegotiate on
KrbVerifyKDC on
AuthLDAPBindPassword xxxxxxx
AuthLDAPBindDN “CN=apache,OU=Utenti,OU=Test Group,DC=windows,DC=com”
Krb5KeyTab /etc/httpd/conf.d/http.keytab
KrbServiceName HTTP/server.linux.com
AuthLDAPUrl ldaps://ad.windows.it:636/dc=windows,dc=com?userPrincipalName
require ldap-group CN=webserver,OU=Utenti,OU=Test Group,DC=windows,DC=com”
</Location>

Let me explain the configuration parameter not yet explained.

The AuthLDAPBindDN is the distinguished name of a normal active directory user necessary for ldap binding: this is necessary because the anonymous binding is not enabled in the active directory configuration used.

The require ldap-group is for authorizing only the active directory user that are member of the webserver group.

The sequence diagram below shows all the details inside the scene every time a web browser from windows system logs successfully on to web server http://server.linux.com.

Diagram sequence apache active directory

Diagram sequence apache active directory

As showed in the picture above, the first message is the AS_REQ versus to active directory. This request is done when the user logs on the windows domain. The goal of this phase is to have a TGT (ticket Granting ticket): it means that the user is correctly logged in the windows domain.

When the user tries to login to http web url http://server.linux.com, a HTTP 401 not authorized is received from the browser with a http header “WWW-Authenticate: Negotiate” in order to negotiate an authentication scheme that in this case will be the GSSAPI/Kerberos. It’s the most robust from those accepted by browsers: Basic, Digest, NTLM and Negotiate.

For completing the request it’s necessary to have a service ticket HTTP/server.linux.com@LINUX.COM and only the linux freeipa is able to provide it after having obtained a trust ticket from the  windows domain.

The service ticket is now showed by GSSAPI protocol to web server using the http header “WWW-Authenticate: Negotiate”: inside this header is encapsulated an AP_REQ kerberos packet.

If we take a look at the kerberos tickets present in the client, the following will be showed:

[tester@server ~]$kinit tester@WINDOWS.COM
Password for tester@WINDOWS.COM:
[tester@server ~]$ klist
Ticket cache: KEYRING:persistent:1001:1001
Default principal: tester@WINDOWS.COM
Valid starting Expires Service principal
05/13/2017 14:48:09 05/14/2017 00:48:03 HTTP/server.linux.com@LINUX.COM
05/13/2017 14:48:09 05/14/2017 00:48:03 krbtgt/LINUX.COM@WINDOWS.COM
renew until 05/14/2017 00:48:03
05/13/2017 14:48:03 05/14/2017 00:48:03 krbtgt/WINDOWS.COM@WINDOWS.COM
renew until 05/14/2017 00:48:03

I showed the kerberos tickets in a linux system where the http get was made by curl. The same thing is possible to see it in a windows client.

Conclusions

In this article I showed how to implement a SSO authentication integrating a web apache server with active directory and freeipa. The process can be used even if the user is not logged in the windows client. In this case the authentication between client and server is Basic (username and password in clear text).

For a more robust process, I suggest to configure https instead http.

I hope I was clear in this article.

I remain available to answer any comments.

LEAVE A COMMENT