## TL;DR
Treat the timeout as a path or response problem between the provisioning tool and the RADIUS server, not as a failed user. Verify the RADIUS service is answering, the shared configuration matches, and the provisioning step waits long enough and retries safely with idempotency, then create the hire account and confirm an authentication test passes.

```text
VPN account provisioning failed: RADIUS user creation timeout
```

## Use this when
- The onboarding job creates the directory account but the VPN or RADIUS step reports a timeout.
- Manual RADIUS administration shows the user sometimes exists despite the timeout message.
- Timeouts worsen during bulk onboarding batches.

## Not for this skill when
- Provisioned users cannot connect with the VPN client. That is a client and policy problem after provisioning.
- The RADIUS server is down for existing users too. Restore the service before provisioning work.

## Steps
1. Check whether the user was actually created despite the timeout by searching the RADIUS user store or its backed directory group for the hire, because a lost response often means success without confirmation. Record the true state before retrying to avoid duplicates. Verify: the RADIUS-side existence of the hire account is established
2. Test the RADIUS service health from the provisioning host: confirm the service responds on its authentication and accounting ports, check server load and recent restarts, and review the RADIUS log for the timed-out request arrival. Verify: the request reached the server or the path failure point is located
3. Compare the client configuration on the provisioning tool with the RADIUS server client entry: network address, ports, and protocol settings must match, and any network change such as a new provisioning subnet must be registered as an allowed client. Never print or share the secret value itself while checking. Verify: the client entry matches the tool host and settings
4. Adjust the provisioning step timing: raise the response timeout modestly, add a retry that first checks existence by username before creating, and serialize bulk creations so a batch does not flood the server. Verify: the step configuration shows the existence check before create
5. Create the hire VPN account through the fixed step, then run an authentication test with the account against RADIUS using the standard test tooling and confirm the correct group or attributes return for VPN access. Verify: the test authentication succeeds with the expected attributes
6. Add monitoring on RADIUS response times seen by the provisioning job and an alert when creations time out, so the next degradation is caught before a hiring batch hits it. Verify: the monitor and alert are active for the provisioning path

## Why it happens
RADIUS runs over UDP in most deployments, so responses can be lost under load or across congested links, and the client reports a timeout without knowing whether the server processed the request. Provisioning tools written as simple request-and-wait calls amplify this by retrying blindly or abandoning the step. The server may also drop requests from unregistered client addresses silently. An existence check before create plus measured timeouts and server-side log confirmation turns an ambiguous protocol behaviour into a reliable provisioning step.

## Variants and edge cases
### Timeouts only from a new provisioning server
A migrated tool often sits on a subnet the RADIUS server does not know. Register the new client address and remove the decommissioned one.

### Accounting succeeds, authentication times out
Split services or a failing backend store can answer one port and not the other. Check the identity store the authentication path queries.

### Intermittent timeouts at peak times
Size the RADIUS service for the Monday onboarding peak and spread bulk jobs, rather than raising timeouts indefinitely to mask capacity.

Compatibility: Applies to FreeRADIUS, Microsoft NPS, and similar RADIUS services used for VPN account provisioning. Requires network and RADIUS admin access.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Jlf5oQj9ZV16XyHX9G7ikA