Migrate user accounts from OpenLDAP to unix system user

Thursday, 3 March 2016

At the moment I want to get rid of an OpenLDAP instance wich is only used to authenticate users on a single host by now. I want to take all user accounts and store them as Unix user accounts in /etc/passwd, /etc/shadow and /etc/group. The only problem is the userPassword field. The passwords in OpenLDAP are hashed with the SSHA algorithm, which means Salted SHA-1. They look like "{SSHA}Nxs1gQ299W/QPXoRwW9kDZfaPpLApSWP", which is the Base64 encoded hash and salt.

SHA-1, and especially salted SHA-1, aren't supported by Linux's crypt. So while I can migrate the user names, uid, gid, homeDirectory and unixShell I am not able to migrate the user's passwords. That is very bad.

Fortunately, PAM and pam_exec.so exists! pam_exec calls a user-defined program that can do it's own verification routine. So I wrote a little Python script that looks into the system's shadow file and if the user's password hash starts with '{SSHA}' tries to verify it using the SSHA algorithm:

https://gist.github.com/Cybso/2016e4de9a2465cef920

Store this script under /usr/local/sbin/verify_ssha_passwd, make it executable and change the /etc/pam.d/common-auth from:

auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_deny.so

to

auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_exec.so expose_authtok /usr/local/sbin/verify_ssha_passwd
auth requisite pam_deny.so

This will call verify_ssha_passwd if and only if pam_unix.so fails to verify the password on its own.

When the password has been verified successfully this program will call 'passwd' to update the password to the system's default format. This means that this program will make itself obsolete over time.

Security considerations:

This script might be vulnerable to timing attacks, so don't use it in critical environments. Also it doesn't respect the additional shadow fields like 'maximum password age' and 'account expiration date'! If your security setup relies on these fields this script is not for you!

Play a movie as screensaver in KDE

Thursday, 3 March 2016

Did you ever want to play a video as screensaver? With KDE this is pretty easy.

  1. First, you need a video player. I choosed mpv, but mplayer will also do.
  2. Second, you need a video. Store it in a public readable place, for example in /opt/cats.mp4. This is not exactly required in a single-user environment, but since your screensaver will be available to all users it is a nice idea. Of course you could also place it in another directory like /etc/screensaver and/or symlink to the real file. This will make it easier to replace the actual video file.
  3. Third, create a custom screensaver service file for KDE:

    /usr/share/kde4/services/ScreenSavers/kcats.desktop

    [Desktop Entry]
Exec=mpv --loop=inf -ao=null /opt/cats.mp4
Icon=kscreensaver
Type=Service
X-KDE-ServiceTypes=ScreenSaver
Actions=Setup;InWindow;Root;
Name=Custom Video

[Desktop Action InWindow]
Exec=mpv --loop=inf -ao=null --no-keepaspect --wid=%w /opt/cats.mp4
Name=Display in Specified Window
NoDisplay=true

[Desktop Action Root]
Exec=mpv --loop=inf -ao=null --no-keepaspect --wid=0 /opt/cats.mp4
Name=Display in Root Window
NoDisplay=true

On an Intel NUC I had also to append '-vo=x11' to the option's list.

    The exact location of the ScreenSavers directory may depend on your distribution. If unsure, try to locate it with:

    $ find /usr -type d -name ScreenSavers
  4. Finally, open the Lock Screen menu from KDE's settings and select your custom screensaver.

Debian Squeeze auf Jessie

Monday, 29 February 2016
TIL Ein Upgrade von Debian Squeeze (6) auf Jessie (8) ohne Umweg über Wheezy (7) ist möglich, aber mit Schmerzen verbunden.
 

TL;DR: Eine Neuinstallation geht in der Regel einfacher. Falls man es trotzdem probieren will, dann sollte man an ein Backup denken und einigermaßen wissen, wie man mit Dependency-Problemen bei der Paketinstallation umzugehen hat.

Der Anfang ist wie üblich:

Sync LDAP accounts to Redmine

Friday, 24 July 2015

You can configure Redmine to use an LDAP or Active Directory server as login backend. Whenever a new user has been successfully authenticated against this service, a new entry in the Redmine's user table is created.

A side effect of this is that you can't work with users that have not logged in into your instance, yet.

To solve this I've created a small python script that can be used to periodically synchronize the users table with your directory services:

How to connect to a FortiGate IPSec-VPN using Linux

Tuesday, 2 June 2015

Update 2016-11-22

This article might not longer be relevant as a new opensource client called "openfortivpn" exists that utilized the SSLVPN feature of Fortigate instead of IPSec. See my new article Connecto to Fortigate VPN with OpenfortiVPN.

This article might be relevant to you if you have problems connecting to a FortiGate IPSec VPN with Linux (vpnc). For example, when using NetworkManager, you might see something like this in syslog:

Pages