* conductor first tries authenticate user against external LDAP
server. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
* This means Using DB as initial resource and falling back to LDAP
These two bullets seem to contrast one another, the first you're saying use LDAP first and in the 2nd your saying use the DB first.
* if admin deletes a LDAP user in admin section, user is deleted
only from local db, but this user can login again (as she will be authenticated against LDAP)
I'm not a fan of this, if an admin deletes a user, it is expected that user is deleted and is not able to login again. An alternate approach would be to introduce the notion of 'disabling' a user account
* do we need UI for LDAP config (it's probably only IP + port,
maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
I image a WUI to control LDAP has been implemented, perhaps this is just finding the right one?
In any case, LDAP config is more suited for a yaml file written by configure, not in a db in the database.
* should be LDAP server setup part of aeolus-configure script? I
don't think so.
I disagree, I think this should be an optional feature able to be setup by configure. The configure script should also support being able to specify an external location for an existing LDAP install (falling back to setting it up locally if it doesn't exist).
All in all, IMO the user shouldn't be required to do anything to setup aeolus other than install the rpms and run aeolus-configure.
-Mo