What is a "self sign-up" account/user?

In this context, any user who can log in to their Atlassian account which has been claimed(managed) by your Atlassian organization is considered a "self sign-up" user.  Users who are able to create their own Atlassian account are able to sign up for any Atlassian Cloud service outside of admin. control(shadow IT). Our product teams are working on allowing admins. to control which products an end user has access to:

CLOUD-11072 - Getting issue details... STATUS

Although it is not possible to stop end users from signing up for Atlassian Cloud services, it is possible to make your default local directory policy nonbillable. If a new user self signs-up for an Atlassian Cloud service - that user is considered billable for Atlassian Access.

To prevent new “self sign up” users from being considered billable for Atlassian Guard by default, it is possible to configure the default local directory policy to nonbillable. This article also applies to users who were invited by admins. of Cloud sites.

Self sign-up demo

In this demo, an end user has navigated to id.atlassian.com and created their own account. Scenarios where the user went to trello.com or bitbucket.org would end with the same result.

Don’t be alarmed if the newly created user doesn’t immediately appear in the default nonbillable(local directory) policy. The change can take a few minutes to update.

Self sign-up screen examples

The table below shows screenshots of how the self sign-up screen/experience looks for each product.

Product	Example
Trello
Cloud site
Bitbucket

How is Access billing calculated

The way Atlassian Guard billing is calculated is by product access. A user who doesn’t have any product access is not considered billable for Atlassian Guard. If an end user self signs up for an Atlassian Cloud service(Jira, Confluence, Trello, Bitbucket, etc.) then they are considered billable for Atlassian Guard.

Manage your bill for Atlassian Guard

Understand authentication policies

Prerequisites

• Only a policy in the local directory can be made nonbillable

• There can only be a single nonbillable policy configured per Atlassian organization

• Users who are a member of a nonbillable policy will not be able to use Atlassian Guard features such as enforced SSO or enforced two-step verification

• You need to claim your domain(s) in order to use authentication policies - Verify a domain to manage accounts

• You need to be an org. admin of the Atlassian organization where your domain(s) are claimed in order to perform this task

How to configure the default nonbillable policy and link your domain(s) so that self sign-up users are automatically added to the nonbillable policy

Part A: Make the default local policy nonbillable

To ensure that users who self sign-up for an Atlassian product/service will appear in your default local directory policy:

Your default local policy may already have the “nonbillable” label

• Navigate to https://admin.atlassian.com > [your Atlassian organization](“dnguyen4” in this example)

• Navigate to Security > Authentication policies

• If your default local directory policy is already nonbillable as per the screenshot above skip to Part B: Link your domain(s) - if not, then please see the steps below:

  
  

1. If you have a non-default policy or another policy that is nonbillable, edit that policy, then click “Add all security settings to policy“(see video below). Skip to Step 2 if this doesn’t apply to you
   

   
   
   

2. Click “Edit” on the default local directory policy
   

3. Click ...
   

4. Confirm the change by clicking “Update policy”
   

Part B: Link your domain(s)

Ensure that your domain(s) are linked to the local directory. In order to do that:

• Navigate to “Security” > “Identity providers” in your Atlassian organization

  1. Select your directory (“AAD” in this example)
     

  2. Click ... (top right-hand corner of page) > select “Link domain”
     

  3. Find the domain(s) you’d like to link to the local directory, then click “Link to a different directory”
     
     

  4. Select “Local (Identity provider not connected)” and confirm the change
     
     

Now, any user on the “kumatsumotors.com” domain who signs up to an Atlassian Cloud service/product would be considered nonbillable for Atlassian Guard.

Domain linking demo video

Notes

• Linking your domain(s) to the local directory will not affect users who are provisioned via automatic provisioning(SCIM) - users synced via SCIM provisioning will be added to the default "IdP directory"

• If your organization has Just in Time provisioning[JIT](SAML) configured, then you’ll have to link your domain(s) to the "IdP directory" in order for JIT to work correctly with enforced SSO. If the domain(s) are linked to the local directory, users will be prompted to sign up for their Atlassian account and will appear in the local default(nonbillable) policy instead of the default "IdP directory" policy