> For the complete documentation index, see [llms.txt](https://herd-security.gitbook.io/herd-security-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://herd-security.gitbook.io/herd-security-docs/okta/okta-single-sign-on.md). # Okta Single Sign-On Connect Okta as your organization's sign-in for Herd, from Settings, without waiting on Herd: create an OIDC app in Okta, enter its values in Herd, test it on yourself, then turn it on. Written so an ## Overview Herd connects to Okta over OpenID Connect (OIDC), not SAML. You set it up yourself in **Settings → General → Access → Sign-in**, in four steps: 1. Create the app in Okta. 2. Enter its credentials in Herd. 3. Test sign-in, on yourself. 4. Turn on SSO. Nothing changes for your organization until step 4. If anything is wrong, your organization keeps signing in exactly as it does today. Values move in both directions, and that is where most setups go wrong: * **Herd → Okta.** Herd *generates* three URLs. You paste them into the Okta app (step 1). * **Okta → Herd.** Okta *generates* the client ID and client secret. You paste them, with your Okta issuer URL, into Herd (step 2). You never type a client ID or secret of your own, and Herd never generates one. If you are looking for "where the keys are generated", it is the Okta app's **General** tab. {% hint style="info" %} SSO uses its own Okta OIDC app's **client ID and client secret**. It does not use the **API token** that Herd's Okta directory-sync tile (Settings → Integrations) takes. They are different credentials from different places in Okta. {% endhint %} ## Decide who gets the app before you build it This is the most consequential decision in the whole setup, and it is easy to get wrong. SSO only handles **sign-in**. Assigning someone to the Herd SSO app in Okta does not add them to Herd's people list, and removing them in Okta does not remove them from Herd (see [Keep your user list current](#keep-your-user-list-current)). Instead, a person appears in Herd the first time they sign in through Okta, named from their Okta profile. Whether a sign-in also gives them the Herd app depends on your organization's [app-access settings](/herd-security-docs/users/users/app-access.md#who-gets-app-access-when-they-sign-in) (**Settings → General → Access**): * By default, everyone who signs in gets the app as a learner, who sees only their own training. People whose access an admin removed get it back at their next sign-in. * With the identity-provider switch on the **Sign-in** card, Okta decides with a group (see [Send who gets the Herd app from Okta](#send-who-gets-the-herd-app-from-okta)). Everyone else lands on **Your training**. * Whatever the settings, once your plan's app seats are all taken, a person who would have got the app still signs in, to their own training only. Learners have no admin permissions. To make someone an admin, add them to Herd's **Full Access** group, which grants every permission in your organization, including **Organization › Manage admins and permissions**, **Organization › Manage network access** and **Communications › Send announcements**. If you set a default group on **Settings → General → Access → Access groups**, everyone who gets the app joins it, so if you make **Full Access** the default, **everyone you assign to the Herd SSO app becomes a full admin the moment they sign in**. {% hint style="warning" %} **Do this before you turn SSO on:** * **Check your default group.** On **Settings → General → Access → Access groups**, make sure the default group isn't **Full Access** (out of the box there's none), unless everyone who gets the app should be an admin. See [Access](/herd-security-docs/settings/settings/access.md#the-default-group). * **Choose who gets the app.** Everyone who signs in gets the app as a learner and takes an app seat. To limit it, let Okta decide with a group. See [App Access](/herd-security-docs/users/users/app-access.md). * **To bring everyone into Herd for training, use** [**Okta directory sync**](/herd-security-docs/okta/okta-group-and-app-sync.md) as well. It is a separate integration (**Settings → Integrations → Identity → Okta**, "Sync users and groups from Okta") and it brings people in as learners, with no dashboard access. That is how a whole workforce gets trainings and simulations. {% endhint %} ## Before you start * A Herd administrator account with the **Organization › Manage admins and permissions** permission (`org.permissions`). * Admin access to the Okta Admin Console, with a role that can create app integrations and assign them (for example Super Administrator or Application Administrator). * The same email address for you in Okta and in Herd: the test in step 3 checks that Okta signs you in as yourself. * A Herd password for yourself. You need it if you ever turn SSO off. {% hint style="warning" %} Some organizations can't use the self-serve setup, and Herd tells you so when you start, with a message that explains the reason and asks you to contact Herd support. It applies to organizations that sign in with Google through Herd, organizations whose sign-in is shared with another Herd environment, organizations whose sign-in routes to more than one identity provider, and organizations on Herd's PKCE proxy. For example: "This organization signs in with Google through Herd, so its sign-in is managed by Herd. Contact Herd support to move it to another identity provider." {% endhint %} ## Where each value goes | Value | Generated by | Where you find it | Where you paste it | | --------------------- | ------------ | --------------------------------------------------------------- | ----------------------------------------------------------- | | Sign-in redirect URI | Herd | Herd, step 1 (copy button) | Okta app → **General** → **Sign-in redirect URIs** | | Sign-out redirect URI | Herd | Herd, step 1 (copy button) | Okta app → **General** → **Sign-out redirect URIs** | | Herd app URL | Herd | Herd, step 1 (copy button) | Okta app → **General** → **Login** → **Initiate login URI** | | Issuer URL | Okta | Your Okta org URL, e.g. `https://acme.okta.com` (see step 2) | Herd, step 2 → **Issuer URL** | | Client ID | Okta | Okta app → **General** → **Client Credentials** → **Client ID** | Herd, step 2 → **Client ID** | | Client secret | Okta | Okta app → **General** → **Client Secrets** (copy icon) | Herd, step 2 → **Client secret** | The client ID and the client secret always come from the **same** Okta app. A client ID from one app with a secret from another fails. ## Step 1: Create the app in Okta In Herd, open **Settings → General → Access → Sign-in**, choose **Okta** and select **Begin setup**. Herd shows three values with copy buttons: the **Sign-in redirect URI**, the **Sign-out redirect URI** and the **Herd app URL (initiate login URI)**. Keep the page open. In the Okta Admin Console: 1. Go to **Applications → Applications → Create App Integration**. * **Sign-in method**: **OIDC - OpenID Connect**. * **Application type**: **Web Application**. * Select **Next**.
2. On **New Web App Integration**: * **App integration name**: Herd. * **Grant type**: keep **Authorization Code**. Nothing else is needed. * **Sign-in redirect URIs**: replace the example with Herd's **Sign-in redirect URI** (it ends in `/oauth2/idpresponse`). * **Sign-out redirect URIs**: replace the example with Herd's **Sign-out redirect URI**. * **Base URIs**: leave empty. * **Assignments**: choose who may sign in (you can change this later, item 4). Include yourself. * Select **Save**. Okta generates the client ID and client secret now.
3. On the new app's **General** tab, under **Login**, select **Edit**: * **Login initiated by**: **Either Okta or App**. * **Application visibility**: check **Display application icon to users**. * **Login flow**: **Redirect to app to initiate login (OIDC Compliant)**. * **Initiate login URI**: Herd's **Herd app URL**. * Select **Save**.
4. **Assignments** tab: assign the people or groups who should sign in to Herd, including yourself. Only assigned people can sign in once SSO is on.

Everyone assigned here gets the Herd app as a learner the first time they sign in, and takes an app seat (see App Access). If you've made Full Access the default group, that makes them a full admin: assign only the people who should be admins. With the identity-provider switch on, assigning someone here lets them sign in but gives them the app only if they're in the Herd app group. To bring the rest of your workforce into Herd for training, use Okta directory sync as well.

Equally, once SSO is on, only people assigned to the app in Okta can sign in to Herd. Check the assignment covers every admin and everyone else who needs the app before you turn it on.

Assign yourself to the app too, before you test. If your issuer is a custom authorization server such as https://<org>.okta.com/oauth2/default, also make sure an access policy on that server covers the Herd app: without one, Okta refuses the test sign-in with "Policy evaluation failed for this request".

5. **General** tab → **Client Credentials**: copy the **Client ID**. Under **Client Secrets**, copy the secret with its copy icon. Keep **Client authentication** as **Client secret**.
Back in Herd, select **I've created the app**. ## Step 2: Enter its credentials | Field | Value | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issuer URL | Your Okta org URL, e.g. `https://acme.okta.com`. If your Okta uses a custom authorization server, use its **Issuer URI** instead (Okta: **Security → API → Authorization Servers**), e.g. `https://acme.okta.com/oauth2/default`. Use the plain org URL, not the admin console's `acme-admin.okta.com`. | | Client ID | The **Client ID** from the app's **General** tab. | | Client secret | The secret from the same app's **Client Secrets** section. Herd stores it encrypted and never shows it again. | | Scopes | Leave `openid email profile`. Must include `openid`; `email` is how Okta releases the address Herd signs people in by, and `profile` their first and last name. Herd updates a person's name and email address from these at each sign-in, unless directory sync or SCIM provisioning already manages them (then it only fills in a missing name). | Select **Save and continue**. Herd checks the issuer before saving anything: an issuer that serves no OIDC discovery document, or that is a Microsoft or Google issuer, is refused with the reason. Any other wrong issuer is saved and fails at the test sign-in in step 3. ## Step 3: Test sign-in Select **Run test sign-in**. A new tab signs you in through Okta, as yourself. Herd checks that Okta signed you in with your own email address, then shows the result in both tabs. Your organization's sign-in has not changed. If a value in step 2 was wrong, select **Edit credentials** on this step, fix it and save again (see [Fix a wrong client ID or secret](#fix-a-wrong-client-id-or-secret)). Then run the test again. {% hint style="info" %} A passed test is good for **one hour**. If you come back later, run the test again before turning SSO on. {% endhint %} ## Step 4: Turn on SSO Within an hour of a passing test, select **Turn on SSO**. The button is there only for the administrator who ran that passing test: any other admin sees the test step instead, and has to run the test themselves. From then on: * Everyone in your organization signs in to Herd through Okta. * Sign-in security, MFA included, is set in Okta; the **Multi-factor authentication** card is hidden. See [General & Security](/herd-security-docs/settings/settings/general-and-approvals.md#security-and-access). * Only people assigned to the app in Okta can sign in. Herd confirms with "Single sign-on is on. Your organization now signs in through Okta." The **Single sign-on** card then shows **Identity provider: Okta**, your Okta host on its **Domain** row, and **Status: Active: your organization signs in through Okta**. ## Fix a wrong client ID or secret Herd keeps the client secret you saved and reuses it when you leave the secret field blank, **but only together with the client ID and issuer it was saved with**. The saved secret belongs to the saved client ID. So whenever you change the client ID (or the issuer URL), you must enter the client secret again, even if the secret itself did not change. A setup that Herd configured for you, rather than one made in self-serve setup, never reuses its saved secret at all: Herd asks for the secret every time you edit those credentials ("Enter the client secret. The saved setup was not made in self-serve setup, so its secret is not reused"). 1. In Herd, open **Settings → General → Access → Sign-in**: * The card shows **Edit credentials** (a configuration is waiting to be tested, whether or not a test has run yet): select **Edit credentials**. Do not re-run the test first; it fails the same way until the values are fixed. * The card shows **Turn on SSO** (the waiting configuration passed its test, but you still need to change it): select **Run the test again** on that card. It brings back the test step without starting a test; select **Edit credentials** there. * SSO is on and nothing is waiting to be tested (the card shows **Test again** and **Reconfigure**): select **Reconfigure**. 2. In Okta, open the Herd app's **General** tab. Copy its **Client ID** and, from **Client Secrets** in the same app, its client secret. 3. In Herd, correct the **Client ID** (and the **Issuer URL**, if that is wrong too), and paste the client secret from the same Okta app into **Client secret**. Do not leave the secret blank: Herd refuses a changed client ID or issuer URL with a blank secret. For a changed client ID the form says so before you save ("You changed the client ID, so enter the client secret too: copy it from the same app as the new client ID"); for a changed issuer URL Herd says so when you select **Save and continue**. 4. Select **Save and continue**, then run the test sign-in again. A live configuration keeps working while you do this. The corrected one takes over only after it passes the test and you select **Turn on SSO**. If you changed the issuer URL or client ID, people signed in through the old configuration are signed out at that point and sign in again through the new one. If you only rotated the secret (same issuer URL and client ID), nobody is signed out. To **rotate the secret** with the same client ID, use the same steps and paste the new secret; the client ID stays as it is. ## Who gets app access Assigning someone to the Herd app lets them sign in. Whether that sign-in gives them the Herd app or only their own training depends on your access settings; see [Who gets app access when they sign in](/herd-security-docs/users/users/app-access.md#who-gets-app-access-when-they-sign-in). Usually every sign-in gets the app, as a learner who sees only their own training, or in your default group if you've set one (if that's **Full Access**, **assign the Herd app only to people who should be admins**); with the identity-provider switch on, the group Okta sends decides. To let people who only take training reach it from the Herd tile in your app launcher, see [Let People Reach Their Training from My Apps](/herd-security-docs/users/users/let-people-reach-training-from-my-apps.md). ### Send who gets the Herd app from Okta To let Okta decide who gets the Herd app, send the person's groups to Herd and tell Herd which group gets the Herd app. For what Herd does with it, see [Your identity provider decides](/herd-security-docs/users/users/app-access.md#your-identity-provider-decides). In Okta: 1. Go to **Directory → Groups** and create a group such as `herd-app`. Add your admins to it. 2. Go to **Applications → Herd → Assignments** and assign the group to the app, next to the people who already have access. 3. Open the app's **Sign On** tab and, under **OpenID Connect ID Token**, select **Edit**. * **Groups claim type**: **Filter**. * **Groups claim name**: `groups`. * **Groups claim filter**: **Starts with** `herd-`. * Select **Save**. The filter keeps the claim to the groups Herd needs. Okta sends only the groups that match, and Herd ignores a claim value longer than 2,048 characters, so avoid a filter that matches most of your groups. In Herd: 1. Open **Settings → General → Access → Sign-in**. Under **Who your identity provider gives the Herd app**, enter the claim name `groups` and the value `herd-app` (the group's name, exactly), then select **Save**. Herd shows **App-access claim saved**. This section appears once single sign-on is on. 2. Sign out of Herd and sign in again through Okta, so your own sign-in carries the group. 3. On the same card, turn on **Let the identity provider's app-access claim decide who joins the default group**. Herd refuses if your own sign-in did not carry the group; see [Turning it on](/herd-security-docs/users/users/app-access.md#turning-it-on). Whether you need one more step in Okta depends on which authorization server your Herd app signs in through. Check the issuer URL in **Settings → General → Access → Sign-in**: * **Org authorization server**: the issuer is your Okta address alone, `https://.okta.com`. Herd requests the `groups` scope from Okta for you, and the Groups claim you set on the app's **Sign On** tab comes back with it. Nothing more to do; after you save the app-access claim, Herd says it requests the `groups` scope for you. * **Custom authorization server**: the issuer has an `/oauth2/` path, `https://.okta.com/oauth2/` (`/oauth2/default` included). Herd leaves its scopes alone, because a custom server refuses a scope it has not defined, which would stop everyone signing in. Add the groups claim to that server's ID token instead, which needs no scope. In Okta: 1. Go to **Security → API → Authorization Servers** and open the server in your Herd issuer URL. 2. On the **Claims** tab, select **Add Claim**. 3. **Name**: `groups`. **Include in token type**: **ID Token**, **Always**. **Value type**: **Groups**. **Filter**: **Starts with** `herd-`. Select **Create**. **Recommended:** create a second group, such as `herd-learners`, put everyone else who signs in to Herd in it, and keep the same **Starts with** `herd-` filter so the claim is sent for them too. When Okta sends a groups claim for every person, someone you remove from `herd-app` loses the Herd app at their next sign-in without depending on Okta leaving the claim out. Herd treats anything that is not one of your configured values as no app access. ## Troubleshooting | What Herd or Okta shows | What it means | Fix | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "You changed the client ID, so enter the client secret too: copy it from the same app as the new client ID" (the form's wording; Herd's refusal when you save says "…so enter the client secret as well") | The client ID differs from the saved one and the secret is blank. | Paste the client secret from the same Okta app as the new client ID. | | "You changed the issuer URL, so enter the client secret as well. The saved secret is reused only with the issuer and client ID it was saved with." | The issuer differs from the saved one and the secret is blank. | Paste the client secret again, from the same app as the client ID. | | "Could not reach the IdP's OIDC discovery document at …", or "IdP OIDC discovery returned … for …" | Herd could not read an OpenID Connect discovery document at the issuer URL, so nothing was saved. | Check the **Issuer URL** for typos. For an Okta custom authorization server it ends in `/oauth2/`. | | "That is not your Okta issuer. Microsoft and Google issuers are set up as their own identity provider, not under Okta." | The issuer URL is a Microsoft or Google issuer. | Use your Okta org URL. To sign in with Microsoft or Google instead, set that provider up on its own, not under Okta. | | Okta error page: "Invalid value for 'client\_id' parameter" | The client ID in Herd is not an Okta app's client ID (a typo, or copied from somewhere else). | [Fix the client ID](#fix-a-wrong-client-id-or-secret). | | Okta error page about `redirect_uri` | Herd's sign-in redirect URI is not on the Okta app. | Paste Herd's **Sign-in redirect URI** into the app's **Sign-in redirect URIs** exactly. | | The sign-in page, after SSO is on: "…your email's domain isn't set up for this organization in Herd…" | Herd doesn't already know the person by their Okta id, and their email is not on one of your organization's email domains, so Herd has no account to link and creates none. | If the domain is yours, ask Herd support to add it ([People on another email domain](#people-on-another-email-domain)). | | "The identity provider did not sign you in: …" mentioning the client or `invalid_client` | The client secret does not match the client ID. | [Enter the secret again](#fix-a-wrong-client-id-or-secret), from the same app as the client ID. | | Okta says you are not assigned to the app | You are not on the app's **Assignments** tab. | Assign yourself (step 1, item 4). | | The test fails because Okta released no email address for you | The `email` scope or attribute is missing. | Add the email attribute to the Okta application, keep `email` in **Scopes**, check your Okta profile has an email, then run the test again. | | "The test signed in as a different person" | The browser was already signed in to Okta as someone else. | Sign out of Okta in that browser, then run the test again as yourself. | | "…which is not on one of your organization's email domains" | Herd links sign-ins only on your organization's own domains. | If the domain is yours, ask Herd support to add it. | | "That sign-in happened before this SSO setup was saved" | An earlier Okta session was reused. | Sign out of Okta in that browser and run the test again. | | "Your test sign-in was more than an hour ago. Run the test again, then turn SSO on." | The passing test expired before SSO was turned on. | Run the test again, then select **Turn on SSO**. | | "Your single sign-on session is more than 24 hours old. Sign in again to continue." | An Okta-started session reached 24 hours since the person's last Okta sign-in. | Herd normally sends them through Okta and back to their page without stopping. If they land on Herd's sign-in page instead, select **Continue to Sign In**; while their Okta session is active, Okta signs them straight back in. | | "You can only sign in through SSO, so turning it off would lock you out" | Herd refuses to turn SSO off for an administrator who has no Herd password of their own. | Ask an administrator who has a Herd password to disable SSO. | | Herd doesn't appear on anyone's Okta dashboard | **Display application icon to users** is off — it is off by default — or the app's login settings are incomplete. | On the app's **General** tab, check **Display application icon to users**, and confirm **Initiate login URI** holds Herd's **Herd app URL** and **Login initiated by** is **Either Okta or App** (step 1, item 3). | | You can't find the **Single sign-on** card in Herd | Your account lacks the **Organization › Manage admins and permissions** permission, so the card is hidden. | Ask an admin to grant it, or to do the setup. See [Managing Roles, Groups, and Permissions](/herd-security-docs/how-to-documentation/managing-roles-groups-and-permissions.md). | | A message that your organization's sign-in is managed by Herd | Your organization is one of the cases Herd manages directly: it signs in with Google through Herd, its sign-in is shared with another Herd environment, its sign-in routes to more than one identity provider, or it is on Herd's PKCE proxy. Each case has its own message. | Contact Herd support; the self-serve setup can't change it. | ## People on another email domain When Herd doesn't already know a person by their identity provider's id, it can only match them by email, and it links or creates their account only for an address on one of your organization's email domains. Herd support keeps that list for your organization: to add a domain (a contractor's company, an alias domain, a newly acquired company), contact Herd support. Until it is added, a person on that domain whom Herd doesn't already know is refused, and the sign-in page says: > Your identity provider signed you in, but your email's domain isn't set up for this organization in Herd. Ask your Herd admin to have it added, then sign in again. The sign-in page never lists your organization's domains. The domain list is not an access control: someone on another domain whom directory sync added, or who is already linked to your identity provider, still signs in. Control who can sign in at your identity provider. ## Admin accounts that sign in with a Herd password Herd never lets an identity provider take over a Herd admin account that signs in with a Herd password just because it sends the same email address. * **You, the administrator running the setup**, get through: your test sign-in proves which Okta identity is yours, and your first Okta sign-in after you turn SSO on (within 7 days of turning it on) moves your account. * **Other admins who sign in with a password**: once SSO is on, their first sign-in through it is refused, and the sign-in page says why and shows **Sign in with your Herd password**. They sign in that way, which takes them to the **Single sign-on** card, and choose **Connect my account to SSO**. That signs them in through Okta once, to prove which identity is theirs; their next sign-in through SSO, within 7 days, moves their account. Accounts that are not admins follow the usual rules above. ## Changing or turning off SSO * **Test again** re-runs the test against your live configuration without changing it. It is offered only when Herd can re-stage your live values as they are; for a setup Herd configured for you, use **Reconfigure**. * **Reconfigure** stages new values (a corrected client ID, a rotated secret, a new issuer). They are tested before they replace the live configuration. * **Disable SSO** returns everyone to Herd passwords. You need a Herd password yourself to do this. ### Disable SSO Select **Disable SSO**. Herd asks "Disable single sign-on?" and explains that this is an off switch, not a pause: * Sign-in through Okta stops right away: Okta can no longer sign anyone in to Herd, and sessions that started through Okta stop working. * Everyone signs in with a Herd password instead. People who have only ever signed in through Okta don't have a Herd password yet, so plan for that before you disable SSO. * You need a Herd password yourself, so you can still sign in. If you can only sign in through SSO, Herd refuses: "You can only sign in through SSO, so turning it off would lock you out. Ask an administrator who has a Herd password to turn SSO off." On success: "Single sign-on is off. Your organization signs in with Herd passwords." Setting SSO up again afterwards starts the wizard over, and asks for the client secret again. ## Leavers and existing sessions A Herd session that started through Okta lasts **24 hours from the person's last Okta sign-in**. Using Herd during that time does not extend it. After 24 hours Herd ends the session and sends the person to your organization's Herd sign-in page, which hands them straight to Okta. While their Okta session is still active, Okta signs them back in without asking for their password, and Herd returns them to the page they were on. If their Okta session has also ended, they see Okta's own sign-in page first. People who sign in with a Herd password are not affected by the 24-hour limit. Unassigning or deactivating a person in Okta stops new sign-ins. If you provision Herd through [SCIM](/herd-security-docs/settings/settings/scim-provisioning.md), Okta also deactivates them in Herd, which ends their Herd session straight away. Without SCIM, a session they already have lasts until 24 hours after their last Okta sign-in. Turning SSO off ends all Okta-started sessions at once. So if you don't use SCIM, deactivate leavers in Okta **and** remove them in Herd. See [Directory](/herd-security-docs/users/users.md). To make sure nobody can keep using a Herd password instead of Okta, turn on [**Require single sign-on**](/herd-security-docs/settings/settings/access.md#require-single-sign-on). ## Keep your user list current SSO controls who can sign in. It never removes anyone from Herd. People you deactivate in Okta, or unassign from the Herd app, can no longer sign in, but they stay on Herd's **Users** list and keep receiving training, reminders and simulations until something tells Herd they left. Herd's **Users** page says so while nothing does. Connect one of these so Okta removals reach Herd: * **SCIM provisioning** through a second Okta app, used only for provisioning and assigned the same groups as this one (Okta can't add SCIM to the OIDC app you sign in with): Okta adds the people you assign and removes the people you unassign or deactivate, as it happens. It needs provisioning (Okta Lifecycle Management) on your Okta org. See [Okta SCIM Provisioning](/herd-security-docs/okta/okta-scim-provisioning.md). * **Okta directory sync** in **Settings → Integrations → Okta**: Herd reads your Okta users and groups and removes the people Okta deactivated. See [Okta Group & App Sync](/herd-security-docs/okta/okta-group-and-app-sync.md). Without either, use the **Possibly left** filter on the [Users page](/herd-security-docs/users/users.md#searching-and-filtering) to find people who have probably left. ## Who changed what Every setup, turn-on, reconfiguration and disable is recorded in your organization's audit log, with the administrator who did it. The client secret is never recorded. Review the entries under **Reports → Activity → Activity log**, which needs compliance view access; see [Activity & Monitoring](/herd-security-docs/reports/reports/activity-and-monitoring.md#activity-log). ## Set the application image 1. Scroll to the top of your application settings in Okta. 2. Select the pencil button next to the gear icon. 3. Save the image below.
4. Upload it to Okta. The Herd tile on the Okta dashboard now shows the logo. ## Related * [Okta Group & App Sync](/herd-security-docs/okta/okta-group-and-app-sync.md) — the separate integration that brings your workforce into Herd as learners. * [Managing Roles, Groups, and Permissions](/herd-security-docs/how-to-documentation/managing-roles-groups-and-permissions.md) — what people who get the app can do, and how to set the default group.