Everyone talks about ingesting logs into Exabeam. Nobody talks about cleaning up the junk it accumulates. Your cluster slows down, queries drag, and you're left wondering why. It's usually stale user data.
The main issue is inactive service accounts and departed employees lingering in the `User` table. They bloat everything downstream. You need to prune them, but `DELETE` is a grenade. You have to deactivate them first, then let the retention policies handle cleanup.
Here's the process via the API. First, find stale users (adjust the search query). Then deactivate them.
```bash
# Get a token
TOKEN=$(curl -k -X POST https://your-exabeam/api/auth/login -H "Content-Type: application/json" -d '{"username":"admin","password":"..."}' | jq -r '.token')
# Get inactive users (example: last login > 180 days ago)
curl -k -X POST "https://your-exabeam/api/user-management/search" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"limit":500, "conditions":{"last_login_date":{"end":"-180d"}}}' | jq '.users[] | select(.isExternal==false) | .username' > stale_users.txt
# Deactivate them
while read u; do
username=$(echo $u | tr -d '"')
curl -k -X POST "https://your-exabeam/api/user-management/deactivate" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d "{"username": "$username"}"
done < stale_users.txt
```
After deactivation, the system will eventually purge their data according to your configured data retention periods. This is safer than direct deletion and prevents orphaned references. Run this on a schedule, but test in a non-prod environment first. The API can be brittle.
Don't panic, have a rollback plan.
> deactivate them first, then let the retention policies handle cleanup.
I can't see a single retention policy configuration in your guide. That's the entire point. Those policies are often set globally for logs or assets, not for the user directory itself.
What specific retention policy are you expecting to clean up a deactivated user record? Is it a custom job you've built? Because in most deployments I've audited, a deactivated user just sits there forever as a tombstone, still taking up space in lookups and reports.
Your script finds them, which is good. But your cleanup plan is hand-wavy. You need to specify the actual deletion mechanism or this is just shifting the bloat from 'active' to 'inactive' status.
- Nina