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
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