Adding a linux server to a windows domain

I already described in an earlier post how I added a linux server to a windows domain. Recently I added a new server to my domain, to replace my existing domain controller. As a consequence I had to update the krb5.conf file to point to the newly added server. Actually this hasn’t been to the first change in domain controllers, and usually users point out, that they cannot authenticate to subversion or apache based applications (which use kerberos authentication as well). OK, so I missed to update the krb5.conf again.

So there must be a more convenient way to configure kerberos. If only I had some way to pull the information of the current KDC from the domain-data. But wait – there is DNS. There are a couple of service-entries in DNS to point to all available kerberos servers in the domain! That sounds promising.

So I changed my krb5.conf file and added

dns_lookup_realm = yes
dns_lookup_kdc = yes

to the libdefaults section. Then I removed the realms and domain_realms section. Now all information about available KDC servers is directly pulled from DNS – sweet.

Integrated Windows Authentication in Mantis (Updated to Mantis 1.2.1)

In a previous post I described the necessary steps, to enable integrated windows authentication when working with Mantis on a linux box. These modifications where targeted against the 1.1.0a2 release of Mantis. In the meantime a lot of development has been done on Mantis, so that my original post isn’t quite accurate anymore. This post will enable you to use integrated security with the current 1.2.1 release of Mantis.

While the basic setup is somewhat unchanged, only the file core/authentication_api.php needs to be changed. The login.php doesn’t need to be changed anymore, since the functionallity moved to the authentication_api.php.

I added an updated patchfile to apply the necessary changes to the file.

Sizing the console

OK, so once in a while I have to work just on a plain old console on one of my linux machines. But since there is this neat 22″ monitor on my desk it hurts to see to see the default-resolution of 640×480 pixels.

So how to alter the default resolution, when you’re not using any graphic window manager thingy?

I have a recent version of Debian running, so I use grub for managing my boot-menu.

To change the resolution the easiest way is to go the /etc/default/grub and edit the commandline settings:

GRUB_CMDLINE_LINUX_DEFAULT="vga=0x0305"

This will give you at least 1024×768 with 256 colors! (A decent list of codes to use can be found at www.pendrivelinux.com).

What's the time?

just stumbled across some configuration stuff in one of my linux-servers and I thought this would be a good time to take some notes … I wanted to check that the time is correct on my linux server (running Debian), so here are some simple steps to verify that.

First off your hardware-clock should run on UTC/GMT. To verify that the clock is synced to UTC on shutdown verify /etc/default/rcS, which should have setting like UTC=yes. Then use tzconfig to manipulate the symlink at /etc/localtime to match your current timezone.

Finally you should set the clock using ntp:

ntpdate time.fu-berlin.de
hwclock --utc --adjust
hwclock --systohc

What's the diff?!

Way back then I created a couple of patches to apply certain changes to some files – but now I needed to created new patches … and how did I create those patches once again? Especially how to create a patch, which can modify several files at the same time?!

OK – after some google-ing I figured it out:

diff -c2 old_file1 new_file1 > patch
diff -c2 old_file2 new_file2 >> patch

This allows me to update both files with just one patch:

patch -p0 -b < patch

Good to know!

Integrated Windows Authentication in Mantis

Update: a new post is availbe, with an updates patchfile for Mantis 1.2.1!

The more tools are being used in an enterprise environment, the more logins and passwords need to be memorized. A first step is to use LDAP based authenticatin. In MS Windows based networks this offers to ability to manage all users in the Active Directory, so the users only have to use on username/password. But the user will still have to enter this into a login-screen in order to access the application.

Using SSO the user is always identified by already existind credentials. In the best case, the logon credetials of the operating system are being used. Since Active Directory is based on the Kereberos authentication protocoll, this offers the ability to use kerberos based authentication in other applications, and thus re-using the existing windows authentication.

The Internet Explorer is capable of using the windws logon-credentials to authenticate users on certain webservers. But with a slight modification this can also be used on an Apache running on a linux box. How to setup Apache to allow kerberos authentication is explained in another article. Once Apache is setup correct, Mantis needs to be slightly modified to use the information supplied by the kerberos authentication. My modifications are all based on the current development-release of mantis 1.1.0a2.

Modifing Mantis

