Integrating OpenLDAP

This document provides information regarding the state of various open source products with regard to building an enterprise directory services/security infrastructure. It will provide specific examples of how this integration can be accomplished as well as pros and cons of specific open source tools and their impact on the overall design and architecture of the solution. It is intended as a guideline and information source for those looking to build an enterprise solution based on available FOSS technologies and offerings.


Having built out a number of enterprise directory services solutions with my most recent experiences leveraging FOSS tools and technologies, I have been both impressed with the state of the technologies and the stability and flexibility of the current offerings from the FOSS community and also disappointed at the general lack of documentation with regard to developing the fully integrated solution. While each of the products and solutions, generally, provide adequate to good documentation of their specific product and the general community provides reasonable documentation of implementation (How-To) and configuration of each or a couple of the components of the solution, the author has not been able to find a comprehensive source for information regarding the integration and design of enterprise solution.

As the author has spent a significant amount of time working with the design and integration of just such a system, it seems reasonable and logical that this information from recent implementations be captured and provided back to the community in order to hopefully ease the implementation and adoption of this very viable platform and solution for others and to also lower the cost of implementation and raise the awareness of the potential for leveraging FOSS in the design and implementation of an enterprise directory service infrastructure.

What to Expect

It is surprising both how easy it has been to build out several infrastructures with purely open source tools and software, and also the general lack of documentation around the integration process. While a general lack of comprehensive documentation has become the general expectation of the author, it is none-the-less surprising that comprehensive documentation seems to be non-existent. That is, while most of the products that have been integrated have some (or at least widely varying degrees and quality of) documentation with regard to integrating with an enterprise directory solution, the process of building out the entire set of products and ensuring seamless integration of the suite of tools does not seem to exist. However, the good news is that with some direction, design, and forethought, the process of integration can be accomplished and in the opinion of the author, the finished solution rivals that of commercial or off the shelf software with regard to simplicity of integration, manageability of the solution, stability, reliability, and scalability. This is extremely encouraging and in the authors opinion indicates a relative shift in how the enterprise should view and manage these assets.

With regard to the process and initial design, most of the products that can be integrated have some documentation and some time can be spent with Google to find others that have documented their design and implementation with regard to a specific tool or potentially a couple of the tools. However, the author spent significant time in investigating and revising his design and the intention of this document is hopefully reduce the overall investment (in time) required for those looking to build out a secure, robust, integrated enterprise security/directory solution and thus to encourage further deployment and use of the assets being developed by the open source community.

With that being said, let's get to the details and enumerate what components are available and have been successfully integrated in order to begin assessing the potential design, re-design, or integration of your existing infrastructure. I will begin by providing a set of capabilities that have been integrated and then proceed to a discussion of various tools and specific solutions that provide those capabilities.

In general, the purpose of providing an integrated directory solution is to reduce the cost of maintaining a secure infrastructure. This itself comes at a cost (as do most architectural decisions, there is not necessarily a "right" and "wrong" answer, but instead, the architect must weigh the various decision points within the framework of their requirements and constraints), which in the authors opinion is primarily one of the overall "secureness" of the solution. That is, better security is generally more "inconvenient" and thus as the overall "secureness" of a system increases, the cost of that solution also increases. This will not be discussed at length in this document, as it is both the subject of another document by this author, as well as the author has found at least one freely available and excellently written discourse on this subject that you should consult if this is important to your considerations. However, given this consideration, the goal of an enterprise directory is generally to reduce the cost of maintaining an enterprise security infrastructure and secondarily to reduce the impact of such a system on the users of the system to the extent this is possible while still maintaining the required level of security. To that end, the general consideration for implementation of an enterprise directory is to simplify the management of user information and specifically to centralize and standardize the management and consumption of user authentication information for the enterprise.

To this end, the following general enterprise access and security tools should be considered when designing, building, or integrating an security infrastructure:

  • External user access to the infrastructure (VPN)
  • General user communication (EMail)
  • Secure access to general network resources (File shares, printers, etc)
  • Securing access to the network infrastructure (802.1x, WPA)
  • Securing shell or direct server access (SSH, Remote Desktop)
  • Securing access to corporate information stores (Database)
  • Securing access to network infrastructure components (Routers, Switches)

With the exception of one component listed above, the database, the author has successfully built a number of integrated infrastructures using open source tools. Some components of the solution are relatively easy and others required considerable time and effort to understand and integrate. The following sections will provide further details with regard to specific choices of tools and their impact on the overall integration effort as well as providing at least two examples of existing integrated infrastructures with details of product and tool configuration to include example configuration files. For a number of the components, the author has had to do some minor customization primarily to the directory schema in order to accomplish the integration and these customizations will also be documented in detail such that by using this document as a blueprint, the reader should be able to accomplish the integration of an identical set of infrastructure with identical requirements and constraints to the author; however, given the low probability that your requirements and constraints will be the same as the author, it is highly probable that you will require deviation from this information, but it is the hope of the author that this information will provide you with enough information and a wide enough base that your integration efforts will be facilitated through the use of this information.

In short, it was to the surprise of the author that a relatively secure infrastructure could be (relatively) easily constructed from primarily open source tools! I have been both impressed and assured that open source is a viable option for the enterprise and that the quality of solutions and components developed by the open source community is at least on par with that of commercial efforts, if not occasionally superior. The only shortcoming of the OSS community, in the authors opinion, is the general and (generally) significant lack of good documentation. Thus, while the author considers himself a decent developer/coder and a reasonably competent architect, he has instead chosen to contribute to the OSS community not through implementation, development, or contribution through writing code, but rather through attempting to address this documentation shortfall.


Before we dive into the details of the choices of product, tools, configuration, and the overall integration, it is important that we take a moment to address, at least at a conceptual level, the key requirements that drove the trade-offs that resulted in the documented architecture and design as implemented and detailed. A detailed discussion of the requirements is most likely not germane or relevant to this document; however, there are a number of key requirements that if not understood by the reader may result in confusion as to the reason the author choose one solution path over another. Again, as stated earlier, in architecture and design, the author feels that in the general case there is seldom a clear "right" or "wrong" technology or solution, and even in the light of relevant and specific requirements there is often not a clear "right" or "wrong" answer, but rather the architect, engineer, or designer must weigh the various key aspects of the decision in context with the specific circumstances of the implementation. Thus, again, in the authors opinion, the key skill of the architect or design is in surveying the landscape of a particular circumstance and quickly discerning the key decision points that bear upon the question at hand and then objectively weighing the solutions or proposed solutions within the context of those questions and against the framework of the requirements. To that end, let's enumerate some of the (potentially arbitrary) requirements that drove the documented solutions:

  1. To the extent possible, use free open source software (FOSS)
  2. When FOSS is not available, use OSS
  3. When OSS is not available, use free (no acquisition cost) software
  4. The solution must support a wide user base to include both FOSS (Linux) and non-FOSS (Windows) clients

These were the primary requirements imposed by the author. The reasons for these are varied and will not necessarily be discussed in detail; however, just for the sake of curiosity, let's assume tat at least on the outset, the author had an interest in assessing the state of open source software development and a curiosity as to whether a solution could be implemented given the requirement that to the extent possible FOSS be used in the implementation. It is not possible (at least in the authors perspective) to construct a "completely" free solution, as various hardware and physical components (servers, routers, switches, etc.) generally require some cost. To this extent, the hardware components used are generally the result of existing purchases and these components were not "chosen" so much as they were constraints (use what you have and do the best at integrating with those constraints, rather than replacing).

To this extent, this document will probably not directly provide you with guidance on hardware or infrastructure components, but rather will focus on components of the solution that facilitate integration with hardware in general and thus the implementor can be knoledgable of the constraints and potential integration scenarios provided by the software and use this to guide hardware or purchasing decisions if there is no existing hardware or hardware must be purchased in order to provide a solution.

