I would appreciate any analytical or remedial suggestions for this problem:

We use 7.6.4 MRE, RCaster, and ReportingServer on a windows platform.
We access these via DevStudio 7.6.4.
All user accesses to workstations, networks, WebFOCUS, and non-IBI applications are authenticated via ActiveDirectory.
We use the realm driver.

- One user reports that he changed his password, yesterday, when prompted to do so by A/D's periodic set-a-new-password process.
- He did not use DevStudio afterward.
- Today, his DevStudio would not open an MRE FocExec because UserID/Password were incorrect. He tried both old and new credintials. Neither worked.
- I assisted him in resetting the credentials for his DevStudio WebFOCUS Environment Properties. Neither old nor new ones worked.
- I'm an MRE Admin and examined his credentials with MRE Administrative Console and the UID/PsWd boxes were greyed out, as they normally are in our situation.
- I checked the MR Security Settings of the WebFOCUS Administrative Console and nothing seemed unusual.
- I coached him in launching both MRE and RCaster through his IE browser. His old and new credentials would not work.
- The Windows WebFOCUS server hardware rebooted last midnight, after the A/D credentials were changed and before today's failures appeared.
- The user has rebooted his workstation several times today and the DevStudio behavior persists ... as does his ability to log-onto and use all other non-IBI applications with his new credentials.
- No other DevStudio/WebFOCUS users have any access problems today, although I don't know the status of their A/D prompts to renew credentials.

H E L P ? Does anyone have any suggestions or ideas about what I should check or do next?

This message has been edited. Last edited by: cburtt,

We use active directory as part of a security exit. When a user changes his/her LAN password, the password is supposed to be replicated throughout all the servers that the user has access to and the LDAP repository is synchronized.

Sometimes that doesn't happen and there is heck to pay. Can you have your Active Directory admins verify that the pw in its repository is what the user changed it to? Maybe, and it sounds like it, that is where the problem is.

Good idea, GinnyJ, but this user can successfully access all his non-IBI business applications, things like e-mail, the corporate ERP system, mapped network resources, etc. Everybody's access to these services is through A/D. So, the fact that he can access these indicates that A/D has his new credentials stored correctly.

Implementing the strategy of "I don't care how it broke, JUST FIX IT!!", I now have a happy user with a new, but identical account.

Deleting the user's MRE account and re-entering it as a new account fixed the problem.
To do that I ...

- In ...\ibi\WebFOCUS76\basedir\:
* Backed-up then deleted user's 'UserID' folder.
* Backed-up then deleted user's 'UserID.htm'.
* Backed-up generic/shared 'user.htm'.
* Found and deleted user's entry in the above preserved 'user.htm'.
- Using the Managed Reporting Administration Console:
* Printed User's property window.
* Deleted User.
* Recreated User's account as new UserID, copying properties from the above printout.
- In ...\ibi\WebFOCUS76\basedir\:
* Replaced newly created user's 'UserID' folder with copy of backup.
* Replaced newly created user's 'UserID.htm' with copy of backup.
- Notified the user that he should try his new account.
* Was told all is now AOK!