Here's my next #TipTuesday post, which is somewhat of a follow-up to another post a few days ago about Web Client & Account Level Security. In that article, I described a couple of bugs that are authentication-related that prevent the use of Account Level Security (ALS) in the Web Client. That bug is predicated on one assumption: users are 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.

Web Client GP login window.

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.

Full Client GP login window.

A user's SQL login is their "old school" GP login. Caveat: this only works if the user is not set 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 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 testing logins or security on new users perhaps, where I could be logging in under different GP logins to confirm security is set up correctly.