Published on (
 See this if you're having trouble printing code examples

LDAP Server Administration with GOsa

by Alexander Prohorenko
Do you pine for the nice days of Minix-1.1, when men were men and wrote their own device drivers?
--Linus Torvalds, comp.os.minix

While I am not a fan of the various web management systems, sometimes I find them pretty useful and convenient. They have their advantages and disadvantages. For example, drawbacks include:

Advantages include:

Related Reading

LDAP System Administration
By Gerald Carter

Many software products have infrequently used options; for example, if I have initially set the system locale to US, I suppose that I'll rarely change that. Adding the option of changing the locale in the web interface is a low priority. However, not having the option there may lead an administrator to believe that it's not possible to change the locale at all.

The most famous web configuration tools are SWAT and Webmin.

SWAT is the Samba Web Administration Tool. SWAT uses integral Samba components to locate parameters supported by the particular version of Samba. Unlike external tools and utilities, SWAT is always up to date as known Samba parameters change. SWAT provides context-sensitive help for each configuration parameter, directly from man page entries. SWAT has pretty nice documentation, including Using Samba, 2nd Edition.

Webmin is a web-based interface for system administration for Unix systems. Using any browser that supports tables and forms (and Java for the File Manager module), you can set up user accounts, Apache, DNS, file sharing, and so on. Currently it works only on Unix platforms, but the Windows version is already under development. Webmin includes a simple web server to run several CGI programs, which update system files directly. The web server and all CGI programs are written in Perl. Dru Lavigne's FreeBSD Basics has two interesting articles about Webmin, An Introduction to Webmin and An Introduction to Webmin--Part Two.

GOsa (GOnicus System Administrator) is a web administration tool for managing accounts and systems in LDAP databases, written in PHP and licensed under the GNU GPL. The author of GOsa is GONICUS GmbH, a German company. GOsa can manage users, groups, mail distribution lists, thin clients, and faxes. Users can retrieve information about themselves, use LDAP contact and telephone lists, change their passwords, and view fax statistics. Users can also configure their own mail accounts, but their configuration possibilities are limited.

The requirements for GOsa are not trivial, so it's usually not a good fit in a small office, such as one that only uses POP3. I'd suggest you to try Webmin instead. However, if your network uses LDAP and you run more than one service inside, GOsa would be a helpful solution. As for the compatibility list, GOsa provides access to POSIX, shadow, Samba, proxy, fax, pure FTP, and Kerberos accounts. It can also manage the Postfix/Cyrus server combination and can write user-adapted sieve scripts. Actually, it can configure any kind of software that uses LDAP.

To run GOsa, you need at least the following software:

I am not giving links to LDAP or IMAP4 servers—there are many implementations of these protocols, and GOsa does not limit itself to any specific software. On the other hand, GOsa has a better support for an OpenLDAP server and includes specific configuration files for this server, so you may like to use it instead of any other one. GOsa uses Crypt::SmbHash for creating a Samba hash.

Installing this software requires some time and definitely some experience, but it's pretty simple if you have both. I doubt that there is much sense in starting GOsa for your network if you only want to change user mail passwords through the Web. However, if you're already using LDAP services and have more than one system administrator, GOsa can make your work easier.

First download the latest GOsa version, as shown in Figure 1. At the time of this writing, the latest was gosa-2.1.3.tar.gz.

Figure 1
Figure 1. Downloading GOsa. Click on the image for a full-size screenshot.

The previous releases had patches available, but they're already in the new tarball.

Then, untar the downloaded tarball and look in the documentation files. Unlike Webmin and SWAT, GOsa has poor documentation. It comes in two files in the distribution, ./gosa-2.1.3/INSTALL and ./gosa-2.1.3/README. The most interesting one is INSTALL, which explains a typical installation.

First create a temporary (spool) directory for GOsa work files and the configuration directory, as Figure 2 suggests.

Figure 2
Figure 2. Creating GOsa directories. Click on the image for a full-size screenshot.

/var/spool/gosa is a spool directory, nobody and nogroup are a web user and its group, and /etc/gosa is a directory for the configuration files.

The documentation suggests modifying httpd.conf, the Apache configuration file. You can put the GOsa web tool into the VirtualHost part by adding the following:

<VirtualHost localhost:80>
	Alias /gosa /home/white/gosa/html

Restart your web server.

# /usr/local/apache/bin/apachectl restart

Now, you'll be able to access the GOsa web console at http://localhost/gosa/setup.php.

After the first run, GOsa will create its configuration at /etc/gosa/gosa.conf (as long as you remembered to set the correct file permissions there and the file wasn't there previously). setup.php starts checking the system according to GOsa requirements; first it checks the PHP installation for required modules, then it checks the needed programs, and finally, after you provide basic information about your LDAP connection, it checks LDAP connectivity.

The most important parts of the PHP setup are the PHP version and the precompiled support for the IMAP4, LDAP, and GD libraries. If these three pieces are in place, setup.php proceeds further, marking the necessary elements OK or Failed, as appropriate. It marks optional components OK or Ignore. If setup.php can't test all needed elements, you will not be able to proceed.

After this, setup.php looks for a set of helper programs and checks their versions. Among these programs are ImageMagick and fping. Then it proceeds to the initial LDAP configuration, where it checks for the required LDAP schemas. It can also detect Samba versions. If the LDAP configuration is fine, the setup moves to the LDAP tree configuration screen.

On the LDAP tree configuration screen, you must specify the location name and the parameters to access the LDAP server. GOsa always acts as admin and manages access rights internally, and it needs the admin DN and corresponding password for this. (This is the documented workaround until OpenLDAP fully supports directory ACLs.) As an option, setup.php allows you to configure some basic LDAP parameters, including how to create accounts, and to change the locations where GOsa saves people and groups.

When you fill in all the necessary fields, setup.php finishes the process by saving the /etc/gosa/gosa.conf configuration file.

Now GOsa is a simple and a user-friendly web interface for your LDAP server. As far as LDAP is an integrated mechanism that allows the centralized management of access, authorization, and authentification, and the storage of the information, like the users and groups of users and different privileges, GOsa simply makes the LDAP possibilities for system administration needs available with a nicer interface.

Figure 3 shows a sample GOsa web interface screen.

Figure 3
Figure 3. The GOsa interface. Click on the image for a full-size screenshot.

LDAP Customization with GOsa

Now it's time to show how to use GOsa to administer an LDAP database. Many modern MTAs know how to work with LDAP. Let's take Postfix as an example. To enable your Postfix virtual domains to use LDAP, modify your to add the following:

virtualsource_server_host =
virtualsource_server_port = 389
virtualsource_bind = no
virtualsource_timeout = 5
virtualsource_search_base = dc=gonicus,dc=de
virtualsource_query_filter = \ (&(|(mail=%s)(gosaMailAlternateAddress=%s))
virtualsource_result_attribute = uid,gosaMailForwardingAddress
virtualsource_lookup_wildcards = no
virtual_maps = ldap:virtualsource

To make Samba use the LDAP server as data storage, edit your smb.conf configuration file in the [global] section to resemble:

passdb backend = ldapsam:<a href="ldap://localhost">ldap://localhost</a>
ldap suffix = dc=gonicus,dc=de
ldap machine suffix = ou=Computers
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=ldapadmin,dc=gonicus,dc=de
ldap ssl = no

Both examples use the domain name as an example, written as dc=gonicus,dc=de. Change this for your specific setup.

The GOsa distribution includes schema files for the OpenLDAP server in gosa-2.1.3/contrib/openldap/*.schema. They have files for all supported services. There's also a configuration file for the server at gosa-2.1.3/contrib/openldap/slapd.conf. You may need to refer to it while writing your configuration.

At the time of writing, GOsa also has OpenLDAP schemas for the DHCP and DNS services and for Samba and PureFTP. Besides that, GOsa supports the whole range of go products, such as goServer, which includes support for NFS, NTP, LDAP, Syslog, Cups, IMAP, and other protocols. Most of this accounting information lives in the general GOSA schema at gosa-2.1.3/contrib/openldap/gosa.schema.

I'd prefer not to detail the problem of configuring your software for LDAP, there are many articles written on this topic. O'Reilly's LDAP System Administration by Gerald Carter explains how to interconnect your software with LDAP data storage. Craig Hunt's recent Cooking with sendmail shows how to add LDAP support to an existing sendmail configuration.

To use GOsa schemas for OpenLDAP, modify slapd.conf to add includes of the schemas:

include /usr/local/etc/ldap/schema/samba.schema
include /usr/local/etc/ldap/schema/pureftpd.schema
include /usr/local/etc/ldap/schema/gosa.schema

Remember to configure the suffix of your LDAP configuration. By default it is dc=gonicus,dc=de:

suffix "dc=gonicus,dc=de"

Then set the rootdn and rootpw for the system:

rootdn "cn=ldapadmin,dc=gonicus,dc=de"
rootpw {crypt}OuorOLd3VqvC2

The default is ldapadmin with the password tester. Do not leave it the same for your configuration, lest someone unwanted have access to your LDAP server.

The sample OpenLDAP configuration file (gosa-2.1.3/contrib/openldap/slapd.conf) from the GOsa distribution has some access rule sets, which limit changing rights for unauthorized users. This is not necessary for the sample setup, but you should definitely configure them on production servers.

To prepare a basic LDAP setup, refer to the LDIF file included at gosa-2.1.3/contrib/demo.ldif. It creates a basic structure of an LDAP database structure.

Unfortunately, GOsa has not yet finished LDAP server support, so you'll need to use an LDAP client to create or modify the LDAP database structure. I prefer phpLDAPadmin and web2ldap. Both of them are available in the FreeBSD Ports, and they provide hierarchical tree viewers and advanced search functionality, letting you intuitively browse and administer your LDAP directory.

After you've configured your LDAP server, you're ready to configure your services. As I mentioned above, there are a lot of different materials devoted to integrating authentication and authorization schemas with LDAP servers, so I won't cover them here. Most of the supported software has internal support for LDAP, except for the regular Unix (POSIX and shadow) accounts.

To enable LDAP queries for your regular Unix accounts, you need to start from PAM. First you need to install LDAP support for PAM. It's possible through pam_ldap, available from FreeBSD Ports at /usr/ports/security/pam_ldap. The pam_ldap module looks for the ldap.conf configuration file, normally found in /etc or /usr/local/etc. The configuration file is pretty simple:

BASE dc=gonicus,dc=de HOST localhost

BASE is the search base in the LDAP tree and HOST is an IP address or FQDN of the LDAP server.

Next, configure the PAM configuration file, normally found at /etc/pam.conf:

login auth sufficient
login auth sufficient
login auth requisite
login auth  required  try_first_pass
login account required
login password required
login session required

Here's a sample LDAP record (in LDIF) for a user named white:

dn: uid=white,ou=Users,dc=gonicus,dc=de
uid: white 
cn: Alexander E.  Prohorenko
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: uidObject
loginShell: /usr/local/bin/bash
uidNumber: 1001
gidNumber: 20 
homeDirectory: /home/white
gecos: Alexander Prohorenko,,,,

With LDAP support configured in your software and GOsa configuration files added to the LDAP server, you are ready to use GOsa.

Figure 4 shows a regular user administration procedure: browsing the accounts.

Figure 4
Figure 4. Browsing accounts. Click on the image for a full-size screenshot.

Figure 5 shows the modification of an account.

Figure 5
Figure 5. Modifying an account. Click on the image for a full-size screenshot.

As you can see, the process looks pretty easy. It doesn't require any filesystem synchronization or updates. The system processes the changes as soon as you click on OK.

The developers of GOsa also made it possible for everyone to try the possibilities of their system using the demonstration mode on the preinstalled server. Point your browser to and use demo and gosa to log in. You can register a personal account with full write access to data placed in "Department of Your_Login". You can also create subdepartments, users, groups, and so on to test the system.

Security Concerns

At the time of writing, GOsa (version 2.1.3, described in this article) didn't appear in any security bulletins. For safety's sake, I recommend protecting the directory containing GOsa scripts from the outside world. If you look at the Debian package, though, the GOsa directory used for the webroot is /usr/share/gosa/html, so that web users cannot see anything outside of the html directory. The upcoming GOsa 2.3 release uses PHP's secure mode for additional testing.

The first release did have an arbitrary PHP code injection flaw reported on Bugtraq. The second version has been more secure and stable, though.


GOsa appears to be a nice tool to manage different services and system accounts on a multiple servers. If you're already running (or planning to run) an LDAP-configured network, GOsa will save a lot of your time and will increase your productivity.

Alexander Prohorenko is a certified professional, who holds Sun Certified System Administrator and Sun Certified Java Programmer certifications.

Return to

Copyright © 2009 O'Reilly Media, Inc.