If an organization does not configure an organization for Atlassian Access, what would the requirements be for users utilizing the system? I'm looking for the following:
Password character requirements
Password reset requirements
Password expiration timeframe
Ability to have forced resets at next login
Hi Scott,
By default, we require all Atlassian account passwords to be a minimum of 8 characters. We do not enforce any other requirements around resets or expiration without an Atlassian Access subscription.
Hope this helps.
Dave
Hey Dave,
Without setting up Atlassian Access, will it be possible for an admin to modify the password policy or atleast set it up.
Regards,
Fahad H.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @[deleted]
Currently Atlassian Access is required to set up any kind of password policy. As a site administrator, you can prompt individual users to reset their password from the user's page, but you cannot set a password policy until you have verified your domain and configured Atlassian Access.
One option would be to verify your domain, start an Atlassian Access trial, set up a password policy, and then trigger a password reset for all your users. This would force all users to set new strong passwords. Then you could let the Atlassian Access trial expire. Obviously users could then reset their passwords again but it would increase your organizations general password quality as a one-off step.
Regards,
Dave
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello everyone,
For all the users searching for this information, since October from this year, it is no longer necessary to purchase Atlassian Access in order to set a password policy. As long as you have a verified domain you are free to do so.
More information can be found n our Atlassian Cloud changes the blog from October.
Wish You the Best,
Giuliano de Campos
Atlassian Team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Password policy is the lowest bar of security, you should make it available without verifying the domain. This should be a no brainer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Domain verification is the process we use for an organization or company administrator to determine which users are internal to the organization, versus external collaborators. Since a user can use the same Atlassian account across multiple Jira or Confluence sites, it would be quite complex of the administrators of different sites tried to impose different password policies on the same user (considering the premise of a single account is that they only have to log in once).
We are developing a solution for customers to enforce an added security layer for external accounts that have access to their content based on one-time passwords. See https://www.atlassian.com/roadmap/cloud??&p=b8d50209-93
While we don't currently enforce password strength requirements on all Atlassian accounts globally beyond a character minimum, we run a rigorous security program across our products and operations: https://www.atlassian.com/trust/security/security-practices
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you are with a very large organisation, claiming a domain is next to impossible, and hence it is not possible to enforce enterprise level password policies. Would be nice to be able set a password policy at an (Atlassian) organisation level. In our case, we would not have any kind of external user.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
agreed - we have sister companies that all use the same domain, however have their own instances of applications that they use (JIRA being one of them). This makes it that we cannot use the same domain name for verification. What should be done instead (based on customer needs) is an option to set authentication policy as a whole on your JIRA instance, like it was done in JIRA Server.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.