Manage groups

Users 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.

Group Types Used 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 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.

LDAP Groups

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.

Application Groups

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:

  • Box
  • Google Apps
  • Jira
  • Microsoft Office 365
  • Workday

Using Groups

The following sections describe the things you can do with the groups that you have created, synchronized, and imported.

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.

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.

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
  • Salesforce
  • Google
  • JIRA
  • Box
  • Slack
  • Dropbox
  • Jive
  • 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. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. 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.


Sample Configurations

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.