Matt (sorry for the delay),
I'm making an assumption that when you say "we were able to change our password
correctly", you did that be changing it in Lion?
The issue I was referring to is this:
- via your institution's account management service, create "password1" and use
it to connect to your SSID
- "password1" is stored in the keychain on the Lion machine
- via your institution's account management service, change password to
"password2"
- Turn on Wi-Fi on the Lion machine and it'll try and use "password1", which is
stored in the keychain. It'll fail and wait ~60seconds before trying again with
"password1". In my testing, I was never prompted to re-enter my password. Thus,
flushing keychain was the only option.
==========
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!
On Aug 15, 2011, at 5:27 PM, Matt Pendleton wrote:
> Hello all,
>
> We tested for this bug on our test OS X Lion device and we were able to
> change our password correctly. Did we not do something right to get this bug
> to appear? I want to make sure we tried everything as our students will be
> returning starting this Wednesday.
>
> Thanks,
>
> Matt
>
>
>
>
> Matt Pendleton | Systems & Network Administrator
> University of Florida Department of Housing and Residence Education
> PO Box 112100 | Gainesville, FL 32611-2100
> office 352.392.2171 x10107 | fax 352.392.6819 | [email protected]
> Before printing this email think if it is necessary.
>
> -------- Original Message --------
> Subject: Re: [WIRELESS-LAN] MacOS Lion & Wireless Password Resets
> Date: Tue, 9 Aug 2011 14:26:40 -0400
> From: Holland, Ryan C. <[email protected]>
> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
> <[email protected]>
> To: [email protected]
>
>
>
> 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] <mailto:[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] <mailto:[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]
>> <mailto:[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] <mailto:[email protected]>>
>>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
>>> <[email protected]
>>> <mailto:[email protected]>>
>>> Date: Fri, 5 Aug 2011 11:00:24 -0400
>>> To: <[email protected]
>>> <mailto:[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]
>>> <mailto:[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]
>>> <mailto:[email protected]>>
>>> *Reply-To: *The EDUCAUSE Wireless Issues Constituent Group Listserv
>>> <[email protected]
>>> <mailto:[email protected]>>
>>> *Date: *Fri, 5 Aug 2011 09:13:43 -0400
>>> *To: *<[email protected]
>>> <mailto:[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]
>>> <mailto:[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] <mailto:[email protected]>
>>>
>>> /Submit a Kudos to an OCIO employee!
>>> <http://www.surveygizmo.com/s/514095/giveociokudos>/
>>>
>>> ********** 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/.
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> 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/.
>
> **********
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 1240822769) is spam:
> Spam: https://antispam.osu.edu/b.php?i=1240822769&m=c45ea678a367&c=s
> Not spam: https://antispam.osu.edu/b.php?i=1240822769&m=c45ea678a367&c=n
> Forget vote: https://antispam.osu.edu/b.php?i=1240822769&m=c45ea678a367&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
