This is an old revision of the document!
CISCO ISE
Note that Cisco ISE (Identity Services Engine) is a RADIUS/TACACS+ Server + policy engine
The posture services workflow is comprised of three main configuration sections:
- Client provisioning
- Posture policy
- Authorization policy
The posture policy defines the set of requirements for an endpoint to be deemed compliant based upon file presence, registry key, process, application, Windows, and anti−virus (AV)/anti−spyware (AS) checks and rules. Posture policy is applied to endpoints based upon a defined set of conditions such as user identity and client OS type. The compliance (posture) status of an endpoint can be:
- Unknown: No data was collected in order to determine posture state.
- Noncompliant: A posture assessment was performed, and one or more requirements failed.
- Compliant: The endpoint is compliant with all mandatory requirements.
TO CREATE A NEW POLICY:
Add the device we want to be Authorised with ISE:
Admin. > Network Devices > Add
Policy sets: They have all the policy type. Authoriz and Authentication
Create the Authorization profile:
Policy > Policy Elements > Results > Authorization > Authorization profiles
Add the corresponding authorization and authentication policies:
Policy > Policy Sets
VPN posture completed and testing done to complete TSHOOT:
updated the security policy before doing so (gpupdate /force) on each machine
PROFILING
POSTURING
ISE NODES TYPES AND ROLES
- Node type:
- Admin (PAN)
- Policy Service (PSN): handles traffic between network devices and ISE (its IP is used aS RADIUS for devices).
- Roles:
- Primary
- Secondary
In order to access the nodes simply browse to node using https. Active Directory account can be used for login.
For the PAN nodes, the concept of primary/secondary must be understood purely from the user management interface point of view. Operationally, the secondary node does exactly the same as the primary one. The only difference is that the primary one allows the user to access all the management features (like logging or policy configuration)
PAN FAILOVER
Cisco advises to have PAN failover disabled.
If one of the ISE PAN nodes fails and we want to have admin features available in the healthy one, we manually promote the secondary to primary: to do so, we log into the UI of the secondary node. Promote to primary takes 10-15 mins and implies restarting services in both nodes. There's no impact in end users, just the Admin UIs get momentary unreachable.
RAISE TAC CASE:
- Operations > Troubleshoot > Download Logs and under Appliance node list select the ISE node you have issues with > 'Support Bundle' tab
- tick: debug logs ; local logs ; mon and reporting logs ; system logs ; from date to date
- encryption : public key enc
CLI:
show version # to check version and patch number show disks show application status ise # application server must be in 'running' state
802.1x
wired
- End users receive local VLAN after authentication and authorization via 801.1x supplicant.
- EAP-TLS is used for mutual authentication between the supplicant and the ISE (Radius) server + AD as a database.
- Supplicant sends the certificate in EAPoL (encapsulated in EAPoL)
- The access switch acts as an authentication capturing the user identity (certificate, MAC address..)
- The switch relays the attributes to via EAP (encapsulated in RADIUS messages) to ISE (RADIUS server)
- ISE authenticates and authorize the user-based after consulting the database (AD (via LDAP))
- ISE sends RADIUS access-accept message with an encapsulated EAP-success message. Also contains things like: radius vlan-id attribute and authorization options like dACLs
- Multiple policy sets in ISE allow flexibility
wireless
When 802.1x is used in wireless, every client (supplicant) uses a different WPA key for encrypting the traffic over the air. It is derived from the user's credentials and the shared secret between the client and the authentication server. So it's unique for every client.
The AP connects to the access switches via an access port ( management VLAN, used for AP<>WLC comms and AP discovery/configuration). Trunk port is not required because wifi traffic is encapsulated in CAPWAP and sent to the WLC. All segmentattion and tagging happens inside the CAPWAP tunnel.
Steps:
Client (supplicant) sends a special EAP request to the AP (EAPoL). EAPoL message is encapsulated in the CAPWAP protocol so it can reach the WLC. WLC forwards the EAP message to the ISE server encapsulated in a RADIUS packet. ISE (Radius) checks AD and, if positive, replies with a RADIUS Access_Accept packet. There are normall also attibutes like VLAN, ACL, etc. Now the WLC does two things: - Moves this session to an specific VLAN (eg: user in prod SSID goes to VLAN PROD) - Derives a unique WPA key for this client (supplicant) and sends it to the AP
