From Colin Simpson: As a heavy corporate user of RHEL, we follow Fedora progress to see what's coming up. We work in an environment that is heavily Windows and our business unit is very much a (admittedly large) Linux enclave. We currently have all our Linux systems joined to AD with Quest Authentication Services and this allows us to have a high degree of integration to the Windows side of the shop. But we are always looking to improve matters. So I read with interest the proposed enhancements to AD integration proposed for F18. All of which looks welcome. One area I don't see mentioned that is causing us pain (and I'd imagine lots of corporates) just now is 802.1x PEAP-MS CHAPv2, that is required to access our corporate WiFi system. Particularly the side that provides client machine authentication to the network. Windows does this transparently. Non-Windows systems are expected to use cert based authentication but our security group is less keen as it means these are easily "stolen" and we have to maintain a MAC address whitelist. To be honest the second stage of authentication (user auth network access) isn't so great either currently. Network Manager can store your credentials but it would be nice if they could be passed through from the login ala Windows. To be honest I don't even know how Windows machine authentication works and can find little documentation on it. It seems to be a hash based on the machine stored AD keytab and passed to Radius. So any thoughts on PEAP-MS CHAPv2 in the AD integration plans or any thoughts on this in Red Hat you know of? Again sorry for the direct email on this, just not sure where else in RH may be the correct place to direct such a query. It seems are corporate security continues to move up the agenda that 802.1x is becoming more of a requirement even on the wired side.
From Stef: We'd need to research exactly how this works. Any links or information you or your network admins have on the specific protocol involved would be helpful. How did you discover the above? Do you have a linux/unix client using that authentication yet? There are so many protocols and variants thereof in this area, that I want make sure we're talking/thinking about the same thing. Do you have documentation for how your AD deployment was configured to do 802.1x PEAP-MS CHAPv2. If not, then we could do that research. But I figured I'd ask.
From Colin Simpson: We utilise all this on Aruba wireless technology but it's standard across Wireless vendors, well as much as an MS standard can be called that. We (our network and security group) currently insist on Computer Authentication followed by User Authentication. The Computer Authentication I believe allows you to get to a limited network where you can talk to the Domain Controllers. Then then allow you to complete User Authentication, then you get full network access. The first issue with 802.1x authentication we notice is even with User Authentication. It would be nice if pam would be able to pass your username and password to to Network Manager for the User Authentication piece (it currently requires domain credentials to be entered directly into Network Connect). Obviously with password expires etc this is problematic. The second harder, bigger issue is that AD Machine Authentication isn't supported at all. Here are the docs we have (sorry for the large attachments). Firstly we found a Cisco document, which is the best overview I've found so far: http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a0080205a52.html#wp803832 Attached is the Aruba manual we worked from (we use Aruba). References are: Basic but succinct (Aruba OS 5 Users Guide pdf, page 277) "Configuring User and Machine Authentication When a Windows device boots, it logs onto the network domain using a machine account. Within the domain, the device is authenticated before computer group policies and software settings can be executed; this process is known as machine authentication. Machine authentication ensures that only authorized devices are allowed on the network. You can configure 802.1x for both user and machine authentication (select the Enforce Machine Authentication option described in Table 51 on page 271). This tightens the authentication process further since both the device and user need to be authenticated." Page 270 User Guide pdf : EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2): Described in RFC 2759, this EAP method is widely supported by Microsoft clients. A RADIUS server must be used as the backend authentication server. Page 271 User Guide pdf : Enforce Machine (For Windows environments only) Select this option to enforce machine authentication Authentication before user authentication. If selected, either the Machine Authentication Default Role or the User Authentication Default Role is assigned to the user, depending on which authentication is successful. This option is disabled by default. Note: This option may require a license (see Chapter 28 on page 551).The Enforce Machine Authentication checkbox is also available on the Advanced settings tab. Info on format of what is passed in machine authentication (Aruba Doc, page 9) "Dynamic Server Selection The controller can dynamically select an authentication server from a server group based on the user information sent by the client in an authentication request. For example, an authentication request can include client or user information in one of the following formats: <domain>\<user> — for example, corpnet.com\darwin258 | Authentication Servers ArubaOS 5.0 | User Guide <user>@<domain> — for example, darwin host/<pc-name>.<domain> — for example, host/darwin-g.finance.corpnet.com (this format is used with 802.1x machine authentication in Windows environments)" Someone at the bottom of here asking about machine authentication: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363600(v=vs.85).aspx "Hi, I am implementing a Eap-Mschapv2 as a inner method for authentication using EAPHost API. Can anyone tell me when will EapPeerBeginSession be called with the flag EAP_FLAG_LOGON set. Does this flag indicate that the peer must perform authentication using windows logged in credentials like EAP_FLAG_MACHINE_AUTH which indicates that machine authentication should be performed. How do I obtain the windows credentials (password) to perform Eap-Mschapv2 if the flag is set."
Created attachment 620378 [details] From Aruba about configuring the auth method
Created attachment 620388 [details] Aruba OS 5.0 Users Guide
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
We have made progress with this. Though it's quite a cross component issue needing Active Directory, SSSD, WiFi and Network Manager. So basically our understanding of how two factor authentication works with PEAP. From this thread: http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/802-1x-Machine-and-User-Authentication/td-p/8886 Basically it seems to be that a Windows machine does a machine auth (when associating), and gets added to a table on the wireless controller if successful. A Windows machines then leaves the network and rejoins with user credentials when a user logs in. This second WiFi associated is allowed only if it's in the machine authenticated table (from first asscociate) From the article: - Default-Machine-Role = Whatever you want a computer with no user logged into it to have access to. I would suggest allowing communication to the domain controller, DHCP, DNS, and the like so that when the user does log on, they can run scripts and the like. - Default-User-Role = Role for NON domain devices with domain users - Default-Dot1x-Role = Role for domain devices with domain users Machine Boot -> Machine Auth -> Default-Machine-Role (Limited Network Access, auth servers etc) -> User logs in -> Default-Dot1x-Role (Full Network Access). I don't believe this is Aruba specific, as this looks like a Windows client method. We managed to figure out how machine authentication works. Basically it's pretty trivial, it just a standard PEAP MSHCAPv2 (everything else is automatic) wireless auth with a username of "host/FQDN", where FQDN is the fully qualified domain name of the host on the AD domain (e.g laptop1.redhat.com would be hostname laptop1 on redhat.com AD domain). The password is just the AD password for the machine object. This isn't directly obtainable from a Kerberos keytab from the AD join (that I know of) but you can force a change of it using Winbind (if using that is what you are using as your AD joining tool), using "net changesecretpw" but this doesn't update the AD side (probably doable in AD users and computers then use this command to sync them), haven't tried. It was easier for us as we use Quest Authentication Services and it allows this to be updated to a new random password and output it (/opt/quest/bin/vastool -q -u host/ passwd -r -o). I'd imagine SSSD can do this somehow.... Standard Windows computers update their machine password monthly for security reasons, not sure if SSSD does (it probably should), so this password is pretty dynamic. Once this is in place the machine passes Machine Auth. My knowledge of this was bootstrapped by this article on wired 802.1x authentication, they used likewise AD connector but it was easy to figure out. http://ubuntuforums.org/showthread.php?t=2141567 The tricky things are: 1/ Is it possible to get Network Manager to use the machine authentication at boot time and then do (switch to) user authentication at login for the WiFi. I have thought of a way this might work, would be to use the standard ifcfg files to do the machine auth (which should apply when the machine boots) then get the users Network Manager session to switch to the users credentials for auth. The issue with this is that if a user turns on WiFi in session (not at boot) the machine auth will never be tried. The real solution would be to allow network manager to perform this dual auth. Anyone talked about this or thought about this? 2/ Storing the machine password in plain text isn't ideal (in the ifcfg files), but unless there is some way that radius auth can use a hash for machine password then I don't see a choice. But it would imply that Windows is storing the machine password in plain text (or at least reversibly encrypted)? 3/ It would be nice if PAM could be persuaded to pass the users username and password for the user auth piece of this dual authentication. Or even single user authentication for that matter. 4/ For AD connection software, most people I guess will be directed to (and should be using) SSSD. So SSSD needs to have a way of passing the updated machine password to the WiFi setup for machine authentication. This is assuming the SSSD updates the machine password regularly, as I say if it doesn't it probably should. The commercial Quest software we use has a hook to allow you to run commands on machine password refreshes. 5/ Have other people not asked about this or needed this is in a corporate environment? I'm a bit surprised about that...
Can this be set to a rawhide bug as I doubt it's been addressed? Though it's maybe now a RFE more than anything else. "AD WiFi PEAP MS-CHAPv2 Dual User and Machine Authentication" maybe a better title.
I have submitted this as a RHEL7 RFE at bug #1129811 This one can therefore probably be closed.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.