Linux by Trial and Error

A repository of the things I learn about Linux

LDAP Directory Server on CentOS 6.3 Using TLS

This is essentially a continuation of my last post because I needed to set up a CA to sign certs in order to configure my Directory Server to use TLS. As before, I’m using a CentOS 6.3 VM which was built using the minimal installation .iso and all responses to prompts are exactly as I used them on my system in order to keep an exact record of how I built this server.

If  you do not currently have a CA to sign certificate requests and are willing to use your own self-created, self-signed CA, follow the steps of my last post and you’ll be right as rain. In fact, as I’m writing, I’m bouncing back and forth between writing this one and the last one because I haven’t generated the certificate request that I documented in the other post yet.

And now, onto my continuation of my LDAP server installation & configuration.

  1. The first thing you’ll need is to set up the EPEL repository so that you can get the full Directory Service package and to do that, you’ll need a way to download the rpm.
    # yum install wget
  2. Now, download the epel repository installation rpm from one of the Fedora mirrors
    # wget http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-8.noarch.rpm
  3. Install the EPEL rpm package
    # rpm -ivh epel-release-6-8.noarch.rpm
  4. Use yum to install the 389-ds package
    # yum install 389-ds
  5. If you are not on a network with a DNS server which has your servers hostname/IP address, you’ll need an entry in your /etc/hosts file. I added the following entry into my /etc/hosts:
    192.168.122.183       ds1    ds1.example.com
  6. Run the setup program
    # setup-ds-admin.pl
    Continue: yes
    Continue: yes
    Setup Type: 2
    Computer Name: ds1.example.com
    Proceed with host name: yes
    System user: nobody
    System group: nobody
    Register with existing Dir Server: no
    DirSrv Admin: admin
    DirSrv password: DirServerPwd
    Confirm password: DirServerPwd
    Admin Domain: example.com
    Dir Srv Port: 389
    Dir Srv ID: ds1
    Suffix: dc=example,dc=com
    Dir Manager DN: cn=Directory Manager
    Dir Manager Password: DirMgrPwd
    Confirm Password: DirMgrPwd
    Admin port: 9830
    Set up servers: yes
  7. For the next steps, you’ll need X-Windows access. This is probably overkill, but just to get things up and running, I ran:
    # yum install xorg-x11-xerver-Xorg xorg-x11-xauth xorg-x11-fonts*
  8. Next, since you’ve only got the root user, you’ll need to modify /etc/ssh/sshd_config using vi (or other editor of choice)
    PermitRootLogin Yes
  9. Connect to  your new server with ssh:
    # ssh root@192.168.122.183
  10. Start the Directory Server Console
    # 389-console &
  11. When prompted to sign into the console, enter the login information:
    User ID: cn=Directory Manager
    Password: DirMgrPwd
    Admin URL: http://localhost:9830
  12. Expand the entry for ds1.example.com
  13. Expand the entry for Server Group
  14. Double-click on Directory Server (ds1)
  15. Select Manage Certificates
  16. When prompted, set up a new password for the private key:
    New Password: DirSrvKeyPwd
    New Password (again): DirSrvKeyPwd
  17. Change to the CA Certs tab
  18. From your shell, get the text for  your CA cert:
    # cat /etc/pki/CA/certs/ca-cert.crt
  19. Copy the contents of the ca-cert.crt to your clipboard
  20. From your Manage Certificates, CA tab, select Install…
  21. Select Paste from Clipboard and then select Next
  22. At the Certificate Information screen, select Next
  23. At the Certificate Type screen, select Next
  24. At the Intended Purpose screen, select Done
  25. Back on the Server Certs tab, select Request…
  26. At the Introduction screen, select Next
  27. Enter Requestor Information and select Next
    Server name: ds1
    Organization: Example
    Organizational Unit: Example
    City: Topeka
    State: Kansas
    Country: US United States
  28. Enter the private key password from Step 16 above and select Next:
    DirSrvKeyPwd
  29. At the Request Submission screen, select Save to file
    File Name: ds1.csr
  30. Select Done
  31. Now, you can follow the steps from the post on setting up your CA. The latter part of that post details how to use this certificate request that we just generated to create a new, signed cert for our Directory Server.
  32. Get the contents of your signed cert
    # cat ds1.pem
  33. From your Manage Certificates screen, on the Server Certs tab, select Install…
  34. From the Certificate Location screen, select Paste from Clipboard and then select Next
  35. From the Certificate Information screen, verify that the information is correct and select Next
  36. From the Certificate Type screen, select Next
  37. From the Token Password screen, enter your private key password and select Done
    DirSrvKeyPwd
  38. From the Manage Certificates screen, select Close
  39. Now, close the Directory Server window and go back to the Console
  40. Double-click the Administration Server
  41. From the Admin Server, select Manage Certificates
  42. Create a new password for the admin server:
    New Password: DirAdminSrvPwd
    New Password (again): DirAdminSrvPwd
  43. From the CA Certs tab, select Install…
  44. From a shell, get the contents of the CA cert and copy the contents to the clipboard
  45. From the Certificate Location screen, select Past from Clipboard and select Next
  46. From the Certificate Information screen, verify the information and select Next
  47. From the Certificate Type screen, select Next
  48. From the Intended Purpose screen, select Done
  49. Back on the Server Certs tab, select Request…
  50. From the Introduction screen, select Next
  51. From the Requestor Information screen, fill out the information and select Next
    Server Name: ds1-admin
    Organization: Example
    Organizational Unit: Example
    City: Topeka
    State: Kansas
    Country: US United States
  52. Enter the private key password and select Next
    DirAdminSrvPwd
  53. At the Request Submission screen, select Save to File and then select Done
    File Name: ds1-admin.csr
  54. Once again, refer to the steps to sign your certificate request
  55. Repeat Steps 33-39, remembering to use the correct password in Step 37
    DirAdminSrvPwd
  56. Create a new text file /etc/dirsrv/slapd-ds1/pin.txt with the following contents:
    Internal (Software) Token:DirSrvKeyPwd
  57. From the Console, double-click to open the Directory Server
  58. From the Directory Server, on the Configuration tab, select the Encryption tab to the right
  59. From the Encryption tab, check the “Enable SSL for this server” checkbox
  60. Next, check the “Use this cipher family: RSA” checkbox, leave the rest of the fields at their defaults and select Save.
  61. From the Directory Server, back on the Tasks tab, select Restart Directory Server
  62. From the Configuration tab, select Data and check the “Enable fine-grained password policy” and any other options you wish to ensure that people use good, solid, secure passwords.
  63. Lastly, we want to make sure our Directory Server is set to start when the system is started:
    # chkconfig dirsrv on
    # chkconfig dirsrv-admin on

