4.2. Database structure

4.2.1. Database Content

In the structure we have adopted, we can isolate our data from other virtual organizations data, collecting all our system data under the object dc=infra, dc=org, o=Anarchy (this is a standard naming convention).

A database includes several kinds of users and objects, which are stored in different branches of the LDAP tree under dc=infra, dc=org, o=Anarchy. For example, these are the main branches we use:

• ou=Admins: this branch includes the servers administrators, that is the users that have an ssh access to the boxes. Note: the administrator tasks that do not imply the use of an ssh access (e.g. the web administration panel) authenticate using objects identical to the ones stored in this branch; anyway these objects are located under the branch ou=People, and have their own set of password. This means that SSH access is completely separated from all the other type of access for what concerns authentication.

• ou=People: this branch includes all website, email, ftp users, and so on. This is the "virtual" part of the LDAP database.

• ou=Operators: this branch includes "system" users that allow the software to handle parts of the LDAP database without requiring the full access privileges of the LDAP administrator. It is mainly used by daemons and software agents accessing the LDAP database.

• ou=Domains: this branch includes an object for each "public" virtual domain managed by the organization. Postfix for example looks in this branch to decide whether a domain is local or not (to build up its transport tables).

4.2.2. Virtual Users

Throughout the following chapter we will mean "contact" by the word "user", that is an entity with access to various services, be it an organization, a person, or anything else. We introduce here this concept to better abstract the administration tasks and therefore the database structure.

Each user is represented in the database by an object identified through the uid key. We can choose whatever naming system for these objects, but in our case we have decided to name them after their main email addess (e.g. uid=phasa@domain.org). If we want to group the services of a whole organization, instead of a single user, we can choose to create an object called after a domain name as uid=organizzazione.it or anything else we deem meaningful (once a scheme has been laid out and chosen).

Each of these objects can be associated to different services, that will be stored under the "user" object. The type of these objects will correspond to the type of service. For example, these are some possible structures:

* a single user with a single mailbox

  ou=People
  \-- uid=user@domain.org                    shadowAccount
      \-- mail=user@domain.org               virtualMailUser

* a user with a mailbox and a website (therefore an ftp account)

  ou=People
  \-- uid=user@domain.org                    shadowAccount              
      +-- mail=user@domain.org               virtualMailUser
      +-- alias=usersite                     subSite
      \-- ftpname=user                       ftpAccount

* an organization with more accounts, a website and a domain of its own

  ou=People
  \-- uid=organiz.org                        shadowAccount
      +-- mail=user1@organiz.org             virtualMailUser
      +-- mail=user2@organiz.org             virtualMailUser
      +-- cn=www.organiz.org                 virtualHost
      \-- ftpname=organiz                    ftpAccount

4.2.3. Authentication

In the structure described above, each service requiring authentication matches the requested credentials directly against the child object of the relative service. So the authentication credentials of the shadowAccount object identifying the user, even if present as requested by the scheme, are never directly used.

By using appropriate query filters, we can then make sure that for example the IMAP daemon matches the authentication of users against a virtualMailUser object, with its own password. This allows, in case, to have different passwords for the different services. This possibility is included in the policy that needs to be implemented through the use of administration tools: in fact, LDAP does not have an internal mechanism to specify particular relationships between objects (apart from the hierarchical relationship), a thing most other relational database can do natively. This is the reason why it is impossible to tell LDAP that an object needs to have the same password of the parent object. This of course implies a certain redundancy of the data in the scheme (but not too much).

We will now see how the different services have been configured (relatively to the LDAP authentication). For each service we specify the configuration files concerning the authentication and what is the query that they are set to do on the LDAP server, composed of a base limiting the scope of the query and a filter that selects one or more specific objects:

Note: all the queries above match the provided password with the one stored in the userPassword attribute. The passwords are stored in the LDAP database with different encoding mechanisms, detailed by a prefix that you can find in the attribute before the encoded password in brackets. E.g.:

	  {crypt}dlkj8h23dU9j1