spellcheck ldap

 * `/var/tmp/bacula-restores/etc/ldap/slapd.conf`

 * `/var/tmp/bacula-restores/etc/ldap/userdir-ldap-slapd.conf`

They can be copied from `/etc`, with the following modificatiosn:

They can be copied from `/etc`, with the following modifications:

    diff -ru /etc/ldap/slapd.conf etc/ldap/slapd.conf

    --- /etc/ldap/slapd.conf	2011-10-30 15:43:43.000000000 +0000

In the above, `arlo` and `arma` are members of the `tordnsel` group.

The fields in the output are in the format of the [group(5)](https://manpages.debian.org/buster/manpages/group.5.en.html) file.

Note that the group membership will vary according to the machie on

Note that the group membership will vary according to the machine on

which the command is run, as not all users are present everywhere.

## Searching LDAP

               SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

 3. finally, the new attribute needs to be added to the

    objectclass. in our example, the field was added alongside the

    other password fields in the `debianAccount` objectclass, which

    `objectclass`. in our example, the field was added alongside the

    other password fields in the `debianAccount` `objectclass`, which

    looked like this after the change:

        objectclass ( 1.3.6.1.4.1.9586.100.4.1.1

If those are the only required changes, it is acceptable to directly

make those changes directly on the LDAP server, as long as the *exact*

same changes are performed in the git repositoy.

same changes are performed in the git repository.

It is preferable, however, to [build and

upload](howto/build_and_upload_debs) `userdir-ldap` as a Debian package instead.

    /srv/db.torproject.org/mail-logs/received.changes

A common problem is people using `--clearsign` instead of `--sign`

when sending an SSH key. When that hapepns, many email clients

when sending an SSH key. When that happens, many email clients

(including Gmail) will word-wrap the SSH key after the comment,

breaking the signature. For example, this might happen:

    -----END PGP SIGNATURE-----

Using `--sign --armor` will work around this problem, as the original

message will all be ascii-armored.

message will all be ASCII-armored.

### Dependency loop on new installs

restored from backups in case of a catastrophic failure. Care should

be taken to keep the SSH keys of the server intact.

The IP address (and name?) of the LDAP server should not be hardcoded

The IP address (and name?) of the LDAP server should not be hard-coded

anywhere. When the server was last renumbered ([issue 33908](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33908)), the

only changes necessary were on the server itself, in `/etc`. So in

theory, a fresh new server could be deployed (from backups) in a new

The LDAP setup at Tor is based on the one from Debian.org. It has a

long, old and complex history, lost in the mists of time.

Configuration and database files like SSH keys, OpenPGP keyringsm,

Configuration and database files like SSH keys, OpenPGP keyrings,

password, group databases, or email forward files are synchronised to

various hosts from the LDAP database. Most operations can be performed

on the [db.torproject.org](https://db.torproject.org/) site or by [email](https://db.torproject.org/doc-mail.html).

   email, DNS, and git servers

 * provides host metadata to Puppet

This diagram covers those interdependencies at the time of writing.

This diagram covers those inter-dependencies at the time of writing.

![LDAP architecture diagram](ldap/graph.svg)

generates configuration files for each host. Then the `ud-replicate`

command runs on each node to `rsync` those files. Both commands are

ran from cron on regular intervals, the latter defined in Puppet, the

former hardcoded to 15 minutes.

former hard-coded to 15 minutes.

More specifically, this is what happens:

| `disabled-accounts`                | list of disabled accounts                                                         | `uid`, `userPassword` (*includes* inactive)                                                                                         |

| `dns-sshfp`                        | per-host DNS entries (e.g. debian.org), if `DNS` in `exportOptions`               | see below                                                                                                                           |

| `dns-zone`                         | user-managed DNS entries (e.g. debian.net), if `DNS` in `exportOptions`           | `dnsZoneEntry`                                                                                                                      |

| `forward.alias`                    | .forward compatibilty, unused?                                                    | `uid`, `emailForward`                                                                                                               |

| `forward.alias`                    | .forward compatibility, unused?                                                   | `uid`, `emailForward`                                                                                                               |

| `group.tdb`                        | `group` file template, with only the group that have access to that host          | `uid`, `gidNumber`, `supplementaryGid`                                                                                              |

| `last_update.trace`                | timestamps of last change to LDAP, keyring and last `ud-generate` run             | N/A                                                                                                                                 |

| `mail-callout`                     | ?                                                                                 | mailCallout                                                                                                                         |

### Authentication mechanisms

ud-ldap deals uses multiple mechanisms to authentify users and

ud-ldap deals uses multiple mechanisms to authenticate users and

machines.

 1. the web interface binds to the LDAP directory anonymously, or as

#### sudoPassword field format

The `sudoPassword` field is special. It has 4 fields seperated by

The `sudoPassword` field is special. It has 4 fields separated by

spaces:

 1. a UUID

 * `PRIVATE`: ship the `debian-private` mailing list registration file

 * `RTC-PASSWORDS`: ship the `rtc-passwords` file

 * `TOTP`: ship the `users.oath` file

 * `UNTRUSTED`: skip sudo passwords for this host unless explicitely

 * `UNTRUSTED`: skip sudo passwords for this host unless explicitly

   set

 * `WEB-PASSWORDS`: ship the `web-passwords` file

updates are possible: if (say) the `rtcPassword` fields don't match

but the `userPassword` fields do, the latter will be performed because

it is done first. It is here that unconfirmed `sudo` passwords are set

as well. It's the user's responsability to send the challenge response

as well. It's the user's responsibility to send the challenge response

by signed OpenPGP email afterwards. This script uses the `update.wml`

template.

hosts the parent metal. This is, in turn, used in Hiera to change

certain parameters, like Debian mirrors.

Note that the above fields are explicitely imported in the

Note that the above fields are explicitly imported in the

`allnodeinfo` data structure, along with `sshRSAHostKey` and

`mXRecord`, but those are not used. Furthermore, the `nodeinfo`

data structure imports all of the host's data, so there might be other

| `ud-fingerserv2.c`        | C      |     | same in C?                                                      |

| `ud-forwardlist`          | Python |     | convert `.forward` files into LDAP configuration                |

| `ud-generate`             | Python | x   | critical code path, generates all configuration files           |

| `ud-gpgimport`            | Python |     | seems unused? "Key Ring Syncronization utility"                 |

| `ud-gpgimport`            | Python |     | seems unused? "Key Ring Synchronization utility"                |

| `ud-gpgsigfetch`          | Python |     | refresh signatures from a keyring? unused?                      |

| `ud-groupadd`             | Python | x   | tries to create a group, possibly broken, not implemented by ud |

| `ud-guest-extend`         | Python |     | "Query/Extend a guest account"                                  |

`ud-ldap` keeps a full copy of all emails sent to

`changes@db.torproject.org`, `ping@torproject.org` and

`chpass@torproject.org` in `/srv/db.torproject.org/mail-logs/`. This

includes personnally identifiable information (PII) like `Received-by`

includes personally identifiable information (PII) like `Received-by`

headers (which may include user's IP addresses), user's email

addresses, SSH public keys, hashed sudo passwords, and junk mail. The

mail server should otherwise follow normal mail server logging

 * **old cryptographic primitives**: SHA-1 is used to hash `sudo`

   passwords, MD5 is used to hash user passwords, those hashes are

   communicated over OpenPGP_encrypted email but stored in LDAP in

   cleartext. There is a "hack" present in the web interface to

   clear-text. There is a "hack" present in the web interface to

   enforce MD5 passwords on logins, and the mail interface also has

   MD5 hardcoded for password resets. Blowfish and HMAC-SHA-1 are also

   MD5 hard-coded for password resets. Blowfish and HMAC-SHA-1 are also

   used to store and authenticate (respectively) LDAP passwords in the

   web interface. MD5 is used to hash usernames.

 * **rolls its own crypto**: ud-ldap ships its own wrapper around GnuPG,

   implementing the (somewhat arcane) commandline dialect. it has not

 * **rolls its own crypto**: `ud-ldap` ships its own wrapper around GnuPG,

   implementing the (somewhat arcane) command-line dialect. it has not

   been determined if that implementation is either accurate or safe.

 * **email interface hard to use**: it has trouble with standard

It seems that upstream doesn't necessarily run released code, and we

certainly don't: the above merge point had 47 commits on top of the

previous release (0.3.96). The current release, as of october 2020, is

previous release (0.3.96). The current release, as of October 2020, is

0.3.97, and upstream already has 14 commits on top of it.

The web interface is in a similar conendrum, except worse:

The web interface is in a similar conundrum, except worse:

    22 files changed, 192 insertions(+), 648 deletions(-)

### Must have

 * framework in use must be supported for the forseeable future

 * framework in use must be supported for the foreseeable future

   (e.g. not Python 2)

 * unit tests or at least upstream support must be active

 * system must be simpler to understand and diagnose

harder to migrate inside containers.

Because the current shell access provided is very limited, it is

believe migration to containers would actually be not only feasable

believe migration to containers would actually be not only feasible

but also beneficial for users, as they would possibly get more

privileges than they currently do.

   account management and self-service password change", seems

   interesting

 * [GOsa][]: "administration frontend for user administration"

 * [phpLDAPadmin][]: like phpMyAdmin but for LDAP, for "power users",

 * [phpLDAPadmin][]: like [phpMyAdmin][] but for LDAP, for "power users",

   long history of critical security issues

 * [web2ldap][]: web interface, python, still maintained, not exactly intuitive

[phpMyAdmin]: https://www.phpmyadmin.net/

[ldap-user-manager]: https://github.com/wheelybird/ldap-user-manager

It might be simpler to rewrite `userdir-ldap-cgi` with [Django][], say

using the [django-auth-ldap][] authentication plugin.