Skip to main content

Thinstation as Citrix thin clients

At work, we have a few very old pc's that I set up with a custom Thinstation Linux distribution. Since getting the configuration file to connect to Citrix needed quite some trial and error work, I'll post it here so I won't forget. Note that the thin clients connect to a Farm called "VIPCORPFARM" and that they connect to a shared application called "Desktop":

# Default Session

Wyse Firmware Policy

is simply fucking retarded. You need a maintenance contract to get updated firmware! Picture this:

  • You have around 200 Wyse thin clients
  • You are being bitten by a bug which is triggered by a Citrix update, but affects only one series of Wyse thin clients
  • You are asked about 4k EUR to get updated firmware for your clients

Now: I'm fine with paying maintenance contracts to be able to open cases and to have some help with troubleshooting. But refusing to give out firmwares is plain stupid. Especially since they give out firmware for the out of production ones. I know which brand of thin clients I will never buy again.

New gpg key

Switched to a new gpg key:

michele@conrad:~$ gpg --fingerprint 75155C6D
pub   4096R/75155C6D 2009-07-12
Fingerprint = C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
uid                  Michele Baldessari <>
uid                  Michele Baldessari <>
uid                  Michele Baldessari <>
sub   4096R/46E72B67 2009-07-12

The new key has been uploaded to the key servers and it is signed with my old key : E4B4 4826 0E0C BF0D 3935 ED35 A1F6 EE94 240B 4C3D

Integrating Active Directory and Squid3

Here's my third and probably last post on a topic about AD integration and linux. This time around the goal is to have Kerberos authentication integrated with Squid, so that users do not have to be prompted for additional authentication when surfing the web.

