10-05-2017 06:25 AM
Is the ISE appliance capable of displaying a list of engagements to the authenticating user? This will allow the user to select the engagement their trying to log in to. The list can be determined by group membership.
Customer has a project to enable local firewall break out in remote offices. 802.1X will be enabled for access control. Device certificate and machine certificate will be used for authentication/authorization. TrustSec is an option and may be enabled end to end (including in local firewall).
Each team needs to be in their dedicated VLAN and go out to specific client VPN gateway IP only, with no access internally except to common services. Each engagement has a different destination IP and they want to use their primary laptop instead of a dedicated engagement laptop. They are looking at using a different AD account/user certificate to identify the user and put them in dedicated VLAN. But the AD team does not want to create user AD account per engagement. They want to see if ISE can be configured to have a menu to select an engagement and trigger an authorization rule to put them in the correct vlan.
Solved! Go to Solution.
10-05-2017 06:28 AM
Ken there is no menu in ISE they would need to create one using an API that would have these controls.
10-05-2017 06:28 AM
Ken there is no menu in ISE they would need to create one using an API that would have these controls.
10-05-2017 06:36 AM
Jason,
Is this possible with the current API calls that we have integrated? Or are we missing something?
Regards,
Ken Kaminski
TECHNICAL SOLUTIONS ARCHITECT.SALES
kkaminsk@cisco.com<mailto:kkaminsk@cisco.com>
Tel: +1 408 895 2321
Cisco Systems, Inc.
500 Beaver Brook Road
BOXBOROUGH
01719
United States
cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html> for Company Registration Information.
10-05-2017 06:40 AM
Ken it might be possible but would have to be something researched more in detail
With API calls since 2.2 you should be able to put endpoints into groups and do COA, that I would think is enough but again customer would have to write their own portal to manage, lookup IP to MAC in ISE database, capture ISE session details, etc
10-05-2017 08:54 AM
Ken,
As Jason mentioned, customer can do this with the APIs if they are capable. If they are not someone who wants to use the APIs (which is not uncommon), there may be some creative ways to deal with this, depending on flexibility available to your user at time of auth.
Here's a non-API example that would work if your user had the ability to pick their username during authentication, even with only one AD account per user:
Since you mention that the accounts are in AD, you could leverage the Identity Rewrite function of ISE for AD and train the users to put some environment/engagement details in their logon (similar to how some MFA solutions work where you can embed tokencode at the end or beginning of a string). Here's a quick example of parsing an environment identifier such as ENV1- using "[ENVIRONMENT]-[IDENTITY[]"
This rewrite only happens just before sending the credentials to AD, so you still have the username in RADIUS request as the real raw request. Then you can put some AuthZ policies in place to give different access as a result of that parsing:
The identity rewrite happens before sending to AD so authentication is successful against AD, but you can differentiate access. Here was a test logon with ENV1-TESTER account, parsed out the TESTER to send to AD and then used the ENV1 to give the right AuthZ profile. (obviously the AuthZ rules would be more restrictive than this but just for simplicity to explain)
Again, may not be applicable in your case if user doesn't have that ability to update their username at time of authentication, and it may not be the most user friendly - but it's a different use of a built-in functionality than originally intended. Often times we can find creative ways with ISE to solve problems when we can't have customers update their internal processes/systems or if APIs are not an option for one reason or another.
Don't know if this will be acceptable, but it does work.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide