Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ISE, Windows 7, Machine AuthZ

I'm running into an issue that has me dead in the water on the completion of a roll out of ISE for Wireless.  The enterprise has two SSIDs, one internal, and one open, which is essentially an internet-only conduit.  No internal resources (other than DHCP and DNS) are available.  We moved this from a legacy SSID to using ISE several months ago. Very simple, no BYOD, no device registration, just Sponsor Portal for external laptops, and AD user authentication for employees smartphones.  Work Great.

The second task was to take a legacy internal SSID and convert it to ISE 1.2.  My thoughts on how to do this, as based upon previous experience, the SISE courseware, the "Cisco ISE BYOD and Secure Unified Access" text (which I recommend), and that of a couple of consultants, was to use 802.1X to enforce machine and user authentication.  Seems pretty straight forward.

Of course, I need to implement this in such a way that it is completely transparent to the users.  The legacy SSID is controlled via AD Group Policy, so it seemed a simple matter of modifying GP such that the new SSID kicks in at a higher priority.  Users will see both, AD will suggest the new one, and life goes on.

That's exactly how it is supposed to work, and as far as I can tell, for any/all cold starting laptops, that exactly what happens.

See coldstart.png.

Until some user decides to close his or her laptop and sleep/hibernation sets in.

In an overnight situation, upon waking up, the laptop proceeds to perform a user authZ but no machine AuthZ.  Because there is no machine authZ, the machine fails to get internal access, which is a problem.  In the log I see this step:

24423  ISE has not been able to confirm previous successful machine authentication for user in Active Directory

In talking with TAC, they are pushing me to use NAM as the supplicant, as opposed to the Native Windows 7 supplicant.  While I have AnyConnect installed on every laptop, I don't at present have NAM configured, and that breaks my "completely transparent to users" directive.

I'm also working with Microsoft, and while they've yet to confirm that Windows 7 is just too stupid to understand the situation the laptop is in, I suspect them to tell me this soon, as we're running out of things to try on the client.

I am aware of the Reauthentication timer that exists under the appropriate Authe\orization Profile, and that number seems to max out at ~18 hours (16 bit).

At present, the I've set the Reauth timer in the policy results at 1800 seconds.  I could probably set it to be a longer time, but weekends will mess up that as a good solution.

Regarding Authentication, my Default Network Policy in ISE, I'm allowing PEAP and EAP-FAST.  PEAP is preferred.  PACs are being utilized.  See Defaultaccess.png, Defaultaccess2.png

 

So, I can't believe I'm the only person having this issue.  Telling users to not suspend their machines is not an option.  So, I have to ask...  Anybody else been able to use 802.1X, ISE, Windows 7 such that it works with sleep/hibernate?

 

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

You are not the only one.

You are not the only one. Performing true machine and user authentication (EAP-TEAP) is currently not supported by any native supplicants out there. If you notice, the Windows 7 supplicant settings allow you to define "user, machine, or user or machine" but not "Machine and User" This is the reason Cisco was pushing you the NAM client. You can check the Cisco deployment guide for EAP-TEAP (aka EAP-Chaining here):

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/howto_80_eapchaining_deployment.pdf

In addition, a draft RFC for TEAP was already posted:

http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01

Just tell your MS and Apple reps about it and demand for it to be supported in future releases and patches. :)

 

I don't know enough about your environment but I am suspecting that you are using MAR (Machine access restriction). If you are using MAR, there is a timer, that is set under the "AD" integration tab. Once that timer expires ISE removes the machine's mac address from the database, thus preventing the machine to come on the network until it performs another machine authentication. Unfortunately, that type of machine authentication only happens during a reboot or during a log off/log in. There are other limitations associated with MAR (see link below) and I personally don't like nor recommend it:

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

With all of that being said I see the following options for you:

1. Bump the MAR timer to 168 hrs (1 week) and instruct users that they have to reboot their machines first thing on Mondays.

2. Set the Windows supplicants to only perform PEAP machine authentications. This is different than MAR as the actual AD machine credentials are used. You won't be able to perform user auth but at least you will only be allowing corp assets on the network. 

