---
title: "Activity in Trails"
description: "The Trails events EZGH SSO records for management changes and for directory sign-in activity."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.ezghcloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Activity in Trails

EZGH SSO records events in [Trails](/trails) with `eventSource` `sso.ezghcloud.com`.

## Management events

Every management API call is recorded like any other API call, with the operation's name as
`eventName`, such as `CreateUser`, `SuspendUser`, `CreateApplication` or `UpdateAssignments`.
The [API reference](/sso-api) lists the operations; reading the catalog isn't recorded. Secrets
are never recorded: client secrets, identity provider client secrets, SCIM tokens, provisioning
bearer tokens, and service provider metadata documents.

When EZGH SSO finds an email domain's verification record, or loses it, it records a service
event, `UpdateDomainVerification` (`userIdentity.type` `EzghService`), naming the domain and its
new status. A custom domain's status changes are recorded the same way, as
`UpdateCustomDomainStatus`.

## Directory sync

Every change your identity provider makes over [inbound SCIM](/sso/scim), and every refused
change, is an `ApiCall`: `ProvisionUser`, `UpdateProvisionedUser`, `SuspendUser`,
`ReactivateUser`, `DeprovisionUser`, `ProvisionGroup`, `UpdateProvisionedGroup`,
`UpdateGroupMembership` or `DeprovisionGroup`. `userIdentity` is the `EzghService`
`scim.ezghcloud.com`, with the SCIM token's ID as `principalId` and its name as `userName`.
`resources` name the directory and the user or group. Reads, and requests refused with `401`,
`429` or `503`, aren't recorded.

## Provisioning pushes

Each [outbound provisioning](/sso/provisioning) push that changes something at an application is
a `ServiceEvent` by the `EzghService` `sso.ezghcloud.com`, naming the application and the user or
group: `ProvisionUser`, `DeprovisionUser` or `ProvisionGroup`. A push that stops is recorded once,
with `errorCode` `provisioning_failed`. Attribute values are never recorded.

## Directory activity

What directory users do at your portal is recorded in your organization too, with
`userIdentity.type` `SsoUser` and the directory in `resources`:

| `eventName` | Records | `eventType` |
| --- | --- | --- |
| `SignIn` | A successful sign-in at the portal | `SignIn` |
| `SignInFailed` | A failed sign-in, including for an email address that isn't a user | `SignIn` |
| `MfaChallenge` | A second-factor attempt | `ApiCall` |
| `Federate` | A sign-in through an identity provider, or its refusal for a known user | `ApiCall` |
| `AuthorizeApplication` | An OIDC grant or a SAML assertion issued, or its refusal (`not_assigned`, a reused code or refresh token) | `ApiCall` |
| `SignOut` | A sign-out, logout from an application (OIDC or SAML), or a refresh token revoked by its client | `ApiCall` |

- A failed sign-in for an email address that isn't a user has `userName`
  `HIDDEN_DUE_TO_SECURITY_REASONS`, and the address appears nowhere in the event.
- Token refreshes aren't recorded.
- Passwords, TOTP codes, passkey assertions, authorization codes, tokens, cookies, client
  secrets, identity provider responses, SAML assertions, NameIDs and attribute values are never
  recorded.

```sh
ezgh trails events --event-source sso.ezghcloud.com --event-name SignInFailed --from 1d
```

## Console access

When a directory user opens the console through [console access](/sso/console-access), the portal
records `AuthorizeApplication` for the console application (or its refusal, `not_assigned`), and
the console sign-in is recorded as `AssumeBot` in `signin.ezghcloud.com`, with
`userIdentity.type` `SsoUser`. A refused sign-in has `errorCode` `none_mapped` or `not_trusted`.
Everything they do in the console, and with the temporary API keys they get, is recorded as the
bot, with the person in `userIdentity.sessionContext.sourceIdentity`. Getting a temporary API key
is recorded as `CreateTemporaryApiKey` in `signin.ezghcloud.com`. See
[Console access: Auditing](/sso/console-access#auditing).

Source: https://docs.ezghcloud.com/sso/trails/index.mdx