I'm wondering if anyone has ever seen this phenomenon: in v15.1, using Windows Authentication, a login gets mapped to an incorrect user. Everything about the Windows Auth set up is correct, and it's been difficult to see anywhere except the IIS logs where this is happening. The only way we know it's happening is the user calls our help desk because they're seeing unusual control grouped data, or something about the initial screen is incorrect.
We are wondering if it has something to do with load balanced application servers, even though sticky sessions is turned on? Has anyone else seen this? (I have opened a help ticket.)
We are currently on version 14.1 and are upgrading on July 14 to v15.1 and Windows Authentication is one of those things everyone is really looking forward to using. However, we are reluctant to activate that feature until we have a better understanding of what is happening here.
Thanks!
Nancy
Are you on RAMP or self-hosted? We had a small, and different, issue with one of our users trying to do Windows Authentication, and it turned out to be a configuration issue in the Tessitura.ini: it sounds like maybe things are written there during login now?
We are self-hosted and everything we have that is Tessitura related is going to AWS. That's where we're testing. We've had a couple of load balanced application servers (both on prem as well as in AWS), but we are using Sticky Sessions.
I've checked the client logs as well as the rest logs... nothing. I would need to bump up the verbosity, probably. However, since we can't accurately recreate the problem, I am reluctant to do so because the experience for all users would be degraded while have logging increased.