This article shows you how to Create New Organization Accounts with User Administration and Sign-Ups.
Introduction
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.
Prerequisites
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, Provision Test Accounts. 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.
Administrative Concurrency
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: Log In 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 definisec+test1u1@gmail.com, as shown:
When you create a new User (Account), its' Policy settings are inherited from the User that's selected (on the left of the dailog) when you click New - even if the User hasn't been created and/ or Validated. This includes the Privileged/ Non-Privileged state as depicted by the Delegate checkbox (which inherits a checked state if the selected User is the one and only Administrator - a Delegate has nearly the same privileged as the Administrator)
For our scenario, things are fairly straightforward given there is only one User to select. As such, it's important to remember to check the Delegate checkbox setting to ensure you are creating the desired Privileged or Non-Privileged User.
STEP 3: Uncheck Delegate then choose Save to create a Non-Privileged User (Account).
Editing Multiple Users
Though not explicitly covered in this Walkthrough, you can Edit more than one Account at a time. After choosing Edit for a specific Account, and before Save or Cancel, click another user in the list and choose Edit (or New to create another Account), then continue editing. You can select any user at any time to update the Policy controls to reflect the target's settings. Choose Save All to commit all changes at once, and/ or click individual users then Save or Cancel each, independently. Use the Edit column status as a guide to those that need to be completed.
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(s) Quick Action submenu when it appears:
When you create a new User (Account) with this method, its' Policy settings are taken from the interactive user's Account. However, the Account(s) will be Non-Privileged when using the Add User(s) Quick Menu item, and Privileged when using the Add Delegate(s) Quick Menu Item (because remember that only Privileged Users can Administer Accounts, so the baseline Policy is always the Privileged Account you're using to execute these actions).
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/ Export facilities that allow 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 ssprotect-admin@definisec.com. This message will include the temporary Password you need to continue, as follows:
NOTE: Your Server designation may be different than that shown here. This value depends on the state of KODiAC Cloud Services and from where you initiate your Registration. It is not a matter of significance unless you are troubleshooting connectivity issues for a geographically distributed team of users.
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.
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.
* Remember that content is never automatically delivered or shared with any SSProtect User - managed content must be delivered or acquired in other ways, though with SSProtect Organization Peers, this data is often stored on internal File Servers or SharePoint resources and as a result readily available to someone with the ability to control a related SSProtect Account.
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 Log In 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, definisec+test1u1@gmail.com 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 definisec+test1u2@gmail.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.
Re-Using a Dismissed Account
Your team cannot immediately recreate a new User with a Dismissed Account's email address. The above-noted Dismiss procedure sends notification to the KODiAC Service Provider who must acknowledge the activities, removing the Account. That triggers email notification sent to all Privileged Organization Users. Your team can, at that time, re-use the associated email address with a new SSProtect Account.
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 definisec+test1u3@gmail.com as shown below:
STEP 19: Check Org and :Recover, then acknowledge the License notification. You can leave :Email unchecked since we won't be using it (for now). 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 Log In. 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.
Summary
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.
Additional Resources
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 support@definisec.com, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v10.7.1 of the :Foundation Client