Security

Currently, we are onboarding all of our wired and wireless devices.  The issue we have is users that have never been authenticated to a machine before.

 

We have a url-redirect for onboarding.  They will mac authenticate onto the network, the following is the ACL currently in place

 

deny tcp any host <clearpass server>

deny ip any host < domain controller>

permit tcp any any eq www

permit tcp any any ew 443

 

 

I see hits on the acl for the domain controller, but windows still replies that the domain controller is not available.  Any ideas?

If you need users to be able to log into the computer, you need to ALLOW traffic to the domain controllers, not block it.

 

Just curious, why are you onboarding devices that are domain-joined (in your control)?

 

It was requested from above for uniformity.  They want all devices onboarded.  We are using PEAP instead for multi-user machines.  

 

QuickConnect doesnt seem to provision PEAP very well though.  We want it to do both user and machine auth, and want it to use the windows credentials.  I am having to configure those settings after the fact.

 

 

Maybe I am not understanding how url-redirect acls work. 

 

I though anything permitted by the ACL is the traffic that gets redirected rather than passing.  Thus on mine only http and https traffic would be re-directed and other traffic would pass as normal.

QuickConnect is designed for BYOD devices. You will need to configure a separate provisioning setup for domain computers then figure out how to assign that profile to the machines. This could get very complex trying to combine user/machine auth with Onboard.

What kind of switch?

Cisco 3560 PoE 8 port running 12.2(55.3)SE8ES

Hi Sburnside1,

 

Are you able to get the Onboard Captive Portal to redirect when you plug into a switch port?

 

Thanks!

 

-Mike

Your ACL looks correct (for a Cisco switch).

 

How many domain controllers do you have? Do you have either an object group with all of your DCs or an ACE entry for each DC? 

 

Also, are your DNS and DHCP servers on the DCs? If not, you'll need to allow those as well.

After testing with one already logged in.  I realized the issue.  with port 443 redirecting as well, it prevented the login from happening.  The acl only needed to be the following:

 

deny tcp any host <clearpass ip>

permit tcp any any eq www

 

the permitting of 443 was cauing that traffic not to hit its destination.  I thinned the ACL back to the basics and it now works.

Hi sburnside1,

 

I have a similar wired redirect setup as you have described. Have you had any issues with a delay in the redirect? For instance if you open a web browser, it takes a few seconds before the redirect page comes up? 

 

Thanks,

can someone please advise me how to do redirect for both wired and wireless? thanks

It's highly dependent on the switch/controller manufacturer, model, and code version.

This bit me the other day - you also need to make sure there's an IP address on the VLAN where the user is currently connected. For instance, if you're on a Cisco switch and a user is connected to VLAN 26, make sure that VLAN 26 has an L3 interface / SVI in order to do the redirect. This same logic applies to an Aruba Switch and an Aruba Controller.

 

-Mike

For the Cisco wired side redirection, we use a profile to send the redirect down. This is done at the switch port level. It is important to note that Cisco switch has https and http services turned on. This way the switch listens on those ports, can then intercept the traffic, and redirect to the URL you've pushed down. There is much more Cisco switch configurations needed, but that is the quick answer

thanks, do you or someone have the switch template for cisco switch for the redirect?

a couple of questions..

 

1) prior to onboard, the switch port needs to be 802.1x enable right?

2) since it's 802.1x enabled, the client will need to be authentication via MSCHAPv2 before onboard can take place right?

3) will the nic card be automatically change the from peap to certificate?

1) You'll likely want the port enabled for 802.1X and MAB

2) Yes, either via EAP-PEAP or via MAC-authentication w/ captive portal fallback

3) The client is configured as part of the Onboard enrollment.

We don't use the onboard, and we already have a pki infrastructure in place with certificates deployed to windows machines. We push a GPO to configure 802.1x on the Windows laptop. However I've attached screenshots on how to manually set 802.1x using certificates on a windows Machine. Apple Mac is must simpler since 802.1x is on and it autodetects on the wired. For Mac the user is prompted.

 

Our use case has a lot to do with how we configure the switch. I'll give you a little bit on the flow to help you understand our switch configuration.

 

In our AD, we have an attribute populated with all the MAC addresses of hosts that are joined to the domain. So we use MAB first on the switch port. In clearpass, if the MAC is present in AD, then a reject is sent to the switch that then forces the switch to move from MAB to 802.1x. The host is then prompted to authenticate with 802.1x. If succesful then a port based ACL is sent down the switch. We use machine certs, so all this is transparent to the user.

 

If a device is plugged in, MAB is triggerred, and the MAC is not in AD, then Clearpass Accepts the MAB and a Captive Portal Redirect is pushed down to the switch. The user then registers/logs in via the portal and then a unique restricted Dynamic ACL is pushed down to the port.

 

We use this MAB first method because of speed. In a lot of our use cases, most of the devices won't have 802.1x and thus a certain action will be used by MAB.

 

Here you go. The port based config has many different options based on how your connection flow will work.