All, Per advice from our Apple rep, I have submitted Apple BUG# 9922069. If you would, please also submit bug entries for this so they understand the affect of this issue. For your ease of submission, here's what I submitted:
> 09-Aug-2011 02:23 PM Ryan Holland: > Summary: > After successfully authenticating via 802.1X to an enterprise Wi-Fi network, > credentials are stored in Keychain correctly. If the username/password are > changed on the enterprise side (i.e., user changes their password), OS 10.7 > continues to use the stored keychain item and never prompts the user to > reenter their username and password. Authentication continuously fails. > > Steps to Reproduce: > 1.) Connect to an 802.1X authenticated WPA2-AES enterprise Wi-Fi network > (like most higher education institutions) and verify credentials are stored > in the keychain. > 2.) Change username and password via the authentication database > 3.) Disconnect from Wi-Fi on the 10.7 machine. > 4.) Reconnect/reauthenticate to Wi-Fi > At this point, reconnection is not possible. > > Expected Results: > OS 10.7 will use the keychain with the now-incorrect username and password. > Upon failed authentication, the UI should prompt the user to reenter their > username and password. User would enter their now-correct username and > password, successfully authenticate, and OS 10.7 would update the keychain > entry appropriately. > > Actual Results: > UI never prompts for now-correct username and password. Authentication > continuously fails. > > Regression: > User must manually remove any and all related keychain items that have the > stored username and password. Then, OS 10.7 UI will prompt user for NEW > username and password. > > Notes: > Regression is workable on a case-by-case basis. However, we have 10,000+ mac > users and a 90-day password policy that is enforced. With this current bug, > users will have to tinker with their keychain at least every 90 days. > > Please email me at [email protected] or call at 614-292-9906 to discuss > this matter further. > **THIS NEEDS TO BE PRIORITIZED, AS NUMEROUS UNIVERSITIES ARE AFFECTED BY THIS > BUG** ========== Ryan Holland Network Engineer, Wireless Office of the Chief Information Officer The Ohio State University 614-292-9906 [email protected] On Aug 5, 2011, at 11:44 AM, Holland, Ryan C. wrote: > All, > > I used the iPhone configuration utility to create a .mobileconfig file, as > recommended by apple. Upon double-clicking, it prompts to install the > profile, and you can optionally enter a username and password at that time. > Either once you enter those and finish profile installation, or if you skip > entering there and later enter username and password connecting, either way > an entry is added to the keychain. THEN, if the user changes their password, > that keychain entry is still there and is used, continuously failing auth. > Only workaround I've found is to delete the keychain, which results in user > prompted for username and password, at which point a new keychain item is > created. > > I think this is more of a keychain behavior problem.....or just a WiFi > problem on the Apple. Regardless, the Mac supplicant's behavior should not > try and be stubbornly using wrong credentials over and over. "That password > didn't work?! Hmm. Maybe I should try it again. Didn't work again? Hmm. Maybe > I should try it again. Dang! How about now? no!? Hmm.... Now?......" > > At this point, Xpressconnect is not an option for us. Also, we can't not do > 802.1X. Right now, the only I do I have is bold face text on the WebUI where > users change their password stating that Mac users *must* delete their > keychain, etc. > > Additional ideas? > > =========== > Ryan Holland > > On Aug 5, 2011, at 11:06 AM, "Palmer IV, Daniel" <[email protected]> wrote: > >> That was going to be my point. That profile can be for the user or for the >> machine. We are using a user based profile that we modify via script and >> "slurp" in to create our connection. (Cannot say which id is being used to >> validate though, have not had time to test that). >> >> dp >> >> Daniel Palmer >> University Technology Services (UTS) >> Emory University >> Atlanta, GA 30322 >> 404.727.5297 (office) >> 404.213.1643 (mobile) >> >> >> >> From: David Blahut <[email protected]> >> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv >> <[email protected]> >> Date: Fri, 5 Aug 2011 11:00:24 -0400 >> To: <[email protected]> >> Subject: Re: [WIRELESS-LAN] MacOS Lion & Wireless Password Resets >> >> Great question, I was surprised to not see the + in the 802.1X window. When >> I associated to the secure SSID a dialog box popped up asking for username >> and password. I think the credentials are added to the keychain at that >> point. >> >> You can also use Lion server to create a profile. I haven’t tested this but >> more information can be found here: http://support.apple.com/kb/HT4772 >> >> -d >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >> [mailto:[email protected]] On Behalf Of Palmer IV, Daniel >> Sent: Friday, August 05, 2011 9:43 AM >> To: [email protected] >> Subject: Re: [WIRELESS-LAN] MacOS Lion & Wireless Password Resets >> >> In your test machine… How did you create your 802.1x profile? >> >> dp >> >> Daniel Palmer >> University Technology Services (UTS) >> Emory University >> Atlanta, GA 30322 >> 404.727.5297 (office) >> 404.213.1643 (mobile) >> >> >> >> From: David Blahut <[email protected]> >> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv >> <[email protected]> >> Date: Fri, 5 Aug 2011 09:13:43 -0400 >> To: <[email protected]> >> Subject: Re: [WIRELESS-LAN] MacOS Lion & Wireless Password Resets >> >> I did some Lion testing yesterday on our 802.1X secured SSID and discovered >> the following while watching the RADIUS logs: >> >> The laptop had two accounts set up on it, mine and another ‘tester’. If you >> simply switched users the machine would reauthenticate but still use the >> other username/password (the account switching from). >> >> If the laptop was restarted or shut down and started back up the correct >> username/password would be used to log into the wireless no matter what user >> was logged in when the restart was initiated. >> >> I don’t necessarily think this is a big problem in our environment but I can >> see where it could be in others. >> >> -d >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >> [mailto:[email protected]] On Behalf Of Holland, Ryan C. >> Sent: Thursday, August 04, 2011 5:01 PM >> To: [email protected] >> Subject: [WIRELESS-LAN] MacOS Lion & Wireless Password Resets >> >> I have finally got my hands on MacOS 10.7 (lion) and have started running it >> through wireless tests. One item I find very worrisome is this: >> - Via WPA2-Enterprise (PEAP/MSCHAPv2), I connect to the SSID using username >> & password1; these credentials are then stored in the keychain >> - If I change my password to, say, "password2", then the next time I >> connect, the Mac fails authentication >> It seems that the Mac, if failing authentication, never prompts for the >> username & password to be reentered. >> >> Our university is soon to roll-out and enforce a 90-day password policy, and >> I am concerned that users will be unable to authenticate and forced to >> remove the password from their keychain. >> >> >> Have any of you run into this similar issue? If so, how do handle this >> behavior? (I don't recall it being this way in MacOS 10.6 or 10.5) >> >> ========== >> Ryan Holland >> Network Engineer, Wireless >> Office of the Chief Information Officer >> The Ohio State University >> 614-292-9906 [email protected] >> >> Submit a Kudos to an OCIO employee! >> >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> >> This e-mail message (including any attachments) is for the sole use of >> the intended recipient(s) and may contain confidential and privileged >> information. If the reader of this message is not the intended >> recipient, you are hereby notified that any dissemination, distribution >> or copying of this message (including any attachments) is strictly >> prohibited. >> >> If you have received this message in error, please contact >> the sender by reply e-mail message and destroy all copies of the >> original message (including attachments). >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> >> Spam >> Not spam >> Forget previous vote >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
