OpenSSH has been upgraded on all the FreeBSD servers to the latest openssh-portable package, correcting the vulnerabilities discovered last week.

FreeBSD 4.4 packages were installed on HEIWA, KE, and SHANTI. A FreeBSD 4.7 package was installed on PAX. These are all openssh-portable-3.6.1p2_3. They install into /usr/local and require the following changes to /etc/rc.conf:

sshd_program="/usr/local/sbin/sshd"

sshd_flags="-f /etc/ssh/sshd_config"

PAX is the only server that currently required these changes, as the others had previously been upgraded to OpenSSH-portable. PAX also required minor changes in the /etc/ssh/sshd_config file.

RADIUS is now entering passwords into Samba for those that have never reset their passwords to log in to the Samba Windows domain.

Due to numerous complaints from people who hadn’t ever changed their passwords, and thus cweren’t ever active in the Samba password file, I rewrote part of the rlm_smb module in RADIUS. It now checks against LDAP first, and if it succeeds there, it changes the Samba password with the supplied password.

The addition to the RADIUS module is a couple of lines of C code that call a perl script. The script does the LDAP checking and Samba password updating. It’s a somewhat kludgy system, but it is working. I put the RADIUS changes in the FreeRADIUS package that I installed on SHANTI, and the perl script is /usr/local/libexec/radldapsmb.pl, which must be called as root (and thus the RADIUS server must run as root, which it was anyway).

As a result, anyone successfully authenticating now can log in to the Windows 2000 computers without having to go through a password reset.

Update

While RADIUS is still working in the mode described here on SHANTI, I have shifted the bulk of authentications (which are e-mail logins from KE) to querying LDAP directly with the pam_ldap module. The above modifications required FreeRADIUS to run in single threaded mode, which was insufficient for the load placed on it by KE. As a result, it was dropping RADIUS request packets and causing login failures. I will keep RADIUS running in this mode for the time being, as it is still useful to have the Samba auto-update feature. However, I suspect we will see a shift away from RADIUS authentication towards direct LDAP authentication.

Samba and FreeRADIUS are now using LDAP (on ASHTI) as their authentication store.

The biggest things here were the migration of all accounts in /etc/passwd to LDAP on ASHTI. This went through pretty easily with the scripts in my directory: ~rowan/smbldap/MigrationTools-44.

Upgrading Samba to LDAP support was straightforward. The new configuration variables in smb.conf are required, and I changed the Unix passwd sync to the resetpass program, which changes the LDAP password and the Seminary password as well as the Unix password. Then Samba can go ahead and change the Samba password. This works well except when the seminary server is unavailable, in which case the Unix and LDAP passwords are changed, but Samba isn’t (and the seminary one isn’t of course, as well).

FreeRADIUS is at version 0.7 currently, but we seem to be having issues with the LDAP module periodically losing its connection to ASHTI. I‘m working on this. Version 0.8.1 of the server might help if I can’t get anything else to work. I changed from TLS enabled LDAP to unencrypted. I might also try using the SMB authentication module, which I happened to compile into the package I installed. I am now currently using the SMB module to authenticate against Samba on SHANTI (which is authenticating against the Samba account fields in LDAP). I’m still not sure what’s wrong, but I can’t leave it periodically dying.

resetpass is being updated to support the seminary servers and add support for LDAP password changes.

The new version adds several things:

1. Remote password changing program: the remote program is a simple command line password changer that is run on a remote host through an SSH tunnel. This requires null-passphrase SSH keys to be set up between SHANTI and the remote server (in this case Bathsheba). Note that the SSH keys and host information must be in root's .ssh directory since resetpass runs as root under sudo.
2. LDAP password changing: it is possible to specify an LDAP server and the appropriate DN and password to reset or change someone's password in an LDAP directory. If LDAP support is specified, the initial authentication check is done via LDAP binds rather than getpwnam lookups.
3. New password specification: this script will take the place of passwd in Samba's system password synchronization, and as such needs to be able to accept a new password specified by the user. The -n argument signals this. If given, resetpass will prompt for the new password rather than generating a random one.

Other minor new features include a command line argument to specify the configuration file (necessary to support two configuration files: one for password resets via the web interface and one for password changes initiated from Samba), checking of the $SUDO_USER environment variable (necessary to work out some kinks with the passwd account and admin users restarting Samba with sudo), and support for password change notifications (another change module: uses a local program to "notify" password changes - could, for example, send e-mail with the user's username to a specified address, or other nasty insecure things - don't use it).

Zach and Steve Spyker have been testing this version for seminary changes with good success. I suspect it will go live on Monday for general purpose resets. It will go live for Samba resets when we move to LDAP authentication (and put in the new Samba).

Upgraded Samba on all systems except MIR on Friday morning.

PACO and ROJ are using Sunfreeware.com packages (requires the popt package). All others are using FreeBSD packages built on my workstation.

On installation on SHANTI, it somehow overwrote all individual entries in the smbpasswd file such that passwords were null and accounts were disabled. Restored from previous night's backup.