Secure your user's information with greater control over password requirements.
To set your password policy:
- Open the vertical menu in the toolbar of Domain Details.
- Select Domain Settings.
- On the Authentications card, edit the relevant fields:
- Minimum password length: This number represents the lowest number of characters the password must contain.
- Minimum character classes used: This number represents the minimum number (up to four) of character classes (lowercase, uppercase, numbers, and special symbols) the password must contain.
- Number of unsuccessful login attempts before lockout: This number represents the number of failed logins before the user is locked out.
- Lockout duration: This duration can be set in various units (days, years, months, etc.) and must be entered using ISO designators (see section below). You can manually override password lockouts if necessary.
- Password expiration: This determines how ofter you require users to reset their passwords. This duration can be set in various units (days, years, months, etc.) and must be entered using International Organization for Standardization (ISO) designators (see section below).
- Prevent password reuse interval: This determines how long one must wait before reusing a password. This duration can be set in various units (days, years, months, etc.) and must be entered using ISO designators (see section below).
- Save.
ISO duration designators
ISO durations use one-letter designators and a simple format to indicate standardized time intervals. To enter a duration:
- Enter P (period) if you want to use days, weeks, months, or years as your unit of time, and PT (period, time) if you want to use seconds, minutes, or hours.
- Enter the number of units that you want to use.
- Enter the desired time unit designators:
- D (days), W (weeks), M (months), Y (years) if you used P.
- S (seconds), M (minutes), H (hours) if you used PT.
Comments (9)
Will this setting at the domain level automatically filter down to all the subdomains, or is it strictly for this one domain?
Hey Candi, it trickles down to subdomains unless that subdomain explicitly has a different password policy defined.
Hi.
Is there a way to require that students change their password after the first time they log in? Please let me know.
Hi Mary!
If you mean is there a way by which to force a student to change their password after first signing on. There currently is not a way within the UI to accomplish this. This would require the API to force a student password change after signing on into Buzz. If additional assistance is needed with the API, please (through your authorized support agent) submit a ticket to Agilix Support.
We are automating the creation of guardian accounts using the DLAP API. When the accounts are created, a default password is set based on information we know about the guardian from our SIS, and then a forcepasswordchange command is run on the user.
I just tested this out on a created user by copying and pasting the username and password to log in. The Change your password screen came up saying that the password had expired, and asked me to enter the current password again, as well as the new password twice (an initial entry and a confirmation). Even though I just pasted the password from what I had already copied and used to successfully login, I got a message saying The current password is invalid. See the screen shot below. Any ideas on what could be causing this? We'd really like to force the password change for security's sake, but this is problematic if this breaks access to the account.
@Shaun, I just tested this out and it worked as expected. In other words, the first password that I used to login was then used in the "Current password" field. However, what you are experiencing is probably not the exact same thing.
When you enter in your username and a password, we will alert the user if that account has had its password expired. But, and this is what you are likely experiencing, the "password has expired" message will display regardless if the original password entered was correct or not. In your case, I'm guessing the password is not correct on both attempts (the original login nor the "current password").
That makes sense. As I said, we are using a script that generates a password based on information from the SIS and emails the person their password for the initial login. So I still think it's strange that users would be logging in with the incorrect password because they just need to copy and paste it from the email. Granted, I know user error is a thing, but from what we're hearing, this is happening a lot.
I'm wondering if maybe there's something about the default password we're trying to set that the Buzz DLAP API doesn't like. Are there any characters that aren't allowed in passwords, or is there a maximum password length?
Thanks for your help, Brad.
As long as you properly escape characters in your request so that it doesn't conflict with your JSON/XML, then there are no limits. I know that we support at least 2000+ characters in the password.
Since your system generated these passwords and emails, is there any way to confirm the process?
We'll check the process out a little more to see if there might be some glitches. I appreciate the help!