Point Solutions

This section will provide information regarding the specific products used for integration and well as providing additional options that may be of interest, but that will not be detailed (at least) in this document.

  • OpenLDAP
  • FreeRadius
  • OpenCA
  • PHP LDAP Admin (phpldapadmin)
  • Eclipse (LDAP directory management)

In addition to the infrastructure components listed above, the following products have been integrated into the solution and their integration will be discussed in detail:

  • OpenSSH
  • Apache HTTP
  • Subversion
  • DBMail
  • Postfix
  • QMail
  • Cisco VPN (PIX)
  • Samba

As you are probably aware, a number of the products above provide general user services, but for sake of completeness and for those not familiar with some of the products, the following capabilities are provided by the discussed infrastructure (and can be secured through the directory) and provide a more general basis for discussion of enterprise integration, enterprise directories, and SSO (Single Sign On):

  • EMail (IMAP, SMTP)
  • VPN (secure remote access)
  • WPA/802.1x (Wireless and wired secure access)
  • SSH (shell access)
  • File and Printer sharing
  • Radius
  • Source Code Management (SCM)
  • HTTP (Web Server)

While the author has been impressed with the FOSS community with regards to the ability to build a truly enterprise class infrastructure from mostly FOSS components, there is one glaring and significant hole that remains which to a greater or lesser extent may have an impact in a given environment, and that is the limitation of a FOSS database that can be integrated into the solution. That is, a FOSS that can leverage a directory for AA (Authentication and Authorization) services. MySQL cannot (at least to the authors knowledge) be integrated to use LDAP. The author is aware that most COTS databases on the market can leverage LDAP for AA services and that most enterprise organizations will probably already own and be using one of these solutions. In this case, the integration of the database should be (relatively) easily accomplished; however, if you are hoping to leverage FOSS databases (at least MySQL) into the solution, I fear we still have a way to go in that respect. The author would welcome indications to the contrary, but has invested a significant amount of time into research of this issue specifically with regard to MySQL as well as a cursory review of options for other FOSS DBM (Database Management) solutions such as Postgres. More information will be provided in the following sections on this limitation and potential alternative solutions.

Capabilities Overview

Since we enumerated a number of capabilities above in this section, we will review each of these capabilities and discuss the specific components that support these capabilities. Additionally, as these capabilities are focused on user services, this section will add the infrastructure services/capabilities that support the user or outward facing capabilities that we require.

Infrastructure Services

This section describes the services, that while not directly "visible" to the users of the infrastructure, they provide the basis of the services that allow integration and simplify the user's experience either through SSO or through consolidation of user authentication information (single repository for user credentials).

Directory Services

Tool: OpenLDAP

It would seem obvious that before one can integrate an infrastructure or set of tools, there must be something to facilitate this integration. While there have been a number of different designs, architectures, and solutions developed over the years to address this specific requirement, it seems the industry and in the authors opinion, the best solution to meet this requirement is an enterprise directory. Additionally, as there are various tools and designs with regard to enterprise directories, the one solution that seems most ubiquitous and most widely supported is LDAP. Additionally, there are a number of potential solutions, even with regard to LDAP; however, the author has gravitated toward and prefers the use of OpenLDAP as the basis his integration efforts; however, it should also be noted that the author recognizes that there is at least one other viable solution that meets the general requirements and when possible, these additional options will be noted. However, as the directory is the foci of the integration effort, a deviation in the choice of the basis for the integration is likely to result in a requirement for more significant deviation from the direction and guidance presented in this document; however, in the general case, the reader should still find relevance, even with regard to specific configuration, thanks to the "standardization" of most directories and tools around the LDAP "standard".

The author is aware of at least one other FOSS directory that may be of interest, which is the Apache directory project. As you will see below, the author has leveraged some of the components of this project for the management of the solution, even though OpenLDAP was used as the directory rather than Apache directory.

Infrastructure Security

Tool: FreeRadius

While LDAP and support for LDAP is relatively ubiquitous in the "applications/user" world, there has been a need for consolidated AA services for the infrastructure for just as long. Unfortunately, this has also meant that services and protocols for standardization of these components has occurred tangentially to more user focused services. To this end, a number of standard services have been created that while they do not (easily) directly integrate with LDAP, the use of an integration layer, such as FreeRadius allows us to integrate these services into the directory. To this end, this architecture leverages FreeRadius to provide a number of services, but uses OpenLDAP as the user store for consolidation of credentials. This document will provide a configuration and examples for FreeRadius that demonstrate how to leverage OpenLDAP on the backend and provide services for securing the following:

  • Wireless access through WPA
  • VPN access through Radius (Cisco VPN Client to Cisco PIX)
  • Securing Cisco (PIX) through Radius AAA
  • Securing other network devices (Switches, Routers, etc.)
  • Port based AAA using 802.1x (wired and wireless)

One optional component that will be discussed within the context of infrastructure security is certificate based authentication. The viability of certificates for various authentication methods will not be covered as it is very well documented; however, depending upon a given organizations needs or based on needs of varying components of the infrastructure, the author finds it useful to occasionally leverage aspects of certificate based authentication and services. The inclusion and consideration of these services in the overall directory design and implementation has the potential to enable more viable scenarios for certificates than in scenarios where these services are not consolidated into the directory. For this reason, the architect or implementor of the infrastructure may want to consider inclusion of these services within your directory implementation. For this reason, this document will provide some guidance and lessons learned for those desiring to understand the potential benefits and drawbacks of the specific implementation tools that are available for facilitation of certificate services.

Server Security

Securing the server assets from access requires a number of components; however, from the core infrastructure services point of view, the primary mechanism leveraged in this solution is PAM and NSS through LDAP. This provides user login AA services to Linux through our consolidated directory services. Remote access to these servers also employs the additional component of SSH and will be discussed further in the user services section. One additional infrastructure component that is not necessarily required, but that can enhance the security of the solution is the inclusion of certificate services into this component of the solution. More information can be found in previous section as to the relevance and greater detail will be provided in subsequent sections.

Management Tools

While many organizations invest significant effort into the selection of infrastructure components, many often fail to factor in the significance of the management tools that enable the organization to effectively change (manage) the required infrastructure. That is, there should be at least two primary areas of focus when selecting a tool or set of tools. The first and primary focus of this document, is how do the tools work. By that, it is meant, the general operation and facilitation of those components in the absence of "change". Once we have the tools, installed, configured, and (depending on the size and nature of our user base) the users entered, how do the component perform; however, another component that should be a key decision point, that will vary significantly from organization to organization or implementation to implementation, is the ability to "change" the tools. That is, how easy/hard is it to add users? What is the maturity level of the management tools.

Management tools are often left as an afterthought to the actual components themselves; however, if the management tools do not fit the constraints of the organization or the process/procedures required by a given industry (banking for instance), then the issues of managing the infrastructure could preclude the use of a better infrastructure component for an inferior component based solely on the organization or administrators ability to "change" the system. For this reason, this document will provide some background regarding the availability, high level features, and viability of a number of tools that have been used by the author. Some of these tools, while not chosen by the author for various reasons might be more suitable for another organization or set of requirements. To the extent possible, this document will attempt to enumerate the options as seen by the author.

User Services

While the infrastructure services provide the core required to enable the user services, without the integration of tools and components directly leveraged by the users, it can be significantly argued that the infrastructure is of no value. That is, the enablement of the users in a more secure environment is the fundamental objective of this exercise. To this end, this section enumerates the user services that are integrated into and enabled by the infrastructure services presented in the previous section.

EMail Services

