Machine authentication with Windows 7

[Mika J]

Version: ISE 1.2p12

Hello,

I'm doing user and machine authentication with ISE.

I use a first authorization rule to authenticate the machine against the AD. If it's part computers of the domain.

Then I use an authorization rule to check if the user's group in AD with the credential he used to open the session + "Network Access:WasMachineAuthenticated = True"

Things seems to be working and I see my switch port is "Authz Success" but shortly after the Windows 7 machine is behaving like 802.1X authentication fails. The little computer on the bottom right has a cross on it.

If I disable and enable again the network card of that windows machine it works.

Does any one of you have an idea about this problem ? something to tweak on Windows 7 like timers...

Thank you

[Massimo Baschieri]

Maybe your host needs some hotfixes, below you can find an article that lists some:

http://robert.penz.name/555/list-of-ieee-802-1x-hotfixes-for-windows-7/

[Mika J]

Buongiorno Massimo,

Thank you for your answer. It's really helpful, I didn't know where to start that troubleshooting.

I'm surprised by the number of hotfixes in Windows 7 SP1. I would have expected that 802.1X was quite mature on that platform.
 

[nspasov]

Hi Mika, the "Network Access:WasMachineAuthenticated = True" is not the same as AD Machine Authentication. Instead that attribute is used for what is called MAR (Machine Access Restriction). You can read more about here:

http://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/116516-problemsolution-technology-00.html

I personally do not like and do not recommend MAR due to its many limitations. 

If you want to perform pure AD Machine Authentication (For Example via PEAP), then the only two rules you should have in ISE are:

1. External Group = The AD group that you want to check (Typically this is domain_computers)

2. Machine Access Restricted = False (This checks if the machine account is disabled in AD...similarly to how a user account can be disabled)

I hope this helps!

Thank you for rating helpful posts! 

[Massimo Baschieri]

At what extent using "Machine Access Restricted = False" insted of "Network Access:WasMachineAuthenticated = True" helps?

Aren't both related to the same machine authentication that happen only at boot time? 

[nspasov]

Hi Massimo, the "Machine Access Restricted = False" is checking if the AD account (User or Computer) is disabled. The result is "false" meaning "it is not disabled." That way if you have a user or machine that was fired, you can right click on that account in AD and disable it. As a result, the user or machine will not match the condition. 

On the other hand, "WasMachineAuthenticated" is referring to MAR or the machine authentication that happens during boot time. Btw, it also happens if you disable and re-enable your NIC and if a user logs out and logs back in to the machine. 

I hope this clarifies things!

Ciao

Thank you for rating helpful posts! 

[Massimo Baschieri]

Sure, but in order to know if the computer account is disabled ise needs to know which computer account to check against AD database, that information could only be provided by the pc itself, and the way the pc communicate to ise it's own computer account, as far as I know, is only one, which is the origin of the issues.

[nspasov]

So I re-read my original answer I my statement of ""Network Access:WasMachineAuthenticated = True" is not the same as AD Machine Authentication" is a bit misleading and perhaps incorrect. MAR uses the information collected during the machine authentication process (More specifically the "Calling-Station-ID" attribute). Inside that attribute is the MAC address of the wired or wireless adapter. That mac address is stored in a cache on the Radius server to be referenced in the future. This process/feature was often used to combine user+computer authentication since the native windows supplicants are unable to do that. However, there are many issues with the MAR cache and one of those is its timer. Once the MAR timer expires the cache for that MAC address is purged, which will consequently cause authentication failures until that cache is re-built. With all of that being said, what I was trying to say is that PEAP-Machine Authentication is not the same as MAR (WasMachineAuthenticated=True). PEAP-Machine authentication will actually use the AD object of that computer vs MAR will only use the cached MAC address. 

Also, the actual attribute that I was referring to is "IdentityAccessRestricted" and NOT "Machine Access Restricted" --sorry about that. Nonetheless, that information is not at all related to the MAR cache explained above. 

With all of that being said, what I was suggesting to use is PEAP-Machine authentication instead of MAR. That way users and administrators won't have to worry about all of the MAR restrictions and shortcomings. 

