locked
802.1x Credential Provider RRS feed

  • Question

  • I have a custom Credential Providers for Windows 7 and I'm trying to implement support for a wired 802.1x enabled network.
    Since my Credentail Provider is used in a Windows domain network, I have to perform a network authentication (using the users credential) before the user can logon to the domain.
    Is there a way to perform (Win32 API or equivalent) a network authentication using the native Windows 802.1x supplicant, or is the only option to build my own supplicant using the EAPHost framework.

    Any help is much appreciated!

    Regards
    Magnus

    Thursday, January 15, 2015 12:12 PM

All replies

  • Are you using information that will work with an in-box EAP configuration?  If so, can you set the EAP information up in a wireless profile and just use that for the connection? See my blog post for information about doing that. 

    If nothing in-box works for the connection you're building, you may have to build your own EAPHost supplicant.


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Friday, January 16, 2015 6:48 PM
  • Thanks for your reply!

    I have seen the API for the wireless configuration, but I would like to connect to a 802.1x enabled wired network. Is there a similar API for a wired connection?

    Basically, I would like to initate/perform a connection from my Credential Provider before the user is logged in, i.e. from the logon screen.

    Regards

    Magnus

    Monday, January 19, 2015 9:25 AM
  • Sorry I missed that in your original post.

    The supplicate guidelines are the same regardless if you need to make a supplicant.  It's hard to be specific for an API that may do what you want without knowing exactly what it is that you're trying to do; you shouldn't force an active connection from the login screen in any case though. You can configure the connection ahead of time so the system knows how to make the connection if it is configured to make it which may or may not require you to write your own library depending on if you can use the built-in configuration to accomplish the communication necessary for your implementation.

    Are you ultimately trying to use 802.1x wired configuration which would result in authenticating the user's domain credentials with EAP before the user has entered their credentials?  Or are you wanting to get the users credentials through your provider and then make a connection to the network before the logon?  Or something else? 


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Monday, January 19, 2015 4:04 PM
  • I'm trying to support the second scenario.

    I have implemented the IConnectableCredentialProviderCredential interface, including the Connect() function. When the user clicks the submit button, Connect() is called, and I guess this is where I should connect to the network. At this stage the user has already entered the credentials.
    The Connect function is called prior to GetSerialization, which in turn is called prior to authenticating the user on the domain; which requires a network connection.

    So, I would like to use the build-in wired 802.1x supplicant to authenticate the user on the network, before the user is logged in, and with the credentials the user has entered in our Custom Credential Provider.

    It may be worth mentioning that we are using smart cards.

    Can that be achieved, or do I have to write my own suplicant?

    Regards
    Magnus

    Monday, January 19, 2015 6:53 PM
  • Does your object need access to the network at the time GetSerialization due to some networking code that you have there?  If not, you shouldn't need to make the connection manually.  If you need to use EAP with the user credentials at that point in a dynamic fashion,  I think you'd have to write your own supplicant. 

    An easier setup may be to verify the domain machine account rather than the user account which has the added security benefit of IT having to add the machine to the domain before it can connect. 


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Monday, January 19, 2015 7:03 PM
  • No, no special network code. I just want to establish a network connection for Windows to auth the user.

    In the GetSerialization function, I serialize the user credentials and returns the resulting blob to Windows. Windows then authenticates the user and, if successful, the user is logged on. With an 802.1x enabled network, Windows cannot connect to the AD, and as a consequence the user is not logged in. If I disable 802.1x on the switch, everything works as expected.

    If the user is already logged in, I can force a re-auth by using netsh lan reconnect. In this scenario, our Provider is loaded, the user can select the smart card and enter the PIN. Our CSP is then used to access the smart card and eventually, the user is auth by the switch. To be able to perform such an authentication, I only started the “Wired AutoConfig” service and made some configuration.

    I’m a bit puzzled by the fact that I have to take in to account that the computer is connected to an 802.1x network at all. Windows should be able to resolve this issue by using the credentials I’m supplying via the GetSerialization function. I really hope that I have misunderstood how this works in Windows, I rather use Windows built-in supplicant then writing my own.

    If you have any pointers to any Win32 API and/or configuration etc. that resolves the situation described above, it would be much appreciated.

    Is it possible to configure Windows to first use the machine account and then at a later stage (when the user is logged on) force a re-auth using the users credential?

    Regards
    Magnus

    Monday, January 19, 2015 9:14 PM
  • If you're just using out of the box 802.1x that otherwise works with Windows you shouldn't have to do anything special.  Most of what I was saying was based on the assumption that you may be implementing your own vendor specific EAP information. 

    It's interesting that you mentioned needing to start the Wired AutoConfig service.  For this to work, that service should be set to Automatic so that's it running before you log in.  Do you still have the issue connecting to the 802.1x network if that service is running?


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Monday, January 19, 2015 9:20 PM
  • Yes, the issue remains even though the service is set to start automatically.

    If I use Windows native Credential Provider instead of our own, everything works as expected. The user is authenticated on the network, and then logged in.

    Obviously something magic happens inside the built-in Credential Provider, but I can’t figure out what Win32 functions the native provider is using.

    Any ideas?

    Regards
    Magnus

    Tuesday, January 20, 2015 7:35 AM
  • I was wrong about not needing to do anything special since that is only the case in certain situations; if it can't auto-connect from the information in the profile, you'd have to do the connection with a supplicant as described here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb530582(v=vs.85).aspx.

    However, you shouldn't necessarily need a custom supplicant depending on how flexible you are with the specific 802.1X configuration. You can still put the information in the network profile as I originally stated for wireless profiles as outlined here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa816372(v=vs.85).aspx. but any existing profile information is read only.  Using machine certificates to do the connection is likely the much more straightforward approach since those and the accompanying profiles can be managed with group policy.


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Tuesday, January 20, 2015 4:58 PM
  • Thanks a lot for this information!

    I will look into the network profiles, and also investigate if we can use machine certificate instead of a smart card.
     
    Regards
    Magnus

    Tuesday, January 20, 2015 6:46 PM
  • I encounter the same issue and am curious. Did you make it work?
    Tuesday, July 9, 2019 11:14 PM