- Client integration
- Security and Privacy
- Privacy / Data Protection
Why yet another LDAP-based user management system?
All other similar products/projects focus on making data easily available everywhere and therefore are not suitable for really strict security/confidentiality requirements. Also other systems do not have a distinct data model for person / multi-user-account relationship.
What's the official name of the project and why I see those strange characters?
The official name is Æ-DIR to be distinguishable from any other project (and to challenge Unicode capabilities of software). AE-DIR is the official pure-ASCII representation.
Only capital letters are used in both representations when occuring in documentation.
Lower-cased letters are used for DNS names (e.g. ae-dir-p1.example.com and the default search base ou=ae-dir.
Æ-DIR seems complex. How to start with a simple setup for my very few systems?
Æ-DIR is designed to scale down and up:
You can install the system and start with one zone and a single host/service group for all your systems pointing to a single user group. Later you can extend that to your growing needs by adding more host/service and user groups and by moving hosts/services.
Can Æ-DIR server run on name-your-favourite-OS-here?
Æ-DIR is not limited to run on Linux. Provided you have packages of all the required software it could be installed on various OS platforms. But note that tweaking the automated ansible installation to run on different platforms is much work.
Can I use another LDAP server software for Æ-DIR?
No. Æ-DIR makes heavy use of OpenLDAP's access control. To best of my knowledge other LDAP server implementations do not provide similar powerful access control (despite by implementing custom server-side plugin). If you have different opinion/suggestion please let me know.
I prefer to install only packages shipped by my Linux (enterprise) distribution. Why are OpenLDAP packages from different repositories installed?
Can I use another search base than ou=ae-dir?
Yes. You can set ansible variable aedir_suffix which is used in all ansible tasks and Jinja2 templates. But the characteristic attribute is limited to a set of common RDN attributes:
Can I migrate my current user management to Æ-DIR?
This very much depends on your current deployment. Things to consider before migration:
- Passwords (hashes)
- User names
- POSIX-IDs (passwd and group)
- Custom schema used by your data
- Access control requirements
- Client capabilities and configuration
- Commercial support
How to backup the data?
On each Æ-DIR provider a CRON job exports the databases to LDIF files with command-line tool slapcat(8) (see also OpenLDAP Admin Guide). How often this happens, where the files are stored and how long they are kept around can be configured with ansible vars openldap_backup_cron_args, openldap_backup_path and openldap_backup_max_days.
Is there an API for bulk operations?
The official API for programming Æ-DIR is LDAPv3 (see RFC 4510). Access control rules and constraints in OpenLDAP configuration prevent your client role to access/alter entries in an invalid way.
A ready-to-use module is available for Python.
I always get an error message insufficientAccess when I try to delete a user or a group. What's wrong?
Nothing's wrong. It works as designed.
User names, group names and numeric POSIX Id must never be reused. This is enforced by unique constraints and therefore deletion of user and group entries is prevented by ACLs. Set the status to "archived" (2) to make the entries invisible even for the zone admins.
Why is the SSH key of a user entry not a self-service attribute?
Managing so-called authorized keys for SSH access to your servers requires that the authenticity of the keys is reliably checked to meet security requirements like NISTIR 7966, section 5.2 . If users would be able to add SSH keys themselves the SSH authentication would only be as strong as the password authentication. Thus the zone admin responsible for a certain user has to check with some out-of-band process that the public key really belongs to this user and only the user has control over the private key.
How to report list of active users?
Any client example configurations available?
Yes. Check out the directory client-examples/.
Why do the client examples not use group authorization (e.g. memberOf filter)?
The goal is to keep client configuration dumb. This makes it possible to change access rights (solely by changing entities' relationship) in the directory without touching the client configuration.
Is the netgroup map supported by Æ-DIR?
Are nested groups supported by Æ-DIR?
No, because of bad performance. Furthermore you will loose oversight over nested groups sooner or later. Try understanding/leveraging the power host/service groups referencing user groups which serves the same purpose in most practical cases.
I'm too lazy to add groups etc. Can I directly assign rights to a user account?
Can I use another LDAP GUI client (e.g. Apache Directory Studio)?
While using any LDAP client (e.g. Apache Directory Studio) is certainly possible it will be rather uncomfortable for daily Æ-DIR maintenance resulting in a waste of your work time. web2ldap installed on each Æ-DIR provider has special customization (LDIF and HTML templates, plugin module) which greatly helps users to just do the right thing. In opposite non-customized clients typically require lots of clicks even for simple tasks, and do not know about Æ-DIR schema, thus probably leading to errornous input data.
Does every application integrated with Æ-DIR stick to its fixed role model?
If you are using shared infrastructure components it is very useful to simply use the Æ-DIR roles (e.g. Setup Admin) for access control in your infrastructure.
But if that model does not fit security requirements of a specific application you can simply maintain groups in Æ-DIR and map those to specific roles within your application just like with any other LDAP server.
Can I setup a Æ-DIR test instance without having to issue TLS certs?
No! In production you must use TLS anyway. So you should use your test environment to get familiar with it right from the start.
Can I let admins impersonate as a user for testing some issues with the user's access rights?
No! That's bad practice regarding audit logs! The admin should add a test user for himself with the very same groups membership and use this for testing.
When using two-factor authentication (2FA) is it possible to distinguish whether password or OTP input was wrong?
No! Both of these authentication factors are checked at once and this succeeds or fails. Æ-DIR deliberately does not tell the end user which authentication factor was wrong. This avoids the authentication factors being attacked separately.
However there are more detailed error messages written to system log on the Æ-DIR providers which can be examined by the authorized Æ-DIR sys admins if needed.
Privacy / Data Protection
- In default configuration the user names are generated as short random strings without personal naming information. So it's impossible to directly have a reference to a person just by looking at a username, e.g. by reviewing archived log files.
- The attribute aeStatus is used to adjust visibility of person records and user accounts. This allows to preserve the data for enforcing global ID uniqueness and for complying to audit requirements while limiting access to a small group of people to meet privacy requirements.
How to find the owner of an object (entry)?
Although widely used the term "owner" is pretty blurry in real-life.
In Æ-DIR each entry resides within a zone and zones are used for delegation. Therefore finding the respective zone admin(s) of the object's zone is a good approach to find the currently responsible "owner(s)".
How to find the privileged users?
"Privileged" is yet another blurry term which oversimplifies access control to a single security class.
Basically access rights (for regular client access) are granted to user groups. So the current group membership of an account defines whether it has to be considered privileged. Note that the result is not a simple yes/no decision. The privileges have always to be reviewed carefully within a particular service context.