-
Today, the last piece of the puzzle for roaming laptops in Debian
-Edu finally entered the Debian archive. Today, the new
-libpam-mklocaluser
-package was accepted. Two days ago, two other pieces was accepted
-into unstable. The
-pam-python
-package needed by libpam-mklocaluser, and the
-sssd package
-passed NEW on Monday. In addition, the
-libpam-ccreds
-package we need is in experimental (version 10-4) since Saturday, and
-hopefully will be moved to unstable soon.
-
-
This collection of packages allow for two different setups for
-roaming laptops. The traditional setup would be using libpam-ccreds,
-nscd and libpam-mklocaluser with LDAP or Kerberos authentication,
-which should work out of the box if the configuration changes proposed
-for nscd in BTS report
-#485282 is implemented. The alternative setup is to use sssd with
-libpam-mklocaluser to connect to LDAP or Kerberos and let sssd take
-care of the caching of passwords and group information.
-
-
I have so far been unable to get sssd to work with the LDAP server
-at the University, but suspect the issue is some SSL/GnuTLS related
-problem with the server certificate. I plan to update the Debian
-package to version 1.2, which is scheduled for next week, and hope to
-find time to make sure the next release will include both the
-Debian/Ubuntu specific patches. Upstream is friendly and responsive,
-and I am sure we will find a good solution.
-
-
The idea is to set up the roaming laptops to authenticate using
-LDAP or Kerberos and create a local user with home directory in /home/
-when a usre in LDAP logs in via KDM or GDM for the first time, and
-cache the password for offline checking, as well as caching group
-memberhips and other relevant LDAP information. The
-libpam-mklocaluser package was created to make sure the local home
-directory is in /home/, instead of /site/server/directory/ which would
-be the home directory if pam_mkhomedir was used. To avoid confusion
-with support requests and configuration, we do not want local laptops
-to have users in a path that is used for the same users home directory
-on the home directory servers.
-
-
One annoying problem with gdm is that it do not show the PAM
-message passed to the user from libpam-mklocaluser when the local user
-is created. Instead gdm simply reject the login with some generic
-message. The message is shown in kdm, ssh and login, so I guess it is
-a bug in gdm. Have not investigated if there is some other message
-type that can be used instead to get gdm to also show the message.
-
-
If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
+
+
Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to
+detect Kerberos realm from DNS, by looking for _kerberos TXT entries
+before falling back to the upper case DNS domain name. Will have to
+implement it for Debian Edu. :)