Posts Tagged ldap

What a difference a working resolver makes

The next phase in tidying up my user authentication environment in the lab was to enable SSL/TLS on the z/VM LDAP server I use for my Linux authentication (I’ll discuss the process on the DeveloperWorks blog, and put a link here).  Apart from being the right way to do things, LDAP authentication appears to require SSL or TLS in Fedora 15.

After I got the Fedora system working, I thought it would be a good idea to have other systems in the complex using SSL/TLS also.  The process was moderately painless on a SLES 10 system, but on the first SLES 11 system I went to YaST froze while saving the changes.  I (foolishly) rebooted the image, and it hung during boot.  Not fun.

After a couple of attempts to fix up what I thought were the obvious problems (each attempt involving logging off the guest, connecting its disk to another guest, mounting the filesystem, making a change, unmounting and disconnecting, and re-IPLing) with no success, I went into /etc/nsswitch.conf and turned off LDAP for everything I could find.  This finally allowed the guest to complete its boot — but I had no LDAP now.  I did a test using ldapsearch, which reported it couldn’t reach the LDAP server.  I tried to ping the LDAP server by address, which worked.  I tried to lookup the hostname of the LDAP server, and name resolution failed with the traditional “no servers could be reached” message.  This was odd, as I knew I’d changed it since it was pointing to the wrong DNS server before…  I could ping the DNS by address, and another system resolved fine.

I thought it might have been a configuration problem — I had earlier had trouble with systems not being able to do recursive DNS lookups through my DNS server.  I went to YaST to configure the DNS Server, and it told me that I had to install the package “bind”.  WHAT?!?!?  How did the BIND package get uninstalled from the system…

Unless…  It’s the wrong system…

I checked /etc/resolv.conf on a working system and sure enough I had the IP address wrong.  I was pointing at a server that was NOT my DNS server.  Presumably the inability to resolve the name of the LDAP server I was trying to reach is what made the first attempt to enable TLS for LDAP fail in YaST, and whatever preload magic SLES uses to enable LDAP authentication got broken by the failure.  Setting the right DNS and re-running the LDAP Client module in YaST not only got LDAP authentication working but got me a bootable system again.

A simple fix in the end, but I’d forgotten the power of the resolver to cause untold and unpredictable havoc.  Now, pardon me while I lie in wait for the YaST-haters who will no doubt come out and sledge me…  🙂

Tags: , , , , , ,

