How to make ISE 1.4 not authenticate a workstation via MAB

[jhodges125]

I am testing an eval of ISE 1.4 so it has all modules available.  We have Polycom IP Phones so I want to use the Profiling service together with MAB to authenticate the phones.  This appears to be working correctly.  I also have ISE setup to query the Windows Active Directory via LDAP to authenticate Domain user dot1x authentications successfully with the Annyconnect dot1x supplicant.

My problem appears when I test connecting a workstation that does not have the dot1x supplicant.  I was expecting ISE to fail the authentication for the workstation.  According to the ISE logs, the workstation does fail the authentication at first, but then ISE profiles the workstation so the workstation mac is then entering into the local endpoint database.  This causes ISE to then pass the authentication for the workstation based on the default Authentication MAB rule that is configured to query the Internal Endpoints database.

Is there a way to configure the Authentication rule(s) to not allow a workstation to pass authentication via the MAB and only allow a workstation to pass authentication via dot1x?

11001	Received RADIUS Access-Request
	11017	RADIUS created a new session
	11027	Detected Host Lookup UseCase (Service-Type = Call Check (10))
	15049	Evaluating Policy Group
	15008	Evaluating Service Selection Policy
	15048	Queried PIP - Radius.Service-Type
	15048	Queried PIP - Radius.NAS-Port-Type
	15004	Matched rule - MAB
	15041	Evaluating Identity Policy
	15006	Matched Default Rule
	15013	Selected Identity Source - Internal Endpoints
	24209	Looking up Endpoint in Internal Endpoints IDStore - 68:B5:99:F7:80:DA
	24211	Found Endpoint in Internal Endpoints IDStore
	22037	Authentication Passed
	15036	Evaluating Authorization Policy
	15048	Queried PIP - EndPoints.LogicalProfile
	15048	Queried PIP - Network Access.AuthenticationStatus
	15004	Matched rule - Basic_Authenticated_Access
	15016	Selected Authorization Profile - PermitAccess
	11002	Returned RADIUS Access-Accept

Thanks,

John

[Tim Steele]

John,

The more pressing issue is the way your authorization policies are configured.  The authentication policies serve to identify the user or device, but even if that gets passed as you are showing, the authorization policies should be setup to keep unwanted behavior like this from happening.  Please post your authz policies for review when you can.

You are testing with this endpoint, so ISE does know about it - and has it entered into the endpoint database, although not in a particular group (unless you put it there already testing another use case or something).

Tim

[jhodges125]

I don't think I have messed with the default Authorization rules yet.  I can see for the logs that the workstation is reaching the Basic_Authenticated_Access rule and the PermitAccess profile.  Will I need to change this rule or add a new rule?

Thanks,

John

[Tim Steele]

Right, that authz rule allows more than what you're looking to allow.  That just says if the authc request passed in the authc phase, go ahead and authz with PermitAccess.  That's not what you are wanting. 

If you are wanting to provide any differentiated access for various authentications, you'll want to modify these policies.  The authc phase will look at the entire AD database or the entire internal endpoint and user database (depending on how your Identity Source Sequence is setup). That, in combination with the Basic_Authenticated_Access authz rule, will allow anything in those identity sources to get full access.

Just for your basic test, you might consider deleting/disabling that Basic_Authenticated_Access rule and create something like this:

Of course, you don't necessarily need to use the PEAP condition that I show above. You can also just use the PermitAccess authz profile if you don't want to provide a specific DACL or vlan along with the authorization.

Also, keep in mind that if you have "authentication order dot1x mab" configured, the switch will attempt three times to dot1X authenticate the endpoint, then failover to using MAB.  This all depends on your switchport config of course.  And, the timing of how long that failover to MAB takes depends on your switchport config.

Tim

[jhodges125]

I thought I would first try to disable the Basic_Authenticated_Access rule to see what ISE would do.  ISE did get all the way to the Default Authz rule with its DenyAccess policy.  This did not stop the workstation from accessing the network, so I tried to modify the Default rule at the bottom from DenyAccess policy to a new policy I created to download a Deny ip any any ACL to see if I could get the client blocked from accessing the network.  Now ISE appears to work how I hoped for one laptop (Thinkpad) but not for another laptop (HP) on the same switchport.  The Thinkpad hits the Default Authz rule and gets the deny ACL applied.  Show authen session details on the port shows the machine is Authorized and the ACL applied.  When the HP laptop is connected, ISE showed the port as unauthorized and the ISE logs show that laptop was not matching any authc or authz rules.  

