In general, no, such a policy is counterproductive to security. While many weak passwords use repeated characters, so do many strong passwords... and many weak passwords don't.
Some reasons not to use such a policy:
- It reduces the brute-force search space (though not by an amount that is really destructive for moderately long passwords)
- It increases the risk that users will pick weak passwords that conform to the rules (e.g. qwertyuiop), when otherwise they'd use a better password generation scheme that doesn't
- It prevents very long passwords/passphrases, if you disallow repeats at all (any remotely sane policy wouldn't be that draconian, though, and merely disallowing consecutive repeats doesn't have this particular problem)
Ultimately, pretty much all password policies are aimed at two things:
- Users should use a novel, high-entropy password (one that hasn't been used before, ideally by any user on any site, and that isn't more likely to be chosen than a huge pool of other options) so that brute-force attacks (even aided by knowledge about common password strategies) don't succeed.
- Users should use a password that can't be predicted even by a knowledgeable attacker (one that, even if the attacker knows every other password the user has ever used, they wouldn't be able to guess in reasonable time)
Unfortunately, nearly every password "quality" requirement dating to before a few years ago - and a whole lot of them since - do terrible jobs of achieving these goals. Character type and repeat requirements (or restrictions) do nothing except get people to "game" the rules (e.g. "Pa$sw0rd"). Minimum length does help, but is insufficient (and you should not enforce a maximum length, unless required for technical reasons).
I'm not familiar with the software you're using, so these are some general recommendations for attempting to enforce password quality, generally based on sources such as NIST.
The recommended fix for the problem of novel passwords is to use a list of known passwords from elsewhere - usually collected from compromised sites that had weak password security - and reject any password on it. Some of these lists are quite long - e.g. https://haveibeenpwned.com/Passwords has a list of over 600 million unique compromised passwords - and site owners can and should reject any password on such a list. You might even want to try "normalizing" the breached password list and the users' password candidates (e.g. "Pa$sw0rd" -> "password", removing capitalization and reversing common substitutions), since you want to catch obvious modifications of passwords even if they haven't been seen in a breach yet.
Addressing the problem of unpredictability is harder. Generally, you end up wanting to block as much information as possible about the user, site/app, date, and any other predictable-to-an-attacker information. So, don't let users use their name, username, age, address, email address, date of birth, or any other information about themselves (to the limits of your knowledge) as part of their password. Similar, don't allow your site, app, or company name, any part of the current date, or so on. Such filters should be fairly narrow - the goal is to block anything a attacker would guess, not everything that plausibly could be related to the user - and match any part of the password, not just the start or the whole.
In combination with the block on compromised passwords this tends to result in fairly novel and unpredictable passwords. Combine that with expensive salted password hashing (ideally something with a high and tunable memory cost, to interfere with parallelization of brute-forcing) and ideally a second factor, and you are well on the way to strong authentication.