Kolab 2.2 and Samba on Ubuntu Hardy
From Kolab wiki
Installation of Kolab 2.2 and Samba on Ubuntu 8.04
Contents |
Abstract
This document describes the installation of Kolab 2.2 on a machine running Ubuntu 8.04 "Hardy". The OpenLDAP data base used by Kolab is used for both POSIX and for Samba authentication on a second machine. All necessary patches, including those for an adjusted SELinux policy (TODO), are presented.
Warning: This document is still incomplete, and not everything has been tested in depth yet! You have been warned!
Introduction
- Machine 1 with IP address 192.168.1.1, will serve as the Internet Gateway. All Kolab components should be installed on this machine. As this machine will be visible from the Internet, SELinux (Security-Enhanced Linux) is highly recommended. E-Mail received on this machine will come from a separate gateway machine running MailScanner. MailScanner uses spamassassin and ClamAV to detect spam and viruses, so no extra spam or virus checkers is needed on machine 1, and should therefore be omitted.
- Machine 2 with IP address 192.168.1.2 will serve as the Intranet Server, running the following services (among others):
- Samba as PDC. All user, group, and workstation data will be stored in Kolab's OpenLDAP data base;
- A DHCP3 daemon to provide IP addresses to all intranet workstations. This information will also be stored in the Kolab OpenLDAP data base;
- radius server (WLan/FIXME)
The local network 192.168.1.0/255.255.255.0 can consist of both Linux and Windows workstations, which will be served by the two servers mentioned above.
Placing the distribution on two separate servers in this way will increase performance, but makes the installations process a little more complicated, since we have to "jump" between the boxes frequently. Please note that all steps within this entire document have to be performed as root.
This wiki article focuses on Kolab-related installation issues. My personal specific tasks like DHCP integration into the Kolab OpenLDAP data base are covered on my personal page. That page also hosts files referred to in this article.
An other source of information about this topic (which also contains some remarks not related to Ubuntu) is at Kolab issue 2997.
Kolab Installation
Note: All steps within this section are to be done on machine 1.
Basic Installation
As recommended in the wiki, Kolab is installed from source, which needs a few packages to be installed in addition to the Kolab sources:
apt-get install make gcc build-essential # use wget to retreive the sources into a suitable folder
Note that it is not necessary to change any permissions as indicated on this wiki page; obmtool doesn't seem to be installed anyway.
On my machine, var is an extra partition, and I want to have all Kolab var files in this partition. Thus, I created the following folders and links:
mkdir /kolab mkdir /var/kolab cd /kolab ln -s /var/kolab var
Now build Kolab as usual and perform the standard configuration:
# cd to the download folder sh install-kolab.sh 2>&1 | tee /root/kolab-install.log /kolab/sbin/kolab_bootstrap -b
In the last step, I skipped the creation of the certificates, as I have a local CA anyway. The certificate and key created using this CA are stored in the folder /opt/kolab-extras/ssl/, so I had to enter the following commands to use them for kolab:
cd /kolab/etc/kolab/ ln -s /opt/kolab-extras/ssl/kolab.pem cert.pem ln -s /opt/kolab-extras/ssl/kolab.key key.pem
I also stored the CA chain file of my local CA as /opt/kolab-extras/ssl/CA-chain.pem. To let the various Kolab components recognise it, add this file name to the following template files (we run kolabconf later, to transfer these settings to the real config files):
- in httpd.conf.template (for Apache) as parameter SSLCACertificateFile;
- in imapd.conf.template (for Cyrus) as parameter tls_ca_file;
- in main.cf.template (for Postfix) as parameter smtpd_tls_CAfile;
- in slapd.conf.template (for OpenLDAP) as parameter TLSCACertificateFile.
Note that you should also install the CA chain on your client boxes, to avoid that they always nag about an unknown or untrusted certificate.
At this point, you can start Kolab by typing
/kolab/bin/openpkg rc all start
and see if the basic configuration is fine. Do not add any Kolab users at this point, as we still have to configure samba and apply some patches!
Language Fixes
If you want to have the Web UI components in any other language than English, remember to install the respective language packs. Also note that Ubuntu installs by default only utf-8 language packs, but kolab and horde rely on ISO 8859 encoding. Thus, locale-gen has to be run to create them. My users are German or Dutch, so I did the following:
apt-get install language-pack-de language-pack-nl for n in de_AT de_BE de_CH de_DE de_LU nl_BE nl_NL ; do locale-gen $n; done
Cracklib Installation
I want to force my users to use secure passwords only. Thus, if you don't care about password security, you may skip this section.
A suitable library to test the strength of passwords is cracklib. It needs word lists to check against dictionaries. Therefore, I installed the English, German and Dutch ones:
apt-get install cracklib2 cracklib2-dev cracklib-runtime wamerican wbritish wdutch wngerman cd /usr/share/dict crack_mkdict american-english british-english dutch ngerman words | crack_packer /var/cache/cracklib/cracklib_dict
The development package cracklib2-dev is only needed if you want to compile your own check application (see below), e.g. if you want to enforce a minimum password length of 8 characters rather than 6 as with the crack_testlib application.
Samba Installation
Many documents explaining the installation of Samba are around, so I present at this point only a brief summary of the steps which were needed to get a working system, including roaming profiles (FIXME: verified yet only on 2k-SP4 and XP-SP3). For more details, in particular have a look at the official Samba Howto.
All Samba related installations take place on machine 2. Basically, you should start by installing the standard samba packages, as well as the PAM and NSS plug-ins for LDAP support:
apt-get install samba samba-doc smbldap-tools libpam-ldap libnss-ldap
You should also install (remember we are on a different machine here!) the Cracklib stuff as described in the cracklib section above.
First, a few words about my general configuration, which you may of course change (see below):
- all regular (not internal) Kolab users shall also have a POSIX and a samba account. This shall be achieved by extending the respective LDAP entries;
- all other information needed by samba (groups, computer accounts, ID map entries and the domain information) shall be stored in extra OU's in the "internal" section, thus hiding them form e.g. address books.
- the home folders, which are also the Samba home drives, shall be stored on the samba server in the unix path /home (roaming home drive for Linux and Windows);
- all accounts get /bin/bash as login shell;
- the roaming profiles are stored in the unix path /home/samba/profiles on the same machine;
- the netlogon stuff is stored in the folder /home/samba/netlogon, again on the same box;
- the LDAP traffic between the two servers is not encrypted which should be fine as long as no user is allowed to log on on any of the two servers and run a packet sniffer. If you are paranoid, you should enable TLS, though.
All configuration files in the next section contain place-holders for several options you will need to set for your installation, as given in the following table:
| Tag | Description | Example |
|---|---|---|
| @@BASE_DN@@ | Base LDAP DN assigned during the Kolab bootstrap process. | dc=my-company,dc=com |
| @@MY_DOMAIN@@ | The Samba Domain name. | MY-COMPANY |
| @@MY_MAIL_DOM@@ | The mail Domain name. | my-company.com |
| @@MY_PDC@@ | The netbios and DNS name of the Primary domain Controller (PDC). Note that the home shares and profiles may of course live on different machines, but then you have to tweak the files further. | UBUNTU-PDC |
| @@MY_HOME_DRIVE@@ | Windows home drive letter. | H: |
| @@MY_LOGON_BAT@@ | Windows logon script name. | logon.bat |
| @@PRI_GROUP@@ | Primary POSIX group number (e.g. 513 which is the Windows "Domain Users" group). | 513 |
| @@EXTRA_GROUPS@@ | Additional POSIX group numbers (comma separated list) of which any new account shall be a member. Leave empty if new accounts shall only be members of the primary group. | 1000,1216 |
| @@MY_NET@@ | The internal network(s) which shall be able to use the Samba server. | 192.168.1.0/255.255.255.0 |
| @@KOLAB_SERVER@@ | The IP address of the kolab server. Use the IP address, not a DNS name, so the system will still work even if DNS is not available. | 192.168.1.1 |
Samba configuration
You can use this file as template for smb.conf. Please note the
check password script = /usr/local/sbin/checkpwd
statement which calls this application as to check the password quality. Compared to the crack_testlib application coming with Cracklib, it has some advantages: it accepts exactly one password, either on stdin or as first argument, it returns a proper return value (0 if the password is acceptable), and is completely silent if the password is fine. Furthermore, you can run tighter checks than the built-in ones of Cracklib; e.g. it accepts only passwords which are at least 8 characters long. You can install it -given you installed the cracklib2-dev package- by typing
gcc -Wall -Werror -O3 checkpwd.c -o checkpwd -lcrack install -m 755 checkpwd /usr/local/sbin/
The application will also be needed by kolab on machine 1. Thus, copy either the source code to that box, and compile and install it there as above, or simply copy the executable to it. Afterwards, you may remove the cracklib development package by typing apt-get purge cracklib2-dev.
FIXME 1: Let Win display a proper dialogue if the pwd has been rejected?
FIXME 2: What about national chars like äöüÄÖÜß? UTF-8? Test Linux/Win behaviour.
Smbldap Tools configuration
The next step is the configuration of the Smbldap Tools. You can use this file, taken from the smbldap-tools package, as template for /etc/smbldap-tools/smbldap.conf. Then create the file /etc/smbldap-tools/smbldap_bind.conf which simply contains
masterDN="cn=manager,cn=internal,@@BASE_DN@@" masterPw="TheSecretManagerPassword"
and make it only root readable as it contains the plain-text manager password.
PAM configuration
The PAM configuration is done for all services using the files /etc/pam.d/common-*. The following works fine for me:
- file common-account:
account required pam_unix.so account sufficient pam_ldap.so
- file common-auth:
auth required pam_env.so auth sufficient pam_unix.so likeauth nullok shadow auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
- file common-password:
password required pam_cracklib.so retry=3 minlen=8 difok=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_ldap.so use_authok use_first_pass password required pam_deny.so
- file common-session:
session required pam_limits.so session required pam_unix.so session optional pam_ldap.so
Finally, you have to configure the PAM LDAP access in the file /etc/ldap.conf. Using this file as template works nicely for me. Note that it is not necessary to have a file named /etc/ldap.secret; it must be present only if you want to use PAM to change a user's password. In this case, it simply contains the manager password.
Note: perfom this step also on all other Linux boxes on which users shall be able to log in using the LDAP accounts. Never place a /etc/ldap.secret file on any workstation.
NSS configuration
Finally, edit the NSS configuration file /etc/nsswitch.conf and make sure that it contains the following lines:
passwd: files ldap shadow: files ldap group: files ldap
Note: perfom this step also on all other Linux boxes on which users shall be able to log in using the LDAP accounts.
Joining Kolab and Samba
At this point, both systems can be joined together after a few more tweaks.
Install additional LDAP Schemas
The Kolab installation lacks the Samba schema file coming with the samba-doc package. Thus, create the folder /opt/kolab-extras/ldap/ on machine 1, copy the file /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz from machine 2 into this new folder on machine 1, and then decompress the file. Of course you may choose a different folder for the schema file, but then you will have to change the file /kolab/etc/kolab/templates/slapd.conf.template (on machine 1) after applying the Kolab patches in the next section.
Kolab Patches
This patch file for Kolab adds the following changes (again on machine 1):
- extend the user.php script to
- add the extra LDAP entries needed for POSIX (Linux) and Samba accounts when a normal (not an internal) user is created;
- update the Samba password if the admin or the user changes the password;
- validate that the password is not a weak one if the user or the admin changes the password. Note that the admin may give a weak password when the user is created;
- remove a user from all secondary POSIX/Samba groups when the account is removed.
- modify the file /kolab/etc/kolab/templates/slapd.conf.template as to include the extra LDAP schemas for samba and DHCP, and to tweak the permissions for the extra stuff;
- add a new template source file named /kolab/etc/kolab/templates/samba.php.template.in containing default values for newly created POSIX and samba accounts;
- add Samba default settings to the file /kolab/etc/kolab/kolab.conf.
In order to apply the patch, store the file somewhere, and run the following commands (the original files will be saved with the extension ".orig"):
cd / patch -b -z .orig -p 0 < /where/you/saved/kolab.diff
You now have to create the file samba.php.template. Note that you have to use the proper value for @sbindir@ (I installed the files in /usr/local/sbin, see the sections about the Cracklib installation and the Windows password support, but you may choose a different folder), @webserver_musr@ and @kolab_grp@:
cd /kolab/etc/kolab/templates sed -e 's;@sysconfdir@;/kolab/etc;g' -e 's;@sbindir@;/usr/local/sbin;g' \ -e 's;@webserver_musr@;kolab;' -e 's;@kolab_grp@;kolab-n;' \ samba.php.template.in > samba.php.template
At this point, you must add a few configuration settings. To this end, edit the file /kolab/etc/kolab/kolab.conf and edit the lines starting with smb_ (see the section about the Samba installation for a description of the placeholders used in this file):
smb_enabled : true smb_pri_group : @@PRI_GROUP@@ smb_homefolder : /home smb_loginshell : /bin/bash smb_extragroups : @@EXTRA_GROUPS@@ smb_homeshare : \\\\@@MY_PDC@@ smb_profileshare : \\\\@@MY_PDC@@\\profiles smb_homedrive : @@MY_HOME_DRIVE@@ smb_logonscript : @@MY_LOGON_BAT@@
Remember that the list of extra groups may be empty if you don't want to add any new user to more than one group by default. You can switch off all Samba features by simply setting smb_enabled to a different value than true.
Now run the command
/kolab/sbin/kolabconf
to add the extra schema files to the LDAP data base. Again, do not add any Kolab users yet, as still the basic Samba entries needs to be configured.
SELinux Patches
TODO
Horde Patches
This patch file for Horde contains two different changes:
- Disable the possibility to change the user password in Horde, as Horde doesn't know about the Samba password. Thus, if a user changed the password in Horde, the old Windows password would still be active, leading to endless confusion. Users must change their password using either the Kolab admin interface, or the Windows client's feature.
This is done by simply commenting out the passwd application in the registry file /kolab/var/kolab/www/horde/config/registry.php. So, if you don't want to have the second tweak below (you don't!), you should better edit this file manually instead of applying the patch file. - As noted above, all incoming mail has already been checked for spam and viruses on an other machine. This machine added header lines reading "X-My-Domain-MailScanner: found to be infected" for viruses and "X-My-Domain-MailScanner-SpamScore: (series of 's' characters)" for spam, respectively. The second part of the patch for /kolab/var/kolab/www/horde/ingo/lib/Script/sieve.php evaluates these two lines and runs the spam rule on matching messages. You will probably not want to apply it, it is included here just to show how easy you could change the behaviour of the system.
Windows Password support
We also need an application which can create hashed Windows passwords. To this end, store this PERL script as /usr/local/sbin/mkntpwd.pl, be sure to make it executable, and install an extra PERL library for it on machine 1:
chmod 755 /usr/local/sbin/mkntpwd.pl apt-get install libcrypt-smbhash-perl
Standard Samba LDAP Entries
After all the setup above, you should now initialise the standard Samba entries in the LDAP data base. To this end, go to machine 2 and run the command
smbldap-populate -b guest -l 65534 -a myadmin
Note that the extra options set the guest account to the name guest with POSIX user ID 65534, and the name of the administrative (root privileges) account to myadmin. You may use other names for these accounts, but you should avoid admin or nobody in order to avoid any confusion with Kolab objects. Note that by default the minimum UNIX user and group ID for new accounts will be both 1000. For more options, see the documentation of this command.
FIXME: I cannot set the password of this account from the script? Why? I have to run smbpasswd myadmin manually.
For security reasons, it is a good idea to grant the rights for the administration of the Samba stuff to all users in the Domain Admins Windows group, and then either remove the admin user created in the last step completely, or map it to different User and Group ID's. Furthermore, I want to have both the admin and the guest user in the internal section, so it is not displayed in the global address book.
Using the following command you can list the rights the admin user has:
net rpc rights list -U myadmin
Now assign these rights to the Domian Admins group, and check for success (note: adjust the list of privileges to those the command above printed):
net rpc rights grant "@@MY_DOMAIN@@\Domain Admins" SeMachineAccountPrivilege \
SeTakeOwnershipPrivilege SeBackupPrivilege SeRestorePrivilege SeRemoteShutdownPrivilege \
SePrintOperatorPrivilege SeAddUsersPrivilege SeDiskOperatorPrivilege -U myadmin
net rpc rights list "@@MY_DOMAIN@@\Domain Admins" -U myadmin
Modifying the LDAP entries is a little tricky, so I wrote this simple shell script for it. It will
- shift the admin user to POSIX UID 65533 and GID 65534, respectively;
- set the login shell of the admin and the guest user to /bin/false;
- set the home folder of the admin and the guest user to /dev/null and
- move the admin and the guest user to the internal section.
As to run the script, save it to disk and then say (replace myadmin guest with the uid's you used)
cd /where/you/saved/the/script chmod 755 modadmin.sh ./modadmin.sh <manager password> myadmin guest getent passwd myadmin guest
The last command will print out the confirmation of the shift.
At this point, you will have the following structure in the LDAP tree (additional entries in bold):
- dc=mycompany,dc=com
- cn=internal
- ou=SmbComputers
- Workstation Accounts go here
- ou=SmbGroups
- POSIX/Samba Groups go here
- ou=SmbIdmap
- Samba ID Map Entries go here
- SambaDomainName=MY-COMPANY (ID pool etc.)
- uid=guest
- uid=myadmin
- ou=SmbComputers
- cn=internal
Note that while new accounts are still placed there Kolab puts them, all other Samba-related stuff (groups, wrokstations, etc.) will be "hidden" in sub-OU's in the internal section.
Install the LDAP Account manager
The Kolab management interface of course does not have support for the extra Samba and POSIX account features. A nice application to manage these LDAP objects is the LDAP Account manager (LAM). As it also builds (like the Kolab administration tool) on Apache and PHP, it should be installed on machine 2 as to avoid any clashes with the Kolab packages. On Ubuntu, simply say
apt-get install ldap-account-manager
which will install LAM and all its (many) dependencies. The configuration is rather simple. However, you should in particular change the range of user and group ID's LAM will use to match the minimum values smbldap-tools use (see the section about standard Samba LDAP entries). You could now start e.g. adding more POSIX/Windows groups.
Adjust the settings to your needs
At this point, you should again review all the template files which have been installed, in particular /kolab/etc/kolab/samba.php and /kolab/etc/kolab/kolab.conf, and check if they really contain what you want. E.g. before adding users, you might want to add groups (POSIX/Windows, not Kolab groups) using LAM, and add all newly created users to one or more extra groups.
Note that you must create all groups, both primary and extra, you defined above as defaults for users. Otherwise, the attempt to add a new user will fail.
Using Kolab and Samba
Using the patches above, Kolab will now create the extra Samba LDAP objects only for each regular user. However, it is possible to create all kinds of accouns by modifying them:
- Regular user with Samba account: simply create it;
- Regular user without Samba account: create it as internal user, and then modify it to become a regular account;
- Internal user with Samba account: create it as regular user, and then modify it to become an internal account;
- Internal user without Samba account: simply create it.
Of course, when adding a user with a POSIX/Samba account, you still have to create the home folder manually. Do not create profile folders manually, as this might break Windows security checks (i.e. roaming profiles will simply not work).
You can add Windows workstations by joining them to the domain as usual (myadmin is the account which has the sufficient privileges). The accounts will of course be stored in the LDAP data base.
