rootninja

<?php
require_once('Auth.php');

// Authenticating with Active Directory
$auth = new Auth("LDAP", array(
   'host' => 'ldap://hostname.domain.com',
   'version' => 3,
   'binddn' => 'CN=Morpheus,DC=domain',
   'bindpw' => 'fishburne',
   'basedn' => 'OU=Users,DC=domain',
   'userattr' => 'samaccountname',
   'userfilter' => '(objectClass=person)',
   'start_tls' => 'true'
   ));

$auth->start();

if ($auth->getAuth()) {
        // validated users
        print "Welcome to the desert of the real";
} else {
        // not yet authenticated
        print "Don't think you are, know you are.";
}

$auth->logout();
?>

networking, programming AD, authentication, ldap, openldap, php, starttls

The s_client and s_server options provide a way to launch SSL-enabled command-line clients and servers

If you’re trying to configure a service that includes a TLS/SSL handshake and you want to know if the problem you’re experiencing is related to the application, firewall, certificate trust, misconfiguration, etc. here’s a way to eliminate TLS/SSL from your list of usual suspects.

I’m trying to use an Active Directory Domain Controller to supply a list of objects for an application running on a Linux machine, and I want to make sure the TLS/SSL is working, is trusted, and has nothing to do with the problem i’m having. The only thing the app tells me is “Unable to read schema”

First i’ll verify that my certificate is trusted. Lets see who issued my certificate.

# openssl x509 -noout -in rootninja.crt -issuer

issuer= /DC=com/DC=DOMAIN/CN=rootserver

Now I know which CA this came from, i’ll make sure I use that CA instead of whatever default one it might look at

# openssl verify -CApath /etc/pki/tls/ -CAfile rootserver.pem

rootserver.crt: OK

So now I know this certificate is blessed by my client, I can try to use it to connect. But let’s say I try to use a self-signed certificate or another cert that’s not trusted…

If it’s a trust issue, perhaps the certificate is valid, but it just can’t find the CA or intermediate certificate.

$ openssl s_client -connect rootserver.rootninja.com:636

CONNECTED(00000003)
depth=0 /CN=domainCA.rootninja.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=domainCA.domain.com
   i:/DC=com/DC=domain/CN=dc1.domain.com
-----BEGIN CERTIFICATE-----
...

...
Verify return code: 21 (unable to verify the first certificate)
---

And using a self-signed certificate, you should see something like this.

CONNECTED(00000003)
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify return:1
...

...
No client certificate CA names sent
---
SSL handshake has read 983 bytes and written 331 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
...

...
    Verify return code: 18 (self signed certificate)
---

But, if everythings working correctly, your client should connect just fine. And it will look something like this, with a big fat Verify return code: 0 (ok) at the end.

CONNECTED(00000003)
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=1 /C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
verify return:1
depth=0 /CN=rootserver.rootninja.com/OU=Domain Control Validated
verify return:1
---
Certificate chain
 0 s:/CN=rootserver.rootninja.com/OU=Domain Control Validated
   i:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
 1 s:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...

...
-----END CERTIFICATE-----
subject=/CN=rootserver.rootninja.com/OU=Domain Control Validated
issuer=/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
---
Acceptable client certificate CA names
/CN=rootserver.rootninja.com/OU=Domain Control Validated
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root CA
/CN=NT AUTHORITY
---
SSL handshake has read 4561 bytes and written 355 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 7407077777C77707177C7
    Session-ID-ctx:
    Master-Key: 7A97FE707C7078797B7437075E7F7267F5787E
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1234567890
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

http://www.openssl.org/

howto, security certificate, handshake, https, ldap, ldaps, openldap, openssl, self-signed certificate, ssl, s_client, tls

I found this posted at some complicated site where it was hard to find the login button. Everything was so cluttered on the site I gave up and decided to post the question here, and answer it here, and maybe this guy (and anyone else having this problem) will find my solution. This may not be the answer to his exact problem, but it worked for me when I ran into this issue.

Check iptables or other firewall applications running on that machine. If ldap traffic is being blocked, this could be causing it to hang. That’s what happened to me. I changed the firewall rules and forgot to add the ldaps rule and it broke. I could work around it by hitting “i” while booting and it would go into Interactive mode and allow me to say No to the MessageBus service. Everything else came up fine in runlevels 3 and 5, but it would always hang when loading the dbus app.

A work around for this could be to swap out your authconfig files. I ran authconfig-tui to temporarily disable ldap, and then ran it again once it was up and running. But there’s no reason you couldnt just have 2 configs and swap them out after booting up and before shutting down. But if my problem is the same as yours, the real answer is to fix the firewall rules!!!

Linux dbus, hangs, iptables, ldap, locksup, workaround

Enabling LDAP authentication should take you about 2 minutes, unless you type with just 2 fingers. Then maybe 3 or 4.

Uncomment “mod_auth” in /etc/lighttpd/lighttpd.conf

Enable debugging info so you can figure out whats wrong if things don’t go smoothly right off the bat.

Here’s the minimal part you’ll need to get going. Add these lines to your lighttpd.conf and customize as needed.

If you don’t allow anonymous connections to your ldap, give it a user/password combination that has enough privs to do the lookups, or just use your master account if you’re just testing or don’t really care.

Now tell it what parts of your webserver you want to protect and how. You can specify any string you’d like for the realm. Here I require an LDAP user account name and password just to get to the wiki main page, and only admin can see the server-config page.

Restart lighttpd and you’re done. I require encrypted connections for my ldap and this works right out of the box. If you run ldapsearch -xZZ it will force encryption or die. So if you’re not seeing a bunch of entries… well there could be a ton of reasons, like no anonymous binds allowed, or perhaps there’s a firewall issue, etc. If it does work, then your ldap is probably set up right :) But you’ve already set up ldap properly before you stumbled this far, right?