Thank you for rating helpful posts!

[Massimo Baschieri]

Hi Neno,

correct me if I'm wrong:

1 - ise checks for "Calling-Station-ID" (mac address) and "username" during machine authentication in order to create cache entries for MAR.

2- machine authentication happens for  windows hosts only at boot time or after a logout/login process, not after sleep/block/hibernation/etc...

3 - if an authorization policy refers to machine id attribute (not necessarily "WasMachineAuthenticated") it checks for an entry in the MAR cache, this way it can surrogate the absense of a live machine authentication looking at the machine id linked to the mac address of the host in the cache.

3 - Machine id from mar cache is checked against AD database and if there is a match policy is satisfied.

Now, am I correct if I say that you can use any authorization attribute you like, but if want to check if a host is a valid domain host you need to compulsorily rely on mar cache, with all of it's lacks?

[Mika J]

Hello,

First thank you for your participation in this question.

I've read a couple of times all the answers but I'm not sure I get it all.

The goal is of course to make sure a legitimate user uses a legitimate device without using Anyconnect (EAP chaining)

a) You told me that MAR ("Network Access:WasMachineAuthenticated = True") has some drawbacks. When hibernation is used it can cause problems since the MAC address could have been removed from the cache when the user un-hibernate its computer. Then why not increasing the MAR cache to a value of 7 days then ? Regarding the roaming between wire and wireless it's a problem indeed.

b) You suggest to use one authorization rule for the device which should be part of the AD and one authorization rule for the user with the extra result "IdentityAccessRestricted = False". By the was, are we really talking about authorization rules here ? I will try this but it's difficult for me to imagine how it would really work.

z) One question I was asking myself for a long time. All of us want to do machine+user authentication but Windows write Machine OR User Authentication. This "OR" is very confusing.

Thank you

[Massimo Baschieri]

Hi Mika,

this discussion is getting very interesting.

About your point a):

in my understanding you are completely right, you can get rid of the "hibernation" issue increasing the cache timeout and/or educating lazy users to logoff more frequently, the roaming wired/wireless issue it's still there and in some cases can have impact on business, but since most applications needs to be restarted when you change ip address to hosts, maybe a logout/login cicle in this cases it's not so destructive.

b):

I personally use an authoritazion rule for the device, a second authorization rule for user with extra result "Network Access:WasMachineAuthenticated = True" and a third authorization rule for user with extra result "Network Access:WasMachineAuthenticated = False", this way I can catch all the cases and threat them accordingly.

Never tried the "IdentityAccessRestricted = False" suggested by Neno, perhaps it has the advantage to catch a disabled host account before a logoff/login cicle or a mar cache timout?

z)

Yes it's a bit misleading, in fact windows clients does both, but with different logic, machine only at login, user more often.

Maybe the OR refers to the server logic, you are in either if you match the machine or the user authentication.  

[nspasov]

Hi Mika. My comments below:

a) You told me that MAR ("Network Access:WasMachineAuthenticated = True") has some drawbacks. When hibernation is used it can cause problems since the MAC address could have been removed from the cache when the user un-hibernate its computer. Then why not increasing the MAR cache to a value of 7 days then ? Regarding the roaming between wire and wireless it's a problem indeed.

NS: I don't believe that the MAR cache would be affected by a machine hibernating or going to sleep. There are some dot1x related bug fixes that Massimo outlined in his first pos that you should look into. But yes, you can increase the MAR timer to a value that fits your environent

b) You suggest to use one authorization rule for the device which should be part of the AD and one authorization rule for the user with the extra result "IdentityAccessRestricted = False". By the was, are we really talking about authorization rules here ? I will try this but it's difficult for me to imagine how it would really work.

NS: Perhaps there is some confusion here but let me try to explain this again. The "IdentityAccessRestricted" is a check that can be done against a machine or a user account in AD. It is an optional attribute and you don't have to have it. I use it so I can prevent terminated users from gaining access to the network by simply disabling their AD account. Again, that account can be either for a "user" or for a "machine"

z) One question I was asking myself for a long time. All of us want to do machine+user authentication but Windows write Machine OR User Authentication. This "OR" is very confusing.

