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.
Nancy --
A thought occurs: I'm in the process of provisioning a set of new external API servers for a load balanced environment and that got me to wondering if you have multiple internal API servers. If you do, check in IIS what kind of session state (IIS > Server Node > "Sites" > Site Node hosting the REST API / TessituraService virtual application > in the "Features View" choose "Session State" from the ASP.NET section; you may need to check on the "TessituraService" virtual application specifically, but my guess is its using the same for all virtual applications in the site) they are using -- are they using In Process on each server or are you using the State Server service on the machine? There's the remote possibility that if you're using In Process instead of State Server, that might be causing some issues.
DGomez