SSO & CAC — Administrator Setup Guide ENT

Enforcing Microsoft Entra ID single sign-on for Enterprise features, and configuring Smart Card / CAC encryption.

Audience: IT / security administrators · Applies to: Slim Archiver Enterprise.

Scope: this guide covers Slim Archiver's own configuration — the policy keys, the Entra app-registration values it needs, and how enforcement behaves. Operating Entra ID itself (creating tenants, registering apps) is standard Microsoft procedure and is only summarized here.

What this feature does

When enabled, Slim Archiver requires a user to be signed in with your organization's Microsoft Entra ID before they can use Enterprise features. This adds an identity and session-governance layer on top of the Enterprise license — the license says the software is entitled; SSO enforcement says this signed-in user, from your tenant, within a session lifetime you set.

1. Concepts you need before configuring

• Enterprise-only. SSO enforcement and CAC encryption require an active Enterprise license. They are enforced in the engine, not merely hidden in the UI.
• Two independent gates. The license gate (is the software entitled?) is always active. The SSO gate (is a valid user signed in?) is opt-in — it applies only when you turn it on in policy.
• Blocked, not revoked. When SSO is required and no one is signed in, Enterprise features are disabled with a prompt to sign in — the license is never revoked, and sign-in is always reachable from Settings.
• Where the token lives. After sign-in, the session is stored in Windows Credential Manager under SlimArchiver_EntraID_SSO. It is never written to settings.json.

2. Policy configuration

SSO enforcement is configured in the machine policy file, read from %ALLUSERSPROFILE%\Slim Archiver\policy.json (typically C:\ProgramData\Slim Archiver\policy.json). Add these keys — all three are read by the engine's policy reader:

2.1 Example policy.json

{
  "requireSsoForEnterprise": true,
  "ssoTenantId": "<your-directory-tenant-id>",
  "ssoSessionLifespanHours": 8
}

Save the file with UTF-8 encoding. A leading byte-order mark (BOM) is tolerated. The file also holds your other governance settings (DLP, etc.) — add these keys alongside them.

3. Microsoft Entra ID app registration

Sign-in uses a public-client (native) app registration in your Entra tenant. Create one (or reuse an existing registration) with these characteristics:

From the registration you need two values for configuration and verification:

• Directory (tenant) ID — goes into ssoTenantId in policy.json.
• Application (client) ID — identifies the app during sign-in.

4. How users sign in

• Sign-in is available from Settings (and the Control Center), and is always reachable even when Enterprise features are blocked — this prevents a lock-out.
• The user signs in with their organization account; on success the session is stored in Windows Credential Manager and Enterprise features unlock.
• The session is refreshed silently while valid, and expires after the lifetime you set in ssoSessionLifespanHours, after which the user signs in again.

5. Smart Card / CAC encryption

CAC encryption encrypts an archive using a Smart Card / CAC credential instead of a typed password. It is an Enterprise feature and is available in both the app (Compress → Advanced → Security → CAC/Smart Card Encryption) and the CLI (-cac).

CAC is the most strongly protected Enterprise operation: it is gated in the compiled engine. When a user attempts a CAC-encrypted archive:

• If the license is not Enterprise, the operation is refused.
• If SSO enforcement is on and no valid sign-in exists, the operation is refused with a prompt to sign in with Entra ID — even from the command line.
• Only with an Enterprise license and (when required) a valid sign-in does the CAC operation proceed.

6. Verifying enforcement

The engine exposes a gate command that returns the current enforcement decision — use it to confirm your policy is applied:

slimarch.exe enterprise-gate

7. Security model & honest limits

So you can set expectations correctly, this is what the SSO gate does and does not guarantee:

• It is an administrative policy on your own already-licensed machines, for your own users — its purpose is governance and audit, not defending revenue against outsiders.
• CAC is hard-gated in the engine. Cloud and vault fetches check the same engine gate before acting.
• Session freshness is based on the credential's presence and last-written time; it is not a cryptographic validation of a signed token. A determined local user with administrative access to the machine's own credential store could bypass it — treat a bypass as a compliance gap, not a breach.
• DLP scanning is deliberately not SSO-gated, so protective scanning is never weakened by sign-in state.

8. Troubleshooting