One fundamental component leveraged by any organization encountered recently by the author is email. Therefore, of significant interest in implementing any infrastructure relating to security is it's ability to integrate various email services. Most integrators would require that at a minimum, the user "directory", that is the list of available users (mail boxes) and the means of contacting those individuals (their addresses, email, phone, "snail mail", etc) should be consolidated into the directory in addition to their access credentials (AA).

The design and architecture of email systems is almost, if not more complex than the integration and use of directory services. For this reason, this document will not focus on the pros and cons of various email systems and architectures, but will rather focus on limited number of potential email architectures and how the means of integrating those architectures into the directory and security architecture. The author will leave the discussion of "good" vs. "bad" and "secure" vs. "more secure" (or "not secure") to other authors and sources.

Specifically, this document will describe how to integrate postfix, DBMail, and QMail into the directory as well as present what the author believes is a more "sophisticated", secure, and "enterprise" solution using a combination of these products to provide various services within the infrastructure at various locations in the infrastructure (DMZ vs. Secured network). The author believes that any solution should provide the following services to the user:

  • The ability to send and receive emails from within the secure corporate infrastructure to any (internet) address
  • The ability of a user to access their email (securely) while outside the corporate infrastructure
  • The consolidation of the users (AA) credentials into the directory
  • The consolidation of the "user directory" (emails and contact information) into the directory services (LDAP)

In order to provide these services to the user, the author proposes the following "lower level" services generally need to be provided:

  • IMAP (User access to mailboxes)
  • SMTP in the DMZ (mail relay for contact outside of the corporate infrastructure)
  • SMTP in the corporate infrastructure (for sending users mail)

Additional components may be required depending on the specific requirements of your organization or required level of security. A number of these additional components will be discussed such as providing web access to email. Greater detail will also be provided regarding the architecture leveraged by the author and the implementation of the various components such as the mail relay and the user mail store.

File and Print Services

After or potentially in line with the significance of email services, the availability and integration of file and print services into the directory is probably the next most significant concern from a user perspective. That is, the ability of the user to access file shares and printers through SSO (optimally) or at least with a single (shared, but less optimal than SSO) set of credentials. In the sprit of FOSS, the author will provide a solution using Samba as the basis for file and print services for use by both Linux and Windows users within the infrastructure.

Remote Access