3. Implement the Cisco NAM client and perform EAP-TEAP

Hope this helps!

 

Thank you for rating helpful posts!

Thank you for rating helpful posts!
13 REPLIES
Cisco Employee

You are not the only one.

You are not the only one. Performing true machine and user authentication (EAP-TEAP) is currently not supported by any native supplicants out there. If you notice, the Windows 7 supplicant settings allow you to define "user, machine, or user or machine" but not "Machine and User" This is the reason Cisco was pushing you the NAM client. You can check the Cisco deployment guide for EAP-TEAP (aka EAP-Chaining here):

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/howto_80_eapchaining_deployment.pdf

In addition, a draft RFC for TEAP was already posted:

http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01

Just tell your MS and Apple reps about it and demand for it to be supported in future releases and patches. :)

 

I don't know enough about your environment but I am suspecting that you are using MAR (Machine access restriction). If you are using MAR, there is a timer, that is set under the "AD" integration tab. Once that timer expires ISE removes the machine's mac address from the database, thus preventing the machine to come on the network until it performs another machine authentication. Unfortunately, that type of machine authentication only happens during a reboot or during a log off/log in. There are other limitations associated with MAR (see link below) and I personally don't like nor recommend it:

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

With all of that being said I see the following options for you:

1. Bump the MAR timer to 168 hrs (1 week) and instruct users that they have to reboot their machines first thing on Mondays.

2. Set the Windows supplicants to only perform PEAP machine authentications. This is different than MAR as the actual AD machine credentials are used. You won't be able to perform user auth but at least you will only be allowing corp assets on the network. 

3. Implement the Cisco NAM client and perform EAP-TEAP

Hope this helps!

 

Thank you for rating helpful posts!

Thank you for rating helpful posts!
New Member

Exactly what I'm looking for!

Exactly what I'm looking for! +1 *10^6!!!

Option 1 seems a bit problematic, as those ocassional user reboots will be annoying and look like things are not reliable.  I'm not sure where the "MAR timer" is.  The one timer I am aware of, called the Reauthentication Timer under Policy Results --> Authorization Profiles seems to max out at 65335 seconds, which is about 18 hours.

I'm playing with Option 2 now, and that will probably be the way I go.  I'll assume that if only "Computer Authentication" is selected in the Windows Security Wireless settings, that when the machine wakes up, thatis the credential that will be sent, as that's the only one Windows has to work with.  User Authentication is still necessary to get onto the PC so it's not a complete failure of concept.

Option 3 is possible, and we have AnyConnect and its Web Security module rolled out to users.  As I've never used NAM, I'm hesitant, as the transition is supposed to be transparent to the users, and I've never used NAM to know how intrusive it is to install, configure, use, etc.  In taking a look at the TrustSec paper, I have the following question:

My users are familiar with the AnyConnect User Interface, in that it is installed on every laptop, and presumably some of them need it to access anything via VPN.  However, when they are on site, they do not utilize the interface. Web Security is enabled, but they never see the UI unless they go to the System Tray.  Additionally, we're not currently ising ISE to manage wired access.  It appears that once NAM is installed, the user MUST use the AnyConnect User Interface when connected via WiFi.  Is this a true statement?  If so, presumably, if we were to use ISE for wired access, they''d need to use it there too.

Lastly, if we were to use NAM, I'd need to be able to install and configure it via SCCM or some other automated means.  Users do not have admin rights, and cannot install software themselves. I'm thinking everybody's profile would be similar, if not identical.

I'll leave my Apple Macintosh concerns for another day.

 

Cisco Employee

Glad I was able to help :)

Glad I was able to help :) Now to answer your questions:

#1 - The MAR timer is located under Administration->Identity Management->External Identity Sources->Active Directory->Advanced Settings. There you will see an option called "Enable Machine Access Restrictions" and right below that you will find the MAR timer

 #2 - Yes, you are correct. The machine credentials will be used to authenticate on the network while user credentials will be used to log the user on the machine.

#3 - You are correct again. The Cisco NAM client will basically replace the native windows supplicant. Thus, users will have to use it for personal type connections as well. You should download and install it on your machine try the experience. 

