ISE 2.7 and AD Authentication, Who's in Control?

[dewey89]

Just finished getting ISE installed for the first time on our network and configured all of the devices.  Cisco best practices say to use AD as one of the ways for authentication, but why?

  With AD authentication to all of your devices, routers, switches ISE appliance and firewalls what prevents a AD administrator from adding his access to your FW and opening ports?

  This seems like a large insider threat vulnerability.  There should be something in ISE to approve accounts from AD.

[balaji.bandi]

I took this more of a compliance/Policy of business, audit than anything else. in your case anything possible - ( as i said in technology anything possible) 

big brother watching all-time - When things changed or added or deleted, the event generated - who changed and what changed. - this information is more than enough as evidence, this is more of a Governance and Security policy issue.

it is More of  "TRUST" we go with sometimes.

Hope this makes sense?

[dewey89]

I'm not worried about big brother.  We have three different contracts/companies providing services, one for Sys Admin, one for IA with Tenable.SC scans and the network.

  If someone wanted to an Admin could use their credentials to log into a network device if they added their account to the Network Admins and then remove it after their access.

  This is just a blind spot for me in that I wouldn't know if this happens or not and a non-network employee gained access.

  If we had an active email capability I could have alerts sent, but that's not possible, yet.  Another hope was to go into Administration> System> Admin Access> Administrators> Admin Users and assign an Active Directory User Account to one of the various Groups for ISE administration.

  This would give the ISE administrator positive control of who accesses ISE and attached Network Devices.

[Mike.Cifelli]

With AD authentication to all of your devices, routers, switches ISE appliance and firewalls what prevents a AD administrator from adding his access to your FW and opening ports?

-IMO there are other mechanisms that would need to be involved for your scenario to occur.  Other mechanisms would include members of your AD team knowing the network layout which includes IP addressing, what IP is what device, what AD group specifically is used by your network team, etc.  Most organizations have separation of duties for these types of reasons.  Depending on your environment if you dont grant a priv 15 shell via T+ then you would need to know the enable password too.  You can also implement an SSH ACL that gets applied to your VTY lines across your gear allowing only the network team range.  Anyways, I think someone on the inside would need a lot more information besides just adding his AD account to the network-infrastrucure group.

  This seems like a large insider threat vulnerability.  There should be something in ISE to approve accounts from AD.

-All mapped groups have to be managed, selected, approved in ISE before you can reference them inside your radius/tacacs+ policies.

 Cisco best practices say to use AD as one of the ways for authentication, but why?

-IMO to keep it short & sweet, ease of use.

Good luck & HTH!

[Marcelo Morais]

Hi @dewey89 ,

 please take a look at the following link, it's a good starting point: Cisco ISE Secure Wired Access Prescriptive Deployment Guide.

Hope this helps !!!

[Arne Bier]

Hi @dewey89 

You could isolate ISE from the AD by not integrating directly to the AD at all. Instead, speak to your AD team and ask them to deploy an IAM (Identity Access Management) solution for you. This would entail something like an LDAP server that sync's part of the AD Domain into an LDAP directory - then integrate ISE with that LDAP directory. It's probably more efficient too. Microsoft and others have LDAP solutions for this.

[thomas · Accepted solution]

We recommend AD because 95+% of our customers use it for their general user management - network admins included - and generally people hate having multiple passwords so why not re-use your existing corporate Identity Management system?

You may absolutely use separate admin users and groups locally within ISE with password policies and expirations and all that. Your choice. Identify your greatest risks and work to minimize the threat!

I assume you are talking about Device Admin (TACACS+) since you talk about changing network devices. The whole point of TACACS+ is to have auditing trail of Who did What, When, and Where whether they are the rogue AD Admin Insider Threat or just the Newbie NetAdmin mistakenly doing things he probably shouldn't or countless other scenarios.

And hopefully you also have other security services to detect anomalous traffic flows on previously unused ports for exfiltration or whatever your concern is since ISE can't do this.