The setup is the exact same as in the two previous articles (just with a 2008 DC instead of a 2003R2):

  • Domain Controller and Kerberos KDC - Windows Server 2008 - dc1.win2008.corp (
  • Proxy Server - Debian Squeeze (as of 05/2009) - www.win008.corp (
  • Client1 - Windows XP Professional - client1.win2008.corp(

I'll assume that the AD domain is already configured and that the Debian box is already joined to the domain (see previous blog posts on how to do that). As a first step the squid3 package needs to be installed (unless #532064 is fixed you'll need to recompile the debian package with the options mentioned in the bug report):

apt-get install squid3

Then we need to export the correct keytab HTTP/www.win2008.corp as required for Kerberos authentication :

net ads keytab add -U Administrator HTTP

Once that is done we'll have the appropriate keys in the default keytab (/etc/krb5.keytab). With ktutil you can explore the keys in the file:

ktutil:  **rkt /etc/krb5.keytab **
ktutil:  **l**
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1    2       host/www.win2008.corp@WIN2008.CORP
2    2       host/www.win2008.corp@WIN2008.CORP
3    2       host/www.win2008.corp@WIN2008.CORP
4    2                    host/www@WIN2008.CORP
5    2                    host/www@WIN2008.CORP
6    2                    host/www@WIN2008.CORP
7    2                        WWW$@WIN2008.CORP
8    2                        WWW$@WIN2008.CORP
9    2                        WWW$@WIN2008.CORP
10    2       HTTP/www.win2008.corp@WIN2008.CORP
11    2       HTTP/www.win2008.corp@WIN2008.CORP
12    2       HTTP/www.win2008.corp@WIN2008.CORP
13    2                    HTTP/www@WIN2008.CORP
14    2                    HTTP/www@WIN2008.CORP
15    2                    HTTP/www@WIN2008.CORP

Make sure squid can read the keytab file: use an ACL, change file permissions or move the key to a different keytab and change the init script KRB5_KTNAME=/etc/squid/HTTP.keytab export KRB5_KTNAME

Here's a minimal configuration in order to test the kerberos negotiate authentication in squid (only the relevant parts):

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d
auth_param negotiate children 10
auth_param negotiate keep_alive on
http_access allow AUTHENTICATED
http_access deny all

At this point a simple XP client that is joined to the Windows win2008.corp domain and that has www.win2008.corp as a proxy should be able to surf authenticated (do not forget to make sure that IE integrated authentication option is active):


Putty, Active Directory and Kerberos

_Update: _This article covers pristine putty without any patches. In the past you could have obtained the same results with the many variants of putty (i.e. Quest's, Centrify's)

This is a short and simple tutorial about setting up Kerberos authentication with putty and Active Directory.  Since a few snapshots putty supports Kerberos-GSS authentication on Windows. This means that we're able to authenticate, without using ssh keys and without being prompted for user/pass, to an ssh linux box which has the appropriate keys in its keytab. I covered the basics of getting the keytabs out of Active Directory onto a Linux box on my previous blog post (I am actually assuming the same setup mentioned in the previous blog posting). The linux box needs to be joined to the Windows domain via samba. Updating the keytab is then trivial; on the linux box (_www.win2008.cor_p) launch the following:

net ads keytab add -U administrator

Verify that the host/fqdn is present in the keytab list:

www:~# <strong>ktutil</strong>
ktutil: <strong>rkt /etc/krb5.keytab</strong>
ktutil:  l
slot KVNO Principal
---- ---- ----------------------------------------------
   1    2       host/www.win2008.corp@WIN2008.CORP
   3    2       host/www.win2008.corp@WIN2008.CORP
   4    2                    host/www@WIN2008.CORP
   5    2                    host/www@WIN2008.CORP
   6    2                    host/www@WIN2008.CORP

Configure the ssh daemon on www.win2008.corp and activate the Kerberos/GSS support:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

Restart ssh :

invoke-rc.d sshd restart

Once the ssh daemon is set up and the keytab contains the correct entries, we log on to a Windows XP client which has the snapshot of putty (Note: the user that logs on the Windows XP box, needs to exist on the Linux machine as well. In my case I have a "michele" user in AD, which needs to exist on Linux as well: adduser michele). We configure putty to send the system username: putty-use-system-user

We also double check that the SSH authentication supports GSSAPI:


At this point we'll be ablt to login on the box from the Windows XP using Kerberos authentication (and hence making use of the TGT we get from using the Active Directory KDC):


Success ;)

For the record, while logging in, sshd (at DEBUG2 LogLevel) will give the following:

May 31 15:27:36 www sshd[2757]: debug1: Got no client credentials
May 31 15:27:36 www sshd[2757]: Authorized to michele, krb5 principal michele@WIN2008.CORP (krb5_kuserok)
May 31 15:27:36 www sshd[2757]: debug1: do_pam_account: called
May 31 15:27:36 www sshd[2757]: Accepted gssapi-with-mic for michele from port 1117 ssh

Active Directory and Apache Kerberos authentication

This article uses Windows 2003R3 as a KDC, but the exact same setup works with Windows 2008 SP1. The only requirement in case of Windows 2008 is a sufficiently recent Samba installation. In my case, samba 3.4.0-pre1 has been used in both 2003 and 2008 environments.


In this short tutorial we'll set up Kerberos and Apache in a Windows 2003 Active Directory forest. It is required that you know your way around with Debian, Apache configuration and not much more ;)

Initial setup

In this article I'll explore how to set up an Apache web server on a Linux Debian box (squeeze testing as of 05/2009) with kerberos authentication integrated with Active Directory on Windows 2003R2. The domain name that I used for this test is: int.test. Three machines make up this small lab:

  • Domain Controller and Kerberos KDC - Windows Server 2003R2 - (
  • Web Server - Debian Squeeze (as of 05/2009) - (
  • Client1 - Windows XP Professional - (

I'll assume that AD is already set up on and that all the clients and the web server point to it as their DNS server. The first necessary step is to have the DNS zone and the corresponding reverse zone in place:


Once all the DNS business is taken care of (do not forget the reverse PTR pointers), the web server needs to be properly configured, starting with the installation of all the needed packages:

apt-get install apache2-mpm-prefork libapache2-mod-auth-kerb krb5-config krb5-clients krb5-user samba-client openntpd


Let's make sure that the clocks between the webserver and the DC are in sync. Edit /etc/openntpd/ntpd.conf _and verify that there is a single line containing the DC as ntp server: _server Check in /var/log/syslog that the synchronization took place [1] :

May  8 22:46:38 www ntpd[3422]: peer now valid
May  8 22:47:59 www ntpd[3422]: clock is now synced


Once time synchronization is taken care of (Kerberos is very sensible about reliable and synchronized clocks), we need to join the machine to the new Active Directory. First let's configure the underlying kerberos libraries in /etc/krb5.conf:

    default_realm = INT.TEST
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    fcc-mit-ticketflags = true
    default_keytab_name = FILE:/etc/krb5.keytab

    int.test = {
        kdc =
        master_kdc =
        admin_server =
        default_domain = int.test

    .int.test = INT.TEST
    int.test = INT.TEST

If everything is set up correctly, you should be able to authenticate to AD via kerberos:

www:~# kinit Administrator
Password for Administrator@INT.TEST:

Double-check that your TGT is correctly set up:

www:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@INT.TEST

Valid starting     Expires            Service principal
05/08/09 22:57:48  05/09/09 08:57:52  krbtgt/INT.TEST@INT.TEST
renew until 05/09/09 22:57:48


Once Kerberos is in place we'll configure samba. The file _/etc/samba/smb.conf _should contain the following:

netbios name = www
realm = INT.TEST
security = ADS
encrypt passwords = yes
password server =
workgroup = INT

Let's join the domain [2]:

www:~# net ads join -U Administrator
Using short domain name -- INTTEST
Joined 'WWW' to realm 'int.test'`


Now that most of the groundwork is done and the web server joined the AD domain correctly, we need to get the service keys in a keytab to be used by apache. Note that most tutorials suggest to use ktpass.exe on windows. I find this approach much more complex and error-prone (i.e. something like ktpass -princ HTTP/ -mapuser http-linux-server -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass password -out c:\server.keytab then copying the file to the linux box, etc.).

Thanks to samba this can be easier:

www:~# net ads keytab add HTTP -U administrator
Processing principals to add...
Enter administrator's password:

Now in _/etc/krb5.keytab _there are the service principals for HTTP/ In order to verify it you can use the ktutil tool:

www:~# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1   19               HTTP/
2   19               HTTP/
3   19               HTTP/
4   19                        HTTP/www@INT.TEST
5   19                        HTTP/www@INT.TEST
6   19                        HTTP/www@INT.TEST

We also need to give permission to apache to read this keytab file:

www:~# chmod 740 /etc/krb5.keytab
www:~# chgrp www-data /etc/krb5.keytab

It's important to understand that the above solution only makes sense if apache is the only kerberized service. If more than apache is present it makes sense to have separated keytabs with appropriate permissions.


Make sure the mod_auth_kerb module is active with a2enmod auth_kerb.

<Location /secured>
  AuthType Kerberos
  AuthName Kerberos Login
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms INT.TEST
  Krb5KeyTab /etc/krb5.keytab
  require valid-user

Make sure that the relative dir_ secured _exists and that it contains an ad  hoc index.html so we can verify the successful authentication. Once the testing phase is completed, I tipically switch off the KrbMethodK5Passwd option, so users do not get promptet for authentication if for some reason the Kerberos authentication fails.

Set up the client

On the Windows XP Pro client ( we can test this kerberized Apache setup.


Mozilla Firefox is a bit simpler to set up. You need to add the domain int.test to the options network.negotiate-auth.trusted-uris and  network.negotiate-auth.delegation-uris.


Once this is done, we just need to browse to the page where Kerberos authentication is forced:


Internet Explorer 8

Internet Explorer is a little bit more difficult to setup. With this I mean that there are a few more spots where things can go wrong. First you need to go in Tools, Internet Options, Advanced and all the way to the bottom you need to make sure that Enable Integrates Windows Authentication is active (it might require a restart):


You will also need to add *.int.test to the Intranet Zones. (Note that Integrated Windows Authentication does not work on home variants of Microsoft Operating Systems)

Under Tools, *Internet Options, Security, Custom Level *verify that Automatic logon only in Intranet zone is selected.

Once all these steps are taken care of you'll see the same HTML page as Firefox when going to


[1] You should make sure that the Domain Controller that has the PDC Emulator role in your domain synchronizes the time with an NTP box somewhere on the net or via a special time HW device.

[2] If you encounter a GSS error related to Stream modified, it might be due to a bug in the kerberos 1.7beta libs (It's been fixed in beta3)

Dual Head on Debian squeeze

I have finalized my setup at home with two 24" Dell monitors. I bought a Radeon HD4350 at, since it was one of the few ATI dual-head cards passively cooled: 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]

Unfortunately after some time tweaking around and compiling from git sources I was unable to drive both displays with the radeonhd driver or the ati driver. I will try it again later on. For now I've settled with the non-free fglrx driver. Here's my /etc/X11/xorg.conf:

Section "ServerLayout"
        Identifier     "aticonfig Layout"
        Screen      0  "aticonfig-Screen[0]-0" 0 0
        Screen         "aticonfig-Screen[0]-1" LeftOf "aticonfig-Screen[0]-0"

Section "Monitor"
        Identifier   "mon0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"

Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"

Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-1"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"

Section "Device"
        Identifier  "dev0"
        Driver      "radeonhd"
        Option      "monitor-DVI-I_1/digital" "mon0"
        Option      "HPD" "off"
        BusID       "PCI:1:0:0"

Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:1:0:0"

Section "Device"
        Identifier  "aticonfig-Device[0]-1"
        Driver      "fglrx"
        BusID       "PCI:1:0:0"
        Screen      1

Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        Monitor    "aticonfig-Monitor[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24

Section "Screen"
        Identifier "aticonfig-Screen[0]-1"
        Device     "aticonfig-Device[0]-1"
        Monitor    "aticonfig-Monitor[0]-1"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24


These are the steps I use to set up my pbuilder environment. Edit /etc/pbuilderrc :

OTHERMIRROR="deb file:/var/cache/pbuilder/result/ ./"

Create the directory that will contain the built packages:

sudo mkdir /var/cache/pbuilder/result

Create the pbduiler chroot:

sudo pbuilder --create --distribution sid

Build a package:

sudo pbuilder --build foo.dsc

Update the Packages.gz:

dpkg-scanpackages . /dev/null | gzip -9 > Packages.gz
echo "Running pbuilder update..."
su -c "pbuilder --update --basetgz /var/cache/pbuilder/base.tgz"