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.
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.
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.
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/
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 |
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/
Comments
I was trying to install the Web Client on my brand new GP 2015 test server, but get stumped with the login process as I had associated my GP user with an AD account, but it was always asking me to authenticate twice over the web login.. nothing in the Web client documentation talks about the GP utilities... since this is not an upgrade, does it need to be ran anyway ? I'm going to try this out tomorrow.
I was able to make the Web authentication work fine with regular user accounts... now I'm still stuck with some dummy user accounts that I've assigned to demo AD user-id's to test out different login scenarios and GP license type... however the login to GP fails with the same error message mentionned in your post. It can't be the GP Web client service account, since it works just fine for other users... so where could the issue come from ?
Can you please explain what you mean here? Is this to re-create the user the GPWeb clients use to authenticate?
My problem is that some user can use the web client but other users with the same GP rights get this message..
Thanks
I am currently experiencing this problem in accessing Dynamics GP 2015 web client. I carefully followed your instruction above to fix the error but the error still exist when I tried to login. I am sure that I have a corresponding GP user and my domain account was linked properly to it. I know I am missing something. Is there anything I can check to solve this error? I have been trying to fix this about a week now but to no avail. Thank you very much.
This isn't a solution.
Also, I cannot always get back to every comment on this blog. If you have an immediate support request that's what Microsoft is for.
No judgment on the author's part, I mean, you're under no obligation to troubleshoot for us, thanks for sharing your scenario and solution.
In most cases, you will need to Repair web client if the above does not fix the problem. Make sure however that you access Dynamics GP Utilities and set the password for the Web Client proxy account prior to repairing web client.
Sorry about the perception this may have created, however, when I originally wrote that article, it was an extremely busy month and really couldn't get back to my blog. Point taken and please keep up the readership.