10-09-2019 03:19 PM
10-15-2019 10:15 AM
Thanks Mig.
Let me know how you get on. Interested in the results. Probably need to do some further testing myself.
Look forward to catching up then.
Cheers.
10-15-2019 10:12 AM
Martin,
Access Control doesn’t rely on the hostname.
It will at least check teh mac-address and finger printing to ensure it is the same device.
picking up the hostname will not give access to the network.
Mig
PS:I still need to test the solution proposed before.
10-15-2019 09:18 AM
Hi Bill,
Thanks for responding.
The forum is great, but sometimes its useful just to have someone else to call and bounce ideas off. Be useful to build a community of like minded people just to chat some times - so open for a call anytime.
So, I could be wrong here, and perfectly happy to be wrong as simply just want to get the right answers, feel free to shoot me down 🙂
I am also completley splitting hairs here, and get what you are saying and know that would indeed work, but you can still get my laptop on that network because its not machine AND user auth.
The first step if configured properly would do machine NTLM based authentication, perfect, only a corporate machine will get on. When logging in as a user though you are still just doing user authentication and then simply doing hostname (lookup) authorisation based on the rule you’ve created.
So, an example might be an emplyee who has a corporate machine and also thereby has a AD account. They decide to bring in their laptop and connect it to the corporate network. They simply change the hostame of the laptop to match their current machine. When they connect it will fail machine authentication, BUT they will presented with the username and password buble for PEAP based authentication of which they will enter their AD credentials. The laptop will then get on the network because the user passed authenticaiton and the hostname passed authorisation because it simply just matches the name based on the end-system configuration, because the hostname is doing authorisation not authentication of the machine. Think I could do the same with my IPhone connecting to wireless, just change the phones name to match a matching hostname that exists in AD of that group, put in my username and password and I’m in.
Again, that is a little over the top but my point is that either using certificates or doing machine AND user authentication is the only way to overcome the porblem of allowing only corporate machines on the network when using some kind of user authenticaton.
Well kind of hoping not, and hopeing someine will put straight on my theory and there is a way around it.
Cheers,
10-15-2019 01:58 AM
Martin,
you can set the the rule to filter on the end-system as well as the user group, and use AD to match both conditions.
The first rule would allow the machine to authenticate via 802.1x PEAP using it’s AD machine user account, this would allow the machine to get onto the network - as mentioned previously.
Once the end-user logs on, then authentication is triggered again, and the matching rule can be set to match that user’s AD OU/Group/etc. and the machine’s AD group as well before allowing access to the network.
We have set this up for our end-customers and it does work as explained.
If a user attempts to gain access with a non-domain device, it fails due to not matching the end-system portion of the rule.
This may be something better explained/shown offline on a call/remote session...
10-13-2019 09:11 PM