So, I learned some interesting and unfortunate news today. I've been troubleshooting an odd issue with the GP 2016 Web Client. We're in the early stages of upgrading from Dynamics GP 2013 to GP 2016. The news? The GP Web Client doesn't play nicely if Account Level Security is enabled in a given company.
What's somewhat fascinating to me is no one I've talked to has ever heard of this yet we are on the 4th version of the web client with GP 2018! I guess that tells me that Account Level Security is not widely adopted by clients using Web Client.
Issue #1 - GL Trial Balances don't work
I was doing data validation and thought I'd use the Web Client to run the reports to test the functionality and performance, kill two birds with one stone? Wasn't I surprised when I printed General Ledger Trial Balance reports and they're empty! What the heck? Did the upgrade not complete successfully?
I was initially concerned that there was a data issue in our upgrade. I switched to the full client and logged into the same company and the report runs just fine. Same user, same company, same security. Huh.
Long story short, I won't bore everyone with the details, I could not figure out why this wasn't working and it was only "not" working in 2 of the 5 companies we had. I couldn't see any similarity between the 2 where it didn't work and the 3 where it did work. So, the issue was lobbed over to a Microsoft support case.
The first question back: Is Account Level Security (ALS) enabled? (My reaction: DOH!)
So, I disabled ALS and sure enough, the report works fine.
What I learned from this was not all of our companies have ALS enabled, which I didn't know when I started the day! That was the common thread, no ALS enabled, reports work; ALS enabled, reports don't work.
Issue #2 - no access to GL accounts
The second issue, also relating to Account Level Security, is the users all have no account access. More on why is coming, but what this means is any user who does anything with transactions (entering, posting), can't do it in the web client in a company with ALS enabled, because the web client thinks they don't have access to any accounts. This is an example, of an edit list for a General Entry.
This is not unusual if a user legitimately doesn't have access to some accounts on the transaction at hand, but in this case, my login has All Accounts access so it's an issue!
Why is this an issue?
Well, it goes back to how the Web Client is designed around authenticating users. Account Level Security is based on SQL Users. The full/rich client uses SQL authentication for logins and ALS is assigned at a login level.
The Web Client uses Windows Authentication instead which means all users essentially share a SQL account that the Web Client runs on to process data. Even if there is a user who is not set up as "Web Client Only", when using the web client, the login process defaults their access to authenticate using the behind-the-scenes SQL user that processes the data, no matter what their own SQL user has for access.
The good news is both of these issues are written up as outstanding quality issues.
- Bug #1 is Trial Balance report does not work when signing into Web Client with Windows Authentication if Account Security is enabled.
- Bug #2 is Web Client users not able to post if Account Security is turned on. The user receives the error “Access denied/Account Missing”
The bad news is there is no timeline for fixing them, and from the sounds of it, it's because there aren't a lot of customers reporting this issue back to Microsoft. A "product suggestion" has been added to the new Ideas site for this which I encourage others to vote for!
Bug #1 aka product suggestion #1 link is here.
Bug #2 aka product suggestion #2 link is here.
Workarounds
Here are the options if this affects your organization as well.
A) Use the full GP client
Yes, that isn't a workaround but it's a solution to the problem.
B) Disable Account Level Security
Also not a workaround, and not a solution to the problem if ALS needs to be enabled. It's not an option for my organization with the current types of inquiries and reports users use.
C) Log in with SQL authentication
This is quite clunky but it does work, I just can't honestly see users doing this every time they log into the Web Client. Here's the gist:
When users first log into the Web Client, at the company selection screen, they can click on Change User. OR, if the user is already logged in, they can click on their user ID in the upper right-hand corner drop-down, and select their UserID.
Then, the screen they see will look like this, the default authentication method for the web client:
Change Authentication to SQL Server Account and log in with their "GP" login. Note, that this requires that users don't get set up as "Web Client Only", because those users do not have their own SQL login. The users doing this must have a regular GP login and password.
Once the user is logged into the web client with SQL authentication, the reports work, the posting works, and it all works as one would expect. The user just has to do this every time they log into the web client, so effectively, they're logging in twice, for no good reason!
Final thoughts
I have to admit, I'm disappointed. I wanted to dig into the Web Client and learn to love it like some of my fellow MVPs do. In my organization, I wanted to greatly reduce the number of workstation installs IT does for an entire swath of users who rarely use GP except for inquiries and reports, and move them to the Web Client. The only way those users have access to GP in the first place is Account Level Security. We can grant them access to out-of-the-box GL inquiry windows and reports and this allows them only to see what they should be able to see. Out-of-the-box SSRS Reports don't work either for the same reason as these issues so there's no "obvious" out-of-the-box solution for simple GL reporting based on a restricted GL account list. The reporting the users want extends past financial reporting so FRx and Management Reporter aren't solutions to this problem either, by themselves.
If I look into better or alternative ways for users to get access to GL information while maintaining the same restrictions, I will be looking at ways to get that OUTSIDE of Dynamics GP in which case, Dynamics GP isn't needed at all for those users from an installation perspective. Only then could we consider disabling Account Level Security but by that time, the users who are left are the ones where they want the full unrestricted functionality of the rich client anyway.
With luck and a lot of votes, maybe this gets moved up the chain of things to be fixed in the next few months and I can revisit it. For now, though, I don't have a lot of choice but to put the Web Client on a shelf for now.
