UsersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. must authenticate in order to access network-based services including email, file servers, and business applications. Using groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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.
Note: When searching for a group, you can search by name, target groups, or use expression conditions.
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 orgThe Okta container that represents a real-world organization..
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 agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations..
Note: Okta does not support DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). Local Groups containing members from multiple domains. We do support Universal Security Groups with cross-domain membership if 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 appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. has been integrated to import them. Among the list of apps this includes are:
- Google Apps
- Microsoft Office 365
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. For details about AD group import scenarios, see FAQ: Okta and AD groups. The AD agent detects all groups in the domain or the Organizational Units (OUs) that you have selected. If you register an AD agent for more than one domain and you have the root OUAn acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. 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 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.
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.
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:
- You have two or more Active Directory forests. For example, forestA and forestZ.
- Microsoft DirSync is configured on forestA to synchronize all groups from the forest into an Office 365 (Azure AD) instance.
- Your Okta AD agent is configured to import users and groups from both forestA and forestZ into an Okta org.
- Okta is configured for provisioning with users from forestZ to the same Office 365 tenant.
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:
- Sign into your Administrator Dashboard, select Directory > Groups, and then select the group you want to assign apps to.
- Click the Manage Apps button to assign apps to the group.
- Click Assign for each app you want users in this group to have access to, then click Done.
Note that, depending upon the app you are assigning, you may need to complete additional dialog boxes. For example, some apps require you to provide certain attributes that will be assigned to all users in a group for that app.
To assign a selected app to one or more groups:
- Sign into your Administrator Dashboard, select Applications, and then select the application you want to assign to one or more groups.
- On the Assignments tab, click the Assign button.
- Select Assign to Groups for each group you want to assign this application to, then click Done.
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.
Note: You can convert application access and user properties settings so that individually-owned applications become group managed. For details see Converting Application Assignments from Individually Owned to Group Managed.
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:
- Select Applications from the Dashboard.
- Select an application.
- Click Assignments and then the Groups tab.
- Change the order of the groups by grabbing the dotted bar next to the group name, as shown below, and moving the group to the desired position in the list.Screenshot
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 adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. 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:
- From the Dashboard, select Directory > Profile Editor.
- Select the Profiles button for an app.
- Scroll down to Attributes for the app, then either click the Add Attribute button or scroll down to an existing attribute.
Once completed, click the Add or Save Attribute button.
Note: Attributes using this feature must use an array data type, and cannot be marked as User personal.
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 scopeA scope is an indication by the client that it wants to access some resource. 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:
- Active Directory
- Office 365
Groups are pushed to applications using two methods.
- By name: An Okta application administrator selects groups from Okta to be created and updated in the target app.
- By rule: You use a string in either the group name or description to push many groups at once.
Using SAML JIT Group Provisioning
You can have groups provisioned during the SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. sign-on process. This works well when you want to do the following:
- Add users to preexisting groups.
- Create new groups in Box.
- Manage group membership in Box.
Essentially there is no provisioning configuration. Group information is sent in the SAML assertion when the user signs into a target app. This is less flexible than group push, in which you must use regular expressions to filter the groups you want. The advantage of this method is that it is available as part of the SAML template. If your target application accepts group information by SAML, you can configure a template without requiring an engineering effort to implement group push. For more information, see Managing Groups for Box.
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.
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.
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:
- A single attribute
- Multiple attributes
- A single group
- Multiple groups
- Combinations of attributes and groups
The resulting groups can be used like any other group in Okta. Groups are commonly used to assign SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. 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
- Avoid manually adding users to groups to determine app assignments:
- Automatically assign users to apps via groups based on a user's attributes.
- Drive app assignment changes based on a user's profile.
- Avoid manually managing lots of groups for every app or role combination.
- Populate Active Directory (AD) groups based on whether a user has a certain attribute:
- Particularly useful in "Workday (WD) as a master" setups for which Okta provisions users and groups to AD. Example: Using the cost center attribute from WD to determine AD group memberships.
- Map Okta groups to AD groups
- Avoid PowerShell scripts
- Avoid expensive 3rd party tools
- Automate provisioning with rules:
- Example: if user profile attribute == X, then provision app Y with Role Z.
- Map multiple AD groups to one Okta group:
- If users belong to AD groups A, B, and C, then add them to Okta group X.
- Use existing groups to drive group memberships in the cloud.
- No need for redundant group management.
- Assign users matching certain criteria to multiple groups with one rule, so that you don't have to setup multiple rules for the same criteria.
Configuring Group Membership Rules
The following constraints apply to all group membership rules.
- Group rules get triggered when the following events occur:
- An attribute mentioned in the User profile changes
- The User's group membership changes. This is applicable to both user and app groups.
- There is a limit of 2000 rules for an org.
To start creating your own rules, do the following:
- From the Admin Dashboard navigate to Directory> Groups.
- Click the Rules tab, then the Add Rule button.
- Create a name for your rule.
You now have two mechanisms for building a rule:
- Simply point and click to create a rule
- Best used to create simple rules
- Create rules from one attribute
- Create rules from one or more groups
Evaluate a Single Attribute
Evaluate A Single Group
Evaluate Multiple Groups
- More customizable expressions with Expression Language functions
- Used to create complex rules
- Create rules from one or more attributes
- Create rules from one or more groups
- Create rules from combinations of attributes and 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.
- Specify single or multiple Okta groups in which the user should be placed if the rule condition is met, as shown below.
- If needed, specify any users that should be excluded from the rule in the Exclude Users field under Options, as shown below
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.
- Use the Preview field to preview how your rule will execute, as shown below.
- When finished, click the Save Rule button.
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:
- From the Groups page, click the All tab.
- Scroll down to the relevant group. Note the change in the People column for updates to the number of members.
- Click on the group name to view its page.
- You can verify the membership and who added the user.
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.
- Expressions must have a valid syntax and use logical operators, leveraging the Okta Expression Language.
- Expressions must evaluate to Boolean.
- Expressions cannot contain an assignment ("=") operator.
- User attributes used in expressions can only refer to available Okta user attributes.
- Most functions are supported in Okta Expression Language.
Note: In the context of custom Expression for Group Rules, only group and user attributes are supported. You cannot use customer expressions that use an application attribute.
- The AND operator
- The OR operator
- The "!" operator (aka NOT operator)
- Standard arithmetic operators like < , > <= , >=
One common error is using "=" instead of "==" for equality checks.
Assume that user has the following attributes with types :
- firstName (String)
- lastName (String)
- city (String)
- salary (Int)
- isContractor (Boolean)
Examples of valid condition expression
|If (implicit)||Condition Expression|
Assign to Group (or any action)
|If||user.city == "San Francisco"||sfo|
|If||user.salary > 1000000||expensiveEmployee|
|If||user.salary > 1000000 AND !user.isContractor||expensiveFullTimeEmployee|