Feature request: Setting to disable password recover flow

[Duologic]

We have setup Sentry with LDAP authentication. This works fine, except it still shows the possibility to recover your password. As the authentication mechanism runs through LDAP, this can be confusing for the users.

I want to propose to add a simple 'auth:recover' switch to SENTRY_FEATURES which would disable the recover form/url and hide the link on the login page.

What do you guys think?

[dcramer]

@Duologic I think we could block accounts which are marked as managed from resetting their password, which seems a lot better than simply hiding the feature.

[Duologic]

That would be one way of looking at it too. Although I think you either have managed users or unmanaged users, rarely both (except for the original root/admin user). Implementing this check would make the logic more complicated for a limited gain while simply having an option to disable it looks like simple operation.

Also, I think it would be useful to hide/disable the feature as it limits the number of entry points to enter when moving an 'On premise' setup from a private network to a publicly reachable one (which is actually the original reason I started thinking about this feature).

[dcramer]

@Duologic i can very easily see having a master account which is unmanaged on most installs. The important thing to note is that managed users exist both on hosted sentry as well as on-premise, and we try very hard to limit features which can be disabled since it often means less tested/overlooked paths.

[Duologic]

Can you collaborate on how admins communicate to the users that this
feature doesn't work for them? I can imagine that this is quite hard for
bigger organizations.

Anyway, thanks for the quick responses. Sentry is a great tool!
On Jul 11, 2016 7:34 PM, "David Cramer" notifications@github.com wrote:

@Duologic https://github.com/Duologic i can very easily see having a
master account which is unmanaged on most installs. The important thing to
note is that managed users exist both on hosted sentry as well as
on-premise, and we try very hard to limit features which can be disabled
since it often means less tested/overlooked paths.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3681 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADMdXxc3pAYIpw37D3F_pp0tXsPuFwAaks5qUn6GgaJpZM4JJOMn
.

[dcramer]

@Duologic I think its something we still need to figure out. I linked the wrong issue to the PR, but #3684 at least fixes the "you shouldn't be able to reset these passwords" issue. The remainder of it I see as a separate problem. If we did take the stance that said "admins should have a way to provide support for a sentry install" we could do something here.

For example, if it said "You can't recover this account, contact support, and contact support was some kind of system that either contacted our support on getsentry.com, or contacted the admin of the install for on-permise.

[Duologic]

The pull request looks great, it solves part of the issue I have.Like you mentioned, this way an attacker might gather information on who has an account.

I do like the approach of showing them a message and telling them to contact support.

[yanir3]

I'd really like to see this feature implemented.
@dcramer Care to explain what are "managed accounts"? And maybe how do I go about creating one?
Haven't found an explanation anywhere.

[dcramer]

Managed accounts come from SSO providers, and it's a flag on the User object.

I'm closing this out, as we're taking an active stance to remove feature requests from GitHub (the combination of this + "help" has become too noisy).

If you want to continue discussion I'd recommend using our new community forum:

https://forum.sentry.io/