Project

General

Profile

README

Ansible role to generate the DuckCorp LDAP database

Introduction

LDAP administration is not very easy. We used to generate the database using LDIF bits written by hand.
We began writing a tool to manipulate a live database but this was complex and never reached production level.

Now we're using Ansible to manage deployments and some of them would benefit from better knowlege of users, groups, associated services…

So this role attempts to formalize and clarify the various objects as simple YAML data structures and hide the LDIF generation and all the hassle from the administrators.
It also provides convenient entry points to ease integration with other Ansible rules without having to recompute LDAP specific information thus duplicating the work of the present role (see Entrypoints chapter).

This roles is highly DuckCorp-specific, and uses the DuckCorp's LDAP schema. It may be of interest as an example though.

Data

All objects data are defined as YAML structures in the Ansible variable system. These structures are meant to be human-understandable and should not reveal the underlying technical processing. If one day we decide to go away from LDAP it should then be possible without changing the format.

Also these data are meant to be usable by other roles. For example, if we declare a user possesses a web site, then a dedicated role could ensure this web site is well setup.

Conventions

In the data descriptions, all compulsory fields will have their name bold printed. If this is defined in a inner structure, it means: if you fill-in this inner structure, then you need to fill these fields too.

Dates and times are defined using the following formats from ISO 8601:

  • YYYY-MM-DD
  • hh:mm:ss
  • YYYY-MM-DD hh:mm:ss ("T" is replaced by a space)

Procedures

LDAP hashed passwords should be generated using: slappasswd -h {CRYPT} -c '$6$rounds=60000$%.16s'

Password-based authentication can be disabled by leaving out the password field (internally the role will use an empty string as password as the schema may sometimes be slightly too strict; as the LDAP servers configuration does not allow password-less authentication, it is safe).

UIDs/GIDs should be chosen according to the entity and local system practices:

Entity UID/GID
(system) 0-999
(local) 1000-4999
- 5000-9999
DuckCorp 10000-10099
MilkyPond 10100-10199
RtpNet 10200-10299
- 10300-64899
users' groups 64900-64999
(reserved) 65000-65533
(nobody/nogroup) 65534
(16bits/error) 65535
- 65536-4294967293
(NFS/anonymous) 4294967294
(64bits/error) 4294967295

LDAP Configuration

In ldap critical parameters need to be defined:

  • organization: (informational) human name of the LDAP naming context (name for the DuckCorp LDAP database)
  • admin_password: password for the LDAP naming context administrator (password for the DuckCorp LDAP database account)
  • service_accounts: list of database accounts used for services queries (a service may need to read certain operation to operate, for eg. Postfix needs to read domains and certain user information)

Each service account is defined with these parameters:

  • password_clear: (only useful if you plan to use the service_account_info entrypoint) clear text version of the account password
  • password: account password
  • description: account human description

Users

In accounts.users all users of the system are declared. It is a hash whose keys are the users' uid.

A user is defined by this structure:

  • firstname: firstname/givenname
  • lastname: lastname/familyname; can be left unset if the user wishes to be anonymous (as some services may leak user info), in this case indicate this info as a comment
  • contact: (informative)
    • mobile_phones: list of international format phone number
    • websites: list of web site's URL
    • address: user's main address
    • emails: lists of email addressed (should be contact emails only but currently also used as extra mail aliases if service is activated; legacy behavior)
  • photo: image filename; the file must be present on the LDAP server in /var/local/ldap/photos/
  • occupation: job description or anything the user identify as main activity
  • preferred_languages: language indication as defined by RFC2798, see definition of Accept-Language in RFC2068
  • tz: timezone name
  • birthday: birth date
  • birthplace: birth location
  • organizations: list of organizations/associations names
  • password: LDAP hashed password generated using slappasswd -h {CRYPT} -c '$6$rounds=60000$%.16s'
  • gpg_fingerprints: list of GPG fingerprints
  • attached_accounts: list of secondary accounts owned by this user, see the Secondary Accounts chapter.
  • attached_bots: list of bots (DNS/Mail) owned by this user, see the Bots chapter.
  • attached_groups: list of groups owned by this user, see the Groups chapter.
  • attached_domains: list of domains (DNS/Mail) owned by this user, see the Domains chapter.
  • description: (informational) account description

