Using LDAP for email aliases

As I gradually migrate various servers to using LDAP as the auth back end, it occured to me that there was some duplication going on in terms of adding the users' email addresses to the LDAP so that they could be looked up on clients and then having an aliases file that was being used by exim to do the delivery.

So I've come up with the following for allowing exim to take advantage of the email addresses stored in the LDAP database:

### router/450_local_ldap_aliases
#################################

# This router handles aliasing looking up email addresses in an ldap database.
#

ldap_aliases:
debug_print = "R: ldap_aliases for $local_part@$domain"
driver = redirect
domains = +local_domains
allow_fail
allow_defer
data = ${lookup ldap {ldap://127.0.0.1/ou=Users,dc=...?uid?sub?(mail=$local_part@$domain)}}

Ubuntu on a Dell XPS M1530

With the release of Ubuntu 8.10 (Intrepid Ibex) the vast majority of stuff on a Dell XPS M1530 works out of the box. One caveat is the touchpad. It jumps around like a demented rabbit!

The solution is simple.

Edit /boot/grub/menu.lst

Find the line that starts
# kopt=root=UUID....

Add i8042.nomux=1 to the end of that line

Then run update-grub and reboot.

Office 97 as a normal user

Usually when you put a Windows XP machine on a user's desktop you want to have them logging in as a standard user rather than a power user. However various bits of software have issues with that due to poor design of the way they handle the registry. They try to write to keys or create keys in areas that they don't have permission.

One such delight is Office 97. There are two specific problems. Firstly, spelling and grammar checking is disabled. This has to be fixed with a registry permissions edit.

HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Proofing Tools\Spelling

HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Proofing Tools\Grammar

both need to have Set Value and Create Subkey enabled for the group Users

The other issue is VBA macros. There are two solutions here. One is another set of permissions changes - but these open up quite a lot in the registry. Much better is this solution.

As administrator run a macro - doesn't matter what - just something to get the macro system used.

Then in

C:\Documents and Settings\Administrator\Local Settings\Temp\VBE\

you will find MSForms.EXD

Copy that to somewhere accessible. Then for each user who needs to run VBA macros, copy this file into their Local Settings\Temp\VBE folder.

LTSP 5 local devices fun

Been working on using LTSP 5 on a Kubuntu machine to replace our current LTSP 4 set up on debian. Part of this has been about getting local devices operational which, on the whole, works "out of the box" with the (k)ubuntu ltsp packages. The local devices appear under /media/ - which you could create a symlink to on the desktop for the users to easily access their devices.

However, I plugged in one of my USB memory sticks and nothing happened. So I went through the debugging routine:
Check that the device is partitioned (/dev/sdb1 rather than just /dev/sdb when plugged into my linux laptop)
Check that the ltsp workstation is seeing the device by logging into the local shell as root and using dmesg after plugging it in
Check the udev stuff is happening (look for an entry in /var/run/ltspfs_fstab)

That was where it was failing - no entry.

So I dug around in the udev rules and looked at the script that adds the entry to the fstab. Here was the source of the problem. This script uses the label on the volume to create the mount point and the volume label on my usb stick had a space in it - that was enough to prevent it from running the script properly.

So - if you want your removable media to work on a (k)ubuntu LTSP set up then make sure that any volume labels are without spaces.

Exim SMTP AUTH from LDAP

This turned out to be very simple indeed.

Here's a suitable config for LOGIN and PLAIN type auth:

ldap_login:
 driver = plaintext
 public_name = LOGIN
 server_prompts = Username:: : Password::
 server_condition = ${if ldapauth {user="uid=${quote_ldap:$1},ou=Users,dc=....." pass="$2" ldap://localhost/}{yes}{no}}
 server_set_id = $1
 server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}

ldap_plain:
 driver = plaintext
 public_name = PLAIN
 server_prompts = :
 server_condition = ${if ldapauth {user="uid=${quote_ldap:$2},ou=Users,dc=...." pass="$3" ldap://localhost/}{yes}{no}}
 server_set_id = $2
 server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}

The bit which wasn't explained very well (or at least not obvious to me) was what ldapauth did. There were various examples around which were pulling passwords out of a directory, having logged in with a suitable dn, but what this simple solution does is attempt to log into the LDAP directory using the credentials that "user" and "pass" are set to and since the LDAP directory contains the user authentication data as used by other systems (such as PAM or the unix NSS) it is authenticating against exactly the same thing.

This method won't work with the cram_md5 authentication driver as that requires a password to be pulled from somewhere and given to exim to work with.

Migrating users from shadow / tdbsam data to LDAP

This is still a work in progress at present, but I'm working on the migration of a set of user accounts from the traditional Linux shadow / Samba tdbsam back ends into an LDAP directory. This should result in a set up with much tidier administration and better sharing of credentials between servers.

A rough summary so far:
Installed slapd and samba and (I'm using Debian etch) the samba-doc package
Installed the smbldap-tools package

Added the samba.schema from the samba-doc package to the ldap config and amended the indices and permissions.

index objectClass,uidNumber,gidNumber,entryUUID,entryCSN eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq


access to attrs=userPassword,shadowLastChange,SambaLMPassword,SambaNTPassword
by dn="cn=......" write
by anonymous auth
by self write
by * none


Got the domain SID and set up the smbldap-tools with appropriate defaults and done the base population of the LDAP directory with smbldap-populate

Amended samba to talk to the ldap directory

passdb backend = ldapsam:ldap://127.0.0.1/
ldap admin dn = cn=.......
ldap delete dn = Yes
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Machines
ldap passwd sync = Yes
ldap suffix = dc=.......
ldap ssl = no

and add references to the tools to make user admin simple (we like simple!)

add user script = /usr/sbin/smbldap-useradd -m "%u"
delete user script = /usr/sbin/smbldap-userdel "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"

(one strange thing above is in the add user script - you may expect to include the -a option - which says this is a Samba account. This is only needed from the command line. Here we're after creating just the posix account and then Samba will separately add the extra bits to make it a Samba account. If you have the -a option in then trying to use the NT user manager will result in "a device attached to the system is not functioning" coming up when you try to add a user.)

Install libnss-ldap and libpam-ldap

Update /etc/nsswitch.conf to use "files ldap" for passwd, group and shadow

Amend the common-* PAM files as follows:

#
# /etc/pam.d/common-account - authorization settings common to all services
#
account sufficient pam_ldap.so
account required pam_unix.so

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so

#
# /etc/pam.d/common-password - password-related modules common to all services
#

password sufficient pam_ldap.so
password sufficient pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass use_authtok
password required pam_deny.so

#
# /etc/pam.d/common-session - session-related modules common to all services
#

session sufficient pam_ldap.so
session required pam_unix.so


For the main migration, the tools of interest are smbldap-migrate-unix-accounts, smbldap-migrate-unix-groups and pdbedit in that order. The first two are in the examples area of the documentation for smbldap-tools, gzipped by default, so you need to uncompress them and make them executable.

Take a copy of the old password and shadow files. Edit it down to just the accounts you want in LDAP (including taking machine accounts out). Then do

/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-accounts -P temp -S temp
/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-groups -G temp

This pulls all the unix stuff in.

Then pdbedit -i tdbsam -e ldapsam (presuming your old passwd.tdb file is still in the same place and Samba is configured to talk to the LDAP server) will pull in the Samba attributes and passwords of the old Samba accounts (including machines).

The next trick I'm working on is getting exim to talk to the LDAP server for SMTP AUTH

Fixing a broken grub MBR with LVM / and /usr

Following a power cut, a friend of mine found that he couldn't boot his Debian etch machine. It appeared that some traces of lilo were still lurking on the machine and had messed up the MBR during a kernel upgrade. As the partitions with the exception of /boot were in LVM volumes, it made the task of recovering the MBR a little more involved.

Here is the procedure we followed:

Boot from a Debian install CD into rescue mode and after following all the prompts get a shell on the system root
Copy the current fstab to fstab.safe (we need this to get the file system back in order later)
Re-boot from the Debian install CD, this time going through the normal route.
At the partition disks prompt, choose Manual.
Then choose the "Configure Logical Volume Manager" option.
Choose to keep the current config and activate the current volume group.
Pick finished to go back to the partitioner.
In the list of partitions, find the root and usr partitions and select each of them in turn option to use them as ext3 file systems with the appropriate mount point.
Choose the write changes to disk option. The installer should say it is going to format the swap partition and nothing else. If it says it is going to format anything else then go back and check how you have configured that partition.
When it brings up the message about an unclean system, use Alt-F2 to switch to the second console
Press enter to access the shell and type "chroot /target"
You are now in your original file system.
Mount the boot file system (probably with either mount /dev/sda1 /boot or mount /dev/hda1 /boot depending on your disks)
Now you can re-initialise grub with grub-install /dev/sda1 (or /dev/hda1) and use update-grub to ensure the menus are built.
Finally cd into /etc and copy your safe copy of fstab back over the one which the installer will have written out for you.
Then Ctrl-Alt-Del and you should be able to boot happily back into your original system.