At this point, you have now installed and configured Directory Server and set it up to use TLS in order to encrypt your logins. Now, this does not mean it is finished, however. Rather than make this post several thousand words long, we are going to leave this as it is today and I will do a separate post later regarding how to make creating users so that you can actually use your new Directory Server.

Advertisements

June 22, 2013 Posted by | authentication, ldap | , , | 2 Comments

Kerberos Authentication on Load Balanced Web Servers

Today is simply a follow-on from yesterday’s post about Kerberos authentication for a Desktop application and a web application. In yesterday’s post, I went over what we did to set up Kerberos authentication for our Dev and QA environments, each of which have a single web server and a single application server.

In our production environment, however, we have two web servers and two application servers. The web servers are handled by a load balancer which provides a virtual IP address (VIP) and determines which web server to send HTTP requests to. The application servers are clustered servers.

Rather than re-hashing a lot of the same steps, it is worth noting that the actual setup of the different Service Principals for the production environment, please read my previous post for creating the Service Principal user accounts in AD and setting up the krb5.conf, krb5_ccache and krb5.keytab files on the server. Basically, all of that remains largely the same except for a couple of things that I will detail out in this post.

Before we get to that, however, we’ll get to how the challenge with this environment manifested and how we went about resolving it…

After having gone through setting up our Dev and QA environments, I moved on to set up the production environment using the same method. Service Principal accounts were created in AD and set the same way we had set the Dev and QA SP’s. The Kerberos config file, cache and keytab files were all created using exactly the same steps as the other servers.

Also, the jaas.conf and tomcat5.conf files were set the same as the other servers. Everything was exactly the same…except for the names of the servers/Service Principals on each system.

Unfortunately, when tomcat was started, we would go to the http://webapp.domain.com and would get “Service Temporarily Unavailable.” If I commented out the following line from the tomcat5.conf file, it would work fine (although then I would have to enter my credentials):

JAVA_OPTS=”${JAVA_OPTS} -Xmx1024m -Djava.security.auth.login.config=/path/to/jaas.conf -Djava.security.krb5.conf=/path/to/krb5/files/krb5.conf -Djavax.security.auth.useSubjectCredsOnly=false”

The only difference between production and Dev/QA was the load balancer. So, off I went to the networking guy…

We found that our load balancer was doing a health check periodically and was using an HTTP call, then looking for specific text in the response. When the above line was uncommented, the load balancer was not authenticated and was therefore not receiving the expected string. Therefore, the load balancer was shutting down the VIP because the server was “unavailable” as far as the health check was concerned.