To define which services are associated with this account more fields are defined, see the Account Services chapter.

Entities

An entity is an association or project led by multiple users.

In entities all entities of the system are declared. It is a hash whose keys are the entities' name.

An entity is defined by this structure:

  • abbreviation: 2-4 letters used as common abbreviation for the entity name : attached objects are encouraged to use this abbreviation as prefix followed by a dash in their names to clarify their provenance and usage
  • founding_date: date when this entiry was created
  • founder: user (uid) who created this entity
  • chairman: user (uid) who is the lead of this entity
  • treasurer: user (uid) who is in charge of the finances of this entity
  • secretary: user (uid) who is in charge of supporting the management of this entity
  • manager: user (uid) who is in charge of the technical aspects of this entity
  • description: (informational) entity description
  • attached_accounts: list of system accounts owned by this entity, see the System Accounts chapter.
  • attached_bots: list of bots (DNS/Mail) owned by this entity, see the Bots chapter.
  • attached_groups: list of groups owned by this entity, see the Groups chapter.
  • attached_domains: list of domains (DNS/Mail) owned by this entity, see the Domains chapter.

Secondary Accounts

A secondary account hold services similary to a user but as it is linked to a user so it does not need to repeat all the basic information.

A secondary account is defined by this structure:

  • password: LDAP hashed password
  • description: (informational) account description

To define which services are associated with this account more fields are defined, see the Account Services chapter.

System Accounts

A system account hold services similary to a user but as it is linked to an entity so it does not need to repeat all the basic information.

A system account is defined by this structure:

  • password: LDAP hashed password
  • managers: list of users in charge of the bot maintenance (list of uids)
  • description: (informational) account description

To define which services are associated with this account more fields are defined, see the Account Services chapter.

Groups

A group is a collection of users or groups used to defined ACLs (on filesystem, services…).

A group is defined by this structure:

  • gid: GID number
  • members: list of users part of this group (list of uids)
  • group_members: list of groups (names) part of this group : the current implementation does not allow groups outside the current scope (user or entity)

Domains

A domain is a hosted Internet domain for DNS and/or MX support.

A domain is defined by this structure:

  • mail: (activates MX support but one of the inner parameters needs to be activated too)
    • delivery: boolean to activate delivery of mails on the DuckCorp MDA
    • relay: boolean to activate DuckCorp MTAs acting as secondary MX
  • managers: list of users allowed to update the DNS zone via Banya (list of uids)
  • description: (informational) account description

WARNING: There is currently no way to know if the domain is really hosted for DNS. The underlying LDAP object lacks this information. If the managers are defined, this is most probably the case.

Bots

A bot is a robot program hosted on a DuckCorp server. For security and resource control reasons creating a separate account is better.

A bot is defined by this structure:

  • password: LDAP hashed password
  • owner: user using the bot (uid)
  • managers: list of users in charge of the bot maintenance (list of uids)
  • description: (informational) account description

To define which services are associated with this account more fields are defined, see the Account Services chapter.

Account Services

This structure is meant to complement an already existing structure. It is defined here to document it only once. It is related to services activation and parameters.

  • fs: (activates NSS account)
    • uid: UID number (first available)
    • gid: GID number (see groups definition)
  • login: (requires a fs account)
    • shell: login shell (defaults to /bin/bash)
    • hosts: (activates shell account) lists of allowed hosts (FQDN) : If the host is prefixed by ALLSRV:, then all PAM services will be allowed on this host
    • ssh_keys: (activates SSH access if shell account is already activated, otherwise informational) list of SSH keys (as defined in authorized_keys file)
  • mail: (activates Mail account)
    • quota: mailbox quota expressed with units (eg "5G") : quota are useless in case of redirection
    • aliases: list of mail addresses (currently complemented by contact.emails if present; legacy behavior)
    • redirections: list of mail addresses to forward all trafic to
  • xmpp_jids: (activates XMPP account) list of JIDs : WARNING: Prosody does not support this (but should), so only <uid>@milkypond.org is supported at the moment
  • web_vhosts: (informational) list of hosted web sites (vhost name, eg. toto.duckcorp.org) : the vhost name possibly contains a subdirectory if the user only owns a part; eg. perso.duckcorp.org/toto) : if the the part is defined as *, then this is a declaration of a multi vhost, hosting parts possibly owned by others
  • databases: (informational) list of hosted databases (prefixed by the database type and a colon; eg. pqsql:toto1, mysql:toto2, ldap:toto3)
  • ddns_hostnames: (activates DDNS account) lists of DDNS hostnames : Please use format <user-nick>-<name>.ddns.duckcorp.org where <user-nick> can be the uid or a shorter nickname and <name> a custom name chosen by the user.
  • services: activates parameter-less services, see below

