... | @@ -592,6 +592,47 @@ More files are handled specially by `ud-replicate`: |
... | @@ -592,6 +592,47 @@ More files are handled specially by `ud-replicate`: |
|
.. and the appropriate service (`freeradius`,
|
|
.. and the appropriate service (`freeradius`,
|
|
`resiprocate-turn-server`, `prosody`, respectively) get reloaded
|
|
`resiprocate-turn-server`, `prosody`, respectively) get reloaded
|
|
|
|
|
|
|
|
### Authentication mechanisms
|
|
|
|
|
|
|
|
ud-ldap deals uses multiple mechanisms to authentify users and
|
|
|
|
machines.
|
|
|
|
|
|
|
|
1. the web interface binds to the LDAP directory anonymously, or as
|
|
|
|
the logged in user, if any. an encrypted copy of the
|
|
|
|
username/password pair is stored on disk, encrypted, and passed
|
|
|
|
around in a URL token
|
|
|
|
2. the email gateway runs as the `sshdist` user and binds to the LDAP
|
|
|
|
directory using the `sshdist`-specific password. the `sshdist`
|
|
|
|
user has full admin rights to the LDAP database through the slapd
|
|
|
|
configuration. commands are authenticated using OpenPGP
|
|
|
|
signatures, checked against the keyring, maintained outside of
|
|
|
|
LDAP, manually, in the `account-keyring.git` repository, which
|
|
|
|
needs to be pushed to the LDAP server by hand.
|
|
|
|
3. `ud-generate` runs as the `sshdist` user and binds as that user
|
|
|
|
to LDAP as well
|
|
|
|
4. `ud-replicate` runs as root on all servers. it authenticates with
|
|
|
|
the central LDAP server over SSH *using the SSH server **host**
|
|
|
|
private key as a user key*, and logs in to the SSH server as the
|
|
|
|
`sshdist` user. the `authorized_keys` file for that user on the
|
|
|
|
LDAP server (`/etc/ssh/userkeys/sshdist`) determines which files
|
|
|
|
the client has access to using a predefined `rsync` command which
|
|
|
|
restricts to only `/var/cache/userdir-ldap/hosts/$HOST/`
|
|
|
|
5. Puppet binds to the LDAP server over LDAPS using the custom CA,
|
|
|
|
anonymously
|
|
|
|
6. LDAP admins also have access to the LDAP server directly, provided
|
|
|
|
they can get a shell (or a port forward) to access it
|
|
|
|
|
|
|
|
This is not related to ud-ldap authentication itself, but ud-ldap
|
|
|
|
obviously distributes authentication systems all over the place:
|
|
|
|
|
|
|
|
* PAM and NSS usernames and passwords
|
|
|
|
* SSH user authentication keys
|
|
|
|
* SSH server public keys
|
|
|
|
* `webPassword`, `rtcPassword` and so on
|
|
|
|
* email forwards and email block list checks
|
|
|
|
* DNS zone files (which may include things like SSH server public
|
|
|
|
keys, for example)
|
|
|
|
|
|
### SSH access controls
|
|
### SSH access controls
|
|
|
|
|
|
A user gets granted access if it is part of a group that has been
|
|
A user gets granted access if it is part of a group that has been
|
... | @@ -964,7 +1005,8 @@ datastructure imports all of the host's data, so there might be other |
... | @@ -964,7 +1005,8 @@ datastructure imports all of the host's data, so there might be other |
|
fields in use that I haven't found.
|
|
fields in use that I haven't found.
|
|
|
|
|
|
Puppet connects to the LDAP server directly over LDAPS (port 636) and
|
|
Puppet connects to the LDAP server directly over LDAPS (port 636) and
|
|
therefore requires the custom LDAP host CA.
|
|
therefore requires the custom LDAP host CA, although it binds to the
|
|
|
|
server anonymously.
|
|
|
|
|
|
### DNS zone file management
|
|
### DNS zone file management
|
|
|
|
|
... | | ... | |