* conductor first tries authenticate user against external
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
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 +
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.