Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Machine authentication - Novell/Windows mixed environment

This thread has been viewed 0 times
  • 1.  Machine authentication - Novell/Windows mixed environment

    Posted Feb 13, 2012 08:56 PM

    Hello,

    I've read a few threads on the Machine Authentication topic, but rather than replying to them, I thought I'd start a new one, since our environment is different.

     

    I work for a school district.  I more-or-less "inherited" management of the wireless network from someone else, who is no longer with the district.  I haven't had much in the way of formal training, either with Aruba or Novell.  I do have an MCSE certification, though, so at least I know my Microsoft. :)  But in terms of the rest, if I sound kind of stupid, that's why.

     

    We run a mixed environment consisting of both Novell eDirectory and Microsoft Active Directory.  We run a combination of NetWare 6.5 and SLES 10 SP4 OES2 servers, as well as Windows servers.  All of our workstations are joined to an AD domain.  We have mostly Windows XP, though we have been getting a lot of Windows 7 lately.  We also have various incarnations of Mac OS X, including Lion (10.7).  Our XP and Win7 machines all have the Novell client installed.

     

    Where we *currently* stand is here:  We have a STAFF network, which is used for district-provided staff wireless devices.  We have a STUDENTS network, which currently isn't used for anything.  We also have a GUESTS network, that makes use of the Captive Portal.  The STAFF network uses WPA/WPA2 Enterprise authentication, and we have a RADIUS server set up with FreeRADIUS that authenticates against eDirectory.

     

    If a district staffmenber with a district-provided laptop wants to connect wirelessly, we connect their laptop to the STAFF network.  Since we are only using user authentication, though, the user must first log in using the "Workstation Only" option in the Novell client, and then when their desktop loads up and Windows authenticates to the wireless, they can then right-click the red N and do their Novell login.  This works, but it presents a problem whenever a user has to change their password (which we require them to do every few months).  The problem is that when they change their password on their desktop system, they generally don't then connect their laptop to the wired network and log in with the new password.  Thus, they are still logging in "Workstation Only" to the laptop using their old password, which is still cached on the machine, and then their wireless authentication fails.  I would love to be able to solve this problem using 802.1X authentication.  However, we have tried that several times using the Novell client, and the results have been disastrous.

     

    To make things more interesting, for our students, we use "Dynamic Local User" policies and "Volatile Profiles", meaning that first, when a student logs in, instead of authenticating to eDirectory *and* AD, as soon as the eDir authentication takes place, a local user account is created on-the-fly on the workstation, and then the student is authenticated to that account.  This prevents students from logging in using the "Workstation Only" option and gaining additional rights to the workstation.  Second, the "Volatile Profile" policy automatically removes the user's local profile (c:\documents and settings\<username>) upon logoff.  The problem here is that for wireless laptops (and desktops, in many cases), if we set up a STUDENTS network that uses WPA/WPA2 authentication, we cannot implement the "double-login" process, because students can't log in Workstation Only.  So, it becomes a chicken-or-the-egg situation:  The student can't log in to the Novell client without an IP address, but the workstation can't get an IP address until the student has logged in.

     

    We have gotten around this by setting up WPA-PSK or WPA2-PSK networks using hidden SSIDs.  That allows the workstation to connect to the wireless in the background, since only a password is required.  However, this kind of defeats the purpose of wireless security, since if the password were to ever leak out, it would compromise an entire school's wireless network.  Machine authentication would REALLY be helpful here as well.

     

    So, if you're still awake after reading this long diatribe, perhaps you can offer some suggestions on how to make this work better?  And please, be as basic as possible. :)  I know my way around the ArubaOS CLI fairly well, but there are a LOT of commands that I know nothing or next-to-nothing about (remember, only basic training here... most of what I know I learned by experimentation).  I'm also not an expert on 802.1X by any means, and I was pretty much lucky to get my RADIUS server up and running after the old one (which was set up before I was here) died.  I would love to implement a solution that would require as little hands-on by our site techs as possible, too, since we are short-handed due to budget cuts (isn't everyone?).

     

    If I can provide anymore info, I'll be more than happy to.  Thanks in advance!

     

    -- Bryce Newall

    Poway Unified School District

    San Diego, CA



  • 2.  RE: Machine authentication - Novell/Windows mixed environment

    Posted Feb 14, 2012 08:25 AM

    Hi Bryce,

     

    For the password cache problem, I experience similar problems with remote VPN Clients.

    Try the following procedure: After a password change, lock your screen and then unlock it using your new password. The lock-unlock will synchronize your cached credentials.

     

    Did you consider using EAP-TLS instead of using machine and user PEAP/MsCHAP authentication for your STAFF network?

    Using a very simple Microsoft based private PKI infrastructure, with automatic certificate installation and auto-renewal, you will simplify the authentication process. You will no longer be vulnerable to PEAP authentication exploits.

     

    For your STUDENTS network, did you consider using a separate CA articulated around the AmigoPod solution? The Idea is to use a PEAP authentication to access the self served private Certification Authority to get a certificate that allows connecting to the EAP-TLS SSID.

     

    You would end up using 4 SSIDs:

     

    STAFF-EAP-TLS

    STUDENTS-PEAP (to get the certificate)

    STUDENT-EAP-TLS

    GUEST

     

    Advantages of using EAP-TLS are:

    - The user name is not sent in clear like PEAP;

    - User requires to be loged in to access the certificate store and unlock the private key usage. Consequently, it is technically a dual factor mutual authentication process.

    - It is the only approved Enterprise grade authentication standard. PEAP never been ratified and it is still in draft form.

     

    Regards,

     

    Paul Gallant, Eng.

    CWNA, CWSP




  • 3.  RE: Machine authentication - Novell/Windows mixed environment

    Posted Feb 14, 2012 12:24 PM

    @paul.gallant wrote:

    Did you consider using EAP-TLS instead of using machine and user PEAP/MsCHAP authentication for your STAFF network?

    Using a very simple Microsoft based private PKI infrastructure, with automatic certificate installation and auto-renewal, you will simplify the authentication process. You will no longer be vulnerable to PEAP authentication exploits.

    Hi Paul,
    Thanks for your response!  This is where it gets into areas that I'm not familiar with.  For example, I don't know how I would set up EAP-TLS.  Some of these authentication protcols are beyond my realm of expertise.  Would this allow for a single sign-on in our Novell environment, negating the need for using the Workstation Only option?  If the password change method you described works, then that would certainly save a lot of headaches for our existing users.

    Thanks!


  • 4.  RE: Machine authentication - Novell/Windows mixed environment

    EMPLOYEE
    Posted Feb 14, 2012 06:08 PM

    Thanks for your response!  This is where it gets into areas that I'm not familiar with.  For example, I don't know how I would set up EAP-TLS.  Some of these authentication protcols are beyond my realm of expertise.  Would this allow for a single sign-on in our Novell environment, negating the need for using the Workstation Only option?  If the password change method you described works, then that would certainly save a lot of headaches for our existing users.

    Thanks!

    Bnewall,

     

    Single Sign on with Novell and 802.1x is quite a challenge.  

     

    If you want to do this absolutely free, there is a gentleman who documented this here:  http://thebackroomtech.com/2008/04/08/8021x-network-authentication-freeradius-with-the-novell-client-resources/

    The biggest drawback is that you cannot browse the tree when using wireless 802.1x  This is not for the faint of heart, by the way.

     

     

    An alternative but easier way to do this  (single sign on) but not the cheapest is the method here:  http://community.arubanetworks.com/aruba/attachments/aruba/115/5080/1/Novell+Single+Sign+on.pdf  

    It does involve installing the Funk (now Juniper) Odyssey Client on all your workstations (http://www.juniper.net/us/en/products-services/software/ipc/odyssey-access-client/oac/) 

     

     

    Alternatively, if your Novell Workstations are truly part of a  Windows domain, you can:

     

    (1) Install a Windows Enterprise CA on one of your domain controllers

    (2) Install IAS (Windows 2003) or NPS (Windows 2008) radius server on any of your domain controllers (free) to authenticate yor users

    (3) Configure Autoenrollment for Computers in your domain using group policy

    (4) Configure your WLAN controller with WPA2-AES and point it to the radius server in (2) for authentication

    (5) Use Group Policy to Push WPA2-AES with TLS (smartcard or other certificate) WLAN configuration to all your computers

     

    The end result is that your workstations (not your users) will authenticate to the radius sever via machine certificates and get an ip address at the ctrl-alt-delete screen.  That means you can browse the tree, etc.  Novell user Authentication will still have to take place, of course, just like you are wired.

     

    If your Novell Workstations are NOT part of a domain and you use Zenworks to configure your workstations, you can:

     

    (1) Get a consultant

    (2) Purchase a 3rd-party radius server like Avenda (avendasystems.com - Acquired by Aruba, yes) that can integrate with LDAP/eDirectory

    (3) Have your consultant go through the all the hassle