Changing password after expiration notice

[GCIT2013]

Running vSphere 5.1.0

View Administrator 5.1
Windows 7 32-bit desktop machines

Wyse P25 zero clients - firmware 4.1.2

Windows Server 2008 R2 Standard 64-bit

Both persistent & non-persistent pools

We have been running into this issue since going into production with our virtual environment (about 6 months now). I have finally documented the process that is causing us trouble. The issue is when a user doesn't change their password before their expiration date, they then become locked out and forced to change their password at log on but the process does not properly work. I went through this process with a test ID I knew was past its expiration. I attempted to log into the zero client and it immediately brought me to the screen with the username already filled in, Domain filled in, and the open fields for Old password: New password: and Confirm new password:. After entering the information I receive an error message stating "unknown user name or bad password", the only option is to click ok. It then brought me back to the screen to create a new password only now that this point the username field was blank and greyed out so I couldn't manually enter it. The user typically doesn't realize it and attempts to enter the old and new passwords again assuming they typed it in wrong the first time. After doing so, I then received the message "authentication can not proceed (missing parameter)" due to the user name filed being blank. Again the only option is to click OK, it then ended the process and brought me back to the first screen for the connection server field. Please see the attached images from documenting the process (forgive the quality, had to take them with my cell phone since there was no where to paste a screenshot) this is all what we have been hearing the users report. The even stranger thing about all of this is that it does infact change the password to what the user typed into the New password fields, but there is nothing hinting at this for the user to know, I only know because I have tested it many times. But usually by the time the user calls me to report their issues they have tried it multiple times and we cannot figure out which password the account is currently set at resulting in myself having to reset their password in Active Directory. *Note that when I choose the option "User must change password at next logon" in AD, this issue does not occur, it is only when the user passes their expiration date.

[rrutia]

I have been having the same problem.

I have two environments in one this configuration works and in the other the configuration doesn't work.

I took a tcpdump and all the kerberos request including the KBR5 and KPASS protocol, which is the protocol in kerberos that change the password are getting from the client to the AD server. So this problem is not an issue of Firewall blocking ports, I am very close but I think the error is coming from the Vmware horizon view client.

Is there a configuration in vmware view that allow/block users from changing passwords?

[GCIT2013]

Not sure but I agree it seems to be in the view client. I at first thought it was a disconnect with the zero clients but it happened with the installed view client on my pc as well. I only experience it when a user gets past expiration but not when I check the box to prompt them to change their password which I feel is strange. I also have noticed some users do not get the notice that their password is about to expire (we have it set to notify 14 days ahead) but some users do. Everyone has the same group policy. all very strange!

[marclehto]

Hi All

We are experiencing the same thing in a VMware DaaS environment. It has been a problem since we launched a bunch of clients into VDI last year. We have tried setting up third party utilities to e-mail users before the password expires, thus having them manually change it in the desktop session, but that really doesn't fix the issue, just works around it. Our help desk still manually has to reset passwords for the forgetful people. Our testing has resulted in the same thing you have experienced, in that if you set the "change password at next logon" it seems to work fine, but somehow this is different than when the password expires. Did you ever get any resolution to this GCIT2013? Our next step is to open tickets with both VMware and our thin client vendor. In our case we are using 10Zig zero clients, and we are using both persistent and non-persistent desktops.

Thanks

[nzorn]

Little different, but I have this documented in our environment:

Scenario:

1. User is working in View, and password expires

2. User locks their session, and when trying to unlock the session they receive the following message: "The password for this account has expired. To change the password, click OK, click Switch User, and then log on."

3. User is not able to follow the instructions listed above as they do not have a Switch User button

Solution:

1. Turn off the Zero Client, and turn it back on

2. Have the user log back in, and the Zero Client should then prompt for the old and new password, it will resume the old session

[marclehto]

I have opened a case with VMware at this point. The engineer assigned to the case claims they have other similar cases right now as well. He is sending it to development and they are testing to see if this is a bug in the VMware View Agent. I will post any updates I get.

Thanks

[hadricus]

Would love to hear any progress on this, we're getting the same issue here.

[gmtx]

Same issue here - users get stuck in a loop trying to change an expired password from within Windows.

We use the same workaround as nzorn - have the users disconnect from the session and reconnect. The zero client login screen will prompt for a password change, and that works.

Geoff

[bjohn]

Just tried this.

My password was already expired, logged in using P25 and was prompted to change. Password change was accepted.

P25 with 4.50 firmware.

Don't know if it makes any difference that I'm not a "regular" user - have some permissions more than the regular user.

[marclehto]

Thanks for the comments so far all. I have been keeping in touch with the engineer assigned to my case, but no fix yet. He claims there are 2 cases for sure right now that have tickets in on this, and the developers are testing and trying to recreate the issue. He thinks it may be the agent, but nothing definitive yet.

I will update again when I hear back.

[hadricus]

Nothing back from the engineers yet? I might also log a case.

[hadricus]

Also I'm interested to know if you have a load balancer in front of your connection servers. If so, what are you using?

[marclehto]

Still have the ticket open, but not gaining a lot of ground.We have gotten them view client and view agents logs, and engineering is going over them. I have a conference call today with the engineer I have been working with and a few of his managers. Not using any load balancers in our environment.

[marclehto]

OK, so just to post a resolution so everyone knows, we ended up receiving a new view agent direct connect build from the development team. We have rolled it out for one of our hosted customers and it does seem to fix the problem. I would imagine this will be going to production as a new build soon.

[Poort443]

Hi marclehto, did you get this new agent in September? I also have the same issue, but it seems there's no update of the View Agent available with VMware yet. Any chance I can try your version of the agent?

Regards,

Martijn

[marclehto]

I don't know if they ever updated it, but I think it was supposed to be the view agent 5.3 build..