#4 - If the users do not have local admin rights then you will have to push the software and the appropriate settings/profiles via SCCM/Config Center or something similar

#5  - I haven't tried this with Apple computers but I have heard that they can also be joined to the domain. So I suppose it could be possible that you can perform machine authentication with them as well I am just not sure. The link below sheds some light:

https://discussions.apple.com/thread/4990427

 

Thank you for rating helpful posts! 

Thank you for rating helpful posts!
New Member

OK, option 2 seems to be

OK, option 2 seems to be working for me,  I had a machine sleeping all weekend, and this morning it woke right up and I had full access!  I seem to recall a similar issue maybe 6-7 years ago in another universe, far, far away.  Results attached.  Now to share this solution with my testing team.

I played with option 3 for a bit as well, and the machine I was using already had AnyConnect VPN and Web Security, as well as DART and the Web Security Profile Editor.  I installed NAM via the standalone MSI file, and the only weird thing I saw was that the NAM Profile Editor was nowhere to be found.  I was hoping that it would show up, as I believe I need to place a valid profile on the ASA or in an SCCM bundle so it would download.  I don't expect users being allowed to edit the profile.  However, since option 2 seems to be working, I'm going to give up on this option, as it isn't transparent.

Cisco Employee

Glad to hear that option 2 is

Glad to hear that option 2 is working for you! For your second question: You will need to download the 
"Profile Editor" from cisco.com. The name of the file for the latest version is: anyconnect-profileeditor-win-3.1.05170-k9.exe

 

Thank you for rating helpful posts! 

Thank you for rating helpful posts!
New Member

Dear Neno Spasov ,I just want

Dear Neno Spasov ,

I just want to understand is that if what exact access we need to be allowed in Machin authnetication acl..?

 

Thanks 

Pranav

Cisco Employee

I am sorry Pranav but I am

I am sorry Pranav but I am not sure what exactly you are asking. Can you please elaborate?

Thank you for rating helpful posts!
New Member

Hi,

Hi, We are having ise 1.2.1 device wherein we are doing machine+user authentication. We have applied machine logon acl for machine authentication wherein we have allowed all domain access on tcp and udp port level(LDAP,DNS,kerberos etc ) ,bootp bootc. Its became almost 45 lines acl. When we do log off login that dacl gets downloaded but we didn't see any hits on acl and its taking long time to display windows home screen. If we allowed all dimains on full TCP and UDP ports then even if we didn't see hits on dacl but its taking less time to disaply window home screen. So want to understand machine acl should be on respective TCP UDP ports level or we can use all TCP UDP for all domains...?
New Member

Neno, if the devices you need

Pranav, if the devices you need the DACLs on are wireless controllers, you need to create the ACLs ON the WLCs AND refer to them by name in the ISE AuthZ Policy Results (Airespace ACL Name).  The WLCS do not actually download they are simply called by name.

If you do not have a corresponding name on the WLC, your traffic will not pass, nor will you have a log of it being dropped.

New Member

Hi , Thanks for reply.. Can

Hi ,

 

Thanks for reply.. Can you tell me what contents need to be mentioned in Machine Acl ?

What is standard way are we need to enable domain controllers on IP level or TCP/UDP port secific in machin logon acl..

Thanks 

Pranav

 

New Member

I don't know your security

I don't know your security requirements, so this becomes a difficult question to answer 100% correctly.

That being said, because the devices are using machine authentication and a user credential, your machine ACL probably doesn't need to be bullet-proof. You could test the concept by placing one rule that permits any traffic, and then filter it down further as need be.

 

New Member

Thanks CSCFitzie_2 , Thanks a

Thanks CSCFitzie_2 ,

 

Thanks a lot for your help..

 

Thanks 

Pranav

Cisco Employee

Keep in mind that lenghty

Keep in mind that lenghty dACLs can be not only a pain to manage but can also deplete TCAM resources on your switch. Take a look at the following link as an example:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/66978-tcam-cat-4500.html

 

Thank you for rating helpful post!

Thank you for rating helpful posts!
861
Views
5
Helpful
13
Replies