After changing the health check to a TCP call rather than HTTP, we were able to get to the main page of the web server, though SSO was still not working correctly.

With much fuss and going back and forth about the fact that, still, the only difference seemed to be the load balancer, we decided to look at how our DNS structure was set up.

We had a HOST(A) entry for web-dev.domain.com as well as for web-qa.domain.com and web-prod1.domain.com and web-prod2.domain.com. Then, we had an Alias set up for web-dev.domain.com called webapp.dev.domain.com. We also had an Alias for web-qa.domain.com called webapp.qa.domain.com.

However, when I looked at the production set up, we had a HOST(A) entry for webapp.domain.com which pointed to the VIP.

Hmmm….

Here is what I did:

Following the steps from the previous post, I created a user in AD called HTTP/webapp-prod.domain.com and set up the Service Principal Name.

Next, I got on web-prod1.domain.com and ran:

# kinit HTTP/webapp-prod.domain.com

This added the ticket to the krb5_ccache file. Next, I ran:

# ktutil
ktutil: addent -password -p HTTP/webapp-prod.domain.com -k 2 -e rc4-hmac
Password for HTTP/webapp-prod.domain.com@DOMAIN.COM:
ktutil: addent -password -p HTTP/webapp-prod -k 2 -e rc4-hmac
Password for HTTP/webapp-prod@DOMAIN.COM:
ktutil: wkt /path/to/krb5/files/krb5.keytab
ktutil: quit
#

Then, I did the same thing on web-prod2.domain.com. Now, each production web server had four Kerberos tickets in the keytab file. Two for the local server itself (one fully qualified and the other a short name) and two for HTTP/webapp-prod (one fully qualified and the other a short name).

In my DNS server, I removed the HOST(A) entry for webapp.domain.com and created a new DNS entry for webapp-prod.domain.com which pointed to the VIP, and an Alias for that entry called webapp.domain.com.

Voila!!

I cleared all my temp files and cookies from IE, relaunched the browser and went to http://webapp.domain.com and found myself already logged into the web application and looking at my Dashboard!

Perhaps there is a better way to accomplish what I was trying to do, but since I was not able to find anything that would resolve this issue, this was the best thing I came up with.

If you know of a better way to use Kerberos authentication on a load balanced VIP to a web server, please share your experience. However, if you are struggling with something similar, hopefully this helps!

June 13, 2012 Posted by | kerberos | , , , , , | Leave a comment

It’s the Little Things

So, I recently deployed the latest errata via our Red Hat Satellite server to a handful of RHEL boxes. The updates included a minor OS revision, so we went from RHEL 5.7 to RHEL 5.8. This was my first deployment of errata onto production servers, so I was a bit nervous.

Because of the kernel update, a reboot was required. So, I scheduled the errata to deploy at 7:00pm in order to give the time to install before I started bouncing servers at 9:00pm. Before I got to 9:00, however, I started getting alert e-mails from system monitors about systems not responding.

Most of the restarts went fine. However, several of them were in our DMZ, so instead of authenticating to our Active Directory server, we have a directory server in the DMZ.

Five of the servers being restarted were in the DMZ, including DNS and Directory Servers. After the application of the errata, I found that I could not log in using LDAP user accounts. Good thing they were VMs and I had access to the console so I could log in as root!

After fighting with this for about 2 1/2 hours in the middle of the night, I decided that since the mission critical applications running in the DMZ did not seem to be adversely affected, I’d get some rest and tackle this first thing in the morning.

Another couple hours of sifting through logs and working with one of my senior server admins (who actually knows how to use tools like strace and such), we found that LDAP was throwing an error regarding “Unauthorized connections” to the directory server. That led us to take a look at the /etc/ldap.secret file.

One thing we have noticed about RHEL is that a lot of files, for some reason, require a blank line at the end of the file in order to be recognized. Our /etc/ldap.secret file did not have a carriage-return at the end of the first line…so there was one and only one line in the file and the EOF was at the end of the first line.

# vi /etc/ldap.secret
<ldap password>
~
~
~

became

# vi /etc/ldap.secret
<ldap password>

~
~
:wq

[Note the lack of the ‘~’ character on the second line.]

Viola!!!

# getent passwd johndoe
johndoe:*:10001:10001:johndoe:/home/johndoe:/bin/bash

In less than 15 seconds, we fixed a problem that I had spent several hours working on.

Don’t you hate when that happens?

March 29, 2012 Posted by | ldap | , , | 2 Comments