11

I'm looking to use my linux workstation on our company network, but i've been running into a few issues, specifically 802.1x i believe.

I'm root on my machine and a windows domain admin so i should be able to access whatever i need to for this to work. Currently my linux machine has restricted connectivity which leads me to believe it's been put into a default vlan for non 802.1x clients.

I guess my overall question is: How can i make my linux machine use 802.1x on the wired windows network ? The network is a typical windows domain and uses machine accounts as well as user ones.

This is what i know & have tried so far:

I believe i'm going to need to obtain a valid client machine certificate for the machine, the CA cert for the domain, and the private key for the client

Idea 1, grab a valid key off a windows machine / domain ca machine I ran a windows VM upon the linux machine, and joined that to the domain, thinking this would produce a valid client cert i could nab for the linux machine. - to that end i then exported the client cert and the ca cert off of the windows ca server, then converted them to PEM format, ready for network manager on linux (assuming that needs PEM not DER). - I then attempted to export the private key on the windows VM itself using certmgr, but it was marked as non exportable :-(

Idea 2 was powerbroker... - I used powerbroker open (formally likewise) to join the linux machine to the domain, getent passwd now shows all domain users. - My thinking was this would put a client cert and private key on the system somewhere (/etc/ssl/certs ?) but i can find nothing

Idea 3, ask someone who knows what they're actually doing.

I should point out that originally this linux machine had windows on it (which i p2v'd upon the linux install) so i know the network switch is setup right, and the MAC etc is accepted on the network; i'm pretty sure its just a 802.1x issue

Edit: totally forgot to mention its fedora 21 xfce spin, 64bit.

  • What supplicant are you using? Xsupplicant, wpa_supplicant or rolling your own? – Brian Feb 15 '15 at 19:11
  • its fedora 21 out the box, seems like only wpa_supplicant is installed. I'm using network manager to try and connect though (with xfce desktop). – Sirex Feb 15 '15 at 19:38
  • yea, that more or less sums up how far i've already got. Looking at the windows machines they seem to use PEAP with MSCHAP v2, so that's what i tried on the linux machines. Mostly i think i'm struggling to know where / how to obtain valid certificates, and what my username should look like ('bob' 'bob@domain.com' 'domain\bob' ? I've tried quite a few ways of getting it working but no success so far, it just re-prompts for my password again – Sirex Feb 15 '15 at 20:01
  • I did try exporting the CA cert (in 'idea 1') but i still get reprompted for password, and i'm not certain i'm even going down the right route with the PEM format. There's a 'no CA cert is required' checkbox also, but i don't know if AD would like that (i'm assuming thats just a client side decision to ditch the CA check anyhow though, right?) – Sirex Feb 15 '15 at 20:04
10
+500

Bad news, everyone! It's seems that there is an unfixed bug in Fedora 21: Wired connection with 802.1x PEAP/MSCHAPv2 not working. So while the answer below may work for other distros, Fedora 21 users are currently out of luck.


Never tried that myself, but this post seems to contain a pretty detailed walkthrough for setting up 802.1x between Linux client and Windows domain. Note the certificate request part: it should solve your problem of non exportable certificate. The software versions are pretty old (Ubuntu is 8.04 and Beyond Trust's Power Broker is still likewise), but the basic idea seems solid to me.

I've formatted abovementioned post to make it easier to read. Quoting makes code boxes to be gray on gray, so I dropped it out, sorry:


Disclaimer: This guide is written from the perspective of the Linux Ubuntu 8.04 distribution. To make this work with other Linux or Unix distributions, some changes may need to be made.

The two main things that are necessary for your Linux machine to authenticate over 802.1x is a client certificate and an account in the Windows domain. During the authentication process, the Linux client presents it's computer certificate to the switch, which in turn presents it to the RADIUS server who verifies the certificate, and verifies the computer account the certificate is assigned to in Active Directory. If the certificate and the computer account are valid, then the RADIUS server approves the authentication request sending it back to the switch, which in turn authenticates the port the Linux box is connected to.

The first thing that needs to be done is to join your Linux computer to the Windows domain. Since Linux cannot natively join a Windows domain, we must download the necessary software to allow us to do this. Likewise makes software to allow us to do just this. To install this on Ubuntu it is very simple, just follow these steps:

  1. sudo apt-get update
  2. sudo apt-get install likewise-open
  3. sudo domainjoin-cli join enter the FQDN of your domain here enter your admin account here, you may use the format user@domain.com. You should also be able to use the GUI version by going to System → Administration → Likewise.
  4. sudo update-rc.d likewise-open defaults
  5. sudo /etc/init.d/likewise-open start

If you are not running Ubuntu, you may download the software here http://www.likewisesoftware.com/products/likewise_open . You may now log out and log back in using your domain account. I believe that either format of user@domain.com and domain\user both work. I will test this later.

There are three files located on the Linux machine that must be configured correctly in order for this authentication to take place. These three files are:

  1. /etc/wpa_supplicant.conf
  2. /etc/network/interfaces
  3. /etc/openssl/openssl.cnf

First we will configure the software to allow our Linux machine to use a client certificate to authenticate to an 802.1x enabled network; wpa_supplicant will be used for this.

Follow these steps to configure your wpa_supplicant.conf file:

  1. sudo gedit /etc/wpa_supplicant.conf
  2. Paste the following into the file and save it:

    # Where is the control interface located? This is the default path:
    ctrl_interface=/var/run/wpa_supplicant
    
    # Who can use the WPA frontend? Replace "0" with a group name if you
    # want other users besides root to control it.
    # There should be no need to chance this value for a basic configuration:
    ctrl_interface_group=0
    
    # IEEE 802.1X works with EAPOL version 2, but the version is defaults 
    # to 1 because of compatibility problems with a number of wireless
    # access points. So we explicitly set it to version 2:
    eapol_version=1
    
    # When configuring WPA-Supplicant for use on a wired network, we don't need to
    # scan for wireless access points. See the wpa-supplicant documentation if you
    # are authenticating through 802.1x on a wireless network:
    ap_scan=0
    
    network={ 
        ssid="<enter any name here, it doesn't matter>" 
        key_mgmt=IEEE8021X 
        eap=TLS 
        identity="<FQDN>/computers/<Linux computer name>" 
        client_cert="/etc/ssl/certs/<your authentication certificate name>.pem" 
        private_key="/etc/ssl/private/<your private key name>.pem" 
    }
    

Now we must edit your interfaces file. Follow these steps to configure your interfaces file:

  1. sudo gedit /etc/network/interfaces
  2. Paste the following into the file under the eth0 interface and save it:

    # Configure the system to authenticate with WPA-Supplicant on interface eth0
    wpa-iface eth0
    
    # In this case we have a wired network:
    wpa-driver wired
    
    # Tell the system we want to use WPA-Supplicant with our configuration file:
    wpa-conf /etc/wpa_supplicant.conf
    

The next step is to generate and install your certificates. We will have to generate a self-signed certificate, then generate a certificate request based on the self-signed certificate we created, then install the certificates.

Note: When creating your certificates, whenever it asks for your name, you must provide the name of the computer which will be authenticating. To be safe, I recommend making the name match the way it is assigned to the computer, including being case sensitive. If you are unsure how it is assigned to your computer, open a terminal and type hostname.

Follow these steps:

  1. sudo openssl req -x509 -nodes -days enter in days how long you want the cert valid for -newkey rsa:1024 -keyout enter a name for your private key/certificate here.pem -out enter a name for your private key/certificate here.pem

    Example: sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout privcert.pem -out privcert.pem

  2. openssl req -new -newkey rsa:1024 -nodes -keyout enter a name for your private key here.pem - out enter a name for your certificate request here.pem

    Example: sudo openssl req -new -newkey rsa:1024 -nodes -keyout privkey.pem -out certreq.pem

All of the certificates created are placed in your home directory (/home/<username>). The next part is to request a certificate from your CA using the certificate request that was created in the previous step. This will need to be done on a Windows machine, since for some reason Linux and Windows don't get along too well when requesting and downloading certificates; I just found it easier to email the certificate request to myself and perform it on a Windows machine.

Follow these steps to complete the certificate request:

  1. Go to your home directory on the Linux machine and find your certificate request file
  2. Either email the file to yourself or open the file with a text editor (such as gedit) and copy and paste the request into an email and send that to yourself.
  3. On a Windows client, open a webpage using IE to your CA's website (such as http://caname/certsrv).
  4. Select Request a Certificate
  5. Advanced Certificate Request
  6. Now open your email and get the certificate request that you emailed yourself.
  7. If you emailed yourself the file, open it with notepad and copy and paste the contents into the Base-64 encoded certificate request box. If you emailed yourself the contents of the certificate request file rather than the file itself, then just copy and paste the request from there into the Base-64 encoded certificate request box.
  8. Click Submit and download the certificate in Base-64 form, not DER.
  9. Save the certificate to your desktop and name it your Linux machine name.pem. The system will automatically append the .cer to the end of it, so just delete that off. Linux uses .pem for certificate extensions.
  10. Take this file and email it back to yourself.
  11. Now, on your Linux machine, get your certificate and save it somewhere (preferably your home folder to keep things organized and together).
  12. Now, we need to copy your certificate that you just received to your /etc/ssl/certs folder, and we need to copy your private key/certificate and private key created earlier in your /etc/ssl/private folder. Now, only root has permission to do this, so you can either do this by command line by typing sudo cp /home/<username>/<certificate>.pem /etc/ssl/private or /etc/ssl/certs. This can also be done from the GUI by copying and pasting by using the command gksudo and typing in nautilus. Nautilus is the GUI file browser that Ubuntu uses and it will run this as root allowing you to copy and paste to directories that only root has access to.

Now that our certificates are in place, we need to tell openssl how we want to use the certificates. To do this, we must edit the openssl.cnf file and tell it to authenticate our Linux machine as a client rather than a user.

To do this follow these steps:

  1. sudo gedit /etc/ssl/openssl.cnf
  2. Scroll down about half way and you should see a section called [usr_cert]. In this section we need the where the nsCertType is defined as "For normal client use this is typical", and it should have nsCertType = client, email and it will be commented out. Uncomment this line and delete the email so that it shows nsCertType = client. Now save the file.

Now you should have everything you need configured properly to have a Linux machine running in a Windows domain environment and authenticating using 802.1x.

All that is left now is to restart your networking service so that Linux will use the wpa_supplicant.conf file that is now tied to your eth0 interface and authenticate. So just run sudo service networking restart. If you don't get an IP address after your interface comes back up, you can manually request an IP from your DHCP server by typing sudo dhclient.


  • i've just tried this, and i tried it when i first found that article myself. I'll try it again though word for word, just in case. – Sirex Feb 16 '15 at 1:23
  • nope, cant get this working. I'd have thought that the advenced signing request would be type 'workstation' but i only had 'user' and 'web server' available. – Sirex Feb 16 '15 at 1:39
  • Ok, so maybe we could go by another route. There is a way, alebit hacky, to export certs marked as non-exportable: github.com/iSECPartners/jailbreak or blog.gentilkiwi.com/mimikatz (stackoverflow.com/questions/3914882/…). Could you try to grab a cert from your p2v'd Windows and use it for authentication? – beatcracker Feb 16 '15 at 11:02
  • the jailbreak app let me get hold of the private key. It didn't work for me in TLS mode. PEAP mode only wants the CA cert - which i can get off the ca server /certsrv/ url, but that dosent work either. Perhaps it's not liking my 'anonymous identity', username type and password, i'm assuming it's either 'username' or 'username@domain.com', but neither works for me. I'll pastebin the message logs. – Sirex Feb 16 '15 at 19:28
  • 1
    Bad news, everyone! It's seems that it's a bug in Fedora 21: Wired connection with 802.1x PEAP/MSCHAPv2 not working. – beatcracker Feb 17 '15 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.