Linux, howto, security howto, ldap, ldaps, lighttpd, mediawiki, mod_auth, server-config, ssl, wiki

I wouldn’t do it this way for a production network, but i’ve set up similar configurations for testing in vmware, in a research environment, and in a production environment.  So instead of a step by step, here’s a quick run through… It should clear up some of the missing pieces when you try to go from a basic ldap server to multiple servers with startTLS encryption.

If you haven’t done this before, you might want to break it into pieces like getting just the primary LDAP  server up with no encryption first.  But you can find those how-to’s anywhere.  Go big or go home right?

On the Server, become root and install OpenLDAP packages.

The machine you designate as the ’server’ will need “openldap-servers” and “openldap-clients” because you’ll want the server to be a client of itself. You’ll also need “nss_ldap” which, from yum info, allows LDAP to be used as a primary source of aliases, ethers, groups, hosts, networks, protocol, users, RPCs, services, and shadow passwords, and contains PAM support for password changes, V2 clients, Netscape’s SSL, ypldapd, Netscape Directory Server password policies, access authorization, and crypted hashes.

Generate a master password using slappasswd, copy and paste this password into slapd.conf

My LDAP primary server’s hostname is “server1″.  I’ll also set up a replica server named “server2″.  My network’s domain is “mydomain.com”.  So your /etc/openldap/slapd.conf.  I’m going to setup both servers and the encryption all at the same time.  If you run into issues after all this, you might not know which part you’ve messed up at, but starting ldap using lots of logging will let us figure out where it’s hung up.  This should all come out fine and work like a charm, so just go for it. But if you really don’t like that approach, feel free to skip the encyption and/or replica server parts (comment them out and delete the “tls_ssf=256″ parts iin slapd.conf) and come back to them later.  Only the last section stating with comment “Replica” will be different on your replica server2.  They’ll point to your primary server, server1, of course!

The finished version of /etc/openldap/slapd.conf should look like this:

The replica’s slapd.conf will include this part instead of the last section:

updatedn "uid=Manager,dc=mydomiain.com"
updateref ldaps://server1.mydomain.com

Create a self signed certificate on server1 and do it again on server2.

Put both pem files on both servers and on all clients.  Clients need the public part so they can talk to either server in case one goes kaboom! and a replica server has to take over for awhile.  Make sure you use the server’s hostname for “Common Name” when you’re creating them.  You can fill in the rest with whatever junk you want.

You’ll get a server.pem file with the private key and certificate together.  The clients only need the certificate part in their /etc/openldap/cacerts/ directory in order to communicate with the servers.  If you want to save time and it’s just for demo installation, you can just leave the keys in there and copy the files to everyone.  NO I DO NOT RECOMMEND THIS FOR ANY TYPE OF PRODUCTION ENVIRONMENT!  I’m just saying that if you want to save time and you’re just testing this stuff out in virtual machines or a private network, then it will work!

Import the local accounts into the LDAP database.

It’s easiest if you just create all the local accounts you want to start with, using whatever method you normally use to make them.  I use useradd from the commandline.

Run the migration script to fill the ldap database with your accounts.

Don’t panic!  They’re not actually migrating, they’re replicating.  Your local accounts will still be there and they’ll actually be looked at first on any machine because you’ll put “ldap” at the end of any lines in /etc/nsswitch.conf.  This means ldap will be considered after everything lese defined.  Think of it like how /etc/hosts supercedes DNS lookups.

Make sure the ldap user (automatically created by your openldap package installation) owns the files in your database directory and the certificates.

Edit /etc/sysconfig/ldap

You want to make it start LDAP and LDAPS so it will listen on ports 389 and 689.  It’s probably not necessary, but maybe you’ll run into a legacy application that uses encryption but doesn’t like StartTLS.

Copy DB_CONFIG.example to the database directory.

If you don’t have this file or something like it, renamed to “DB_CONFIG” in there, you will see warnings when you try to start the ldap service.  So just copy and forget about it.

At this point, the server side of things is done, however, you won’t be able to verify this until you set up the server as a client.  So continue on with server1.  Edit /etc/ldap.conf and tell it the server, where in the tree to start searching from, and where to get encryption info from.  Or you can just run /usr/bin/authconfig-tui which is provided by package “authconfig”.  This will prompt you for all the fields necessary to configure the machine for ldap.  I use “localhost” for the server, but the actual dns name or ip address for the server for the clients.

Configure /etc/ldap.conf on the clients (and the server so it can be a client of itself)

Configure the OS to actually acknowledge LDAP’s existence

Add “ldap” to the passwd, shadow, and group lines in /etc/nsswitch.conf and edit PAM settings. If you used authconfig-tui, this will get added automagically for you. When you’re done nsswitch should include this:

Start the ldap service on the primary and replica servers.  You should see the primary server start both slapd and slurpd while the replica just starts slapd.  That’s it.

Linux encryption, howto, ldap, replica, starttls

This doesn’t have to be complicated at all.  This was what I did on my ldap servers:

That’s it!  No messing with the CA.pl script or running multiple openssl commands for requests, signings, password stripping, and catting keys/crts together.  I tested my LDAP implementation like this and it worked like a charm.  Having a copy of both certificates located at /etc/openldap/cacerts/ on both machines worked for me.  When I set up clients, I put the certs in their cacerts directory and they work just fine with start tls.  If you’re doing this for an openldap implementation, you can make sure it’s working using “ldapsearch -x -ZZ” which requires your encryption to work.

http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg“>http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg” alt=”root|ninja” width=”80″ height=”15″ />

Linux cert, key, ldap, openldap, openssl, pki, self-signed certificate, ssl, tls