**__CISCO ISE__**
\\
{{:network_stuff:cisco:ise1.png?400|}}
Note that Cisco ISE (Identity Services Engine) __**is**__ a RADIUS/TACACS+ Server + policy engine
\\
  * [[https://www.youtube.com/watch?v=ANbCfegrq9Y]]
  * [[http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/anyconnectadmin30/ac05hostscanposture.html]]
\\
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 [[https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/12433-32.html|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. 

{{:network_stuff:cisco:ise-pan-failover.png?400|}}
----

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 ===

{{:network_stuff:cisco:8021x-wired.png?700|}}

  * 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

Commands: 
  show vlans
  show authentication sessions
  show dot1x all summary

=== wireless ===

{{:network_stuff:cisco:8021x-wireless.png?700|}}


  * 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 segmentation 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 normal also attributes 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