No announcement yet.

How to clear the password in Tortoise SVN if it fails to authenticate

  • Filter
  • Time
  • Show
Clear All
new posts

  • How to clear the password in Tortoise SVN if it fails to authenticate


    We are facing a issue where Authorization is done via ldap -> IAM service, but when user changes password its not flushed and asked for new password instead lock the user account by attempting the same old password.

    Is there any way we can avoid this ?


  • #2
    "IAM" is a generic term meaning "Identity and Access Management". Is there a specific instance of this generic that you're talking about (for instance "AWS IAM")? Is your "IAM" solution providing LDAP services?

    If so, then the policy is completely held within that product. If/when the user changes their account password then they should immediately change it within any "stored" location. That includes TortoiseSVN and any keyring data set they've got.

    It also helps if the IAM instance does not lock the account so quickly. I've seen folks set it up to lock the account at 2 or 3. That's just "human unfriendly": should be 6 or so. But even then, with enough automation going on the account is likely to get locked very quickly unless the password change is quickly coordinated.


    • #3

      We are using LDAP services.

      Yes this is the same issue we are facing, wanted to understand if tortoise offers any solution for this that it can auto flush the password if login failure happens or any other workaround.



      • #4
        None that I know of. In general, if possible, I would suggest that when it comes time for your users to change their account password they do a "clear all" in TortoiseSVN before changing the password. Then change the password. Then go back and re-configure their credentials. That's UGLY - I know.

        Perhaps someone else knows of a tunable in TortoiseSVN that can, say, prevent Tortoise from trying the same password more than 1X? Unfortunately, even that won't help if there are multiple servers involved since each server is still likely talking to your single IAM and therefore after N different servers fail the account is still going to get locked out...