Basically three files need to be modified: core\authentication_api.php, login.php and config.inc.php.

  1. In config.inc.php I switch from LDAP authentication to HTTP_AUTH, since I wand the webserver to handle the authentication. Also I introduce a new configuration setting sso_user_regex. This is needed, because I need to extract the username from the user identified by the webserver. So I use this handy little regex to do this for me:
             $g_login_method    = HTTP_AUTH;
             $g_sso_user_regex  = '/^(.*)@ACME\.COM$/i';

    This regex would extract the username portion for users of the domain “ACME.COM”.

  2. Next would be to modify login.php to extract the username from the authenticated user, if the user was detected using “Negotiation” (which is the case if IWA was used). So I apply my previously defined regex to the “Remote-User” variable of the server to get my mantis username. So we have to insert some code at line 32:
          if ( isset($_SERVER['REMOTE_USER'])) { #  $_SERVER['AUTH_TYPE'] == 'Negotiate' )
            preg_match(config_get('sso_user_regex'), $_SERVER['REMOTE_USER'], $user_match);
            $f_username = $user_match[1];
          }
  3. The last step is to add an additional condition to the authentication_api.php to prevent from trying to authenticate the user with the mantis user database using the username and password. This would only work, if the username and password would be supplied by the webserver, but using IWA we only have the username (the password is not transmitted in IWA, only the logon-challange). So this would only work if Basic Authentication would be used instead of kerberos authentication. So validating username and password with the mantis user database is restricted for HTTP_AUTH by modifing line 121:
          if ( HTTP_AUTH != $t_login_method && !auth_does_password_match( $t_user_id, $p_password ) ) {
          # if ( !auth_does_password_match( $t_user_id, $p_password ) ) {

So this should be all, to get Integrated Windows Authentication running. Below is a patchfile to apply the changes of authentication_api.php and login.php.

Attached you’ll find a patch-file to modified the corresponding files. To apply the patch you simple need to execute (assuming you have patch, and you’re executing it within your install-directory of Mantis):

   patch < iwa_sso.patch -p0

Download: iwa_sso patch

Kerberos authentication in Apache

First of all the mod_auth_kerb is needed to add kerberos capabilities to Apache. Besides this a working configuration of kerberos 5 is needed on the server running Apache.

Prepare Active Directoy

  1. To enable authentication against Active Directory a dedicated user is needed for each Apache server. The password doesn’t really matter, but the username should use a certain convention and maybe a explaining description. Such a account could be http-linuxserver.
  2. For the newly created account a keytab is needed to use the account from Apache. To create such a keytab the ktpass.exe is needed. The command on a Server running Windows 2003 looks like this:
             ktpass.exe -princ HTTP/linuxserver@ACME.COM
             -mapuser http-linuxserver
             -crypto DES-CBC-MD5 +DesOnly
             -pass myverygoodpass
             -ptype KRB5_NT_PRINCIPAL
             -out linuxxserver.keytab

    For domain-controllers running Windows 2000 the command might be slightly different.

Configuring Apache

After installing the mod_auth_kerb a couple configuration settings need to be made.

  1. First the previously created keytab file needs to be copied to the server (prefferedly using scp or simillar).
  2. Change to owner of the keytab-file to the user running Apache (depending on your distribution that could be apache, www-data or something else).
  3. To secure a directory or using kerberos the following entries need to be added to the appropriate configuration section of apache:
        AuthType Kerberos
        AuthName "Kerberos Login"
        KrbServiceName HTTP
        KrbMethodK5Passwd On
        KrbAuthRealms ACME.COM
        Krb5KeyTab /etc/httpd/conf/linuxserver.keytab
        require valid-user
  4. Restart Apache to apply the changes.

If you now access the secured website using Internet Explorer that supports Integrated Windows Authentication, you can see the content without being prompted for a password as long as you have valid windows-credentials.

Programme ausserhalb des Suchpfads bequem starten

Angenommen, Sie haben in /home/ichselber/test/ das Programm fiesesskript.sh liegen und wollen nicht bei jedem Start des Programms den Pfad komplett eingeben: Wenn Sie das Programm nicht in den Suchpfad mit aufnehmen wollen, liegt die Loesung in dem Befehl hash:

 hash -p /pfad/zu/meinem/programm/programm kurzname

Anhand unseres Beispiels sieht das so aus:

 hash -p /home/ichselber/test/fiessesskript.sh fies

Mit diesem Befehl bewirken Sie, dass ab jetzt die Eingabe fies reicht. Wenn Sie nur hash eingeben, bekommen Sie die Liste der bereits gespeicherten Kommandos angezeigt. Mit dem Befehl hash -r wird die Liste geleert.

Einrichtung von winbind unter Debian

Im folgenden wir beschrieben, wie winbind unter Debian eingerichtet werden muss, damit User ab Samba 3.x durch Active Directory authentifiziert werden können. In weiteren Schritten können sich User auch direkt an einem Linux-Terminal anmelden, deren Accounts lediglich im Active Directory vorhanden sind.

Voraussetzungen

Folgende Packages sollten installiert sein:

  • winbind
  • samba
  • libkrb53
  • krb5-user

Bei der Installation von krb5-conf werden ein paar Informationen direkt abgefragt, wie etwas der Default Realm (entspricht dem Namen der Active Directory Domäne) und des Domänenservers. Anschließend sollte allerdings die Datei /etc/krb5.conf noch ein wenig bearbeitet werden. Soll Kerberos nur für in Zusammenhang mit Winbind eingesetzt werden, so können die ganzen MIT-Realms ersteinmal entfernt werden. Auch werden eine ganze Reihe von Einstellungen für Kerberos 4 nicht benötigt; auch diese können weg.

Eine einfache krb5.conf Datei für die Domäne ACME.COM (aka Realm) könnte also so aussehen:

 [libdefaults]
        default_realm = ACME.COM
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
 [realms]
 ACME.COM = {
        kdc = server.acme.com
        admin_server = server.acme.com
 }
 [domain_realm]
        acme.com = ACME.COM
        .acme.com = ACME.COM

Damit die Benutzerauflösung auch durch Winbind erfolgen kann, muss zum einen in der nsswitch.confneben compat auch windbind eingetragen werden (auf diese Weise werden sowohl lokale Benutzer als auch Benutzer über Winbind zur Verfügung gestellt) und Samba muss noch so eingestellt werden, daß die Authentifizierung über das ADS läuft. Eine einfach smb.conf sieht dann etwa so aus:

 # Global parameters
 [global]
        workgroup = ACME
        realm = ACME.COM
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        winbind separator = /
        winbind use default domain = yes
        server string = %h server (Samba %v)
        security = ADS
        password server = server.acme.com
        client use spnego = yes

Damit die Änderungen übernommen werden, muss sowohl Samba als auch Winbind neu gestartet werden (/etc/init.d/samba restart; /etc/init.d/winbind restart). Anschließend kann mit wbinfo -u eine Liste alle Benutzer über winbind angezeigt werden.

Nun sollten sich auch Windows-Benutzer, die auf dem Linux Rechner nicht lokal angelegt sind, auf Samba-Freigaben verbinden können. Die Authentifizierung wird im Hintergrund durch Winbind erledgit.