Forcing a SQL login in Web Client

Here’s my next #TipTuesday post, which is somewhat of a follow up on another post a few days ago about Web Client & Account Level Security. In that article, I described a couple of bugs that are really authentication related that prevent using Account Level Security (ALS) in the Web Client. That bug is predicated on one assumption: that you’re using the default Windows authentication to log into Web Client.

Default Web Client Login

Out of the box, the typical implementation of the web client will be with a single expectation: a user will be presented with a single login box asking for their Windows/Network credentials, and that’s it. From there, GP security is handled via connecting the dots between their network login and their GP login, to determine what they have access to. The next screen, after the login below, would be to choose a company.

It works that way when the user has a Windows (Directory) account associated with their GP login.

Changing to force SQL authentication

The only reason I’m even looking at alternatives here is testing ways to work around the ALS issue. If a user does not have a Directory account associated with their Dynamics GP login, they will be prompted for a SQL login upon logging into the Web Client AFTER logging in with their network credentials on the default screen above.

A user’s SQL login is their “old school” GP login. Caveat: this only works if you have not set the user as “Web Client Only” on their User Setup in Dynamics GP. They must have a SQL login to go this route.

The downside to this obviously is the user is logging in twice, just so they can provide SQL authentication to work around an issue like ALS not working in the web client with Windows Auth. So… I don’t imagine most users would want to use this.

Where else might it be useful?

Perhaps an administrative user might want to make this their default if they are often logging in as ‘sa’ or ‘DYNSA’, both of which are SQL logins of course! (A whole other post would be about why someone needs to log in as ‘sa’ or ‘DYNSA’ but I digress…). It could also be useful if you are testing logins or security on new users perhaps, where you could be logging in under different GP logins to confirm security is set up correctly.

comments powered by Disqus
Built with Hugo
Theme Stack designed by Jimmy