NS: At the moment, the only way you can accomplish a true machine+user authentication is to use the Cisco AnyConnect supplicant. The process is also known as "EAP-Chaining" and/or "EAP-TEAP." In fact there is an official RFC (RFC 7170 - See link below). Now the question is when and if Microsoft, Apple, Linux, etc will start supporting it:

https://tools.ietf.org/html/rfc7170�

Thank you for rating helpful posts!

[nspasov]

1 - ise checks for "Calling-Station-ID" (mac address) and "username" during machine authentication in order to create cache entries for MAR.

NS: I guess I am not 100% sure of what the mechanics are behind the scene but a machine must first successfully authenticate (Weather that is PEAP or EAP-TLS) before a MAR cache entry is created for that machine

2- machine authentication happens for  windows hosts only at boot time or after a logout/login process, not after sleep/block/hibernation/etc...

NS: Yes, I believe that is correct. However, I also think that the supplicant can be configured to "save/cache" its credentials so they are used again if challenged by a Radius server

3 - if an authorization policy refers to machine id attribute (not necessarily "WasMachineAuthenticated") it checks for an entry in the MAR cache, this way it can surrogate the absense of a live machine authentication looking at the machine id linked to the mac address of the host in the cache.s

NS: Can you give me a more specific example? I am not sure what you mean by "machine id attribute"

3 - Machine id from mar cache is checked against AD database and if there is a match policy is satisfied.

NS: The MAR cache entry for an authenticated machine is simply that machine's MAC address. The MAR cache itself is local to ISE and it is not shared with anyone...not even a secondary ISE node. Thus, no information from the MAR cache is checked against AD. 

Now, am I correct if I say that you can use any authorization attribute you like, but if want to check if a host is a valid domain host you need to compulsorily rely on mar cache, with all of it's lacks?

NS: No, you can perform machine authentication (PEAP, EAP-TLS, etc) without the need of the MAR cache

Thank you for rating helpful posts!

[Massimo Baschieri]

Hi neno,

Maybe I've not made myself clear, my english is not so good, but maybe I've missed something.

Also, sorry if I did appear a little assumptive, it's not my nature.

My point is simply that if you want to check for a machine to be a valid AD host you need to rely on 802.1x machine auth at login, as far as I know is the only way for ise to have knowledge of that detail.

So forth, if you want to do it after a pc resume/unlock/etc you need to rely on mar cache, since windows hosts doesn't provide that information at those stages.

With those (maybe wrong) assumptions in mind, i've not understood why using a different attribute helps, all in all the origin of the issue is from the windows clients behaviour. 

[nspasov]

Hi Massimo. No worries, your English is just fine :) And yes, this thread is getting way to long. By the time I write up one reply there are three new pots :) Anyways, my comments below:

My point is simply that if you want to check for a machine to be a valid AD host you need to rely on 802.1x machine auth at login, as far as I know is the only way for ise to have knowledge of that detail.

NS: Again, I am by no means an expert on AD and/or the mechanics behind the authentication but I believe that:

1. The supplicant can be configured to "save/cache" its machine credentials and present those as well during re-authentication, that way a machine won't have to reboot if another PEAP-Machine authentication takes place

2. ISE can query the AD during an authentication session and can obtain the account status of that machine (IdentityAccessRestricted) and can also find out what AD groups that machine belongs to. My understanding is that both of the above can be collected by ISE at any time and not only during the boot process of the machine. 

So forth, if you want to do it after a pc resume/unlock/etc you need to rely on mar cache, since windows hosts doesn't provide that information at those stages.

NS: Similar to above. I don't believe that is true. I think if you configure the supplicant to perform "only machine authentication" then you don't need the MAR cache. Now, if you configure the supplicant to perform (Machine or User Authentication) then you would be correct because with that configuration:

1. Machine authentication takes place during boot

2. User authentication takes place at the login screen

3. Subsequent re-authentications are going to be user based - Again, the supplicant here can be configured in a way so the credentials are saved/cached so the user won't have to re-type them

Thank you for rating helpful posts!