Configure CrowdStrike

Overview

Everything on the CrowdStrike side happens before Britive is touched. You need an API client for Britive to authenticate with, and the elevation scripts stored in Falcon where RTR can execute them.

Do the role check first. It is the step that most often stops a setup halfway through.

Before You Begin

• Falcon administrator access.
• Falcon Insight or Falcon Enterprise licensing, with RTR support.
• The elevation scripts from britive/access-broker-examples, or your own equivalents:

Steps

runscript -CloudFile="britive-elevate-windows" -CommandLine="-Username jdoe"

runscript -CloudFile="britive-deelevate-windows" -CommandLine="-Username jdoe"

What the Scripts Do

Both platforms follow the same shape: resolve the account, change the group, verify the change took, notify the user, then report the outcome on stdout. The verification step matters — a group change that silently failed would otherwise look like a successful elevation.

try {
    $isMember = Get-LocalGroupMember -Group "Administrators" -ErrorAction Stop |
        Where-Object { $_.SID.Value -eq $accountSid }

    if ($isMember) {
        Write-Output "User '$qualified' is already a local Administrator."
    }
    else {
        Add-LocalGroupMember -Group "Administrators" -Member $qualified -ErrorAction Stop
        Write-Output "SUCCESS: Added '$qualified' to local Administrators."
    }
}
catch {
    Exit-BritiveFail -Code 'GROUP_ADD_FAILED' -Message "Failed to add '$qualified' to local Administrators. $_"
}

ALREADY_ADMIN=$(dseditgroup -o checkmember -m "$TARGET_USER" admin 2>&1 || true)

if echo "$ALREADY_ADMIN" | grep -q "yes"; then
    echo "User '$TARGET_USER' is already in the admin group."
else
    if dseditgroup -o edit -a "$TARGET_USER" -t user admin 2>/dev/null; then
        echo "SUCCESS: Added '$TARGET_USER' to the admin group."
    else
        fail "GROUP_ADD_FAILED" "Failed to add '$TARGET_USER' to the admin group."
    fi
fi

Every script takes a single -Username parameter. RTR is non-interactive and cannot prompt, so a missing parameter is reported as MISSING_PARAM rather than a prompt.

Reading the Result

Because of that, the outcome travels in stdout. Every script ends by writing one line:

BRITIVE_STATUS {"status":"success","action":"elevate","code":"OK","user":"CONTOSO\\jdoe","host":"WKS-01","message":"...","warnings":["notify_no_session"]}

How to read it, in order:

1. Take the last line matching ^BRITIVE_STATUS , strip the prefix, parse the rest as JSON.
2. If there is no such line, treat the run as an error. A missing marker means the script was killed, timed out, or its output was truncated — never that it succeeded.
3. Branch on status. Use code for specific handling; never parse message.

Rule 2 holds because the marker is written on every path, including unhandled failures — the Bash scripts arm an EXIT trap with a pessimistic default before doing any work, and the PowerShell scripts install a script-scope trap alongside the same default:

BRITIVE_STATUS="error"
BRITIVE_CODE="UNEXPECTED"
BRITIVE_MESSAGE="Script terminated before reaching an outcome."
...
trap emit_status EXIT

Result codes

Warnings

warnings records what degraded without changing the outcome — the privilege change is the deliverable; the notification and cleanup are not.

notify_no_session, notify_failed, notify_dialog_failed, notify_toast_failed, session_lookup_failed, profile_lookup_failed, verify_failed_soft, process_terminate_partial, file_delete_partial, desktop_not_found, user_not_found.

Human-readable prefixes

The chatty output above the marker uses consistent prefixes — SUCCESS:, VERIFIED:, WARNING:, ERROR: — which are useful when reading a run by hand. Do not parse them. They are for people; BRITIVE_STATUS is for machines.

Verify

BRITIVE_STATUS {"status":"success","action":"elevate","code":"OK",...}

net localgroup Administrators

dseditgroup -o checkmember -m jdoe admin

Troubleshoot

Next Steps