Remote access can take many forms and can be leveraged for a number of purposes within the infrastructure; for these reasons, it is critical that any potential solution be able to leverage a number of remote access strategies in order to be flexible enough to provide the users with a convenient or at least viable infrastructure. A number of key aspects of remote access should probably be addressed and should include:

  • VPN access
  • Remote shell (command line access, primarily for servers and generally Linux or Unix servers)
  • Remote desktop (primarily used for Windows servers, but can be used for XWindow/*nix)

The potential combinations and permutations of various aspects of remote access and their place within the infrastructure is well beyond the scope of this document; however, the author will present a number of components that have been used as well as their configuration and integration into the overall solution. Specifically, the capability to enable SSH and SSH AA within the solution is critical in order to be able to securely manage the solution defined in this document. Additionally, the capability to leverage VPN within a given architecture provides a potential solution a number of critical capabilities such as (secure) remote access to email and the ability to enable remote desktop access are two capabilities that can be facilitated integration of VPN into the enterprise directory.

The case of remote desktop, while enumerated above is really a special case in that it is enabled through a combination of capabilities and is not necessarily (directly) integrated into the directory. That is, while AA and VPN might be used to enable secure access to a remote desktop, the enabling technologies would likely be VPN (or Radius) and AA provided by PAM/NSS integration with LDAP (in the case of X Window/*nix), rather than any direct access of the directory by RDP (in the case of Windows).

Other Services

While the services enumerated above constitute, generally, the most readily apparent and direct use of the directory solution with regards to impact on the user community, there are a number of other services enabled by the integrated directory that have either a less direct or indirect impact on the users. That is not to say that these services are any less important, as they may be more important, but generally, the user's interaction with the directory is less apparent. Such is the case with line of business applications that requires secured access. While the user is primarily interacting with the LOB application, the AA services of the LOB application are (or can be) provided by the directory. Such integration can be enabled through technologies or tools such as Apache, which can integrate AA services into the directory or through a custom LOB that has been designed and implemented to leverage LDAP as it's authentication method.

One such solution that can leverage AA services is Subversion, which can be used for source code management within the development environment. Another solution, which can heavily leverage Apache's AA services to the directory is Trak, which is used by development organizations for (defect) request tracking. These are just two examples of other integrations that are possible once the enterprise directory is in place. This document will specifically provide details around integration of Apache into the directory for facilitation of AA services.

Design Overview

This section provides a brief overview of the completed system in order to facilitate the detailed discussion and presentation of the configuration required to implement and integrate the solution. In short, the infrastructure is designed around three security "zones".

  • The Internet or unsecured zone
  • The DMZ or limited security zone
  • The corporate network or the secure zone

This model should be familiar to anyone that has experience with infrastructure and presents what the author believes to be the minimum in order to begin to construct a secure infrastructure. By the same token, the three zones can be thought of as "untrusted" the Internet, "limited trust" the DMZ, and "fully trusted" the corporate network. Information can feely flow from a zone of greater trust to one of lesser trust (within the framework of this discussion and model; however, in actual implementation, the enterprise should also be concerned with the nature and potential of information leakage whether intentional or unintentional from the corporate network, but for now, the author chooses to ignore this aspect). However, in order for information to flow from a less secure/trusted zone to a more secure one, some form of authentication and authorization (AA) must occur.

If you're primary concern is only with regard to assets within the corporate network, then you might be able to ignore this aspect of the design; however, it is quite common and required by most organizations to enable secure access to assets from the internet. The primary example is the traveling worker (say a salesman) that is infrequently in the office, but must have access to corporate assets, such as their corporate email inbox or a corporate LOB application for access to product availability and pricing information.

Additionally, the requirement to be able to send and receive email from other organizations outside the corporate infrastructure is often enough to justify at least three trust zones within an organization. However, while we invest time in understanding and enabling this access, the majority of the services and integration provided by this document is focused on access to assets from within the corporate or trusted zone.

Network Overview

Without getting too detailed or focused on the network architecture, it is probably critical to provide a logical overview of the layout of the typical network and explain the various services provided in each of the "zones". For the context of this discussion, "zone" will mean collection of assets to be managed at the same or similar level of trust/security. This will probably become more clear as you read through the following three brief sections. For the sake of clarity, the reader could also assume (simply ) that each zone represents a separate "section" (sub-net or separate private networks) that requires routing from one to the other. Additionally, each zone will have something between it and the other zones that enables this "routing" and also can control access in some way (specifically, this is a firewall in the case of the networks designed and implemented by the author).

The Unsecured Zone

While this document and the requirements/parameters of this solution do not explicitly require (direct) deployment of assets to this zone, there is at least one component that provides the interface between the Internet and the DMZ, which is the corporate firewall. Scenarios will be presented that allow the integration of this firewall into the directory service in order to provide AA services for infrastructure maintainers accessing and making changes to this device, assuming that the device meets some requirements. The author has specifically leveraged Cisco appliances (primarily PIX) and provided various integrations between these devices and the directory through the Radius protocol.


A number of assets can, should, and probably will be deployed into this zone that will require integration into the directory services. The author has designed his mail services such that he has deployed an SMTP mail relay into the DMZ to facilitate email communication with other hosts and organizations on the Internet. Additionally, it is frequently desirable to deploy HTTP services to the DMZ for various reasons. Additionally, access to these HTTP services often require AA services that may or may not need to be integrated into the corporate directory services (there are various pros/cons, depending on the type/class of user requiring AA services, such as a corporate employee vs. a customer).

Additionally, the organization will want to ensure that access (programmatic, at least, as physical access and security is beyond the scope of this document) to the servers deployed into this environment is secured. There are both pros and cons to integrating the AA services for these assets into the corporate directory; however, the author will leave this well documented discussion to others and will provide direction on one approach to integrating those services into the directory for those that choose to do so.

The Secured Zone

Between the DMZ and the secured zone lies (either logically or physically) another firewall in order to control ingress and (hopefully) egress from the corporate network.

The bulk of the corporate assets (including informational or online assets) probably reside in the secure zone otherwise known as "on the corporate network". This is also (usually) the zone where the corporate users are "located" or connected. For this reason, the bulk of the services provided reside in this zone as well as most of the activity to and from the directory is in this zone. The author chooses to locate (to the extent possible and depending on the nature of the information) information stores in this zone. That is, the following general assets reside in this zone:

  • The user mail store
  • The directory "store"
  • LOB application databases

The majority of the services discussed in this document are also deployed into this zone. While services may be (securely) access from the DMZ, the services provided are hosted in the corporate security zone.

Directory Design

There are a number of aspects to the design of the directory that should be considered. For the purposes of this document, the directory is relatively simple. That is, the directory is only hosted in a single physical location. There is not a need to have a distributed directory, such that part of the directory was on the east coast, while another part of the directory is deployed in Asia. For the purposes of integration of services, this can have an impact on overall directory design; however, the discussion of distributed directory design and implementation is well outside the intended scope of this document. That is not to say that if such a requirement arises that this document becomes of little value, but rather that the detailed configuration and discussion presented focus on a consolidated directory design rather than a distributed design.

Directory Implementation

While it is highly recommended that to the extent possible, you provide as much fault tolerance as you can afford (both capital costs as well as time), it is especially critical that you provide for fault-tolerance in the deployment of your directory services. While a detailed discussion of fault-tolerance and disaster recovery are beyond the scope of this document, the author encourages the reader to implement a master/slave design when installing the directory services. Further, these installations should be on separate physical servers (it is not a generally accepted practice to have two logical installations or VMs on the same physical sever, although this would be better than a single instance).

Directory Structure

There are probably as many opinions on "correct" directory structure as there are grains of sand on the beach. As such, I have tried a number of them and while there are many pros and cons, the one presented here is essentially just what I have come to through trial and error. There are some decisions that will limit your options and there are others that will provide you with greater flexibility with regard to specific tool choices. As we navigate through the "how-to" sections of this document, I will try to point these out to the best of my ability.

There are a few items that I would like to point out that are potential issues to be avoided as well as presenting my current directory structure and also present what I have settled on as my preferred directory structure which you are welcome to use or discard at your discretion.

What follows is the high level directory structure that I currently use as my preferred template and as I undertake new integration projects, I tend to favor this template, unless requirements dictate otherwise (split directory, etc.):

  • Root DN
    • ou=People
    • ou=Groups
    • ou=Computers

The directory structure use in most of the config files used for this document use the following structure:

  • Root DN = dc=hendrix,dc=local
    • ou=Users
    • ou=Groups
    • ou=Computers

You will probably find more books and documentation on directory structure that you will any other topic relating to enterprise directories and my suggestion is to invest some time in researching the subject then pick one that seems to suit your liking and then stick with it...

Object Classes
This section will undergo significant expansion before publication and its current state is very preliminary

Part of the challenges with implementing an enterprise directory is ensuring proper segmentation of roles and authorization for differing users. Some of these requirements can be satisfied through the use of groups for role based access; however, this is not always possible due to the limitation of the applications using the directory. For this reason, the author tends to also use various LDAP Object Classes to enable and control authorization for specific services that use the directory. This is one specific area that the author has been unable to find good information on the Internet regarding and thus seems to be one area that deserves greater attention in this document. This section provides an overview of the various object classes used by each application and some of the challenges encountered with integrating a significant number of services into the directory that are not easily managed through group permissions/roles.

The following key object classes will be further discussed in this section:

  • account
  • dbmailUser
  • ldapPublicKey
  • posixAccount
  • postfixUser
  • radiusprofile
  • sambaSamAccount
  • shadowAccount
Object Attributes
This section will undergo significant expansion before publication and its current state is very preliminary

While applying the appropriate object classes to entries within the directory is important, the primary purpose of applying object classes is to ensure that the appropriate object attributes are available so that users can be appropriately configured and authorization and access can be controlled.

The following are the key attributes that are used within the document:

  • cn
  • gidNumber
  • homeDirectory
  • mail
  • sambaSID
  • sshPublicKey
  • uid
  • uidNumber
  • clientCertPrint
  • dbmailGID
  • dbmailUID
  • dialupAccess
  • loginShell
  • mailAlternateAddress
  • radiusServiceType
  • sambaLMPassword
  • sambaNTPassword
  • sambaPrimaryGroupSID
  • userPassword

There are a few recommendations that I will make with regard to your directory and this section contains those suggestions.

My first recommendation is in regards to whether you should include the "root" user in the directory. While there are security concerns on both sides, my recommendation is not to include the root user in your directory. The reason is that while I have tried it both ways, I have had issues when I put the root user in the directory and removed the user from the local user/password files. That is, when the machine was unable to contact the directory (it happens, especially when initially installing, configuring and integrating), you are unable to log into the machine. By leaving the root user on the local machine, you should always be able to log into the console with the locally defined root user. This also allows you to define a different root password on each server which should enhance your security. Additionally, if the root user is in the directory and someone "cracks" the user, they would most likely have root access to every machine in your network (while if they crack the root on just one machine, they probably will still be able to obtain root access to other machines, but not quite so easily).

As I continue to work through my documentation of integration, I will most likely remember other issues and suggestions and will continue to update this section as these thoughts and issues come up.


Well, we are finally here, or if you skipped the previous section, which is also OK, welcome! If you did skip the previous sections and something doesn't seem to make sense, it may be beneficial to go back and review the relevant section above as it is focused more on the "why" whereas, this section of the document is focused on "how". Notice I didn't say "the how", but rather "how", that is, this is but one way to about the task, as the author has been able to accomplish. As such, I will provide an approach that makes sense to me and hopefully it will either make sense to you or you will be able to use it as a basis and develop a way that make sense to you but not require the investment of time, pain, and frustration (or at least not as much as I have) along the way.

Each of the following sections will provide a building block within which the system is taken through a complete integration. That is, with the exception of the first section, which would be required by any of the following sections, each section should stand alone and once you have completed working through a section, you should have a working system that has an additional component integrated into the whole. This has been the approach taken by the author and with minor exceptions, has required very little rework as additional integrations were attempted/completed. Luckily (or perhaps by design), each service can pretty well stand on it's own, at least once consideration has been given to the whole. That is, if you, like the author, started on your own, yes, you would (potentially) have significant rework as you attempted the integration of a each component, however, after having integrated all of the components enumerated above, it is quite clear that this could have been avoided if I would have had access to a consolidated set of information to begin with. Thus the reason for this documentation and hopefully the reason you are making the investment in reading this documentation.

That being said, it is obviously important that you implement that base directory services prior to integrating something into those services. Additionally, some of the decisions (of structure or why certain elements were used by an application in a certain way) may not make apparent sense. I will try to recognize this and point out any "illogical" decisions as we proceed through each of the sections, as it is certainly a result of needing to integrate something else into the solution that "forced" a somewhat or blatantly (in a few cases) illogical decision/implementation. Additionally, some additional information regarding design and the "why" is enumerated in the previous section and I will do my best to reference back to that information when it may be of particular interest.


The directory I have come to use is OpenLDAP. This was due to a number of factors, but as I am now quite familiar and comfortable with it and have not found a imputues for change, it is what I will focus on in this document. I know of at least one other seemingly viable alternative provided by the Apache Foundation and I would encourage you to evaluate both if you are not already working with one or the other; however, if you are using a different directory, some of the specifics (especially in this section) may be less relevant, but much of the overall document should still be significant and relevant to your efforts.

I am currently using OpenLDAP version 2.3.41. It has been some time since I evaluated the specific version I am using, but the last time I invested significant time into that research was when I implemented my current master/slave installation as there seemed to be significant improvements to the configuration of this scenario (significant simplification in both configuration and implementation). Therefore, I would suggest that if something doesn't seem to be working for you that you review what version you have installed and if there has been any significant changes between the version you are attempting to use and the version above that I am using for this documentation.

OpenLDAP can be found at www.openldap.organd should be your primary reference for information. I will not be replicating information provided by the project, but rather will focus on the specifics required for the task at hand.

Additional Resources

This section provides additional resources that you may find helpful when working with OpenLDAP and these sources are one reason that I have not duplicated this information here as there are good "point" sources while this document focuses more on the overall integration and specifics required for this integration rather than on "all" the details.

  • OpenLDAP project page - Various resources, some enumerated below - the FAQ section seems to have improved significantly since I last reviewed it and I would suggest it as a good reference
    • admin guide - I won't post the URL, since it will vary based on the version you are using, but it can generally be found off of the home page for OpenLDAP
    • ACL FAQ - Securing OpenLDAP through ACLs
  • Yolinux LDAP Tutorial - Collection of misc information, but also has pointers to other sites and resources that may be of interest - may be somewhat dated, but still a good resource (I couldn't find a last published/updated date on the site, so I am unsure of when the last time the information was updated)
  • OpenLDAP on TLDP - TLDP is almost always a good source for information


Obtain the bits and install them by whatever method you have available or are comfortable with. If you require assistance with installation, I would suggest you consult your distributions package management system documentation or the installation documentation on the OpenLDAP project site.

There are a couple of options that we will be using that may or may not be the defaults on your preferred platform, so I will mention them here. First, we need to ensure that SSL support is compiles into the package as I make heavy use of TLS for secure connections to the directory, especially for communications to and from the DMZ. I am not as concerned about the communications within the secure (corporate) zone; however, that is primarily due to the small number of users and the amount of physical and logical control over the connections to my physical and logical networks. In the typical corporate environment you would not typically have such tight control and I would strongly suggest that you leverage TLS even within the secure zone (even with the controls I have in place, I still use TLS for most if not all access to the directory service).

You will also want to ensure that you enable "overlays" as we will use the "syncprov" overlay provider to enable replication for our master/slave scenario.

Most of the other configuration options have to do with backend support for the datastore. As I have no strong preference and have chosen to use the backend suggested by the OpenLDAP documentation, I have pretty much accepted the defaults. One option that you may consider, my distribution allows me to select "Samba" support, but I believe this is mostly to add the Samba "schema" to the installed/provided schemas and I am not sure that it has an impact on the binary created, but do your due diligence and ensure you have the options enabled that make sense for your preferences or environment, beyond support for SSL (which in my distribution enables TLS).

The use of TLS will also probably add a dependency on an SSL library. I make use of OpenSSL as it is provided by default on my platform. If this is not provided or the version provided is not compatible with OpenLDAP (consult the project documentation), then you may need to update or install OpenSSL. There are other viable TLS implementations that should also be suitable, as I am pretty sure I have used GnuTLS previously (the reason I don't think I remember is that, at least for the functionality I have required, they are pretty interchangeable; however, the configuration and installation I am using as the basis for this documentation is using OpenSSL).

Master Configuration

Once you have a default installation of OpenLDAP with SSL/TLS enabled, we can start configuring the master "instance". We will work to get the master up and do some initial integration before attempting to integrate the slave into the configuration.

Please consult the OpenLDAP project documentation for specifics, as while I am providing complete working configuration files, I will only be discussing very specific items of configuration that are not enumerated in the OpenLDAP documentation or that are a result of integration decisions required. There are several configuration files that are used by either "slapd" or various components that will be integrated with OpenLDAP. First I will present the slapd.conf file:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/freeradius.schema
include /etc/openldap/schema/openscep.schema
include /etc/openldap/schema/dbmail.schema
include /etc/openldap/schema/postfix.schema
include /etc/openldap/schema/openssh-lpk.schema

TLSCACertificateFile /etc/ssl/certs/cacert.pem
TLSCertificateFile /etc/openldap/certs/ldap.hendrix.local.cert.pem
TLSCertificateKeyFile /etc/openldap/certs/ldap.hendrix.local.unsecurekey.pem

pidfile /var/run/openldap/slapd.pid
loglevel none
#loglevel 256

modulepath      /usr/lib64/openldap/openldap
#moduleload     back_monitor.so

access to * by * read

database bdb
suffix "dc=hendrix,dc=local"
directory /var/lib/openldap-data
rootdn "cn=manager,dc=hendrix,dc=local"
lastmod on

cachesize 1000
idlcachesize 3000
checkpoint 32 30
dbconfig set_cachesize 0 268435456 1
dbconfig set_lg_regionmax 262144
dbconfig set_lg_bsize 2097152

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

index objectClass eq
index cn pres,eq,sub
index uid pres,eq,sub
index uidNumber eq
index gidNumber eq
index sn pres,eq,sub
index memberUid eq
index sambaSID eq
index displayName pres,eq,sub
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaSIDList eq
index sambaGroupType eq
index uniqueMember eq
index default sub
index entryCSN eq
index dbmailUID eq
index mail eq
index mailAlternateAddress eq
index clientCertPrint eq

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by anonymous auth
        by * none

access to *
        by * read

This is pretty much a minimal configuration file for OpenLDAP. I would not say that it is necessarily secure although this is what I would consider the minimum, as I do have an access rule to limit access to the various password fields in a user record. I am still search for some good documentation on securing records in OpenLDAP and have yet to find much guidance, although the OpenLDAP documentation is a pretty good reference, little guidance from an implementation standpoint is provided. As this is not necessarily a focus of this document (securing OpenLDAP), but rather a focus on how to integrate, I encourage you to do your own research and improve upon this as a basis.

The various included schemas will be discussed in the sections relevant to the products associated with them and as such, I will not elaborate here except to say that with one exception, I have used either schemas as the are available on the OpenLDAP site or on the site of the product for which they are intended without modification, with the notable exception of the "postfix.schema" which I will go into elaborate detail on the why and how's later in this document as it was the most significant change that was required beyond the standard modifications required to integrate the products. That is, it does not seem possible to implement and integrate the products in the manner I require without this modification.

You should note the inclusion of the TLS information as this is significant. As stated earlier I believe in implementing as much security as is reasonable, especially if I can find good documentation or examples of such. The use of TLS is one area that pretty much "comes for free" and can provide a significant improvement in the overall security (within reasonable controls in place) of your directory integration solution/implementation. You will also notice that I am using certificates (which is a requirement of TLS). One item that is not readily apparent however is that these are private certificates issues from a self signed CA that I have created. That is, you don't have to go out and buy certificates in order to get this solution to work. There are some potential benefits to using trusted third party certificates if you have them available or your constraints permit thier cost, but otherwise there is minimal impact on the overall quality of the solution to using certificates from your own self signed CA.

The "loglevel" directive should be of some interest. I leave both in the file so that I can remember what it needs to be when I am diagnosing and resolving issues. That is, my "default" state is the one depicted above, but as I don't want to look up the codes everytime I need to diagnose a problem, I just leave this in the file for convenience. The "back_monitor" module was one that I was evaluating, but as you can see, I do not currently have it enabled.

The cache parameters are either defaults or suggested values that I found on the net. You may need to modify these based on your environment and as stated earlier, for more information, consult the OpenLDAP documentation.

You will also need to determine what to call the root of your directory. I have named mine "hendrix.local". I have a number of domains registered, but as I use "hendrix.local" as the domain for my private network and all the clients on this network are both "nat'd" out and "proxied", this domain is never actually seen (well mostly not seen) "in the wild" (on the Internet). I could just as well have used one of the domains that I have registered. If you ever plan to integrate or open your directory wider than your private network, you may want to consider using a name (namespace) that you have registered in order to try to circumvent potential name clashes. Additionally, if you plan to integrate your DNS infrastructure into the directory (which I have not for a number of reasons), you may also be better served by using your registered domain name; however you decide, this is an important but not overly critical decision. It should be pointed out that this "root" can be changed, but as we will use it in almost every configuration file we modify, it is not impossible to change, but in order to change, you will have to change a number of configuration files on every server in your infrastructure and potentially on each client, so it is more of an inconvenience than an impossibility.

One entry to pay particular attention to is the "overlay syncprov" which enables our master/slave replication architecture.

Once you have made your configuration changes, you will need to create the root node in your directory and create your initial directory structure...

There are two additional 'ldap" configuration files that we also need to modify so that some of the other components of our system can find and use our LDAP configuration. These are the "ldap.conf" in the slapd configuration directory and the "ldap.config" in the /etc or the /etc/ldap directory. Both are provided below starting with the "ldap.conf" from my openldap configuration directory (for my distribution, this is /etc/openldap):

# @(#)$Id: ldap.conf,v 2.47 2006/05/15 08:13:44 lukeh Exp $
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
# PADL Software
# http://www.padl.com

uri ldap://ldap.hendrix.local
base dc=hendrix,dc=local
ldap_version 3
ssl start_tls
TLS_CACERT /etc/ssl/certs/cacert.pem

And the almost identical "ldap.conf" from my /etc directory:

# @(#)$Id: ldap.conf,v 2.47 2006/05/15 08:13:44 lukeh Exp $
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
# PADL Software
# http://www.padl.com

uri ldap://ldap.hendrix.local
base dc=hendrix,dc=local
ldap_version 3
ssl start_tls
bind_policy soft

pam_filter objectclass=posixAccount
pam_password exop

nss_base_passwd         ou=Users,dc=hendrix,dc=local?one
nss_base_passwd         ou=Computers,dc=hendrix,dc=local?one
nss_base_shadow         ou=Users,dc=hendrix,dc=local?one
nss_base_group          ou=Groups,dc=hendrix,dc=local?one

TLS_CACERT /etc/ssl/certs/cacert.pem

nss_reconnect_tries 4
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 16
nss_reconnect_maxconntries 2

The first file appears to be used by various components from the "slapd" installation, where the second is primarily used by PAM/NSS for ldap integration.

To complete the installation and integration of OpenLDAP for authentication on your initial server, you need to make some changes to a few additional files. The first is the nsswitch.conf file:

# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      files ldap
shadow:      files ldap
group:       files ldap

hosts:       dns files wins
networks:    dns files

services:    db files
protocols:   db files
rpc:         db files
ethers:      db files

netmasks:    files
netgroup:    files
bootparams:  files

automount:   files
aliases:     files

You will also need to make changes to your PAM configuration in order to leverage LDAP directory. Luckily in my distribution, all the changes can be made in a single file. At least one other distribution I have implemented an integrated solution on required changing more than one file, but that is due to the way that the PAM configuration files were designed. PAM configuration changes for my environment are contained in the system-auth configuration file in the pam.d configuration file directory:


auth       required     pam_env.so
auth       sufficient   pam_ldap.so     use_first_pass
auth       sufficient   pam_unix.so     shadow likeauth try_first_pass
auth       required     pam_deny.so

account    sufficient   pam_unix.so
account    sufficient   pam_ldap.so

password   required     pam_cracklib.so
password   sufficient   pam_unix.so     use_authtok md5 shadow
password   sufficient   pam_ldap.so
password   required     pam_deny.so

session    required     pam_limits.so
session    sufficient   pam_ldap.so
session    required     pam_unix.so

I have removed my parameters from the "pam_cracklib.so" line so that anyone deciding to target my infrastructure doesn't have some key information regarding password length, history, etc. Otherwise, this is the exact configuration file I am using.

More to come...

Slave Configuration

This section will undergo significant expansion before publication and its current state is very preliminary

The configuration of the slave server is not significantly different that the master with the exception of the slapd.conf file which follows:

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/samba.schema
include         /etc/openldap/schema/freeradius.schema
include         /etc/openldap/schema/openscep.schema
include         /etc/openldap/schema/dbmail.schema
include         /etc/openldap/schema/postfix.schema
include         /etc/openldap/schema/openssh-lpk.schema

TLSCACertificateFile /etc/ssl/certs/ca.hendrix.local.pem
TLSCertificateFile /etc/openldap/certs/ldap.hendrix.local.cert.pem
TLSCertificateKeyFile /etc/openldap/certs/ldap.hendrix.local.unsecurekey.pem

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

loglevel        none
#loglevel       256

access to *
        by * read

database        bdb
suffix          "dc=hendrix,dc=local"
checkpoint      32      30
rootdn          "cn=Manager,dc=hendrix,dc=local"
directory       /var/lib/openldap-data


index objectClass eq
index cn pres,eq,sub
index uid pres,eq,sub
index uidNumber eq
index gidNumber eq
index sn pres,eq,sub
index memberUid eq
index sambaSID eq
index displayName pres,eq,sub
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaSIDList eq
index sambaGroupType eq
index uniqueMember eq
index default sub
index entryCSN eq
index dbmailUID eq
index mail eq
index mailAlternateAddress eq
index clientCertPrint eq

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by anonymous auth
        by * none

access to *
        by * read

This should look familiar with the exception of the "syncrepl" section, which completes the configuration of our master/slave server pair...


This section will undergo significant expansion before publication and its current state is very preliminary

While the configuration files for PAM/NSS with LDAP were provided above, not much information or guidance was provided in that section, as it was primarily focused configuration of the initial OpenLDAP installation. This section will provide futher information and resources focused specifically on PAM/NSS integration with LDAP.


This section provides detailed information on the installation and integration of OpenSSH with OpenLDAP for the purpose of providing secure shell access to your servers for administrators and those that required direct access to the servers or the *nix infrastructure. There are a number of decisions that you should probably make and these will be further enumerated as we move through this section of the document and work to integrate OpenSSH into our directory services.


This section will undergo significant expansion before publication and its current state is very preliminary

The configuration of OpenSSH in order to take advantage of our directory services is mostly enabled through the PAM/NSS LDAP configuration; however, there are a number of items that are specific to OpenSSH and the directory. The configuration file for OpenSSH that the author typically uses is:

#       $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

UseLPK yes
LpkLdapConf /etc/ldap.conf
UsePrivilegeSeparation yes
X11Forwarding yes

The items worth noting are the "LPK" configuration options and the "PAM" configuration... More to come...


This section will undergo significant expansion before publication and its current state is very preliminary

EMail services with my infrastructure are divided into three separate components. The first is the mail relay that sits in the DMZ, for which I use the postfix mail server. The mail store and primary user interface for users inside the corporate network is provided by DBMail. EMail services for users outside the corporate network are provided by RoundMail and are provided from the DMZ. One critical requirement that I impose on my infrastructure is that the protocol used to communicate from the internet to the DMZ must be different than the protocol used to communicate from the DMZ to the corporate network. This is called a "protocol break" and is the primary reason for some of the convoluted configuration that may leave you scratching your head when you see the configuration files and the email design.

Postfix (mail relay in DMZ)

I use postfix as my mail relay in the DMZ and permit SMTP connection from the internet to this server and from this server to other servers on the internet. My primary postfix configuration file is as follows:

# Global Postfix configuration file. This file lists only a subset
# of all parameters. For the syntax, and for a complete parameter
# list, see the postconf(5) manual page (command: "man 5 postconf").
# For common configuration examples, see BASIC_CONFIGURATION_README
# and STANDARD_CONFIGURATION_README. To find these documents, use
# the command "postconf html_directory readme_directory", or go to
# http://www.postfix.org/.
# For best results, change no more than 2-3 parameters at a time,
# and test if Postfix still works after every change.

command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix

virtual_transport = lmtp:[]
virtual_mailbox_domains = lancehendrix.com lanchendrix.net
virtual_mailbox_maps = ldap:/etc/postfix/ldap.validaddresses.map.cf
virtual_alias_maps = ldap:/etc/postfix/ldap.aliases.map.cf

alias_maps = ldap:/etc/postfix/ldap.aliases.map.cf

parent_domain_matches_subdomains =

smtpd_recipient_restrictions =
        check_helo_access hash:/etc/postfix/helo_checks
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client list.dsbl.org,
        reject_rbl_client multihop.dsbl.org,

smtpd_data_restrictions =

smtpd_helo_required = yes
disable_vrfy_command = yes

smtp_tls_CAfile = /etc/postfix/certs/hendrix.local.cert.pem
smtp_tls_cert_file = /etc/postfix/certs/mail.lancehendrix.com.cert.pem
smtp_tls_key_file = /etc/postfix/certs/mail.lancehendrix.com.unsecurekey.pem
smtp_tls_session_cache_database = btree:/var/spool/postfix/smtp_tls_sess_cache
smtp_use_tls = yes

smtpd_tls_CAfile = /etc/postfix/certs/hendrix.local.cert.pem
smtpd_tls_cert_file = /etc/postfix/certs/mail.lancehendrix.com.cert.pem
smtpd_tls_key_file = /etc/postfix/certs/mail.lancehendrix.com.unsecurekey.pem
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_sess_cache
smtpd_tls_received_header = no
smtpd_tls_security_level = may
smtpd_tls_loglevel = 0
smtpd_tls_ask_ccert = yes

relay_clientcerts = ldap:/etc/postfix/ldap.relay.clientcerts.cf

debug_peer_level = 2
debug_peer_list =

sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = /usr/share/doc/postfix-2.4.6-r2/html
manpage_directory = /usr/share/man
sample_directory = /etc/postfix
readme_directory = /usr/share/doc/postfix-2.4.6-r2/readme

While this may not be a "pretty" configuration, it does work. More to come...

DBMail (Mailstore & IMAP)

I chose DBMail for my primary mail store for a number of reasons that might or might not make sense for your environment and constraints. First, I wanted a user store based on a data store (rather than file based storage such as MBox or Maildir). Second, since I require a protocol break, I required an email server that could use a protocol other than SMTP for communication with the mail relay (postfix) in the DMZ.

My DBMail configuration file is:

# (c) 2000-2006 IC&S, The Netherlands
# Configuration file for DBMAIL

driver               = mysql
authdriver           = ldap
host                 = localhost
sqlsocket            = /var/run/mysqld/mysqld.sock
user                 = dbmail
pass                 = password!changeme
db                   = dbmail
table_prefix         = dbmail_
encoding             = utf8
default_msg_encoding = utf8

#postmaster           = DBMAIL-MAILER
sendmail              = /usr/sbin/sendmail
TRACE_SYSLOG          = 3
TRACE_STDERR          = 1
EFFECTIVE_USER        = dbmail
EFFECTIVE_GROUP       = dbmail
BINDIP                = *
NCHILDREN             = 20
MAXCHILDREN           = 100
MAXCONNECTS           = 10000
MAX_ERRORS            = 500
TIMEOUT               = 300
login_timeout         = 60
RESOLVE_IP            = no
pid_directory         = /var/run
state_directory       = /var/run


PORT                  = 24
NCHILDREN             = 5
MAXCHILDREN           = 100

PORT                  = 110
POP_BEFORE_SMTP       = no

PORT                  = 143
TIMEOUT               = 4000

PORT                  = 2000

PORT                  = 389
VERSION               = 3
BASE_DN               = ou=Users,dc=hendrix,dc=local

# If your LDAP library supports ldap_initialize(), then you can use the
# alternative LDAP server DSN like following.
URI                   = ldap://ldap.hendrix.local
# URI                = ldapi://%2fvar%2frun%2fopenldap%2fldapi/

BIND_DN               = cn=Manager,dc=hendrix,dc=local
BIND_PW               = password!changeme
SCOPE                 = SubTree
USER_OBJECTCLASS      = top,account,dbmailUser
FORW_OBJECTCLASS      = top,account,dbmailForwardingAddress
CN_STRING             = uid
FIELD_PASSWD          = userPassword
FIELD_UID             = uid
FIELD_NID             = dbmailUID
MIN_NID               = 5005
MAX_NID               = 15000
FIELD_CID             = dbmailGID
MIN_CID               = 5005
MAX_CID               = 15000
FIELD_MAIL            = mailAlternateAddress
FIELD_QUOTA           = mailQuota
FIELD_FWDTARGET       = mailForwardingAddress

SIEVE                 = yes
SUBADDRESS            = yes
SIEVE_VACATION        = yes
SIEVE_NOTIFY          = yes
SIEVE_DEBUG           = no
AUTO_NOTIFY           = no
AUTO_REPLY            = no


# Defaults to POSTMASTER from the DBMAIL section.

# If you set this to 'yes' dbmail will check for duplicate
# messages in the relevant mailbox during delivery using
# the Message-ID header
suppress_duplicates     = no

# end of configuration file

Unfortunately, this is one of those configuration files that require the password in the configuration file (or at least is seems so, primarily so that DBMail utilities can manipulate the directory, although I don't generally use these to manage users), so the password has been replaced in this file. No other changes have been made to this file.


This section will undergo significant expansion before publication and its current state is very preliminary

Freeradius is an interesting tool and really serves a number of functions within the infrastructure, serving to allow the full integration of most AAA services into the enterprise directory. As such, Freeradius can really be thought of as an integration layer that provides AAA services through implementation and exposure of a number of AAA protocols that can be leveraged within the infrastructure, while on the backend, Freeradius is configured to leverage our enterprise directory (OpenLDAP) for information storage and retrieval.

While I will provide significantly more information as this document develops, what follows is my current Freeradius configuration file:

## radiusd.conf -- FreeRADIUS server configuration file.
##      http://www.freeradius.org/
##      $Id: radiusd.conf.in,v 2007/07/16 10:53:13 pnixon Exp $

prefix                  = /usr
exec_prefix             = ${prefix}
sysconfdir              = /etc
localstatedir           = /var
sbindir                 = ${exec_prefix}/sbin
logdir                  = ${localstatedir}/log/radius
raddbdir                = ${sysconfdir}/raddb
radacctdir              = ${logdir}/radacct

confdir                 = ${raddbdir}
run_dir                 = ${localstatedir}/run/radiusd
log_file                = ${logdir}/radius.log
log_destination         = files

libdir                  = /usr/lib64

pidfile                 = ${run_dir}/radiusd.pid

user = radiusd
group = radiusd

max_request_time        = 30
delete_blocked_requests = no
cleanup_delay           = 5

max_requests            = 1024
bind_address            = *
port                    = 0
hostname_lookups        = no
allow_core_dumps        = no
regular_expressions     = yes
extended_expressions    = yes

log_stripped_names      = no
log_auth                = yes
log_auth_badpass        = yes
log_auth_goodpass       = no

usercollide             = no

lower_user              = no
lower_pass              = no

nospace_user            = no
nospace_pass            = no

security {
        max_attributes  = 200
        reject_delay    = 1
        status_server   = no

proxy_requests          = no

$INCLUDE  ${confdir}/clients.conf

snmp                    = no

thread pool {
        start_servers           = 5
        max_servers             = 30
        min_spare_servers       = 3
        max_spare_servers       = 10
        max_requests_per_server = 1000

modules {
        ldap {
                server          = "ldap.hendrix.local"
                identity        = "cn=Manager,dc=hendrix,dc=local"
                password        = "password!changeme!"
                basedn          = "dc=hendrix,dc=local"
                filter          = "(uid=%{Stripped-User-Name:-%{User-Name}})"
                base_filter     = "(objectclass=radiusprofile)"

                start_tls = yes

                tls_cacertfile          = /etc/ssl/certs/cacert.pem
                tls_require_cert        = "demand"

                access_attr = "dialupAccess"

                dictionary_mapping = ${raddbdir}/ldap.attrmap
                auto_header = yes

                ldap_connections_number = 5

                password_attribute = userPassword
                auto_header = yes
                edir_account_policy_check = no
                timeout = 4
                timelimit = 3
                net_timeout = 1
                compare_check_items = no
                do_xlat = yes
                access_attr_used_for_allow = yes
                set_auth_type = yes

        pap {
                auto_header = yes

        chap {
                authtype = CHAP

        mschap {
                use_mppe = no

        eap {
                default_eap_type = peap
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no

                gtc {
                        auth_type = PAP

                tls {
                        private_key_password = password!changeme!
                        private_key_file = /etc/raddb/certs/server.hendrix.local.securekey.pem
                        certificate_file = /etc/raddb/certs/server.hendrix.local.cert.pem
                        CA_file = /etc/ssl/certs/cacert.pem
                        dh_file = /etc/raddb/certs/dh
                        random_file = /etc/raddb/certs/random
                        fragment_size = 1024
                        include_length = yes
                        check_crl = no

                ttls {
                        default_eap_type = md5

                peap {
                        default_eap_type = mschapv2

                mschapv2 {

        realm suffix {
                format = suffix
                delimiter = "@"
                ignore_default = yes
                ignore_null = yes

        realm ntdomain {
                format = prefix
                delimiter = "\\"

        preprocess {
                huntgroups = ${confdir}/huntgroups
                hints = ${confdir}/hints

                with_ascend_hack = no
                ascend_channels_per_line = 23
                with_ntdomain_hack = no
                with_specialix_jetstream_hack = no
                with_cisco_vsa_hack = no

        detail {
                detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
                detailperm = 0600
                dirperm = 0700

        detail auth_log {
                detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail-%Y%m%d
                detailperm = 0600
                dirperm = 0700

        detail reply_log {
                detailfile = ${radacctdir}/%{Client-IP-Address}/reply-detail-%Y%m%d
                detailperm = 0600

        acct_unique {
                key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port"

        radutmp {
                filename = ${logdir}/radutmp
                username = %{User-Name}
                case_sensitive = yes
                check_with_nas = yes
                perm = 0600
                callerid = "yes"

        radutmp sradutmp {
                filename = ${logdir}/sradutmp
                perm = 0644
                callerid = "no"

        expr {


instantiate {

authorize {

authenticate {
        Auth-Type PAP {

        Auth-Type CHAP {

        Auth-Type MS-CHAP {

        Auth-Type LDAP {


preacct {

accounting {

session {

post-auth {


This section will undergo significant expansion before publication and its current state is very preliminary

The following is the Samba config files that I am using:

# Samba config file created using SWAT
# from (
# Date: 2008/04/05 20:05:14

        workgroup = HENDRIX
        server string = Samba Server %v
        passdb backend = ldapsam:"ldap://ldap.hendrix.local"
        pam password change = Yes
        lanman auth = No
        client NTLMv2 auth = Yes
        client lanman auth = No
        client plaintext auth = No
        log file = /var/log/samba/log.%m
        max log size = 500
        debug prefix timestamp = Yes
        min protocol = LANMAN1
        reset on zero vc = Yes
        time server = Yes
        server signing = auto
        socket options = TCP_NODELAY SO_SNDBUF=32768 SO_RCVBUF=32768
        printcap name = cups
        logon script = logon.bat
        logon path = \\%N\profiles\%U
        logon drive = H:
        logon home = \\NEPTUNE\%U\profile
        domain logons = Yes
        os level = 35
        preferred master = Yes
        domain master = Yes
        wins support = Yes
        ldap admin dn = cn=Manager,dc=hendrix,dc=local
        ldap group suffix = ou=Groups
        ldap idmap suffix = ou=Idmap
        ldap machine suffix = ou=Computers
        ldap passwd sync = Yes
        ldap suffix = dc=hendrix,dc=local
        ldap ssl = start tls
        ldap user suffix = ou=Users
        idmap backend = ldap:"ldap://ldap.hendrix.local"
        idmap alloc backend = ldap
        idmap uid = 30000-50000
        idmap gid = 30000-50000
        template homedir = /home/%U
        winbind use default domain = Yes
        ldapsam:editposix = yes
        ldapsam:trusted = yes
        printing = cups
        print command =
        lpq command = %p
        lprm command =

        comment = All Printers
        path = /var/spool/samba
        guest ok = Yes
        printable = Yes
        browseable = No

        comment = Printer Drivers
        path = /etc/samba/drivers
        write list = lance

        comment = Network Logon Service
        path = /var/lib/samba/netlogon
        guest ok = Yes
        browseable = No

        path = /var/lib/samba/profiles
        read only = No
        create mask = 0600
        directory mask = 0700
        browseable = No

        read only = No
        create mask = 0640
        directory mask = 0750
        use sendfile = Yes
        veto files = /Desktop*/
        browseable = No

Notes on my environment

As much as possible, I have tried to stay away from details with regard to the distribution I am partial to. That is, I have tried to provide an objective representation that I hope is relevant no matter what OS or distribution you would choose for your implementation; however, it is probably blatantly obvious that my primary implementation platform for this set of infrastructure is Linux. Specifically, I am partial to the Gentoo distribution for my general use, research, and personal work. As to whether this is the "best" Linux distribution, as I have stated ad-nasem, I don't necessarily believe there is such a thing, rather that each situation warrants an objective evaluation of requirements and constraints. However, in order to further clarify some of the information presented in this document, I do think it is relevant to provide the reader with some background as to the specifics of my enironment and deployment as this may help clarify some ambiguities. That said, I have implemented the solutions and integrations presented above on a number of distributions and other than the method of getting the bits on the servers and the specifics of where the files are in relation to the root of the file system (directory structure), I find very little (with regard to the implementation of this specific set of components) to differentiate one Linux distribution over another. In general, I do find it convenient if the distribute provides a "package" of some kind for each of the components, but I am also quite comfortable with the usual "configure/make/install" routine from a source package.

To further elaborate one of the reasons I am probably using the version of a given package rather than the latest available "stable" version for said components website/sourceforge is that while I have not had significant issues with "the latest version", I do tend to value the work and effort put into testing and the "certification" (if you will allow me) provided by the Gentoo package maintainers and as such, I tend to wait until they have "blessed" a version before upgrading. That is, if you wonder what the reason for my use of a specific version and I have not explicity mentioned that I migrated to a given version for some specific reason, you can probably be assured that it is because I am tracking the most recent (non-beta) version of the product as provided by Gentoo's portage (package) system.

by Lance Hendrix