We use Galera+Xtradb here (for a different application though).  I believe it should work (with teampass) from what I've seen, but would advise setting the Galera nodes to do single-thread-only repllication ( wsrep_slave_threads=1 ) to avoid any chance of a race condition over referential integrity loss.  This is a good setting to use on read-mostly galera databases anyway.  The lack of a single unique key does put you at more risk if replication goes wrong - as galera will not be able to notice inconsistencies - but the single-thread replication helps protect against that.

Yes, I think that works (will try it next week).  It would be better to have this as a user-configurable option though, rather than having to modify the code.

In addition, if 2FA is enabled, then it would be really good for the initial temporary code email to be sent out immediately (provided an email address is configured) rather than when the user clicks the link on the login page.

I have roughly done this in function identifyUser(), in identify.php (line 671), by simply copying a section of the code from main.queries.php:

        // should send email notification if using 2FA
        if (isset($user_info_from_ad[0]['mail'][0]) && $SETTINGS['ga_website_name'] !== false ) {
                    // generate new GA user code
                    include_once($SETTINGS['cpassman_dir']."/includes/libraries/Authentication/TwoFactorAuth/TwoFactorAuth.php");
                    $tfa = new Authentication\TwoFactorAuth\TwoFactorAuth($SETTINGS['ga_website_name']);
                    $gaSecretKey = $tfa->createSecret();
                    $gaTemporaryCode = GenerateCryptKey(12);

                    // save the code
                    DB::update(
                        prefix_table("users"),
                        array(
                            'ga' => $gaSecretKey,
                            'ga_temporary_code' => $gaTemporaryCode
                            ),
                        "login = %i",
                        $username
                    );

                    // send mail?
                        sendEmail(
                            $LANG['email_ga_subject'],
                            str_replace(
                                "#2FACode#",
                                $gaTemporaryCode,
                                $LANG['email_ga_text']
                            ),
                            $user_info_from_ad[0]['mail'][0]
                        );

        }
    }

However this is not ideal because it does not properly test for 2FA being enabled, though it does check for the email address.

Having these features (default roles, configurable attributes, and automatic 2FA notification) would mean that self-registration would be much quicker and simpler.

Thanks for your time with this; there are almost no Linux-based enterprise password managers with a web GUI and support for LDAP, which makes it really hard to find something suitable for our situation.

This feature could maybe be enabled on a per-object level?  Not all of the items necessarily require this level of logging.  Personal items should be exempt, too.

It might be a bit awkward as there are several places (preview pane, copy button, etc) where the password is retrieved

To be more precise; the LDAP configuration will set up the name and email address when auto-provisioning a new LDAP user, but the attributes used are hard-coded.  If (like us) you use a non-standard schema, then there is no way to configure which alternative attributes should be used for these initial settings.

There is also no way to initialise the role membership or link it to LDAP groups.

In sources/identify.php, the attribute names are fixed, and fonction_id (the semicolon-separated list of roles) defaults to blank:

        DB::insert(
            prefix_table('users'),
            array(
                'login' => $username,
                'pw' => $data['pw'],
                'email' => (isset($user_info_from_ad[0]['mail'][0]) === false) ? '' : $user_info_from_ad[0]['mail'][0],
                'name' => $user_info_from_ad[0]['givenname'][0],
                'lastname' => $user_info_from_ad[0]['sn'][0],
                'admin' => '0',
                'gestionnaire' => '0',
                'can_manage_all_users' => '0',
                'personal_folder' => $SETTINGS['enable_pf_feature'] === "1" ? '1' : '0',
                'fonction_id' => '',

Of course we can (for the time being) alter these in the code to match our schema and preferred defaults, but it would be better for this to be configurable

The Keepass import feature is very important to us as it provides a migration path from our existing Keepass-based solution.  However, it currently seems to be a bit limited in its support for the various KeePass fields.

Also this ticket http://teampass.userecho.com/forums/1-feature-requests/topics/17-manage-users-and-groups/

This is to grant roles to LDAP groups, which would also achieve what we're after.

This is part of my other request at http://teampass.userecho.com/forums/1-feature-requests/topics/101-automatically-configure-user-from-ldap-on-first-login/

Basically, we want to be able to set up some autoconfiguration rules for new LDAP users - default role, and autopopulation of the name and email address from LDAP attributes.  Maybe have an LDAP attribute that holds roles?

I have the LDAP auth working here, at last.  I can share what I found out.

* The admin account logs in with the local password, other accounts with the LDAP password

* The local account needs to exist before you can log in with the LDAP.  Disabling the "teampass local users only" option automatically makes the new account, but doesn't fill in name or email address, which means you cant have 2FA until someone sets these.

* I use the "Posix SearchBased" LDAP type, with Account Suffix and Group blank

* The 'test current configuration' doesn't work, although the logins do.  This may be because we have 2FA enabled?

Our system uses email address (smxMailboxAddress) and LDAP password to log in, and we have a special Class attribute (smxMailbox).

It would be really, really good if under "Newly created user is administered by" there were also fields for "populate name from LDAP attribute" and "populate email address from ldap attribute".  Also, "Newly created users are given this role" would be good, and a "Send initial 2FA email to newly created users" checkbox...

Not only for AD groups, but also for LDAP groups in general it would be good to be able to grant roles to groups.