You receive "You are not allowed to use Microsoft Dynamics GP. Please sign out and sign in with an authorized account" when accessing Web Client with Directory Account

One of the cool things about Microsoft Dynamics GP 2015 is the new Web Client Identity Management feature. Having the ability to access Microsoft Dynamics GP with your Windows Directory or Windows Azure credentials without ever needing a SQL login account is just beautiful.

The Theory - Part 1: GP Utilities

The theory is fairly simple: you have a Microsoft Dynamics GP user account, which in turn is tied to a Windows Active Directory account or Windows Azure Active Directory account. User accounts are stored in the User Master table (dbo.SY01400) in the system database, which has been beefed up with a new column called Active Directory Object GUID (ADObjectGuid) to store the actual GUID of the directory or organizational account mapped to the GP user.

User Setup window

However, because Microsoft Dynamics GP continues to be dependent on SQL authentication for all intends and purposes, it continues to need a SQL login to be able to access the Dynamics GP database objects. This is where the new Web Client SQL Login user comes into play.

If you have done a new install of Microsoft Dynamics GP 2015, you would have noticed a new window called Manage Web Client SQL Server Login during the GP Utilities process. This window prompts for SQL credentials that will be used to access the SQL server database objects from Web Client.

Manage Web Client SQL Server Login window (GP Utilities)

If you are doing an upgrade, you will need to direct your attention to the drop-down list in the Additional Tasks window to find it -- more on this later.

Additional Tasks window (GP Utilities)

When you enter the credentials in the Manage Web Client SQL Server Login window, the actual SQL Server security principal is created with the same password encryption at the database level. To understand more about this, read Why does Microsoft Dynamics GP encrypt passwords by David Musgrave over at Developing for Dynamics GP.

The Theory - Part 2: Web Client

When you are installing the Web Client itself, you are once again prompted to enter the Web Client SQL Server Login credentials. At this stage you MUST enter the same account information entered when you ran the GP Utilities.

This information is stored in the TenantConfiguration.xml file (in a single-machine instance) under the SessionCentral folder. The same information is used by the Service Based Architecture service (GPService service) to gain access to database resources, hence there's also a TenantConfiguration.xml file (again, in a single-machine instance) under the GPService folder. These two folders can be located under your \Program Files\Microsoft Dynamics\GP Web Components root folder.

Now that your AD or Organizational account is tied to your GP user account, when you launch the web client and your AD credentials are validated against IIS, a security token is created and passed on to Session Central service, which in turn spins up a runtime process passing on your AD account credentials in the GP Login window. The log in process itself will use the Web Client SQL Server login to access the system database and in particular the User Master table to validate the AD account GUID against the one stored in the table. If all matches, you are allowed access and from there on you go about your business.

The Problem

This brings us to the topic of this post...

As it turns out, during that handshake between Session Central and the Runtime service to pass off the AD credentials, I received the following error:

Further review of the Dynamics application and services log in Event Viewer, shows the following error:

System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
   at System.Security.Cryptography.CapiSymmetricAlgorithm.DepadBlock(Byte[] block, Int32 offset, Int32 count)
   at System.Security.Cryptography.CapiSymmetricAlgorithm.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
   at System.IO.Stream.Close()
   at Microsoft.Dynamics.GP.Web.Foundation.AesCryptographer.Decrypt(String value)
   at Microsoft.Dynamics.GP.Web.Services.Session.TenantServiceXmlHandler.ResolveTenantPasswords(Tenant tenant)
   at Microsoft.Dynamics.GP.Web.Services.Session.TenantServiceXmlHandler.GetTenantDetails(String identity, String tenantName)
   at Microsoft.Dynamics.GP.Web.Services.Session.Service.SessionCentralService.CreateSession(String tenantName, UserContext userContext)

Typically, any Crypto exception is directly related to credentials. So I traced back my steps after the upgrade and realized I had created the Web Client SQL server login account manually -- after all, I had not seen the option in the GP Utilities drop down to do so. Of course, this would mean that the password was un-encrypted on SQL server and wouldn't match the password stored in the TenantConfiguration.xml file. In retrospect, had I even used GP Utilities to setup the account and entered a different password from the one I entered during the Web Client install, I would have received the same error.

The Solution

Knowing that in essence what I had was a password mismatch between the value stored in TenantConfiguration.xml and the password at the SQL Server level, I decided to make things simple and removed the database user (sp_dropuser) corresponding to the security principal and the actual security principal (sp_droplogin) then re-launched GP Utilities and created the account once more, this time making sure the password matched what I had entered when installing the Web Client.

Once I launched the Web Client and entered my Windows credentials information, I was able to experience the beauty of single sign-on all the way to the company database I had selected as my default company.

Also, it is worthwhile to mention that Service Based Architecture was failing validation, but I will address this in my next article.

Acknowledgements

I want to thank Chris Rudolph with the Microsoft Dynamics GP Software Engineering team for his valuable insight into working through this issue. Chris also helped me with understanding some deep architecture stuff that I will be presenting in a future related article to this one.

Until next post!

MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.intelligentpartnerships.com/