Skip to main content
Version: 3.0

Post-Upgrade: Missing Cortex Security Group Permissions

If you upgraded Cortex from 2.3.3 or earlier to 2.4.0 or later, you may find that an account marked as an admin can see the Admin menu but cannot open the admin screens inside it, or that users cannot reach data at all.

This is a known consequence of the permission changes described below, and it can be resolved. The steps to take depend on which of the two root causes applies to your environment.

Why this happens​

Cortex 2.4.0 introduced the Cortex Security Group - a set of permissions for Cortex's own features, stored in the Cortex configuration database and managed on Admin → Security Groups.

Before that release, an account's admin status was a single flag. Later releases split that into granular permissions and kept adding new ones:

ReleaseChange to Cortex permissions
2.4.0Introduced the Cortex Security Group permissioning system, with a single Is this the admin security group? setting on the group's Application tab
2.5.0Added Cortex Security Group permissions for editing global saved searches, and a setting to limit the Browse page to role-visible business objects
3.0.0Made the Data Source rights of the built-in Admin and Default User groups fixed in the dialog, and made Cortex restore them on startup
3.1.0Replaced the single admin-group setting with granular per-section admin permissions, and made Cortex restore full admin rights on admin groups on startup

Security groups that were created before these releases can therefore be left without values for the newer permissions, and the upgrade itself does not fill them in for existing groups or existing user accounts.

Two permissions that are easy to confuse​

These are separate settings, and an upgrade can leave them out of step:

  • The Is Admin flag on the user account. This controls whether the Admin navigation item appears and whether the user can reach the admin pages at all.
  • The permissions on the account's Cortex Security Group. These control what is visible and actionable inside the admin area - which sections the user can see, and whether they can add, edit, or delete within them.

An account can have Is Admin ticked and still reach no admin screens, because the group it is assigned to has none of the matching section permissions. This is the most common symptom after an upgrade.

note

This page is about Cortex Security Groups, which control Cortex's own features. A Cherwell Security Group is a separate concept: it comes from your source system and controls access to source data. See Security groups and access control for that model.

Step 1: Check whether the account has a Cortex Security Group​

If you can open Admin → Users: find the affected account in the list and check whether a Cortex Security Group is shown next to it.

If you cannot open that screen (for example, Cortex tells you that you do not have permission to view it), have a database administrator check the account directly. In SQL Server Management Studio (SSMS), run this against the Cortex configuration database:

SELECT Username, EmailAddress, IsAdmin, IsDisabled, CortexSecurityGroup
FROM cortex.UsersToSecurityGroups;

Then follow the branch that matches what you see:

  • CortexSecurityGroup is empty (NULL) - the account has no Cortex security group assigned. Go to Step 3.
  • CortexSecurityGroup has a value - the group is assigned but is missing permissions. Go to Step 2.

Step 2: The security group is missing permissions​

Open Admin → Security Groups and edit the group the account is assigned to. The dialog changed between releases, so the section you need depends on your version.

Granting admin access to the group​

Cortex 3.1.0 and later: on the Admin Permissions tab, select Full Admin Access — all admin functions are available. This grants every admin screen in a single step. With that box cleared, you can instead set View, Edit / Create, and Delete for each admin section individually - useful when a group should only reach some admin screens.

Cortex 3.0.0 and earlier: there are no per-section admin permissions. On the Application tab, select Is this the admin security group?.

For a non-admin group on 3.1.0 and later, grant at least View for the admin sections those users need, so that the pages they should reach are visible to them.

Data Source rights​

On the Data Sources tab, check the group's default data source rights. A group created by an older release can simply have these unset. The built-in groups should have:

Built-in groupExpected Data Source rights
AdminView, Add, Edit, Delete
Default UserView

If a right the group should have is unchecked, select it and save the group.

note

Whether these checkboxes can be edited depends on your Cortex version, so your screen may not match another environment's:

  • In 2.7 and earlier, they are ordinary editable checkboxes, and a group that has come through an upgrade can easily have them unchecked.
  • From 3.0.0, the Data Source rights of the built-in Admin and Default User groups are treated as fixed. The checkboxes are read-only and Cortex displays "Data Source permissions for this built-in group are fixed. To customize Data Source access, create a separate security group and assign users to it." In these versions the correct values are restored automatically on startup, as described below.

If your version shows the fixed message and you need different Data Source access for a set of users, create a new security group and assign those users to it.

Cortex may correct this on its own​

On startup, Cortex runs a one-time normalization that restores the correct Data Source rights for the built-in Admin and Default User groups on 3.0.0 and later, and restores full admin rights on the Admin group and other legacy admin groups on 3.1.0 and later.

If you are on one of those releases and the values are still missing, restart Cortex (recycle the application pool in IIS) and check again before editing anything by hand. The normalization is skipped if Cortex has read-only access to its configuration database.

Step 3: Users have no Cortex Security Group​

Cortex creates three built-in security groups on startup if they do not already exist: Admin, Default User, and Default Portal. Deleting a broken group and restarting Cortex recreates it with the correct default permissions.

warning

Only recreate a group when it is genuinely broken and cannot be repaired through the Admin → Security Groups screen. Recreating a group assigns it a new ID, so every user mapped to the old group must be re-mapped afterwards.

Recreate a default security group​

  1. In SSMS, right-click the cortex.SecurityGroups table and select Edit Top 200 Rows.
  2. Right-click the row for the group and choose Delete.
  3. Recycle the Cortex application pool in IIS (or restart IIS).
  4. On startup, Cortex recreates the missing default group with the correct permissions.

Re-assign users to a group​

  1. List the security group IDs so you have the new one to hand:

    SELECT Id, Name FROM cortex.SecurityGroups;

  2. Point each affected account at the correct group:

    UPDATE cortex.UsersToSecurityGroups
    SET CortexSecurityGroup = '<Group-Id>',
        UpdatedAt = GETUTCDATE()
    WHERE Username = '<username>' OR EmailAddress = '<email>';

    Replace <Group-Id> with the Id from step 1, and <username> or <email> with the account you are fixing.

warning

Do not change the SecurityGroupRecId column while you are in this table. Despite the name, it is not the Cortex security group ID - it is a Cherwell security group mapping that controls the account's access to source data. Changing it will break that user's data access. Only ever edit CortexSecurityGroup.

Bulk-assign accounts that have no group​

If many accounts have an empty CortexSecurityGroup - common when a whole environment was upgraded from an older version - assign them all the Default User group in one statement, then promote the few that need admin through the Cortex UI.

UPDATE cortex.UsersToSecurityGroups
SET CortexSecurityGroup = '<Default-User-Group-Id>',
    UpdatedAt = GETUTCDATE()
WHERE CortexSecurityGroup IS NULL;

You can list the group IDs with the query above to find the ID of the Default User group.

Step 4: Verify the fix​

  1. Have the affected user refresh the page in Cortex, or sign out and sign back in.
  2. Confirm the Admin screens now open and that the expected data sources and records are visible.
  3. If an admin account still cannot reach a specific admin section, re-check that section's View permission on its security group (the Admin Permissions tab on 3.1.0 and later, or the Application tab earlier).