When using Shared Workplace, is there something that needs setup on the back end for password changes to work. I have logins working through Shared Workplace, but if a user’s password expires, they get a prompt to change their password, but it will not actually change it. They enter the new password twice (once in each box) and click the right arrow to submit and it says “You are required to change your password” and then switches to “Changing Password…”, but it never actually changes it. When I look at logs on the domain controller, it shows a TGT certificate request was done, but nothing else. I haven’t been able to find anything in documentation on this so I am not sure where to go from here. UMS is running on a Linux OS that is joined to our domain.
You have to make sure the account that is used to bind to AD in UMS has rights to change user passwords. If you need the functionality to work for Domain Admins it needs to be a Domain Admin account
Or have the correct permissions on the OU (but this is more difficult)
taking a look at that now
gave that user rights to change passwords, but it still wouldn’t work. I found that if I enabled ad/kerberos I was able to change the password, but logging in no longer worked (for any user, not just the one I changed the password for). I will do some more testing tomorrow on it. Our password change policies don’t make it easy to test this as it will only allow the password to be changed every 24 hours and I haven’t taken the time to figure out if there is a way to exclude a user from that.
Yea, may be permissions or policies on the AD side. It’s not straight forward
seems to be very little documentation on shared workplace.
Honestly, Shared Workplace isn’t used much, and usually the issues with password authentication is more about the AD / Kerberos configuration than anything in Shared Workplace.
Are you using LDAPS to connect UMS to your Domain controllers? Also, can you point at one or two if you have multiple configured in UMS?
The way it works, is that the IGEL device connects to the UMS server, and uses it to authenticate. UMS acts as an intermediate and authenticates the user against AD and then provides the authentication token back to IGEL to authenticate the user.
Then UMS applies any policies. Also, you must have an EMP license.
The benefits are that you can use AD credentials outside of the four walls via ICG and that you can apply user specific policies (although I typically don’t like this workflow).
Honestly I prefer using other methods for external users and VDI is a better solution in my opinion, but it has it’s purpose.
Also, make sure you don’t configure Domain Autrhentication on the same device with shared workplace enabled
Our use case is that we want the same user experience externally and internally. Internally, we currently use AD/kerberos authentication. Externally, we currently use the Citrix Workspace app to connect to our Netscaler. So the look is different. Ultimately, they both result in Desktop icons being placed on the IGEL desktop. The other issue we have right now with our current setup is that external users can’t change their passwords after they have expired. This is the biggest reason we were looking at IGEL Workplace.
Gotcha. Then yes, make sure you disable AD authentication when you enable Shared Workplace. They can’t both be enabled at the same time.
Continue reading and comment on the thread ‘When using IGEL Shared Workplace, how to enable password changes?’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!