LDAP authentication?

[unquietwiki]

https://msdn.microsoft.com/en-us/library/system.directoryservices.protocols.ldapconnection(v=vs.110).aspx

Might be useful for business environments.

[kspearrin]

I am not sure if a third party authentication provider would work for this type of application. For one, how could I possible handle things like password changes? Currently that is a transnational operation (see https://github.com/bitwarden/core/blob/master/src/Core/Repositories/SqlServer/CipherRepository.cs#L85)

[unquietwiki]

@kspearrin In other applications I've seen that handle LDAP/AD authentication, you'd use the Domain+Username of the account provider, and defer password authentication to that server. Changing the password is usually done through the workstation / domain admin; and not usually a function of the app. This functionality would really be for business settings wherein you don't want to have multiple accounts of everything: might also tie into #1

Some examples of apps with this ability...

• https://github.com/RocketChat/Rocket.Chat/search?utf8=%E2%9C%93&q=LDAP
• https://github.com/rbCAS/casino-ldap_authenticator

Now, tying this back in with Issue #1: earlier this year I was made aware of http://www.keycloak.org/ ; its a broad-scale SSO that RedHat has been backing. A cursory search yields a C# connector to it, that you might have interest. https://github.com/dylanplecki/KeycloakOwinAuthentication

[kspearrin]

The main problem with that is that the bitwarden API never actually receives the password in a form that would be acceptable to pass along to LDAP. The API only gets a hash of the password from the client.

[kspearrin]

I may be misunderstanding LDAP (I have never used it). Is the process handled on the backend or the client?

[kspearrin]

Another problem that I see: like you mentioned, there is some third party admin that could change your password. bitwarden has to reencrypt all of your data as part of a password change process (and email). These are the two components that make up your encryption key. How is the bitwarden application suppose to know about these events in order to make other changes? Your data would become corrupt without re-encrypting.

[unquietwiki]

@kspearrin Could the encryption key be based in part on a unique identifier, instead of the username/email address? https://en.wikipedia.org/wiki/Universally_unique_identifier & https://msdn.microsoft.com/en-us/library/system.guid.newguid.aspx might help.

[kspearrin]

@unquietwiki I don't think that basing the encryption key on a value that cannot be cycled or controlled by the user themselves is a very good idea.

Other problems: how is the user suppose to use apps such as the web vault or mobile?

I feel like this would end up being a nightmare to support with a lot of limitations being put on the entire product suite.

[unquietwiki]

@kspearrin If the app is to remain purely web-based, then yes, none of this matters. If its allowed to be used internally, then allowing the option of 3rd-party authentication would make things easier from an admin perspective. Concurrently, since the source is available, then it'd be a matter of whomever really needs the support, to fork + modify the code accordingly, if this isn't a direction you want to go.

I know at least one person personally that's already switched over to using your system, and my boss likes the concept of the software, so I might be able/willing to contribute some code to tackle this. That'd certainly be an "as able" effort though.

[kspearrin]

Yea, this isn't really the direction I plan on taking the product at the moment so it would be up to someone else to add this in if desired. Thanks for the feedback and discussion but I'm going to go ahead and close this out.

[atocyo]

I dont think this app is usable in big org without SSO/LDAP support.

[windware-ono]

Is the process handled on the backend or the client?

It's handled on the backend just as consulting a database, so the client does not change.

How is the bitwarden application suppose to know about these events in order to make other changes?

• On first login, where Bitwarden doesn't have the user in its database, access LDAP to check if the login succeeds, if successful, the daemon creates a new vault with the provided email/password. At this point, remember the hash of the email/password combination.
• If the password is changed through Bitwarden, try to update LDAP password, if the LDAP policy allows for the password to get updated, the daemon can decrypt and re-encrypt the vault, but if the password cannot be changed, warn the user and leave the vault as is.
• If the password is changed outside Bitwarden, on next login with a successful new combination through LDAP, detect the hash of the email/password combination has changed since last successful login and prompt the user to enter the old password and use that to decrypt and re-encrypt the vault with the new combination.

If the user forgets or has no access to the old password, the vault is lost but it should be mentioned for LDAP setting when the password is changed outside Bitwarden.

@kspearrin , can this be done?

[enoch85]

I'm also interested in LDAP support. Any news on this matter?

[ptman]

LDAP support could be limited to group membership and whitelisting usernames (emails) and leaving password handling to bitwarden.

[enoch85]

LDAP support could be limited to group membership and whitelisting usernames (emails) and leaving password handling to bitwarden.

Interesting! Is that live now, or does it need to be developed?

[bfd69]

Is the process handled on the backend or the client?

It's handled on the backend just as consulting a database, so the client does not change.

How is the bitwarden application suppose to know about these events in order to make other changes?

* On first login, where Bitwarden doesn't have the user in its database, access LDAP to check if the login succeeds, if successful, the daemon creates a new vault with the provided email/password. At this point, remember the hash of the email/password combination.

* If the password is changed through Bitwarden, try to update LDAP password, if the LDAP policy allows for the password to get updated, the daemon can decrypt and re-encrypt the vault, but if the password cannot be changed, warn the user and leave the vault as is.

* If the password is changed outside Bitwarden, on next login with a successful new combination through LDAP, detect the hash of the email/password combination has changed since last successful login and prompt the user to enter the old password and use that to decrypt and re-encrypt the vault with the new combination.

If the user forgets or has no access to the old password, the vault is lost but it should be mentioned for LDAP setting when the password is changed outside Bitwarden.

@kspearrin , can this be done?

nice idea,
but the second step is only doable if bitwarden is aware of the clear text password since ldap doesnt provide a way to push already hashed passwords. Another way would be the possibility to provide an url to change the password then step 3 would be sufficient.

[ptman]

https://community.bitwarden.com/t/sync-users-from-active-directory-with-ldaps-but-how-about-sso/4976/3 SSO seems to be only for checking if users are allowed. They still need their bitwarden password

[windware-ono]

@bfd69 , what do you mean by this?

the second step is only doable if bitwarden is aware of the clear text password since ldap doesnt provide a way to push already hashed passwords.

I assume you're referring to this part.

• If the password is changed through Bitwarden, try to update LDAP password, if the LDAP policy allows for the password to get updated, the daemon can decrypt and re-encrypt the vault, but if the password cannot be changed, warn the user and leave the vault as is.

Bitwarden is certainly aware of the clear text password as the user has just typed in the new and old password to change through Bitwarden.