I went into the Internal Endpoints database and found the HP mac address at the root of the Profiled folder and move the mac to the Workstation folder.  A few minutes later the ISE matched the HP laptop to authc and authz rules and applied the deny acl.  Can you tell me why this is happening?

Thanks for your help so far

[Tim Steele]

Does your switchport config include "authentication open" in the list of statements?  If so, a deny from the radius server will allow the endpoint to get on the network using the vlan you have configured on the switchport.  This is called Monitor Mode.

Are you working with a partner to help you design your ISE deployment?  It sounds like a design workshop would help you identify your use cases and give you some clear direction as to how to implement them.  That's not to say that you can't figure it out on your own, but getting the most out of your investment and getting best practices direction might save you a lot of pain and frustration as you put the deployment into production.

Tim

[jhodges125]

Yes, I do have the authentication open command on the switchport

interface GigabitEthernet1/0/4
 switchport access vlan 144
 switchport mode access
 switchport voice vlan 128
 ip access-group PRE-AUTH in
 authentication host-mode multi-domain
 authentication open
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate 7200
 authentication timer inactivity 30
 authentication violation restrict
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 10
 auto qos trust
 spanning-tree portfast
 service-policy input AutoQos-4.0-Trust-Cos-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
!

Since this just the Eval setup for ISE, we are not working with a partner at this time to go through all of the use cases.  I agree it would save me time and frustration, but I don't know if there is currently money in our budget for the design workshop consultant.  I have taken the Cisco ISE admin class, but that really just scratches the surface of what I really need to know to take this into production.  Just trying to get through the major use cases that I know I have to address first to start the production deployment.

Thanks again for you feedback and guidance

John

[Tim Steele]

No worries, John, I completely understand.  Sometimes you have to wrestle with the level of effort required to bring an initial ISE implementation into PoC in order to communicate the level of effort required to bring it to pilot and then production. :)  If you get the option to bring a consultant in just for the design (to start with) to build an HLD and LLD for you, it will likely save you money in the long run.

The command "authentication open" on the switchport is made for Monitor Mode (MM).  MM allows you to have a low-risk first step in rolling out ISE to a location.  With MM, all endpoints get network access - whether they pass authc/authz or not.  The Default policy should be DenyAccess.  When an endpoint that has the right wired supplicant config (wired supplicant turned on and the connection profile pushed - often via GPO) in place, it will authenticate with correct credentials and can be authorized correctly based on your authz policies.  But, lets say a handful of the endpoints didn't get the GPO applied for some reason - those won't be kept off the network, they'll be allowed on the network with the vlan specified in the switchport config, even though they "failed" authz in ISE.  With MM, you can look in Live Authentications to see the pass/fail report and see who passed and who didn't.  This gives you a low-risk window to get those endpoints fixed before moving to Closed Mode (locked down).  When in Closed Mode, those endpoints that failed in ISE but got on the network anyway during MM will be denied access to the network.

So, having "authentication open" in your interface config allowed the HP to have network access even though you see the failed attempt in Live Authentications.  This is by design with MM.  When the switch gets an "Access-Reject" from radius, that kicks in the "authentication open" part of your switchport config.

You'll want to setup your authz policies such that you have rules for each use case so those endpoints get the proper authz (vlan, acl, etc.), but you generally want your Default policy to be DenyAccess.  There are other schools of thought, but that is how I do it.

Also, in your switchport config, you'll want to change to "host mode multi-auth" if you chose to go with MM.  Your reauthenticate and inactivity timers can be set to "server" and configured on your authz profile in ISE.  That is not a requirement, but is an option and can be centrally controlled - and varied by use case if necessary.

You might consider also adding the following to your switchport config:

authentication event fail action next-method

authentication event server dead action authorize

authentication event server dead action authorize voice

authentication event server alive action reinitialize

This is getting a bit deeper, but the bottom three have to do with how you want the switch to behave in the event that it can't reach ISE.

I also don't typically go with the Low-Impact method where you have a port ACL.  I apply the ACL I want per use case via authz profile - it also keeps you from flipping vlans on the client if your use cases call for varying vlans.  Again, other schools of thought do exist. :)

Tim

[jhodges125]

Deleted non-related info

[Tim Steele]

John,

There are a number of strong consulting firms out there - just make sure the company is ATP certified and the engineer on your project has ISE certs too.  I don't want to advertise too much here for my company or others as that would turn this forum into something it shouldn't be.  :)

That being said, ISE is an advanced technology with a number of moving parts and lots of things to be considered.  You can expect to pay more for ISE related services than for some other technologies.  That's not to say that ISE is the MOST advanced, but it's not basic to be sure.

Tim

[jhodges125]

Deleted non-related info