The following parameter-less services are currently defined:

  • dl_netdev: access to DuckLand network devices
  • ftp: (DEPRECATED) activates FTP account
  • smtp: activates SMTP account (relaying through DuckCorp's main SMTP server)
  • stuffcloud: (always ON for users)(secondary accounts only) activates StuffCloud access

Technical Details

The generation occurs in /var/local/ldap on the server. The fragments subdirectory is used to generate fragments of the LDAP database in LDIF format. These fragments are then assembled in the main directory in ldap.ldif, which is validated using OpenLDAP's tools. If it succeeds then OpenLDAP and dependent services are stopped, the databases files are destroyed and recreate by import, permissions are corrected, LDAP indexes regenerated, and finally all services restarted.

User's photo files are stored in the photos subdirectory. Management of these files is outside the goal of this role, an administrator would need to place the required files into it.

Entrypoints

These entrypoints are meant to be used with import_role; the name of the entrypoint is used with the tasks_from parameter to access a different code path.

service_account_info

In the LDAP Configuration a list of service accounts have been defined. This entrypoint computes a structure with all necessary parameters needed to connect to a LDAP server using this account:

  • base_dn: search path
  • bind_dn: login
  • bind_pw: password
Statistics
| Branch: | Revision:

duckcorp-infra / ansible / roles / dc-ldap @ fccc455f

Name Size Revision Age Author Comment
  files 40fa7e1b 11 months Marc Dequènes Install LDAP servers
  handlers 40fa7e1b 11 months Marc Dequènes Install LDAP servers
  meta 5d76f2d8 over 1 year Marc Dequènes First public version
  tasks fccc455f about 2 months Marc Dequènes dc-ldap: use vars instead of static set_fact
  templates 40fa7e1b 11 months Marc Dequènes Install LDAP servers
  vars fccc455f about 2 months Marc Dequènes dc-ldap: use vars instead of static set_fact
README.md 12.4 KB 1efb8bbd 11 months Pierre-Louis Bonicoli Use static imports when possible - static impo...

Latest revisions

# Date Author Comment
fccc455f 2019-02-24 11:01 Marc Dequènes

dc-ldap: use vars instead of static set_fact

4de9bb8d 2018-12-05 07:13 Marc Dequènes

fix E502

e706037e 2018-09-15 09:48 Marc Dequènes

dc-ldap: add 'su' as login service

a5db3503 2018-09-15 05:32 Marc Dequènes

dc-ldap: use new conditional syntax

6b8f5f09 2018-05-26 12:23 Marc Dequènes

dc-ldap: added deref control

See #594

0db301ee 2018-05-26 12:23 Marc Dequènes

dc-ldap: removing what seemed to be the default db files is not a good idea

708a3d1d 2018-05-24 06:04 Marc Dequènes

dc-ldap: restart if database was created

40fa7e1b 2018-05-24 05:10 Marc Dequènes

Install LDAP servers

1efb8bbd 2018-05-23 18:43 Pierre-Louis Bonicoli

Use static imports when possible

- static imports allow to use --list-tags, --list-tasks, --start-at-tasks
switches,
- since 2.5, tags applied to dynamic includes are not applied to
included tasks

82689b26 2018-04-29 15:18 Marc Dequènes

removed obsolete im_gateway service

View revisions

Also available in: Atom