Configure automatic account inactivity disable
What you’ll accomplish
Section titled “What you’ll accomplish”You’ll configure UDS Core’s Keycloak to automatically disable non-admin user accounts that have not authenticated for a configurable number of days. Accounts belonging to realm administrators are excluded and are never automatically disabled.
Prerequisites
Section titled “Prerequisites”- UDS Core 1.2+ deployed
- UDS CLI installed
- UDS Registry account created and authenticated locally with a read token
Before you begin
Section titled “Before you begin”UDS Core uses the Keycloak Workflows preview feature to track user-authenticated events per user and trigger a disable-user action after the configured inactivity window. The workflow is seeded into the uds realm on initial deployment and is disabled by default (ACCOUNT_INACTIVITY_DAYS unset).
What counts as activity: The workflow tracks user-authenticated events. Any successful login through UDS Core SSO, including logins via federated identity providers (Azure AD, Google SAML), resets the inactivity timer.
Newly provisioned accounts: Accounts that have never logged in do not generate a user-authenticated event and therefore never start a workflow instance. Accounts provisioned before this feature was enabled are also not retroactively evaluated. Run a one-time audit of last-login timestamps after enabling via Keycloak Admin Console → Users.
Admin accounts excluded: Users with the realm-management/realm-admin role are never disabled by this workflow.
-
Set
ACCOUNT_INACTIVITY_DAYSin your bundle overrideAdd the override to your
uds-bundle.yaml. Set the value to the number of days of inactivity after which you want non-admin accounts to be disabled.uds-bundle.yaml packages:- name: corerepository: registry.defenseunicorns.com/public/coreref: x.x.x-upstreamoverrides:keycloak:keycloak:values:- path: realmInitEnvvalue:ACCOUNT_INACTIVITY_DAYS: "35"Omitting
ACCOUNT_INACTIVITY_DAYS(the default) leaves the workflow disabled. -
Create and deploy your bundle
Terminal window uds create <path-to-bundle-dir>uds deploy uds-bundle-<name>-<arch>-<version>.tar.zst -
Optional: Update the inactivity window on a running instance
If you need to change the inactivity window after initial deployment, update the workflow directly in the Keycloak Admin Console:
- Log in to the Keycloak Admin Console at
keycloak.<admin_domain> - Switch to the uds realm
- In the left sidebar under Configure, click Workflows
- Open the
disable-inactive-usersworkflow - Click the
disable-userstep and update the after duration to your desired number of days - Toggle Enabled to On if not already enabled
- Click Save
- Log in to the Keycloak Admin Console at
Verification
Section titled “Verification”After deployment, confirm the workflow is active:
- Log in to the Keycloak Admin Console at
keycloak.<admin_domain> - Switch to the uds realm
- In the left sidebar under Configure, click Workflows
- Confirm the
disable-inactive-usersworkflow is listed and Enabled is toggled on - Log in as a non-admin test user through UDS Core SSO
- Return to the Admin Console, open the workflow, and click View active instances. A new instance should appear for the test user with a
disable-userstep scheduled at the number of days you configured
Troubleshooting
Section titled “Troubleshooting”Problem: Workflow shows as disabled after deployment
Section titled “Problem: Workflow shows as disabled after deployment”Symptom: The disable-inactive-users workflow exists in the Admin Console but Enabled is off.
Solution: ACCOUNT_INACTIVITY_DAYS was not set or was not applied. Verify the bundle override was included and the value is set to a positive integer. To enable on a running instance without redeploying, toggle Enabled directly in the Admin Console and verify the after duration on the disable-user step is set to your desired number of days. If the value reads 0, update it before enabling. A 0d duration will disable accounts immediately on their next login.
Problem: No workflow instances appear after user login
Section titled “Problem: No workflow instances appear after user login”Symptom: A non-admin user logged in successfully but no active workflow instance appears.
Solution: Confirm the login fired a user-authenticated event. In the Admin Console, navigate to Manage → Events, filter by event type LOGIN, and confirm the user’s event is present. Federated logins via an IdP also fire this event as long as the user authenticated through Keycloak.
Problem: A disabled account needs to be re-enabled
Section titled “Problem: A disabled account needs to be re-enabled”Symptom: A user cannot log in and their account shows as disabled.
Solution: An administrator must manually re-enable the account in the Keycloak Admin Console:
- Navigate to Users and find the affected user
- Click the user to open their profile
- On the Details tab, toggle Enabled to On
- Save
Problem: Admin account was disabled
Section titled “Problem: Admin account was disabled”Symptom: A user with admin privileges was automatically disabled.
Solution: The workflow excludes users with the realm-management/realm-admin client role. If an admin account was disabled, it was not assigned that role. Re-enable the account manually and assign the role via Users → select user → Role Mapping → assign realm-admin under realm-management.
Related documentation
Section titled “Related documentation”- Keycloak: Managing workflows - upstream reference for the Workflows preview feature
- Configure Keycloak account lockout - configure brute-force lockout thresholds alongside inactivity disable
- Configure user accounts and security policies - set password policy, email verification, and other account-level security settings