none
WinPE 802.1x TLS authentication during zero touch?

    Question

  • I have downloaded, extracted, and installed the Hotfix KB972831 that is intended to provide IEEE 802.1X authentication protocol support in the Windows Preinstall Environment (PE) 3.0.   I have a certificate available with exported private key in .PFX format that can be used for client authentication to the port.  

    What are the procedures to import / inject a client certificate into the WindowsPE image and configure it to authenticate via EAP-TLS during an OS-Replacement or PXE-based zero-touch boot scenario with SCCM 2007 SP2 OSD?   (This is not a media-based boot session!)

    My initial thoughts after adding the KB972831 package are to while wim image is mounted via DISM:

    1. Copy the PFX certificate export file to the WinPE image

    2. Copy the %systemroot%\systemroot\certutil.exe and %systemroot%\systemroot\en-US\certutil.exe.mui files from a Windows 7 system to the %WinPEsystemroot%\system32 folder 

    3.  Somehow via script in WinPE run the command 'certutil -importPFX <PFXFilepath> -p <Password>'
      ( How to best do this?  I haven't found clear documentation for script and command execution order for WinPE yet  - especially when it need only be done once)

    4. Copy my Wired Autoconfig LAN Profile.XML file to the WinPE image

    5. Somehow after the network card is bound, running commands via script:
        net start dot3svc
        netsh lan set autoconfig enabled=yes interface=L*
        netsh lan add profile Profile.XML
        netsh lan reconnect interface=L*

    So the biggest question is how to get these script to run properly at the right time.


    Thanks.

    Thursday, January 14, 2010 10:09 AM

Answers

  • Okay - figured it out. The instructions we have all been brooding over and which Nick Lowe has succinctly descripted are only part of the solution and only work when you boot directly to the media. If you initiate the task sequence from the SMS client, or have to reboot into 64bit PXE, the normal boot sequence does not take place and tsbootshell is bypassed. It launches straight into the requested task sequence.

    Since all my PCs boot to the 32bit boot image, all my 64bit deployments were failing. To combat this I added the 802.1x configuration script to the start of the task sequence without conditions. In the 32bit image I did the same script in place but put a condition on it _SMSTSLaunchMode = SMS, so that the script is skipped when booted straight from media.


    Anthony Sheehy - MCP, MCITP
    Friday, April 16, 2010 11:41 AM

All replies

  • Hi There,

    I've just spent the past few days working on the same thing, only we used user authentication not certificate authentication. I'm not sure if this is something that you want to do or not, Also, we were using WinPE from the WAIK not SCCM, so may make a difference.

    Cheers
    Friday, January 15, 2010 12:05 AM
  • Hi,

       I've found a way to inject a client certificate into the winpe and get it to send the TLS authentication in proper order...

       Current stumbling block is how to get it to work with the network RADIUS service (CISCO ACS).   In my case the certificate is issued by the domain-integrated CA, with private key, in PFX format to a CN = CommonName, DC = Domain, DC = Domain (FQDN CommonName.Domain.Domain).  But network trace shows that when the WinPE sends it during authentication it is arriving as  host/CommonName.Domain.Domain and not as  domain/CommonName.Domain.Domain.  The RADIUS server is configured to trust the proper root and intermediate certificates, but fails the WinPE host authentication.   I haven't yet tried TLS user authentication with a user certificate, but suspect similar problems.    
       If and when I find a way to make the CISCO ACS happy I will post the full methods.

         I'd definitely be interested in seeing how you did it with user auth.  Especially how you were able to encapsulate and send the domain\username & password. 

    Thanks.
    Monday, January 18, 2010 9:28 PM
  • it was all done through NetSH and XML files.

    We have dot1x pointing to a radius server on our cisco switches and they pass the requests through to  the radius server. if you require more info feel free to flick me an email.

    Cheers
    Monday, January 18, 2010 10:29 PM
  • We have tried every reasonable combination to authenticate WinPE 3.0 across an 802.1x enabled Cisco 3750 switch controlled by Windows 2003 AD Integrated Cisco SecureACS version 4.2 RADIUS server without any success - with our without MS Hotfix KB972831.

    Using EAP-TLS with a user certificate we have observed through network trace that the WinPE client will not pass the certificate.

    Using MSChapV2, Win PE will not parse and pass the supplied MsChapV2UserPropertiesV1  authentication credentials: Username, Password, and LogonDomain as defined in the associated schema .xsd. 

    Using EAP-TLS with a system certificate, WinPE will pass a certificate but will not complete the handshake with the result shown in the Cisco SecureACS log "External user not found".

    My belief is that there are some critical support components that are required to support the process that are missing fromt he KB972831 Hotfix. 

    The conspicuous lack of useful documentation has led all involved to reach the conclusion that should we spend any more time field testing this that Microsoft should provide some resources, documentation and examples. 

    • Edited by Chris Fors Friday, January 22, 2010 8:21 PM 802.1x SCCM SP2 WinPE KB972831
    Tuesday, January 19, 2010 2:15 PM
  • I would like to email you, but your email is not obtainable.

    Any chance you could detail how you did this? or email me anthony dot sheehy westminster.org.uk?
    Anthony Sheehy - MCP, MCITP
    Thursday, February 18, 2010 9:19 AM
  • We did it with a Cisco 3750, pointing to a radius server, using WinPE 3.0 with KB972831 installed


    below are parts of what i used to get it working (should be enough for anyone to replicate)

    *** startnet.cmd ***
    
    wpeinit


    wpeutil initializenetwork

    net start dot3svc netsh lan add profile filename="x:\windows\system32\Local Area Connection.xml" interface="Local Area Connection" > X:\log.txt netsh lan set eapuserdata filename="x:\userinfo.xml" allusers=yes interface="Local Area Connection" rem wait 10 seconds before connecting to the network < was needed otherwise it wouldn't map drives to the server ping -n 10 127.0.0.1 > nul *** end startnet.cmd ***



    **** userinfo.xml ****
    
    
    <?xml version="1.0" ?>
      <EapHostUserCredentials xmlns="http://www.microsoft.com/provisioning/EapHostUserCredentials"
        xmlns:eapCommon="http://www.microsoft.com/provisioning/EapCommon"
        xmlns:baseEap="http://www.microsoft.com/provisioning/BaseEapMethodUserCredentials">
        <EapMethod>
          <eapCommon:Type>25</eapCommon:Type>
          <eapCommon:AuthorId>0</eapCommon:AuthorId>
        </EapMethod>
        <Credentials xmlns:eapUser="http://www.microsoft.com/provisioning/EapUserPropertiesV1"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:baseEap="http://www.microsoft.com/provisioning/BaseEapUserPropertiesV1"
          xmlns:MsPeap="http://www.microsoft.com/provisioning/MsPeapUserPropertiesV1"
          xmlns:MsChapV2="http://www.microsoft.com/provisioning/MsChapV2UserPropertiesV1">
          <baseEap:Eap>
            <baseEap:Type>25</baseEap:Type>
            <MsPeap:EapType>
              <MsPeap:RoutingIdentity>test</MsPeap:RoutingIdentity>
              <baseEap:Eap>
                <baseEap:Type>26</baseEap:Type>
                <MsChapV2:EapType>
                  <MsChapV2:Username>$USERNAME$</MsChapV2:Username>
                  <MsChapV2:Password>$PASSWORD$</MsChapV2:Password>
                  <MsChapV2:LogonDomain>$DOMAIN$</MsChapV2:LogonDomain>
                </MsChapV2:EapType>
              </baseEap:Eap>
            </MsPeap:EapType>
          </baseEap:Eap>
        </Credentials>
      </EapHostUserCredentials>
    
    
    **** End Userinfo.xml ****


    **** Local Area Connection.xml ****
    
    
    <?xml version="1.0"?>
    <LANProfile xmlns="http://www.microsoft.com/networking/LAN/profile/v1">
    	<MSM>
    		<security>
    			<OneXEnforced>true</OneXEnforced>
    			<OneXEnabled>true</OneXEnabled>
    			<OneX xmlns="http://www.microsoft.com/networking/OneX/v1">
    				<cacheUserData>true</cacheUserData>
    				<authMode>user</authMode>
    				<EAPConfig><EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type><VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>25</Type><EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1"><ServerValidation><DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames></ServerNames></ServerValidation><FastReconnect>true</FastReconnect><InnerEapOptional>false</InnerEapOptional><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>26</Type><EapType xmlns="http://www.microsoft.com/provisioning/MsChapV2ConnectionPropertiesV1"><UseWinLogonCredentials>false</UseWinLogonCredentials></EapType></Eap><EnableQuarantineChecks>false</EnableQuarantineChecks><RequireCryptoBinding>false</RequireCryptoBinding><PeapExtensions><PerformServerValidation xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</PerformServerValidation><AcceptServerName xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</AcceptServerName></PeapExtensions></EapType></Eap></Config></EapHostConfig></EAPConfig>
    			</OneX>
    		</security>
    	</MSM>
    </LANProfile>
    
    
    
    **** End Local Area Connection.xml ****


    I had a vbscript that prompted for the username and password then injected it into userinfo.xml ......


    Once the patch was installed into WinPE 3.0 this was all that was needed to get the WinPE client to authenticate using Dot1x to our 3750


    Any questions feel free to email me at Andrew.Husking@erh-software.com


    Cheers


    I might note, that once authenticated, the userinfo.xml was removed from X:\
    • Proposed as answer by Andrew Husking Friday, February 19, 2010 1:25 AM
    Friday, February 19, 2010 1:23 AM
  • Aha - the missing link...

    The result - winpe responding to eapol messages as per below:

    Feb 19 09:35:48: %DOT1X-6-INFO_EAPOL_PING_RESPONSE: The interface Gi0/2 has an 802.1x capable client with MAC 0024.e8xx.5b38

    Gi0/2      0024.e8xx.5b38  dot1x    DATA     Authz Success  AC107002000000770CBB7DD0

    However Andrew, running this in Startnet.cmd after winpeinit means that the custom tsmbootstrap.exe shell kicks in before the client has had a chance to authenticate. So I created a pretsmboot.cmd with the following:

    @echo off
    net start dot3svc
    netsh lan set autoconfig enabled=yes interface="Local Area Connection"
    netsh lan add profile filename=%SYSTEMDRIVE%\windows\system32\profile.xml interface="Local Area Connection"
    netsh lan set eapuserdata filename=%SYSTEMDRIVE%\windows\system32\uprofile.xml allusers=yes interface="Local Area Connection"
    netsh lan reconnect interface="Local Area Connection"
    del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q
    X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

    And substituted

    Run=X:\sms\bin\i386\pretsmboot.cmd

    for

    Run=X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

    in tsbootshell.ini

    (Because tsbootshell.ini is replaced when the image is updated in SCCM, I need to capture the image, insert the profiles, the pretsmboot.cmd and the amended tsbootshell.ini between Updating the boot image and before refreshing the distribution points...)



    It does leave a nasty command shell window visible but authenticates, starts responding to EAPoL messages and is enabled on the correct LAN. I'm happy with that. Now we just need to see if Chris can get his certificate authentication to work...
    Anthony Sheehy - MCP, MCITP
    Friday, February 19, 2010 10:15 AM
  • Hmmm. We have a catch. Our 802.1x SCCM WinPE client now refuses to connect on a non 802.1x protected port. It fails at the first hurdle, in the logs, downloading via FTP.
    Anthony Sheehy - MCP, MCITP
    Monday, February 22, 2010 10:20 AM
  • Hi,

    Likely the reason it is failing on non-eapol ports is because of the following line in the LAN profile:

    <
    OneXEnforced > true</ OneXEnforced >


    Wednesday, February 24, 2010 7:40 PM
  • Here is how I have been  (semi) successful in getting certificate-based authentication to work:

    1) Using a Computer cert from our AD CA (2k8 Enterprise....minted from a copy of the Computer Certificate Template with key exporting enabled and free-form Subject submission turned on.) The Subject of the cert is important, since this is what Windows PE uses as it's User-Name when authenticating.

    2) Create an unprivileged user object in AD that has same username as certificate subject

    3) Associate minted cert from #1 to user object in AD from #2

    4) Copy certutil.exe into WinPE image (as per original post)

    5) Copy minted cert (exported with password-protected key), CA cert, and LAN profile to WinPE image. The LAN profile specifies machine authmode, but is otherwise very much the same as the one posted above by Andrew H.

    6) Insert the following commands into startnet.cmd:
    wpeinit
    certutil -addstore ca x:\eapol\ca-cert.cer
    certutil -importPFX x:\eapol\machine-cert.pfx

    wpeutil initializenetwork
    net start dot3svc
    netsh lan add profile filename="x:\windows\system32\Local Area Connection.xml" interface="Local Area Connection"
    7) Upon applying the lan profile to the Interface, the workstation attempts 802.1x authentication using the machine certificate from its certificate store. It sets the User-Name attribute to host/<cert subject name>

    8) Used Realm attribute re-writing in IAS to strip host/ from the User-Name attribute.

    9) IAS finds the user in AD which has the same name as the certificate subject minted in #1. Since the certificate the workstation is passing was minted by the AD CA, and is associated to the AD user object, the EAPOL/TLS negotiation succeeds.

    I'm sorry if the above description is a bit vague and is likely missing a few minor elements...but that's the jist of it. There are a few outstanding issues right now that I have:

    1) Startnet.cmd does not appear to be executing for some reason ( I think).
    2) If it is executing, the certutil -importPFX command is not prompting for the password to unlock the cert private key.

    Wednesday, February 24, 2010 8:05 PM
  • I actually had to use the TSConfig.ini hook instead of Startnet.cmd.  Now after the client enters the Task Sequence password, they get prompted for the PFX password. The cert gets added to the local store, the profile gets added to the interface, and the workstation eapol authenticates.
    Thursday, February 25, 2010 7:31 PM
  • Great Andrew,

    Two questions/observations:

    1, Using the startnet.cmd, how do you avoid the problem of having the Task Sequence start (tsbootshell.ini is executed by winpeinit.exe) before your net servicing commands are completed. (in the above example this would not apply because you have to ask for a password)

    2, Actually asking for a certificate password means this is no longer a ZTI as you have to be at the console to type the password in. Was that intended?

    Oh, and thanks for the onexenforced tip. Somethings really are in front of my nose.
    Anthony Sheehy - MCP, MCITP
    Friday, February 26, 2010 7:47 AM
  • Anthony,

    1.  In our configuration, I found that the StartNet.cmd was never actually being executed. This is due to SCCM inserting it's own winpeshl.ini into the WinPE image as the boot image is published to the PXE service point.  It was mentioned in a KB article that the presence of winpeshl.ini will cause WinPE 3.x to ignore the startnet.cmd file.  It was for this reason that we had to use the Custom hook feature in TSConfig.ini.  When you use TSConfig.ini, the tsbootshell runs your custom scripts to completion before the task sequence kicks off.  It was suggested in another forum that you could wrap your custom script in a vbs to either insert a pause, or execute logic to make sure the interface is EAPOL authenticated before the script exits.  Another non-vbs option that was mentioned was to insert a pause at the end of the custom script by pinging localhost a suitable number of times.

    2. Due to the security demands of our environment, we were forced to make concessions with respect to zero touch.  We have also password protected the PXE service point (the tsbootshell prompts for a password before the Task Sequence kicks off). That said, it is possible to specify the certificate password on the cmdline with certutil as follows:

    certutil -p <key password> -importPFX x:\eapol\machine-cert.pfx

    This would make the process zero touch, but would also expose the password to the certificate keys. Since the WinPE image is freely downloadable via TFTP over our guest vlan, EAPOL security would be effectively negated.

    At the end of the day, I'm not sure if there is any way around this, other than perhaps making use of smart cards.
    Friday, February 26, 2010 4:07 PM
  • As i think i stated originally, this was all done using the WAIK and WinPE3.0

    I haven't actually seen or touched SCCM (ever), i work in the networks section not in the desktops or deployment section of the org i work for....

    So unfortunately i can't help you with SCCM related questions. Sorry
    Sunday, February 28, 2010 5:57 AM
  • Thanks Andrew P,

    Re point 1, that was our approach also.

    (I wonder if we could get a few more Andrews in on this question just to make it more confusing...)

    With regards to password security, all our passwords are in a file that is imported and then deleted, which would mean that booting into the image and searching would find nothing of use. Of course, if somoene was determined, they could falsely download the image and trawl it. You just make that searching harder by giving the password file an arbitrary location and name.

    We have used a username and password rather than certificate approach. This means you have no certificate to compromise. It also means that we can specify (as indeed you can with the certificate) which vlan the username has access to. The username has no other use but to authentication on to the build vlan, which allows bootps, domain and access to the build PCs with ACLs on the VLAN itself. Any compromise of the username would then only allow a very small attack vector and still retain ZTI.

    But then again I understand that you sometimes have other pressures that dictate your method of working.

    Once again. Thanks.
    Anthony Sheehy - MCP, MCITP
    Monday, March 01, 2010 8:31 AM
  • A quick reminder that this thread is about Zero Touch???
    Anthony Sheehy - MCP, MCITP
    Monday, March 01, 2010 2:17 PM
    • Edited by Nick Lowe Wednesday, March 03, 2010 12:13 AM Fix link.
    • Proposed as answer by ACSheehy Friday, April 16, 2010 11:41 AM
    Wednesday, March 03, 2010 12:10 AM
  • This is good work, Nick. but now, I have a new problem: This works fine with 32bit, but somehow with a 64bit Windows 7 deployment this falls over after the initial reboot, not having authenticated. It is as if the script is never initially run on 64bit Windows 7, and so all http is then redirected to our web authentication page, which causes the deployment to fail.

    I originally used the same answer file. Then I created an answer file against the 64 bit image I am deploying. Neither seem to work.

    What now?


    Anthony Sheehy - MCP, MCITP
    Wednesday, April 14, 2010 9:06 AM
  • Okay - figured it out. The instructions we have all been brooding over and which Nick Lowe has succinctly descripted are only part of the solution and only work when you boot directly to the media. If you initiate the task sequence from the SMS client, or have to reboot into 64bit PXE, the normal boot sequence does not take place and tsbootshell is bypassed. It launches straight into the requested task sequence.

    Since all my PCs boot to the 32bit boot image, all my 64bit deployments were failing. To combat this I added the 802.1x configuration script to the start of the task sequence without conditions. In the 32bit image I did the same script in place but put a condition on it _SMSTSLaunchMode = SMS, so that the script is skipped when booted straight from media.


    Anthony Sheehy - MCP, MCITP
    Friday, April 16, 2010 11:41 AM
  • Hey Chris-

     

    I'm seeing the same behavior with Win PE 3.0 not sending the MSChapV2 authentication credentials. I just captured this with a sniffer and the Win PE host is not responding to the EAP Identity request, after it sends the initial EAP Start packet.

    Did anyone ever find a solution or fix for this?

     

    Philip-

    Tuesday, February 01, 2011 7:46 PM