I have an application that uses CSLA remoting between the client and SQL server machine. I am using a Windows Service to host the remoting. The application and host service use Windows authentication rather than CSLA authentication. The connection string to the database on the server machine is using the sa account and its password rather than integrated security.
When a user that has administrator privileges runs the program everything works fine. However when a non-administrative user runs the program all read operations work, but write operations seem to fail. What is strange is no errors are being reported back to the client so it thinks everything is working just fine. The write operations just don't write anything to the database.
Is mixing Windows Authentication with this type of connection string the possible cause of a problem like this? I am getting ready to troubleshoot the problem, but if the real solution is to go back to integrated security and just update the security definitions in the database to allow authorized users write access to the neccesary databases that would be easier.
Has anyone encountered something like this with CSLA before? We are using version 3.0.2 with this application. Thank you for your help!
JeffQ
If you are using an explicit username/password in your connection string, then it should not matter at all what kind of security you use to get to the app server. The only thing that matters is the u/p passed in the connection string.
Except that the user identity under which the app server service runs does need to be able to reach the database server (it could fail due to NTFS security or other security concerns).
It is odd that reads work and updates fail. This makes me suspect that you are using the DTC and perhaps the non-admin user is somehow unable to interact with the DTC or some other network service?
I do believe we are interacting with DTC. We will be working on this Monday. I will let you know what we find if it is interesting in any way. Thank you!
JeffQ
Thank you for your help on this, it turned out to be a non-problem. The user was not accurately reporting what was really happening. Not the first time that has happened to any of us is it? The software and CSLA was performing as designed.
Jeff
This turned out to not be a problem. The user was not reporting the circumstances accurately. Everything works as it should. Thank you for your help!
Jeff
Copyright (c) Marimer LLC