Documentation
Intended Audience: System architects, developers and system administrators
- Design paradigms
- System architecture
- Roles and Access Rights
- Directory Information Tree (DIT)
- Entity Relationship
- Schema
- OpenLDAP configuration (slapd.conf)
- Hardening
Design paradigms
- Explicit is better than implicit
- Secure authorization requires secure authentication
- No anonymous access at all
- Individual authentication instead of shared credentials
- Avoid all-mighty proxy roles
- Rights assignment / permission granting always based on groups
- Do not assume hierarchical structure
- A person is not an user account
- Role separation with multiple user accounts per person
- Persistent IDs (never re-used) for reliable audit trails
- Only encrypted network traffic
- Well-defined semantics for all object classes and attributes (better no data than bad data)
System architecture
A two-tier replication topology is implemented for separated access:
- Administrators and their tools who maintain entries access the writeable Æ-DIR providers.
- Applications and systems using Æ-DIR access the read-only Æ-DIR consumers.
Æ-DIR provider
For maintaining entries the Æ-DIR provider are used.
The following roles may access Æ-DIR provider:
Note: It is recommended to restrict network access to IP networks used by the roles above.
The following system components are running on each Æ-DIR provider system:
- slapd provider
- OpenLDAP's slapd acting as roles Æ Replica and Æ Provider (see also provider configuration)
- web2ldap
- web2ldap is a web-based LDAPv3 client to access and maintain LDAP servers. It is used as Æ-DIR's main admin user interface. Check out the documentation to find out about fine-tuning, customizing etc.
- aedir_pproc.pwd.web
- aedir_pproc.pwd.web is a small web application for password self-service (see user guide for instructions how to use it).
- oathenroll
- oathenroll is a small web application for resetting and preparing HOTP token entries (see OATH-LDAP docs).
- CRON jobs
-
Various small Python programs are running as CRON job
performing the following tasks:
- remove expired password reset attributes
- send welcome e-mails to new users especially with password reset instructions
- send password expiry warning e-mails to users
- update person name attributes in personal user accounts
- deactivate personal user accounts for deactivated persons
- deactivate expired entries
- update user groups defined with member search parameters
- custom sync jobs for retrieving person and organization data from HR
- OATH-LDAP HOTP validator
- A slapd-sock listener which verifies LDAP simple bind operations with user password and HOTP (two-factor authentication).
Æ-DIR consumer
All integrated hosts and services query the Æ-DIR consumers for accessing user and group entries and checking user passwords. Write access to consumers is deliberately disallowed. All write operations must be sent to the Æ-DIR provider systems.
The following roles may access Æ-DIR provider:
Note: It is recommended to restrict network access to IP networks used by the roles above.
The following system components are running on each Æ-DIR consumer system:
- slapd consumer
- OpenLDAP's slapd acting as role Æ Replica (see also consumer configuration)
- OATH-LDAP bind proxy
- A slapd-sock listener for proxying LDAP simple bind operations for two-factor authentication to a writeable provider.
Roles
This chapter gives a high-level overview over the different roles and their access rights in Æ-DIR. See chapter access control for technical details.
Æ Admin
Æ admins (role assigned by membership in group ae-admins) directly manage all Æ-DIR systems and therefore have full write access (including manage privilege) to all LDAP entries. Furthermore this role has full read access to the audit database.
Typically the Æ admins are not expected to know the systems using Æ-DIR or the users in detail. Therefore Æ admins are advised not to perform daily maintenance tasks except those directly related to Æ-DIR systems.
Typical tasks:
- add/modify zone entries (see aeZone)
- entitle Æ auditors
- entitle zone admin(s) in new or orphaned zones and help them with password reset procedure
- add/modify/remove replicas
Exceptional tasks (requires careful consideration):
- tasks usually done by zone admin(s)
- add/modify password policies (possibly also requires modification of system configuration)
- repair broken entries which requires circumventing constraints and therefore needs manage privilege
Æ Auditor
Æ auditors (role assigned by membership in group ae-auditors) have full read access to all LDAP entries including the audit database. Even when added to another user group members of group ae-auditors will not gain any write access.
Typical tasks:
- review normal entries to ensure compliance to internal security policies
- search accesslog database(s) to clarify impact of possible security incidents
Zone Admin
Zone admins have full write access (but no manage privilege) to all entries within a zone. Typically they perform the daily data maintenance tasks.
The role is assigned to a user account by adding it to a user group with name *-zone-admins which is referenced by attribute aeZoneAdmins in the aeZone entry.
Typical tasks:
- entitle other zone admin(s)
- entitle zone auditor(s)
- add/modify personal user accounts (aeUser)
- help the users with password reset procedure for their personal user accounts (aeUser)
- add/modify service accounts for client systems (aeService)
- add/modify user groups (aeGroup)
- add/modify/delete server/service groups (aeSrvGroup)
- add/modify/delete service accounts (aeService) or hosts/servers (aeHost) within a server/service group
People Admin
Zone admins in the special zone people are People Admins and can write organizational entries (aePerson, aeDept and aeLocation) and maintain organizational management relationships.
Zone Auditor
Zone auditors have full read access to all entries within a zone. Typically zone auditors need to read entries to reference them from another zone where they act as zone admin.
The role is assigned to a user account by adding it to a user group with name *-zone-admins or *-zone-auditors which is referenced by attribute aeZoneAuditors in the aeZone entry.
Typical tasks:
- review normal entries to ensure correct functional behaviour
Setup Admin
Setup admins can maintain (add/modify/delete) member hosts/services of a service group typically while setting up a hosts/services instances. They can read but not write the service group (aeSrvGroup) entry. The role is assigned by adding a user to a user group referenced in attribute aeSetupGroups in the service group (aeSrvGroup).
Typical tasks:
- add/modify/delete entries for hosts (aeHost) and services (aeService)
- set LDAP client configuration of services
- prepare OS deployment (kickstart, seed, autoyast, etc.) with host credential (host or client cert)
- configure hosts/services (e.g. via puppet, ansible, etc.)
Æ User
Normal Æ users can read their own person and user entries including own group membership and all user entries which are in at least one common user group. Users can set their own password but cannot read it.
Æ client service
Æ client services
Æ server service
Æ server services
Æ host
Æ host
Æ Replica
The system role Æ replicas can read all entries including userPassword except some sensitive attributes only usable by role Æ provider.
The role is assigned to service accounts (aeService) of all provider and replica slapd instances by adding them to user group ae-replicas.
Æ Provider
Additionally to the rights assigned to role Æ replica the role Æ provider has read access to:
- organizational entries
- some more credential attributes (e.g. shared secrets used for two-factor authentication and password history)
The role is assigned to service accounts (aeService) of all provider slapd instances by adding them to user group ae-providers.
Æ Login Proxy
The system role Æ login proxy can read all attributes in user, group, service group and service group member entries needed for determining user role relationship.
The role is typically assigned solely to central service accounts (aeService) in zone ae by adding them to user group ae-login-proxies.
Directory Information Tree (DIT)
ou=ae-dir
The following diagram illustrates the directory information tree (DIT) structure of Æ-DIR in naming context ou=ae-dir where all Æ-DIR entities are stored as separate LDAP entries. The nodes contain the relative distinguished name (RDN) and the structural object class used for that entry. The tree structure is also formally specified (within web2ldap's configuration) with DIT structure rules and name forms.
cn=ae,ou=ae-dir
Zone ae is used for administration of Æ-DIR itself. Therefore some special restrictions apply.
| RDN | Description | Structural object class |
|---|---|---|
| cn=ae-admins | Group members can manage all Æ-DIR entries (see also role Æ Admin) | aeGroup |
| cn=ae-auditors | Group members can read all Æ-DIR entries (see also role Æ Auditor) | aeGroup |
| cn=ae-all-zone-admins | Æ-DIR user group entry updated by a CRON job to contain all active zone admins (see also role Zone Admin) | aeGroup |
| cn=ae-all-zone-auditors | This Æ-DIR user group entry is updated by a CRON job to contain all active zone auditors (see also role Zone Auditor) | aeGroup |
| cn=ae-dir-provider-hosts | Server group for all AE-DIR provider hosts | aeSrvGroup |
| cn=ae-dir-consumer-hosts | Server group for all AE-DIR consumer hosts | aeSrvGroup |
| cn=ae-login-proxies | Members are central login (proxy) components which are allowed to see all users/groups and must determine login user/target relation themselves (see also role Æ Login Proxy) | aeGroup |
| cn=ae-replicas | Members of this group are AE-DIR replicas including providers and consumers (see also role Æ Replica) | aeGroup |
| cn=ae-providers | Members of this group are AE-DIR provider replicas (see also role Æ Provider) | aeGroup |
| cn=ae-sudo-sys-admins | allows su - root for AE-DIR system admins (group ae-sys-admins) |
aeSudoRule |
| cn=ae-sys-admins | Members are system admins for AE-DIR servers | aeGroup |
| cn=ae-uid-badwords | This entry contains a list of bad words not allowed in 'uid' values. You have to add this list yourself. | namedObject |
| cn=ae-uid-reserved | This entry contains a list of reserved 'uid' values not allowed for normal accounts | namedObject |
| cn=ppolicy-base-users | Password policy for primary personal user accounts (aeUser) in zone base | aePolicy |
| cn=ppolicy-default | Unusable default password policy | aePolicy |
| cn=ppolicy-otptokens | Password policy for OTP enrollment | aePolicy |
| cn=ppolicy-sasl-external | Password policy for services which must use SASL/EXTERNAL (mainly disallows using simple bind with password) | aePolicy |
| cn=ppolicy-systems | Password policy for hosts and system/service accounts (aeHost and aeService) | aePolicy |
| cn=ppolicy-users | Password policy for personal user accounts (aeUser) | aePolicy |
| uid=ae-dir-otpenroll | Service account for two-factor enrollment application (based on OATH-LDAP) | aeService |
| uid=ae-dir-otpverify | Service account for OATH-LDAP validator demon | aeService |
| uid=ae-dir-pwd | Service account for password self-service application and CRON job | aeService |
cn=people,ou=ae-dir
Zone people is used for storing organizational entries. These can be maintained manually or could be synced with a HR system or similar if appropriate. Make sure to avoid hen-and-egg issues when syncing entries. Manual maintenance is done by role People Admin.
cn=pub,ou=ae-dir
Zone pub contains entries which are globally readable by all authenticated clients and maintained by role Æ Admin:
| RDN | Description | Structural object class |
|---|---|---|
| cn=sudo-defaults | sets sudoers defaults | sudoRole |
| cn=pub-tag-no-welcome-yet | tag used with aeUser entries indicating that welcome e-mail was not sent to user yet | aeTag |
| cn=dua-profile | client configuration profile (see RFC 4876) | DUAConfigProfile |
Entity Relationship
The following diagram illustrates how the different entities in Æ-DIR are referenced from each other. This entity relationship is evaluated by the OpenLDAP ACLs to determine access rights of bound entity.
- A reference is set by adding an appropriate value to a link attribute.
- Cross-zone references are allowed for cross-zone delegation (except aeProxyFor and aeSrvGroup → )
- Almost all references by distinguished name of referenced entry (except sudoUser → aeGroup by prefixed group name for backward compatibility)
-
Sometimes references are implicit by tree structure (child of):
- ae* → aeZone
- aeHost or aeService → aeSrvGroup
Role References
The following smaller diagram shows only references for assigning Æ-DIR roles.
Setting cross-zone references allow zone admins to delegate tasks to zone admins of other zones:
-
Strictest level for preservation of full control:
Users, user groups, service groups and services / hosts all in one zone. This gives the responsible zone admins full control over all authentication and authorization but also places the burden of having to maintain all these entries on them.
This model should be used for hosts/services with high security requirements with access probably only for rather few administrators. -
Preservation of permissions control,
user maintenance delegation to foreign zone:
A zone admin can add users located in foreign zones to user groups in their zone. The rights to assign permissions to users is preserved but user maintenance (e.g. helping with password reset) is delegated to foreign zone admins.
This model is reasonable for most hosts/services.
The cross-zone reference link from aeGroup to aeUser/ aeService. -
Full foreign zone delegation of user and permission group
maintenance:
Delegating permission assignment (granted by group membership) can be achieved by referencing user groups in another zone from a server group. Note that different permissions are assigned by different link attributes and application-specific permissions for groups within services.
This model is reasonable for most hosts/services.
The cross-zone reference link from aeSrvGroup to aeGroup.
Example
Here is a diagram which shows an example of the various entries and their references stored in: test on demo server :
Schema
Attribute Types
The following diagram shows the attribute type hierarchy:
Structural Object Classes
For each entity in Æ-DIR there is a distinct structural object class (see also RFC 4512 section 2.4.2). All Æ-DIR object classes are derived from multiple abstract and structural object classes defined in various other standards.
The following diagram shows the object class hierarchy:
The structural object classes are also referenced in the accompanying…
- DIT content rules using NOT and AUX (see RFC 4512 section 4.1.6)
- DIT structure rules and name forms for enforcing the DIT (see RFC 4512 section 4.1.7)
- constraints enforcing the entity relationship
| NAME | RDN | DESC | SUP | AUX |
|---|---|---|---|---|
| aeAuthcToken | cn | Authentication token device | aeDevice |
|
| aeContact | cn | Mail contact |
|
|
| aeDept | departmentNumber | department / organization unit |
|
labeledURIObject |
| aeGroup | cn | user group |
|
-/- |
| aeHost | host | host information and for host authentication | aeDevice |
|
| aeLocation | cn | location |
|
labeledURIObject |
| aeMailGroup | cn | user group |
|
|
| aeNwDevice | cn | Network device information | aeDevice |
|
| aeObject | -/- | abstract meta class | -/- | |
| aePerson | uniqueIdentifier | personal information |
|
msPerson |
| aePolicy | cn | Policy information |
|
|
| aeRoot | ou | root entry of Æ-DIR tree |
|
aePosixIdRanges |
| aeService | uid | service user account |
|
|
| aeSrvGroup | cn | host/service group |
|
-/- |
| aeSudoRule | cn | sudoers entry |
|
-/- |
| aeTag | cn | tag name-description mapping | namedObject | -/- |
| aeUser | uid | personal user account |
|
|
| aeZone | cn | zone (delegation container) |
|
aePosixIdRanges |
aeObject
aeObject is an abstract object class, which only contains some common meta data attributes, to be available in all entries as described in the following list:
- description
- Must / should contain short description of the purpose / reason / usage of an entry. Especially this attribute is very often displayed as pop-up title in web2ldap.
- aeStatus
-
The current status of an entry:
Value Meaning Usage -1 requested Especially useful for adding an entry without making it directly usable, e.g. in case a confirmation is needed. 0 active In this state an entry is visible depending on the normal ACLs. 1 deactivated In this state an entry is still visible for zone admins/auditors but is not usable on systems/services. The entry can be set to active by zone admins if no other constraint disallows it. 2 archived In this state an entry is invisible even for zone admins/auditors and some attributes might already been stripped off due to privacy regulations. Which attributes are stripped is to be defined as local policy. 
- aeExpiryStatus
- If set this triggers auto-expiration of entries and specifies the value to which aeStatus is set when aeNotAfter is in the past.
- aeTicketId
- This attribute is used to record the bug/issue tracker ID of the last change applied to an entry.
- Validity period
-
Two attributes define the time period in which an entry can be used:
- aeNotBefore
- The entry must not be actively used before this timestamp.
- aeNotAfter
- The entry must not be actively used after this timestamp.
Validity period aeStatus aeNotBefore <= [current time] <= aeNotAfter requested (-1)
active (0)
deactivated (1)
archived (2)[current time] > aeNotAfter (expired) deactivated (1)
archived (2)[current time] < aeNotBefore requested (-1)
- aeTag
- This attribute contains names (attribute cn) of aeTag entries useful for marking various entries across zones or other boundaries. This eases searching for entries which are used together to provide a certain service.
aeRoot
The object class aeRoot is solely used for locating an Æ-DIR tree within another tree of other entries. Especially it also serves as start point to Æ-DIR's specific DIT structure rules and name forms.
- description
- set to "Æ-DIR - Authorized Entities Directory"
- ou
- usually set to ae-dir resulting in naming context / search root ou=ae-dir
- meta attributes
- see aeObject
aePolicy
The object class aePolicy is used for policy / security parameter entries. The real effective policy parameters are supposed to be attributes of AUXILIARY object classes added to the entry.
- cn
- common name of policy
- description
- Must contain short description of the purpose / meaning / scope of the policy
- meta attributes
- see aeObject
aeDept
The object class aeDept is used for entries for departments or units within an organization.
- departmentNumber
- Unique identifier / short name of department / organizational unit
- ou
- Descriptive name of department / organizational unit
- organizationalUnit attributes
- see RFC 4519 section 3.11
- meta attributes
- see aeObject
aeLocation
The object class aeLocation is used for entries representing geographic locations (offices, data centers) which are referenced from aePerson or aeHost entries to indicate the current location of these objects.
- cn
- Short name of location
- locality attributes
- see RFC 4519 section 3.7
- meta attributes
- see aeObject
aeTag
The structural object class aeTag is used to create tagging entries mapping an arbitrary name (RFN attribute cn) to a meaningful usage definition in attribute description.
- description
- Must contain short description of the purpose / meaning of a tag.
- cn
- Name of the tag.
- aeStatus
- Status of tag (see aeStatus values and their meaning)
aeZone
Entries of object class aeZone are simply used as container for delegated administration. Besides the meta attributes and the zone name in attribute cn for forming the RDN there are no other attributes therein.
- cn
- Name of the zone. For the sake of clarity the value in cn must also be used as prefix of attribute cn in these subordinate entries:
- aeDept
- Associated departments referenced by DN of aeDept entry. If set, this constraints the set of persons, for which aeUser entries can be added within this zone to matching department members.
- aeLocation
- Associated locations referenced by DN of aeLocation entry. If set, this constraints the set of persons, for which aeUser entries can be added within this zone to same location(s).
- meta attributes
- see aeObject
- aeZoneAdmins
-
Distinguished names of all aeGroup entries which's members
act with role zone admin for the zone.
Constraint enforces that the group exists, is active and has name (attribute cn) of the form *-zone-admins. - aePasswordAdmins
-
Distinguished names of all aeGroup entries which's members
are allowed to change password of aeUser
entries and thus circumventing the password reset process.
Constraint enforces that the values are a subset of aeZoneAdmins. - aeZoneAuditors
-
Distinguished names of all aeGroup entries which's members
act with role zone admin for the zone.
Constraint enforces that the group exists, is active and has name (attribute cn) of the form *-zone-admins or *-zone-auditors.
aePerson
Person entries are added using object class aePerson. Note that such an entry is not a user account and thus cannot authenticate to a the directory.
Despite the object class name aePerson these entries rather represent contracts with persons (e.g. employment/freelancing/customer contracts, or some other user subscription) than persons. Thus it is highly recommended to maintain the attributes aeNotBefore and aeNotAfter to represent the contract period.
Typically aePerson are maintained by human resource (HR) or sales departments (for customers), optionally synchronized from HR database or a customer relationship management (CRM) database or similar.
- uniqueIdentifier
- Unique primary key possibly possibly used for synchronisation with HR or CRM systems (e.g. contract number). This attribute is readable to various roles and thus is not really considered confidential.
- employeeNumber
- Another unique primary key possibly used for synchronisation but subject to stricter access control due to privacy regulations for HR databases.
- inetOrgPerson attributes
- A limited subset of the widely used attributes defined in RFC 2798.
- meta attributes
- see aeObject
aeUser
Accounts for persons are created by using object class aeUser. For compatibility reasons with existing software aeUser is derived from the superior object classes account and inetOrgPerson. This object class must not be used when creating system/service/tool accounts. For these use aeService instead.
- uid
- unique username / user-ID of the personal account
- aePerson
- DN of the associated aePerson entry
- aePerson attributes
-
The following name attributes values are copied from the accompanying
aePerson name attributes:
- sn
- givenName
- cn
- aeRemoteHost
- remote host (client IP or FQDN) used during login
- meta attributes
- see aeObject
aeGroup
User groups are created using object class aeGroup. This hybrid group object class is derived from two structural group object classes:
- groupOfEntries
- replacement for groupOfNames which permits empty groups (see draft-findlay-ldap-groupofentries)
- posixGroup
- multiple attributes required for POSIX groups used for Unixoid operating systems (see RFC 2307)
The following attributes are used in aeGroup entries:
- cn
- unique group name
- gidNumber
- unique numerical POSIX GID for the group
- member
- Distinguished names of all member entries
- memberUid
- uid values of all member entries
- aeDept
- Associated departments referenced by DN of aeDept entry. If set, this constraints the set of persons whose aeUser entries can be added to the group.
- aeLocation
- Associated locations referenced by DN of aeLocation entry. If set, this constraints the set of persons whose aeUser entries can be added to the group.
- meta attributes
-
- see aeObject
- When aeStatus is set to archived (2) all group members will be removed, which means attributes member and rfc822MailMember will be deleted.
aeMailGroup
Mail groups are created using object class aeMailGroup. This hybrid group object class is derived from two structural group object classes:
- groupOfEntries
- replacement for groupOfNames which permits empty groups (see draft-findlay-ldap-groupofentries)
- nisMailAlias
- for adding list of members' mail addresses
The following attributes are used in aeMailGroup entries:
- cn
- unique group name
- member
- Distinguished names of all member entries
- rfc822MailMember
- mail values of all member entries
- aeDept
- Associated departments referenced by DN of aeDept entry. If set, this constraints the set of persons whose aeUser entries can be added to the group.
- aeLocation
- Associated locations referenced by DN of aeLocation entry. If set, this constraints the set of persons whose aeUser entries can be added to the group.
- meta attributes
-
- see aeObject
- When aeStatus is set to archived (2) all group members will be removed, which means attributes member and rfc822MailMember will be deleted.
aeSrvGroup
In general a service group contains service instances which are
together providing a service and are thus considered subject to unified
administrative rules. So for each service providing a user login a
service group entry has to be added with object class
aeSrvGroup. Likely a clustered service consists of multiple
hosts or other services which are called the members of the service
group.
Service group entries have the following attributes:
- cn
- unique service group name
- aeLoginGroups
- Distinguished names of all aeGroup entries which's members have the right to login to the members of the service group
- aeLogStoreGroups
- Distinguished names of all aeGroup entries which's members have the right to access the centrally stored logs of the members of the service group
- aeLogStorePeriod
- aeRequires
- Distinguished names of all aeSrvGroup this service group depends on for providing its own service.
- aeProxyFor
- Distinguished names of all aeSrvGroup for which this service group acts as proxy (must be within same zone)
- aeSetupGroups
- Distinguished names of all aeGroup entries which's members have the right to setup the members of the service group
- aeVisibleGroups
- Distinguished names of all aeGroup entries visible with their member accounts on all members of the service group
- aeDisplayNameGroups
- Distinguished names of all aeGroup entries define for which member accounts person attributes are visible for all service group members
- aeVisibleSudoers
- Distinguished names of all aeSudoRule entries visible on all members of the service group
- meta attributes
- see aeObject
aeSudoRule
sudoers rules are stored in entries of object class aeSudoRule. The attributes are compatible to those defined for sudo-ldap plus the meta information of aeObject and some constraints.
- cn
- unique rule name
- sudo-ldap attributes
-
See sudo-ldap documentation:
Notes:
- The attribute sudoUser is constrained to only contain the name of a group (cn of an aeGroup entry) prefixed with a single percent character.
- You must set attribute sudoHost to ALL because restricting sudoers rules to hosts is better achieved by restricting visibility in the service group (attribute aeVisibleSudoers in aeSrvGroup entry).
- meta attributes
- see aeObject
aeService
Object class aeService is used for creating accounts for services (sometimes called tool / machine / system account or similar). The service must authenticate by using bind-DN/password or TLS client cert. aeService entries may have a password (attribute userPassword) to authenticate to Æ-DIR. X.509 client certificate(s) may be associated by adding AUX object class pkiUser and setting the attribute seeAlso to the client certs subject-DN.
Two possible usage types (roles):
- Member of aeGroup to access other resources as client (similar to aeUser for humans).
- Member of aeSrvGroup to access user/group information when providing a service to users.
- uid
- unique username / user-ID of the system account
- cn
- unique service name
- aeSrvGroup
- distinguished names of aeSrvGroup entries this service is also member of
- aeHost
- distinguished name of aeHost entry for the system this service is running on
- aeRemoteHost
- remote host (client IP or FQDN) used during login
- meta attributes
- see aeObject
aeHost
Object class aeHost for host systems with login service for the operating system on this host.
- Hosts are at least member of the superior aeSrvGroup entry.
- Hosts can be member of other aeSrvGroup entries by adding those to the aeSrvGroup attribute.
- Hosts must not be a member of aeGroup entry.
- The host must authenticate by using bind-DN/password or TLS client cert.
- Entries may have a password (attribute userPassword) to authenticate to Æ-DIR.
- X.509 client certificate(s) may be associated by adding AUX object class pkiUser and setting the attribute seeAlso to the client certs subject-DN.
- SSH host keys may be associated by using AUX object class ldapPublicKey and setting the attribute sshPublicKey.
- host
- unique canonical hostname (FQDN)
- aeSrvGroup
- distinguished names of aeSrvGroup entries this host is also member of
- aeRemoteHost
- remote host (client IP or FQDN) used during login
- meta attributes
- see aeObject
aeAuthcToken
Object class aeAuthcToken is used to add entries for personal authentication (OTP) token devices (e.g. yubikey).
- cn
- Device name
- serialNumber
- unique serial number (most times aeHwSerialNumber with prefix)
- aeHwSerialNumber
- vendor-specific serial number (not necessarily unique)
- aeStockId
- inventory number used for warehousing
- meta attributes
- see aeObject
aeNwDevice
Object class aeNwDevice is used to add entries subordinate to aeHost entries for network devices available on that particular host system.
- cn
- OS-assigned device name of network device
- aeFqdn
- fully qualified domain name (FQDN) of IP address(es) assigned to this device
- aeNwDevice
- DN reference to another aeNwDevice entry, e.g. to be used for bridge/virtual interfaces without macAddress attribute (constrained to DNs beneath same superior aeHost)
- ipHostNumber
- the IP address(es) of the network interface which must match the DNS lookup of values in attribute aeFqdn
- macAddress
- the hardware MAC address of the network interface
- bootFile
- which PXE file to load via TFTP
- bootParameter
- OS-specific boot parameters
- meta attributes
- see aeObject
Auxiliary Object Classes
Various auxiliary object classes are used to provide supplemental attributes. The DIT content rules defined for structural object classes restrict which auxiliary object classes can be added to an entry (see also table of structural object classes).
posixAccount
The auxiliary object class posixAccount contains multiple attributes required for POSIX login to Unixoid operating systems (see RFC 2307).
The following posixAccount attributes are always added to aeUser and aeService entries:
- uidNumber
- gidNumber
- homeDirectory
- loginShell
inetLocalMailRecipient
The auxiliary object class inetLocalMailRecipient contains multiple attributes used for SMTP e-mail routing (see draft-lachman-laser-ldap-mail-routing).
The following inetLocalMailRecipient attributes are optionally added to aeUser and aeService entries to turn these entries into a mailbox account:
- mailLocalAddress
pkiUser
The auxiliary object class pkiUser is used (see RFC 4523) to mark an system or personal account for being used with TLS client authentication.
The following pkiUser attribute is optionally added to aeUser, aeService or aeHost entries:
- userCertificate
aeSSHAccount
The auxiliary object class aeSSHAccount is used to store SSH public keys and SSH key options and is derived from object class ldapPublicKey (see openssh-ldap-publickey).
The following aeSSHAccount attribute can be optionally added to aeUser and aeService entries:
- aeSSHPermissions
- sshPublicKey
OpenLDAP configuration (slapd.conf)
The OpenLDAP server process (slapd) is configured with a single static
configuration file located at /opt/ae-dir/etc/openldap/slapd.conf
which is generated during installation and potentially modified during
each ansible play, e.g. when adding replicas, tweaking security
settings or similar.
See format description: slapd-config(5)
slapd replica roles
slapd provider
An slapd provider is a writeable replica which holds the complete data including sensitive data like OTP shared secrets. In the default configuration all providers have fully-meshed multi-provider replication configured.
slapd consumer
An slapd consumer is a read-only replica and is used by the hosts and services using Æ-DIR. Some sensitive data like OTP shared secrets is not replicated to consumers because it cannot be used there.
Database backends
Different backends are used on all slapd instances listed in the following table.
| Suffix | No. | Description | Backend |
|---|---|---|---|
| cn=config | 0 | used in read-only mode for retrieving configuration (e.g. for monitoring) | slapd-config(5) |
| cn=accesslog-ae-dir | 1 | Real database storage backend available only on providers for storing audit log entries of all write operations. The schema is formally specified in the Internet draft draft-chu-ldap-logschema. | slapd-mdb(5) |
| ou=ae-dir | 2 | Real database storage backend used for Æ-DIR itself (see details) | slapd-mdb(5) |
| cn=monitor | used for retrieving performance monitor data | slapd-monitor(5) |
Overlays
Various overlays are configured on all replicas:
- slapo-memberof
- (see also slapo-memberof(5))
- slapo-accesslog
- used on providers to log all write operations to the separate naming context cn=accesslog-ae-dir (see also slapo-accesslog(5))
- slapo-rwm
- (see also slapo-rwm(5))
- slapo-syncprov
- (see also slapo-syncprov(5))
- slapo-allowed
- slapo-lastbind
- slapo-ppolicy
- (see also slapo-ppolicy(5))
- slapo-noopsrch
- slapo-deref
- (see also slapo-deref(5) and draft-masarati-ldap-deref )
- slapd-sock
- When using two-factor authentication bind requests are externally processed. The bind requests are passed to the external bind listeners by configuring slapd-sock(5) as overlay.
Several constraints are enforced by overlays configured on the slapd provider to ensure data consistency and some more security policies:
- slapo-unique
- Uniqueness constraints slapo-unique(5)
- slapo-constraint
- Attribute value constraints slapo-constraint(5)
- slapo-refint
- Referential integrity slapo-refint(5)
Access control
Security policies are enforced by different types of OpenLDAP ACLs:
- group
- Access rights are granted based on simple group membership.
- regex
- Access rights are granted based on DIT with distinguished names matching certain regex patterns.
- sets
- Access rights are granted based on (indirect) entity relationship by following the references from entries to other entries.
If you want to understand the ACLs in detail you should consult various on-line documentation:
- OpenLDAP 2.6 Admin Guide -- Access control
- slapd.access(5)
- FAQ-O-MATIC: Access Control
- FAQ-O-MATIC: Sets in Access Control
Hardening
AppArmor
If you set ansible variable apparmor_enabled: True then AppArmor profiles and abstractions are installed to confine all components to enforce mode on all Linux distributions supporting AppArmor (the default on Debian, Ubuntu, openSUSE/SLE, Arch Linux).
systemd
Various systemd security configuration options are used when starting services via systemd units. See ansible variable aedir_systemd_hardening for global settings.
See also: