cancel
Showing results for 
Search instead for 
Did you mean: 

UAC - Odd Host Checker behaviour

SOLVED
papageno_
Contributor

UAC - Odd Host Checker behaviour

A customer has UAC controlling 802.1x access.  I am seeing odd behaviour regarding host checking (HC) for different types of endpoints - can anyone tell me if it is normal?

 

There is one realm which has a number of roles within it.  Some of the roles require HC, some do not, so HC evaluationis enabled at realm level.  The roles that require HC all have the same HC policy, which only has restrictions for Windows devices configured.  All other device types have no HC restrictions.

 

  1. A Windows device with an HC-capable supplicant (Odyssey) can authenticate to any role, depending on HC outcome.  This is what I expect.
  2. A Windows device with the native 802.1x stack can not authenticate to a role requiring HC restrictions - which is what I expect - but it can authenticate to a role that has no HC restrictions for Windows devices.
  3. An Apple device running the native 802.1x stack can not authenticate to a role with HC restrictions defined (even though the restrictions are for Windows devices only).  The UAC logs "Host Checking is not possible with this protocol"

The strange thing, to me, is the difference between outcomes 2 and 3. Both are using protocols that cannot provide HC, so how is it that a Windows device can get into a role inside the realm that has no HC restrictions for Windows devices, but an Apple device can't get into a role that has no HC restrictions for Apple devices?  Is there some information passing inside the 802.1x that allows the UAC to differentiate on the client OS that accounts for this?

 

Is this normal, or should I be going to JTAC with it?

1 ACCEPTED SOLUTION

Accepted Solutions
papageno_
Contributor

Re: UAC - Odd Host Checker behaviour

Hi all

 

I believe I have resolved the issue now.  The key lies in the UAC Admin Guide where it says:

 

You must explicitly create policies for each operating system you

want to allow. For example, if you create a Windows Host Checker policy.

But you do not create one for Macintosh or Linux, users who sign into the

IC Series device from a Macintosh or Linux machine do not comply with

the Host Checker policy and therefore will not be able to access the realm,

role, or resource on which you enforce Host Checker.

 

I therefore added a policy for Mac devices into the Host Checker policy that is applied to Windows devices, even though the roles I want to assign to the Macs do not have any Host Checker requirements for them.  The Macs are now being admitted to these roles, even though the cannot communicate Host Checker status.

View solution in original post

2 REPLIES 2
kalagesan_
Super Contributor

Re: UAC - Odd Host Checker behaviour

Hi,

 

What is the UAC version that you are testing with ? ,  I understand that HC policy is defined only for windows OS .

 

Can you test with IC 4.2 R4  version ?

 

For the issue 2.

 

2. A Windows device with the native 802.1x stack can not authenticate to a role requiring HC restrictions - which is what I expect - but it can authenticate to a role that has no HC restrictions for Windows devices.

 

Answer: We need to check the rolemapping rule , how is it configured and we should see corresponding policy trace and user access log by replicating the issue to see what is causing the issue.

 

3.An Apple device running the native 802.1x stack can not authenticate to a role with HC restrictions defined (even though the restrictions are for Windows devices only).  The UAC logs "Host Checking is not possible with this protocol"

 

Answer: Can you test the behavior  by installing OAC (MAC edition), I would recommend you to work with JTAC on this with the logs collected since it looks like an issue.

 

Regards,

Kannan

 

 

 

 

 

 

papageno_
Contributor

Re: UAC - Odd Host Checker behaviour

Hi all

 

I believe I have resolved the issue now.  The key lies in the UAC Admin Guide where it says:

 

You must explicitly create policies for each operating system you

want to allow. For example, if you create a Windows Host Checker policy.

But you do not create one for Macintosh or Linux, users who sign into the

IC Series device from a Macintosh or Linux machine do not comply with

the Host Checker policy and therefore will not be able to access the realm,

role, or resource on which you enforce Host Checker.

 

I therefore added a policy for Mac devices into the Host Checker policy that is applied to Windows devices, even though the roles I want to assign to the Macs do not have any Host Checker requirements for them.  The Macs are now being admitted to these roles, even though the cannot communicate Host Checker status.

View solution in original post