Users must authenticate in order to access network-based services including email, file servers, and business applications. Using groups can help you manage user access on a case-by-case basis.
To help make assigning access to networks and applications easier, you can group users based on common themes. For example, you might create a group called Sales and grant it access to the Sales Documentation folder on a company file server. Or, you might create a group called Company Employees that you assign to the company HR system.
Groups are important tools for identity management systems, and group data typically resides in a directory. Most applications support groups, either at the application level, or within the application to specific resources.
Groups are used in almost every IT department. This document clarifies how groups work in Okta.
The following sections describe the group types used by Okta.
Native Okta Groups
Before you connect Okta to anything, you can create groups in your Okta organization. The default group Everyone contains every person in your Okta org.
To manage your Okta groups, sign into your Administrator Dashboard and select Directory > Groups.
Active Directory Groups
The most common source of groups is Active Directory. Nearly every business of significant size uses Active Directory in some form. Okta integrates Active Directory through an AD agent.
Note: Okta does not support Domain Local Groups containing members from multiple domains. We do support Universal Security Groups with cross-domain membership, provided that there is a two-way trust established between the domains. Universal Security Groups do not support cross-forest membership.
Okta can import groups from LDAP-compliant servers through a Java LDAP agent that runs on both Windows and Unix. For supported LDAP distributions, see LDAP Agent Deployment Guide.
Some apps have groups that can be imported into Okta. The ability to import these groups depends on whether or not the groups can be accessed through an API and if the Okta app has been integrated to import them. Among the list of apps this includes are:
Importing Groups into Okta
The following sections describe the methods you can use to import groups into Okta.
Importing Groups From Active Directory Using the Okta AD Agent
You can import security groups from any forest or domain that you connect to Okta. Okta does not support distribution groups or Exchange Dynamic Distribution groups. The AD agent detects all groups in the domain or the OUs that you have selected. If you register an AD agent for more than one domain and you have the root OU selected for all domains, it imports all groups. To limit the groups that are synchronized, sign into your Administrator Dashboard, select Directory > Directory Integrations > Active Directory, click the Settings tab, and in the section Import and Account Settings, select only the OUs that you want to import. For details about using the separate OU selectors to set up more granular imports from specific OUs, see Installing and Configuring the Active Directory Agent.
About Group Imports
The AD agent imports groups differently depending on how your org is configured. After you install your first AD agent, you can specify the OUs that you want to connect Okta, and then run either an incremental or full import.
For details about common group import scenarios, see FAQ: Okta and AD Groups.
About Nested Groups
Many directory systems and applications support the concept of nested groups (or groups in groups). Okta does not currently support nested groups. Okta imports all nested directories for group members and adds the user to each group in Okta. See the example below in which the group in AD on the left has two groups as child members, and the resultant group in Okta on the right.
About Universal Security Groups
In Active Directory, a universal security group (USG) allows for membership across all trusted forests in an AD environment. By default, USGs only exist in Okta if there is an AD agent in a domain importing users and groups. Enabling the Universal Security Group (USG) option ignores domain boundaries when importing group memberships for your users. This assumes that the relevant domains are connected in Okta.
You must also deploy an AD agent for every domain in your forest that contains the USG object that you want to sync with Okta. Each connected domain then imports its groups. When a user's group memberships match any groups that were imported (from any connected domain in the forest), Okta syncs the memberships for the user to each group. This option provides greater control of group imports from on-premises apps to Okta. Only groups from connected domains are imported.
For details about USG import scenarios, see FAQ: Okta and AD Groups.
Importing Groups from Applications with Provisioning
You can import groups from applications that have provisioning enabled. If you set up an import schedule for the app, it also imports new groups that you add and makes membership changes to existing ones. If you only want to import groups, set up provisioning but do not configure any user options. You cannot edit the memberships of these imported groups.
Confirming Your Group Imports
After you configure provisioning on an app that supports groups, Okta automatically imports groups from that app. Sign into your Administrator Dashboard and select Directory > Groups to see newly imported groups. You can also select Reports > System Log, and then select the Application Imports (Summary) report to see new groups that have been imported.
Following a successful import, under specific conditions Okta automatically sends an email to designated administrators. The email details the number of users and groups scanned, added, updated, or removed during the import. Okta only sends the email if the scan detects any new users or groups, or changes to any existing user profile or group membership.
About Duplicate Groups in Microsoft Office 365
If your application also imports groups from Active Directory (for example, Office 365 via DirSync), you might have duplicate groups in Okta if you have enabled provisioning on the app. This happens under the following conditions:
When you configure provisioning on the forestZ Office 365 app, it automatically imports groups from Office 365 into Okta. There are groups in Office 365 that are imported from forestA that already exist in Okta because of a sync from the forestA AD agent. The image below shows a mix of groups from Box, LDAP, and Active Directory alongside native groups in Okta.
The following sections describe the things you can do with the groups that you have created, synchronized, and imported.
Assigning applications is one of the main uses of groups. You can assign users to an application manually, person by person (see People for more details), but this does not scale well when you have a large number of users. You can create groups directly in Okta but then you must also manage those groups in Okta. Most admins already have groups in their corporate directories (for example, in Active Directory or an LDAP server) that have existing group management processes to keep them up to date.
It makes sense to use these groups for application assignment purposes.
You can either select a group, then assign applications to that group; or you can select an application, then assign that application to one or more groups. Both methods are described below.
To assign apps to a selected group:
To assign a selected app to one or more groups:
After you assign apps to groups (or groups to apps), all users in the group can access the application from their Okta home page.
Note: Assigning applications to users might cause Okta to provision accounts for them in the target application. You can use groups imported from apps like Box and JIRA to manage application access, but this is not common. Groups from directories are more likely to be used for the management of group memberships.
When you assign a group to an application, there might be information in the target application that you want to assign to the user. For example, in Salesforce there is Profile and Role data. When a user is a member of more than one group assigned to the application, it might be confusing which Profile and Role they get. Group priority determines this.
To set group priority:
Choosing this option in UD allows admins to prioritize which individual attributes should be honored when a user belongs to more than one group.
The Office 365 app can serve as a good example of how this works. One very common attribute that Office 365 brings into Okta is Licenses. This is an attribute that might easily be shared by various groups within an organization. If a user is assigned to two different groups, Engineering and Sales, for example, which have overlapping attributes, choosing Combine values across groups would be the best choice because it unifies all the attributes.
Here's how this scenario might look in Office 365. A user named Mike Barnes is given the Office 365 app. Mike is a member of both the Engineering and Sales teams, shown as groups in Okta.
Both groups receive License data from Office 365. If an admin chooses the Use Group Priority option in UD (as explained in Group Priority, above), Mike would only receive attributes from the Engineering team because the group holds priority on the group level.
If an admin chooses Combine values across groups in UD, Mike would receive the attributes from both the Engineering and Sales groups because their attributes are combined.
See the next section, Applying an Option, for details on choosing this option.
Applying an Option
Group Priority options can be accessed during attribute creation, as shown below, and can be changed later.
To access group policy options, do the following:
Configuring Application Policies
You can use App Sign On Rules to deny access to apps if users are not accessing them from a particular network location, or enforce the use of multifactor authentication (MFA). When you define an app sign on rule, you can limit its scope to a group. You can configure policies to implement MFA for remote, temporary, or contract employees.
You can also use this feature to exclude groups. This feature is useful to allow a small group of users to access apps from anywhere, but we recommend that generally users should be on your corporate network.
For detailed information, see Application Level Multifactor Authentication.
Using Okta Groups in Applications and Directories
Okta enables you to define group membership in one directory and then use your groups in multiple connected systems. In on-premises systems, applications can connect to and query for groups from a central directory. Cloud apps often lack a common Active Directory, so you must use a different approach to use groups with multiple applications. Okta uses a feature called push groups to make this happen.
About Group Push
You can push groups from Okta to other connected applications and directories such as Box and Active Directory. The list below is not exhaustive, but includes the following:
Groups are pushed to applications using two methods.
Using SAML JIT Group Provisioning
You can have groups provisioned during the SAML sign-on process. This works well when you want to do the following:
The following sections provide examples of how groups can be used across Okta.
Provisioning Users in Target Applications
Applications that support provisioning can use group membership to determine which user accounts are created, updated, and deleted or deactivated. After you have configured provisioning, assign a group to your application. Members of the group are automatically created in the target app.
Some services have additional data that you can assign to a newly created user. For example, when you assign a group to a Salesforce application with provisioning enabled, you can choose the Salesforce roles and profiles that are assigned to users in the group.
Mapping Active Directory Groups to Box Folders
A company uses AD groups to control access to files and they are migrating to Box for file sharing. Folders are set up in Box that reflect the same or a similar hierarchy to the on-premises file server. Import groups into Okta and then push them to Box where they can be assigned to Collaboration Folders.
Using Group Membership Rules
Groups are an important asset so leveraging them properly is important. Groups simplify administration in various ways, including the ability to determine who gets access to applications, who is assigned a certain role in an app, and who gets subjected to security policies. Unfortunately, managing groups can be tedious, especially if users must be added and removed manually.
Before You Start
There are three important requirements that apply to all the uses of group membership rules in this article.
The Group Membership Rules feature simplifies the administration of groups. Creating rules allows you to automatically populate Okta groups based on rules that you define. For example, instead of manually populating a group named "Sales" in Okta, you can define a rule that populates the group with users whose attribute department = "sales". If a user's attribute value changes, Okta reevaluates the rule and removes the user from the group, as needed. Rules can be defined from the following:
*Valid groups must be "app groups," not Okta groups. App groups can come from any app, and are not limited to master sources.
The resulting groups can be used like any other group in Okta. Groups are commonly used to assign SSO access within Okta and to provision users to apps with specific entitlements (roles, profiles, etc). When rules are configured to populate groups based on attributes, you achieve attributed-based access control (ABAC).
Use Group Membership Rules to
Configuring Group Membership Rules
The following constraints apply to all group membership rules.
To start creating your own rules, do the following:
You now have two mechanisms for building a rule:
Evaluate a Single Attribute
Evaluate A Single Group
Evaluate Multiple Groups
Evaluate Multiple Attributes
Evaluate Combinations of Attributes and Groups
Please note that both mechanisms allow you to exclude individual users, and that attributes can only come from the Okta user profile. So if you want to evaluate attributes from WD, AD, or other sources, map them to the Okta user profile attributes first.
Adding users into the Exclude users field prevents the rule from acting on the excluded user. If the user did not satisfy the rules for being in the group, even meeting those conditions later will not add them to it. If they are already a member of the group, they will not be removed if they no longer meet the condition.
Note: The Excluded users field can only accept a maximum of 100 users.
After your rule is created and saved, it is inactive by default. Once activated, it will run across your entire user population. The new rule then runs on a particular user as its profile is updated via import, direct updating, or other changes.
Note: To successfully move users to their assigned groups, the user cannot be in a Pending or Inactive state.
To quickly verify your group membership changes, do the following:
Editing Your RulesAfter completion, the rules you've created appear under the Rules tab.
To edit your existing rules, click the Edit button—keeping in mind that a rule can only be edited when its status is Inactive.
In an inactive rule, click the Edit button to change the conditions of the rule or, add or remove members from the excluded users list. Here is where you can also remove users from the Exclude users list, as needed.
Note: The one element you cannot delete is an assigned group. To remove or change a previously assigned group, you must delete the rule and create a new one. To delete an inactive rule, click the X.
Adding People ManuallyIt is still possible to manually add or remove users to a rule-managed group, even if rules for that group already exist. Users added this way are displayed as such in the Managed column.
If a user is manually added to a group then, through profile changes, begins to meet the condition, they will automatically become managed by the rule. When you add a rule-managed user of the group into the Exclude users field, they are automatically excluded from the rule.
One common error is using "=" instead of "==" for equality checks.
Assume that user has the following attributes with types :
Examples of valid condition expression