I managed to update that attribute and the user is able to login with the newly updated login information, which works great. I am contunuing to test this however it does seem to function quite well.
Users are able to login with old@domain.com as well as domain
ew, however when logging in they are logged into the new profile. The sAMAccountName attribute is what is used to determine the account.
Any feedback from others who have tried this would be most welcome.
Hi Scott,
Can you post how you went about solving this so that others will have the answer if they have the same question?
Thanks and glad you figured it out.
Sure thing. So the issue at hand was relatively straight forward and my main stumbling block was a query that was giving me incorrect results when I went looking for changes in AD with my action. Once I cleared out my list and started from scratch, it was able to work.
The issue I had was the 'initiator' below in the workflow, and I was using a different account that I am used to and was looking at the wrong account for changes in AD.
How I got it to work:
In the 'AD fields to update' select the drop down >> Other >> Add
Enter in sAMAccountName (ensure spelling is exactly the same as the attribute name in AD)
What this changed was the sAMAccountName and the pre-Windows 2000 logon name. It does not change the 'Windows Login Name' - see below:
You will not be able to login with domainoldname but if you did oldname@domain you can still login, however it will change to display the new updated information. When you login with the new account name the same profile exists with the same permissions and access and the user is able to work without interruption.
I'm left now trying to see how to update the 'User logon name' field.