This article shows you how to Create New Organization Accounts with User Administration and Sign-Ups.
The previous Simple Administration Walkthrough showed you how to create an Organization by Migrating your Test Account. This article shows you a couple ways to Provision Organization Accounts, then works through both Validate and Dismiss in these situations.
This article assumes you have downloaded and installed the :Foundation Client as described in the article, Installing the :Foundation Client, then Provisioned a Test Account as described in the Walkthrough, Introduction and Preparation. You must also have completed the Walkthrough, Migrate to an Organization.
You can, however, use any Privileged Organization Account, though we do not recommend Production Accounts due to the way content is stored, shared, and accessed.
SSProtect manages exclusive access to shared configuration details to maintain data integrity. This prohibits Privileged Users from attempting to modify content at the same time. SSProtect/ KODiAC manage administrative activities as described in the article, Administrative Concurrency.
Provision with User Administration
To work through upcoming Sharing/ Managing Data Walkthroughs, we'll need at least one more Account in our Test Organization. Let's first do this with User Administration.
STEP 1: Login to your Organization Administrator Account, then from the notification icon's context menu, hover over the Administer Users menu item and choose Manage when the submenu appears:
Refer to the article, Managing Organization Users, for insight on the User Administration interface and related activities.
STEP 2: Create a new Organization Account by clicking New. For Username, enter the email address for the new Non-Privileged Account you are creating, which for our noted use of Gmail aliases, is firstname.lastname@example.org, as shown:
STEP 3: Keep the default Policy settings, mostly inherited from your Account's settings, and choose Save.
Quick Action Menu to Provision a New User
Because we're using the inherited Policy settings for the new Account, we can use the Quick Action Menu to do the same thing, in fact many times in succession (when desired).
Let's create a second User (that we'll Dismiss in STEP guidance that follows).
STEP 4: Choose OK to dismiss the Administer Users dialog, then from the notification icon's context menu, right-click and park your mouse over Administer Users. Choose the Add User Quick Action submenu when it appears:
STEP 5: In the Add User popup dialog, for Username, enter the email address for the 2nd Non-Privileged Account you're creating, then OK:
After you choose OK, you will receive notification for request results. Acknowledge the prompt and you will be presented with a new, empty Add User dialog. This allows you to Provision several new Accounts in succession, all inheriting default, "defaults".
STEP 6: Tap <ESC> on your keyboard to terminate the Add User sequence.
NOTE: The User Administration dialog provides Import Users/ Export Users that allows you to create more than a few Accounts at one time.
Looking Deeper: Case-insensitive Usernames and Organizations
Organization Names and Account Usernames are NOT case-sensitive. However, SSProtect converts Account Usernames to lowercase* though maintains the case you use when Naming an Organization.
Why the difference? This was a somewhat arbitrary decision by the development team when deciding how to manage Organization Names in UI displays, Reports, and email messages. Though not the case (...ahem...) with Usernames, the team felt the case-retaining nature of an Organization would be suitable and helpful when searching through results lists and Reports.
Stated another way, this may have been an oversight in the initial implementation for Usernames.
* If you followed the previous progression very closely, you may have noticed we used uppercase input for User Administration input, and it was subsequently displayed in lowercase form.
Register the First New User
Both of the procedures, above, generate a Registration Email for the recipient. Let's switch roles and go through the process as the New User.
STEP 7: Check your email's Inbox for a message entitled, [SSProtect] Register Account, from email@example.com. This message will include the temporary Password you need to continue, as follows:*
STEP 8: Refresh Login from your notification icon's context menu, then from the Profile dropdown, choose, Register Existing...:
STEP 9: Enter the New User's Username into the dialog, then copy/ paste the temporary Password. Click Register to continue:
SSProtect will then prompt you to create a Password for your new Account:
STEP 10: Create and enter the New Pwd (and confirm in Repeat New) that you'll use for SSProtect Login, then click Change to finish:*
SSProtect will prompt you with a message indicating that you cannot use your Account until it has been Validated by a Privileged Organization User:
STEP 11: Repeat the Registration process for the 2nd Account we created, for which we used the Quick Action Menu so it's available for subsequent consideration.
* Your Server designation will be ssp.secdefini.com or similar, rather than the non-public instance noted for our team's internal use.
Looking Deeper: User Validation
As the previous section's last notice indicates, new Organization Accounts cannot be used until they are Validated by a Privileged User (technically the one Organization Administrator or any Organization Delegate).
When an Account is added to an Organization, the associated User inherently gains Peer Sharing permissions to access content created and managed by every Account in the same Organization. It would not be prudent to rely on insecure email delivery of a temporary password in order to ensure the Registration process isn't intercepted by an intruder and carried out by an unauthorized threat actor.
This scenario is far more common than most of the general public (and even trained practitioners) realize. Corporations aren't highly motivated to disclose data breach information, especially in detail - and in fact only do so to the extent required by law. When end-users aren't (financially) impacted, disclosure requirements change dramatically. Even when notification is required, few have to, much less want to, publicly share details - for example that a nation-state operator successfully engaged in a long-term espionage campaign by penetrating their corporate network resources and stealing massive amounts of sensitive information and Intellectual Property.
This will be the topic for additional review when we get to :Respond and its' Incident Response capabilities, more specifically its' ability to show you reliable, certain, Definitive and Objective Disclosure Risk Insight.
In the meantime, let's put our Administrator hat back on to Validate the New User(s) we just Registered.
Validate the New User
SSProtect Validation is simple - the interim steps for interactive verification are probably harder.
Any Privileged User in the associated Organization can carry out these tasks, and ultimately each team will have their own policies and procedures they use as a means for coordinating these steps.
Registration can only be executed once, and verification may be a simple matter of calling the intended recipient to verify he/ she carried out the procedure. Though you can cross-reference details from :Assess reports, it's not always necessary if you trust the claims of the Account holder.
Once you're satisfied the intended recipient carried out Registration, return to the User Administration interface to Validate the Account, as shown below.
STEP 11: Refresh Login from your notification icon's context menu, use the Login dialog's Profile dropdown to select your original Test Account (now the Organization Administrator), then Login with the appropriate Password.
STEP 12: Navigate back through Administer Users /Manage with the notification icon's context menu, displaying the User Administration dialog. Select the new Account from the Account List on the left, as shown:
The Account's Reg is (also) Reg, indicating that someone has carried out Registration (otherwise it would be, No). Config shows Invalid, which indicates the User is waiting for administrative Validation. The Dismiss and Validate buttons are enabled specifically for this purpose; the former should be used when there are questions on the integrity of the procedure (see below), the latter to enable the Account for use.
STEP 13: Select the Non-Privileged User you created, firstname.lastname@example.org in our sample and as shown, then Validate to enable Account use. Choose Yes when prompted to confirm the transaction.
You have probably noticed that various aspects of these proceedings are reflected in notification email messages to your Account. Validate sends notification to the Account's recipient so the User knows he/ she can proceed with Login.
Dismiss a Registered Account
When Register proceedings are in question, you should Dismiss the Account rather than Validate it, otherwise you offer direct opportunities for a hijacked Account to be used in gaining access to Organization data.
STEP 14: In the User Administration dialog, from the Account List, select the 2nd Account you created (using the Quick Action Menu). In our use of Gmail aliases, this matches email@example.com, and your state should match that given below (Reg=No and Config=Invalid):
As with this phase of the process with the 1st (Non-Privileged) Account we Provisioned, both Dismiss and Validate are available since someone has performed the Register operation.
STEP 15: While the 2nd Account is still selected, choose Dismiss then Yes to acknowledge the confirmation prompt. Results for your operation will be displayed at the bottom of the right-hand side of the dialog.
Sign-Ups that Join Existing Organizations
You can configure your Organization to onboard New Users with Sign-Up described in the article, Creating an Account. This provides added flexibility that substitutes self-service activities for Administrative Provisioning.
As you will see below, successful Provisioning requires Validation for every Account. You can also limit the number of potential Sign-Ups or disable them completely.
Enable Sign-Ups for an Organization
When you create an Organization, by default Sign-Ups (for Join activities) are NOT enabled. You can change this from User Administration, described here.
STEP 16: From the User Administration display that should be present from previous steps, click the Sign-Up Policy button at the top right to adjust its' configuration:
This display is briefly described in the article, Managing Sign-Ups, summarized here:
- Open/ Max Open: The number of concurrent Sign-Up requests outstanding, and maximum permitted
- Sign Ups/ Max Sign Ups: The number of processed Sign-Ups, and max permitted
These controls allow you limit the number of outstanding requests and/ or total number of Provisioned Accounts using this procedure.
STEP 17: Use the existing defaults, but check Enable then click OK to permit Sign-Up requests. Dismiss User Administration then Refresh Login: We'll switch hats and Sign-Up with the procedure, below.
It's important to remember that Sign-Up Requests are just that: Absolutely zero content is shared until a User is Validated. Sign-Up Validation uses the same procedures we worked through, above.
Join a New Account to an Organization
Let's operate in the context of a New User attempting to Sign-Up - to Join - an existing Organization.
STEP 18: After Refresh Login and at the Login dialog, use the Profile dropdown to choose, Create New.... Use your Gmail alias scheme to create and enter a new Account Username for the Email Address entry, in our case firstname.lastname@example.org as shown below:
STEP 19: Check Org and :Recover, though you can leave :Email unchecked since we won't be using it (and couldn't anyway due to the use of the Gmail alias). For the Organization, use the exact name of the Organization you created, above - then click Create....
Because Sign-Ups are enabled, the request will process else you would receive a generic error, hiding the details of the specific Request to ensure attackers can't, "profile" resources by looking for different responses that give up important details or a, "footprint".
STEP 20: Check your Inbox for the Code associated with your Sign-Up proceedings, then enter it as we have done in previous Walkthrough cases. Create and enter the new Account Password then use Change. Acknowledge the notification indicating that you cannot use your Account until a Privileged Organization User carries out Validation.
Validate a Join Request
Return to the context of your Organization Administrator from the dialog prompt:
STEP 21: Use the Login dialog's Profile dropdown to choose your Organization Administrator then Login. Navigate to User Administration and select the Account that has most recently submitted the Join request described above:
Notice that the Reg column in the Account List now shows Join, reflecting our recent activities and differing from the Reg result you see when Provisioning from this dialog or the Quick Action Menu (as in previous Walkthroughs).
As expected, the Config column indicates that Validation has not yet been carried out (Invalid). Let's do this now:
STEP 22: Select the Account with the Join status for Reg, which should match the Account you used for Sign-Up, above, then choose Validate to enable use. Acknowledge the popup confirmation to complete the request.
SSProtect Organizations allow you to manage collections of grouped Accounts while sharing configuration resources (such as :Recover Quota). There are a variety of ways to Provision New Users, from the use of independent, manual configuration in User Administration, Import Users/ Export Users, and Sign-Ups. Accounts can also be created with a combination of automated activities using the :Expand API and by utilizing common deployment technologies.
Overall, SSProtect was designed to reduce Administrative overhead while remaining simple enough for end-users to self-install, setup, and configure. Choose the combination that's right for your environment, and when you have questions, submit them to our Support team using the information below.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to email@example.com, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client