RACF Native Authentication with z/VM

 In 2009 I was part of the team that produced the Redbook "Security for Linux on System z" (find it at http://www.redbooks.ibm.com/abstracts/sg247728.html).  Part of my contribution was a discussion about using the z/VM LDAP Server to provide Linux guests with a secure password authentication capability.  I probably went a little overboard with screenshots of phpLDAPadmin, but overall I think it was useful.

I’ve come back to implement some of what I’d put together then, and unfortunately found…  not errors as such, but things I perhaps could have discussed in a little more detail.  I’ve been using the z/VM LDAP Server on a couple of systems in my lab but had not enabled RACF.  I realised I need to "eat my own cooking" though, so decided to implement RACF and enable the SDBM backend as well as switch to using Native Authentication in the LDBM backend.

Native Authentication provides a way for security administrators to present a standard RFC 2307 (or equivalent) directory structure to clients while at the same time taking advantage of RACF as a password or pass phrase store.  Have a look in our Redbook for more detail, but basically the usual schema is loaded into LDAP and records are created using the usual object classes like inetOrgPerson, but the records do not contain the userPassword attribute.  Instead of comparing a presented password against the field contained in LDAP, the z/VM LDAP Server (when Native Authentication is enabled) issues a RACROUTE call to RACF to have it check the password.

In my existing LDAP database, I had user records that were working quite successfully to authenticate logons to Linux.  My plan was simply to enable RACF, creating users in RACF with the same userid as the uid field in LDAP (I have access to a userid convention that fits RACF’s 8-character restriction, so no need to change it).  After going through the steps in the RACF program directory, and various follow-up tasks to make sure that various service machines would work correctly, I did the LDAP reconfiguration to get Native Authentication.

At this point I probably need to clarify my userid plan.  The documentation for Native Authentication in the TCP/IP Planning and Administration manual says that the LDAP server needs to be able to work out which RACF userid corresponds to the user record in LDAP to be able to validate the password.  It does this by either having the RACF userid explicitly specified using the ibm-nativeId attribute (the object class ibm-NativeAuthentication has to be added to the user object), or by matching the existing uid attribute with RACF.  This is what I hoped to be able to do; by using the same ID in RACF as I was already using in LDAP, I planned to not require the extra object class and attribute.  In the Redbook, because my RACF ID was different from the LDAP one I went straight to using the ibm-nativeId attribute and didn’t go back and test the uid method.

So, I gave it a try.  I had to disable SSH public-key authentication so that my password would actually get used, and once I did that I found that I couldn’t log on.  It didn’t matter whether I tried with my password or pass phrase, neither was successful.  I read and re-read all the LDAP setup tasks and checked the setup, but it all looked fine.  In one of those "let’s just see" moments, I decided to see if it worked with the ibm-nativeId attribute specified in uppercase…  and it did!

Okay, so it appeared that the testing of uid against a RACF id was case-sensitive.  I decided to try creating a different ID, with an uppercase uid, in LDAP to double-check.  Since phpLDAPadmin wouldn’t let me create an uppercase version of my own userid (since that would be non-unique), I created a different LDAP id to test:

[viccross@laptop ~]$ ssh MAINT@zlinux1
Password:
Could not chdir to home directory /home/MAINT: No such file or directory
/usr/X11R6/bin/xauth:  error in locking authority file /home/MAINT/.Xauthority
MAINT@zlinux1:/>

My MAINT user in LDAP has no ibm-nativeId attribute, so the only operational difference is the uppercase uid (the error messages are caused by the LDAP userid not having a home directory; I use a NFS shared home directory had I hadn’t bothered setting up the homedir for a test userid).

The final test was to change the contents of the ibm-nativeId attribute in my LDAP user record to lower-case — and it broke my login.  So that would seem to indicate that the user check against RACF is case sensitive wherever LDAP gets the userid from.  I’m going to have a look through documentation to see if there’s something I need to change, but this looks like something to be aware of when using Native Authentication.

I also noticed that I didn’t describe the LDAP Server SSL/TLS support in the Redbook, but that’s a post for another day…

Tags: , , , , , , ,

LDAP groups in Postfix

For a long time I’ve been managing virtual e-mail addresses (the ones you create when you sign up to a web service, so that you know where your spam is originating) using Postfix’s LDAP alias capability.  At the time I was still putting every bit of configuration I could into LDAP–particularly if it was user-id related–and I’ve never had a need to change what was working really well.

N’s school recently decided to distribute the weekly school newsletter via e-mail, and had allowance for one e-mail address per family.  Not wanting the additional overhead of having to have either S or me receive it and then having to forward it to the other, I thought it would be neat to have a single common address that, when items arrived, distributed the mail to multiple boxes.  Of course I took the stupid path of providing the school with a yet-to-be-created e-mail address, foolishly trusting my ability to set the system up before they tried to send anything to it…  but in the end it was not so foolish after all, as unbeknown to me I already had everything I needed to achieve my objective.

Unfortunately the first thing I did was assume that I needed mailing list software.  I installed Mailman, and started to read-up on the process to get it working.  I did this on my yet-to-be-commissioned KVM-hosted mail server (a blog post for another day), and started trying to diagnose why mail wasn’t getting delivered.  I had set up Postfix on this mail server to point to my existing LDAP to test, and thought that there was a problem there (but also started to work out if there was a way to use the LDAP server to manage the Mailman aliases).  I re-found the Postfix LDAP HOWTO, and stumbled over the section entitled “Example: expanding LDAP groups”.  Et voila: multidrop incoming mail without the need for a mailing list manager!

I had always assumed that e-mail aliases were a one-to-one mapping of alias address to real destination.  Not the case: an alias can have multiple destinations.  It doesn’t just apply to LDAP alias support, either: as per the “aliases” man page you can do

name: value1, value2, ...

In my LDAP situation, all I need to do is list the alias in the “mailLocalAddress” attribute of which ever users need to receive mail for that alias.  Done!

I may have to keep Mailman, however.  Shortly after this success, I wondered how cool it would be to have the notification SMS messages for voicemail received at home, that currently go only to S, come to me as well.  I’m using a hosted email-to-SMS gateway service for this, so the “alias” would have to expand to multiple external e-mail addresses.  I’m not sure if you can alias mail addresses that are not in your domain…  I’ll have to try and see–might be easier to do that than subscribing to a Mailman list via SMS-to-email!  🙂

Tags: , ,

LDAP-backed DNS and DHCP…?

I’m having a bit of an infrastructure redesign here at the Crossed Wires campus.  Each time I have an outage (the last one was caused by a power failure) I learn a little more about the holes in my current setup and what I can do better.

I’m implementing a router box on an old low(-ish)-power PC that will be backed up by a virtual machine on my main virt-box.  I’ve already done most of the preparation of using keepalived to implement VRRP, and a colleague has given me some pointers in using the Linux-HA tools like Heartbeat and DRBD to make services like e-mail and Samba redundant.

I’ve had a soft spot for LDAP for ages; I’ve always thought that putting as much backend data into LDAP as you can would be a really good way to get failover and redundancy.  Instead of having to deal with every single server’s different way of doing replication and failover, just bung everything into LDAP and get that replicating.  Sounds good in theory, but in a nutshell it’s not working out that way for the two least-celebrated but most important components of my (arguably any) network: DNS and DHCP.

There are a number of LDAP-backed DNS projects out there.  If I’m willing to go to the bleeding edge with BIND on my Gentoo build I can get access to the two most talked-about ones (bind9-sdb-ldap and the BIND DLZ LDAP driver), and other solutions like PowerDNS and ldapdns are available.  But none of them offer integration with DHCP, and I’m currently using dhcpd’s “interim DDNS update method” to make sure that hostnames are seen in my DNS when a lease is granted (okay, there’s a Perl daemon that goes with bind9-sdb-ldap, but it seems like a sort-of clunky afterthought).

Speaking of DHCP, LDAP backends for it are virtually non-existent.  The only LDAP-enablement I’ve found for ISC DHCP involves putting the config file into LDAP, not the leases…  I actually used that for a few days a while ago and pulled it out because it was actually more work to do it that way (and for no benefit in failover).

It seems to me it would be a project ripe for the picking: take an integrated DNS/DHCP server like dnsmasq and make it write into LDAP instead of to a file.  If I had more free time I’d probably have a go at it, except for the fact that no-one really seems to be that interested in storing DNS and DHCP in LDAP: that it hasn’t been done says to me that there’s no demand for it, and it’d end up being a big waste of time and effort.

Over to you, lazyweb…  Is this a yawning chasm of unfulfilled networking dreams, or a case of me trying to make something more complex than it needs to be?  After all, the rest of the world gets by with DNS master-slave and DHCP failover, they should be good enough for me too, right?  😉

Tags: , , , ,

LDAP Caller ID again!

After a hiatus that has lasted since I first cut the phone system over to Trixbox (probably a year or more), LDAP caller-ID name lookup is working again on my Asterisk system!  A lot easier to maintain than the original version I implemented ages ago, too.  A bit of PHP code does the trick!

I’m using FreePBX for keeping my Asterisk box configured, and it’s working great — but there are a couple of tricks that I just haven’t quite been able to work around.  You see, FreePBX applies a few assumptions that work fine in a small office environment (like voicemail-per-extension) but don’t map to home use (one voicemail for the household).  The biggest aspect of FreePBX is that it maintains the dialplan in a set of files all of its own making — you can extend it using “custom applications” (basically a reference to a dialplan file of your own creation), but I’d be concerned about an upgrade trenching custom dialplan files…

My original LDAP caller-id lookup module implemented a new dialplan app (something like  LDAPCallerName).  I inserted it into the dialplan at the relevant place, et voila, name lookup.  But even if I could port my old code to the later revisions of Asterisk, or use the community LDAP lookup module (which was written just a little while after I wrote mine), how do I add the lookup into the dialplan?

FreePBX has a module called “Caller Name Lookup Sources”.  Out of the box, it has the types “Internal”, “ENUM”, “HTTP”, and “MySQL” (“SugarCRM” is listed as well, which I figured would be tied into the SugarCRM system that’s provided with Trixbox, but when you select it you get “not yet implemented”).  MySQL doesn’t help me, as I don’t want to transfer data out of LDAP into some other store.  ENUM is a name lookup system based on DNS, and having seen a lot of work on LDAP-backed DNS servers I thought this might be interesting… until I realised that I’d likely have to spend a heap of effort adding the DNS attributes and object types to my existing LDAP data (assuming that I could use the data in its existing structure at all).

I had disregarded the HTTP method as overly clumsy — on a single host, contacting the HTTP server to run a script to get data from the LDAP server just seemed too much overhead to me.  After I had a think about the available options though, it made a lot of sense — and half-an-hour after I decided to do it, I had a working prototype (and I consider myself very much a PHP newbie).  My script has a few nice features that tie in with the way the Caller Name Lookup module works in FreePBX, including the thing that I found was missing in the Asterisk LDAP module — the ability to drop leading zeroes from the number to be looked up, allowing you to have numbers stored in your database in international format.

Next to come will be the directory lookup CMXML app, that will allow the “External Directory” function on the Cisco phones to work again!

Tags: , ,

Veejoe goes LDAP

We bit the bullet here at the new Ellendale data centre.  LDAP authentication!  Works like a bought one.

Coinciding with the relocation of the prime server from Rubicon DC to Ellendale DC, we’ve implemented LDAP authentication for Linux and Mac OS X clients.  There’s also automounted home directories to boot!  It went quite smoothly, all things considered.

Now will come the dreaded data reorganisation (there’s about 1.5TB of storage across all the Crossed Wires machines).  Also, I’ve been running Samba 3 for a while so there’s probably not much reason to keep putting off integrating the Windows boxes into LDAP as well…

Tags: ,