Creating Policies
Step-by-step guide to setting up authentication policies
Before You Start
You'll need at least one of these set up before creating a policy:
- Identity Provider - Where user credentials are verified
- Local Service - A RADIUS or LDAP service to assign the policy to
You can always come back and modify the policy later as you add more providers and services.
Creating a Policy
- Navigate to Policies in the sidebar
- Click Add Policy
- Enter a name and description
- Assign at least one local service
- Add identity providers to the authentication chain
- Click Save All Changes
Naming tip: Use descriptive names that indicate the policy's purpose. "Corp-WiFi-Standard" is better than "Policy1". You'll reference policies when configuring hosts.
Policy Editor Tabs
The policy editor has four tabs:
Tab 1: General
Basic policy settings and service assignments.
Unique identifier for this policy. Used when assigning the policy to hosts.
Notes about what this policy is for. Good for documentation.
Toggle off to disable this policy. Hosts using it will reject all authentications.
When enabled, this policy is used for hosts that don't have a specific policy assigned.
Select which local services (RADIUS, LDAP) can use this policy. A policy must be assigned to at least one service to be useful. You can assign the same policy to multiple services.
Tab 2: Identity Providers
Configure the authentication chain - the identity providers to check and in what order. Warden evaluates each IDP based on its logic operator to determine the final result.
Select and order your providers. Common patterns:
- Single AD/LDAP for corporate networks
- LDAP + Local for AD users with local fallback
- RADIUS for chaining to external MFA providers
Each IDP after the first has a logic operator that determines how its result combines with previous IDPs:
- AND - Both must pass. Use for layered auth (password AND MFA provider)
- OR - Either can pass. Use for fallback (try AD, or try local users)
- NOT - IDP must fail. Use for exclusions (must NOT be in blocked list)
AND and NOT bind tighter than OR (like math). This means:
A OR B AND C=A OR (B AND C)A OR B AND C NOT D=A OR (B AND C AND NOT D)A AND B OR C AND D=(A AND B) OR (C AND D)
If A succeeds, the entire chain succeeds (B, C, D are skipped). If A fails, then B AND C must both succeed for the chain to pass.
The NOT operator applies to one IDP at a time, not groups. To exclude multiple conditions, use De Morgan's law:
NOT (D AND E)=NOT D OR NOT E(either can fail)NOT (D OR E)=NOT D NOT E(both must fail)
Example: AD with Local Fallback
User passes if found in AD or local database
Example: Password + External MFA
User must pass LDAP and Duo push
Example: AD or (LDAP + MFA)
AD alone succeeds, or LDAP + Duo together succeed
Example: Exclude Blocked Users
User passes AD but is NOT in the blocked list
Optimization: Warden skips unnecessary IDPs. If an OR group already succeeded, remaining groups are skipped. If an AND group already failed, remaining IDPs in that group are skipped.
Order matters: Put your most-used provider first to minimize authentication time. If 90% of users are in AD, don't check a local database first.
Tab 3: 2FA Methods
Configure two-factor authentication requirements for this policy.
Where users enter their TOTP code in the password field:
- Append - After password:
password123456 - Prepend - Before password:
123456password
Note: This only applies to TOTP. Email OTP uses Access-Challenge flow where the code is entered separately after password verification.
Add one or more 2FA methods (TOTP, Email OTP, etc.) to require second-factor authentication. If any methods are configured, users must successfully verify with at least one of them. Methods are tried in priority order until one succeeds.
If no 2FA methods are added, two-factor authentication is not required for this policy.
Tab 4: Response Attributes
RADIUS attributes to return on successful authentication. See the Response Attributes guide for detailed documentation.
The RADIUS attribute name (e.g., Tunnel-Private-Group-ID, Session-Timeout).
How the attribute value is determined:
- Static Value - A fixed value you specify
- User Attribute - Pulled from the authenticated user's profile
- Group Attribute - Pulled from the user's group
- Computed - Calculated at runtime
The actual value or attribute path to use.
Optional transformation to apply to the value (e.g., uppercase, lowercase).
Click the "Templates" button to apply pre-configured attribute sets for common vendors (Cisco, Aruba, Meraki, etc.). This auto-populates the correct attribute names and formats.
Example: Corporate WiFi Policy
Here's a complete example for a typical corporate WiFi setup:
Testing Your Policy
- Assign the policy to a local service
- Ensure a host is using that service
- Attempt authentication with a valid user
- Check NAC Tracer to see the flow
- Verify the correct attributes were returned
- Test edge cases: wrong password, expired account, missing 2FA
Pro tip: Create a "test" host entry pointing to your workstation's radtest or similar tool. This lets you test policies without affecting production devices.