Best Practices

Intended Audience: System architects, developers and system administrators

1. Names and identifiers
   1. User names
      1. Personal accounts
      2. Tool/service accounts
   2. Host entries
   3. User group names
   4. Service group names
2. Security considerations
   1. Using tool/service accounts (aeService)
3. Æ-DIR setup
   1. Networking
   2. Host names

Names and identifiers

User identifiers

The user name of an account is stored in attribute uid and the POSIX-UID is stored in attribute uidNumber.

Recommendations for user names and POSIX-UIDs:

• Must be globally unique!
• Must never be reused to preserve audit trails and file ownership of file archive!
• Only lower-cased user names!
• Avoid using non-ASCII user names and other special characters.

Personal accounts

Recommendations for user names (attribute uid) in aeUser entries:

• Do not derive user names from the person's name.
• It's probably a good idea to let Æ-DIR create short random ASCII-letter user names.

Tool/service accounts

Recommendations for user names (attribute uid) in aeService entries:

• Choose a naming scheme to easily distinguish tool/service accounts from personal user accounts.
• Use singular form in user name.

Examples:

• example-test-system-1
• example-test-system-2
• example-web-server
• example-host-42

Host entries

Recommendations for host names in aeHost entries:

• Attribute host in aeHost entries should contain the canonical hostname returned by command hostname -f.
• Ideally make sure that the left-most DNS label of the canonical hostname is globally unique and in case of virtual machine matches the dom(ain) name.
• In any case provide a globally unique machine name added to attribute cn in aeHost entry.
• If you plan to issue X.509 TLS client certs for host authentication make sure to put the unique canonical hostname in the certificate's subject DN.

User group names

General recommendations for user group names (attribute cn) and POSIX-GID (attribute gidNumber) in aeGroup entries:

• Must be globally unique!
• Must never be reused to preserve audit trails and file ownership of file archive!

More on group names:

• Only lower-cased group names!
• Choose a word easily associated with the user group's members,
• Use plural form in group name.
• It's probably a good idea to derive group names from unique organizational identifiers, e.g. project IDs etc.

Examples:

• example-sys-admins-1
• example-db-admins
• example-console-users-42

Service group names

Recommendations for service group names (attribute cn) aeSrvGroup entries:

• Choose a word easily associated with the service group's members, e.g. example-test-systems-23 or example-db-hosts-42.
• Use plural form in group name.

Examples:

• example-test-systems-23
• example-http-services
• example-db-hosts-42

Security considerations

Using tool/service accounts (aeService)

Some general recommendations if you really cannot avoid using tool/service accounts acting as clients:

• Add an aeService entry with attribute sshPublicKey and do not use passwords.
• Use separate aeService entries with different SSH private keys for your different environments and service instances. This avoids having to shut-down all your tools in case a widely used private key was compromised.
• Set login shell to /usr/sbin/nologin or similar if shell access with invoking commands is not needed.
• Use fine-grained ownership/permissions for all files to be accessed.
• Avoid using sudo for tool accounts!
• If you cannot avoid using sudo:
  • Never ever grant such a "tool user" full root access!
    Rather grant the minimum required rights by defining fine-grained sudoers rules.
  • For this add a separate aeGroup entry used by specific aeSudoRule.
  • If you set attribute sudoOptions: !authenticate for password-less sudo then take care that this particular rule cannot be used by personal user accounts!
• Consider limiting SSH commands by ForceCommand in the host's sshd_config.
• Consider setting the client's IP address(es) in attribute aeRemoteHost in the tool's aeService entry.
  This results in key option from=.. being added by search_authorized_keys.py to the authorized key which restricts the usage of the private key to these address(es) (see sshd(8), section "AUTHORIZED KEYS FILE FORMAT").

Æ-DIR setup

In general Æ-DIR's access control does not care about DNS names or network configuration at all. But it's a good idea to have separate DNS domains and network configuration.

Networking

Recommendations:

• You should put your Æ-DIR servers into separate network(s) (IP address range, VLAN). It is recommended to even place provider and consumer replicas into separate networks because they provide services to different clients.
• Add host-based firewall rules to your Æ-DIR servers!
• Adjust the ansible variables apache_*_requires for IP-based access control to web applications.

Host names

Hostnames should not match any wild-card certificate you are using!

Besides general recommendations some more:

• Don't forget to add correct reverse DNS entries (PTR RRs) required for correctly creating LDIF data for initial load.
• The hostnames should at least contain one dot. Otherwise Chrome web browser won't accept/return cookies.
• It's helpful to encode the Æ-DIR slapd role into the host names.
• Make sure to use a numbering scheme which allows you to add more replicas for each role without having to invent new host naming scheme.
• It is recommended to add the value of ansible variable openldap_server_id to the hostname of provider hosts.

If you have fine-grained access control for delegated sub domains in your DNS server then it's a good idea to use separate sub domains (forward and reverse) and strictly delegate control to Æ-DIR system admins (members of group ae-sys-admins). Sub-domains also avoid accidentally matching wild-card certificates issued to your domains.

Example sub-domain: ae-dir.example.com

Examples:
ae-dir-p1.ae-dir.example.com for a provider with openldap_server_id=1
ae-dir-c2.ae-dir.example.com for a consumer