Wednesday 28 December 2016

SISAS ISE Part One


        

What is ISE:
Provides a scalable and unified network access policy platform.
Centralized network access policy for any device , from anywhere , at anytime.

wired access
wireless access
VPN Access

Implements a flexible policy-based model
Rule-based approach for authentication & authorization
Rules are composed of conditions & results

ISE Personas
It supports both physical & virtual environment .
Built of three major roles , named personas

>> PSN (policy service node)
         Responsible for network access request processing
         --- Radius , posture , profiling , web redirection , guest portal
>> PAN ( policy administration Node)
        --- Responsible for all configurations
        --- Conditions, results , policies , external identity store integration
>> MnT ( Monitoring and Troubleshooting Node)
      --- Collects logs from PAN, PSN, NAD

ISE Deployment Modes

All personas residing on the same entity
Personas are distributed for scalability or design requirements
>> Multiple PSN's
>> 2 PAN's (one active , one standby)
>> 2 MnT's (one active, one standby)

ISE Architecture:

>> Everything circles around two types of policies
    -  Authentication policies , processed first
    -  Authorization policies , processed second
>> Inbound AAA request flow
    -  Authentication policy matching
       -  Single or rule-based policy
            - Single model does not allow defining conditions
       -  Rules are processed top-down until first match
           - Action "drop" means play dead , no RADIUS message sent back to NAD
           - Action "continue" means act like authentication was successful , inspect
             authorization policies

Inbound AAA request flow:
>> Authorization policy matching
      Standard and exception policies
           -- Exception policies are processed before standard policies
      > Rules are processed top-down until first match by default
     > Optionally multiple-rules can be matched with actions being combined
  ---- Access-Accept takes precedence over Access-Reject

Authentication Policies :

Based on configured conditions each request matches a rule:
       > Request is routed over to configured identity store or identity sequence
       > Identity is validated
       > If successful authentication , token is passed over to Authorization policies
      --- otherwise send Access-Reject or actions configured for authentication failure
       > Only processed if authentication passed
            > successful or by the explicit "continue" action
       > Based on configured conditions each request matches a rule
           > On match , access-access is issued and optional authorization attributes sent
          > ACL (dACL, filter-ID  ACL, per-user ACL, airespace ACL )
          > dVLAN and Voice VLAN permission
         > MACsec and URL Redirection (with Redirect-ACL)

Authentication Policy Format

if condition
     identify the RADIUS packet based on RADIUS attributes
Then allowed protocols
     which authentication protocols can be used by the supplicant
And Validate Credentials
      which identity source can be queried for authentication

Authorization Policy Format 

if condition
    Identify the RADIUS session or supplicant by profiling
And optionally if used identity store
    Store of user credentials
Then apply authorization profile
    User/device authorization
 

.

No comments:

Post a Comment