Hi All,
I'm having trouble remotely debugging a console application. The application will run on my server, but I am developing it on my desktop machine. I am using Visual Studio 2005 and C#. On both machines (server and desktop) I am logged in with my domain account that has administrator rights on both machines.
When I run the executable on the server it connects to the SQL Server 2000 instance without problem and starts accessing data. However when I try to start the executable by remote debugging from my desktop machine I get to this line of code:
unfetchedPhotosTableAdapter.Fill(photoDataSet.UnfetchedPhotos);
and it throws an unhandled exception System.Security.SecurityException because a "request for permission" failed.
What's going on and how do I fix it I really don't want to have to install VS2005 on the server to do my development locally; I want to get remote debugging using this data connection working.
Thanks in advance for your help.
Cheers,
Tim.
PS Here's the full text of the exception:
System.Security.SecurityException was unhandled
Message="Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
Source="mscorlib"
StackTrace:
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.PermissionSet.Demand()
at System.Data.Common.DbConnectionOptions.DemandPermission()
at System.Data.SqlClient.SqlConnection.PermissionDemand()
at System.Data.SqlClient.SqlConnectionFactory.PermissionDemand(DbConnection outerConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
at MSNPictureFetcher.PhotoDataSetTableAdapters.UnfetchedPhotosTableAdapter.Fill(UnfetchedPhotosDataTable dataTable)
at MSNPictureFetcher.PictureURLProvider..ctor(PictureFetcher inFetcher, ActivityLogger inLogger)
at MSNPictureFetcher.Controller..ctor()
at MSNPictureFetcher.Program.Main(String[] args)
SQL SecurityException, but only when debugging remotely?
Niko Vrdoljak
Hi Zlatko,
Thanks again. The app is running on behalf of my domain account on the remote machine. So I'll jump to your second set of options.
Before doing that it might be worth me pointing out that the solution described in http://msdn.microsoft.com/library/en-us/vsdebug/html/vxtskremotedebuggingacrossmachineaccounts.asp (which is linked to from the page you recommended) cannot be used. The two recommendations there are
1) "Using Administrative Tools, add YourAccount to the Debugger Users group"
There is no Debugger Users group on my remote machine.
2) "Using regedit.exe, set the value of the DWORD HKEY_LOCAL_MACHINE\Software\Microsoft\Machine Debug Manager\AllowLaunchAsOtherUser to 1"
There is no such key on my remote machine.
But getting back to your second suggestions, I have tried (1) replacing the machine name with "." in the connection string, and (2) I have tried completely removing the Data Source parameter from the connection string. Neither resolved the problem
Cheers,
Tim.
sreekanthL
Where is the database – on the same server where the application is, or on a third machine
It would be nice to see the “Data Source/Server” part of your connection string.
Zlatko
Amar_k_solai
Before we dive into delegation, there is one more thing you could try. See if SQL 2000 has “Shared Memory” as a network protocol. If so, enable it both through the Client- and Server Network Utilities, and make sure it is at the top in the Client NU. Restart your app. (You may also try the same with Named Pipes.)
If it still doesn’t work, continue reading.
We are dealing with delegation. It means the following: the remote machine (on the server) verifies the domain credentials of the source session (from your desktop) and assigns a valid domain session token to the new process. However that new session token is limited in a way that it cannot further cross network boundaries. Thus when your remote app tries to further authenticate with the SQL Server across the network, it fails.
What I suggested above was to eliminate the second network hop. But if you are reading this far, I guess it didn’t work. We have two options: 1) to enable delegation, if you have admin privileges over your domain controller, or 2) to avoid delegation.
1. Here’s an article that explains how to enable delegation. Again, it requires admin access to the domain controller:
http://www.windowsecurity.com/articles/Delegation_Authentication_Windows_Server_2003.html
2. To avoid delegation, you still have two options:
a) Create a SQL Server account and use it in a connection string for debugging your app remotely.
b) Create a local (non-domain) account on each machine with the same username and same password. Make sure each account has sufficient privileges on its machine. Log onto your desktop using that new local account. It will transform into the corresponding account on the remote machine but this time the session token will be fully functional and will be able to propagate to the SQL Server.
Zlatko
virtually
Thanks Zlatko,
Before moving on to the main body of your analysis I have found that I cannot enable "Shared Memory" as a network protocol on the Windows Server 2003 (i.e. the remote machine). When I start up the two network utilities for SQL Server 2000 I see:
(1) SQL Server Client Network Utility
Enabled: TCP/IP; Named Pipes
Disabled: Multiprotocol; NWLink IPX/SPX; VIA
(2) SQL Server Network Utility
Enabled: Named Pipes; TCP/IP
Disabled: Multiprotocol; NWLink IPX/SPX; Apple Talk; Banyan Vines; VIA
(And both lists of libraries under the "Network Libraries" tab do not contain "Shared Memory".)
Cheers,
Tim.
Graham Laidler
Did you remove (or set to FALSE) the “Integrated Security” parameter from the connection string Your connection string should look like this:
“Data Source=(local);Initial Catalog=ws_comm;User ID=foo;Password=bar”
Again, this is only for debugging. Integrated security is the recommended way to go in production.
Zlatko
Jaie Wilson
Hi Zlatko,
The connection string I had was:
Data Source=MYSERVER;Initial Catalog=ws_comm;Persist Security Info=True;User ID=foo;Password=bar;User Instance=False;Context Connection=False
But I just substituted yours and it suffers the same error.
Cheers,
Tim.
mabraham1
Tim,
I suspect when you start your app through remote debugging, it runs on behalf of the SYSTEM account. In order for the app to make a connection using that connection string, it has to run on behalf of a user account, e.g. your domain account. You can see the account of a process in the Task Manager: View > Select Columns > check User Name. Then look up the Processes tab.
If my suspicion is correct, this article will explain how to setup impersonation for the VS Remote Debugger service:
http://msdn.microsoft.com/library/default.asp url=/library/en-us/vsdebug/html/vxoriRemoteDebuggingSetup.asp
If it already runs on behalf of your account, you can try two things:
1. Replace the machine name with a dot (.) in the Data Source parameter of the connection string.
2. Completely remove the Data Source parameter
The above is an “easy” workaround that may not work. If that is the case, I’ll explain how to proceed.
Zlatko
pedron
Hi,
Zlatko, I just tried your suggestion and added a database user and added that new user and credentials to the connection string. But when I am trying to remotely debug the application I get to the line of code:
requestLogTableAdapter.Fill(photoDataSet.RequestLog);
I still get the unhandled SecurityException with the same error message:
Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
As before, if I run it locally on the server the application does not have a problem at that line.
Cheers,
Tim.
Keith Lai
Hi Zlatko,< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
The application and the SQL Server 2000 run on the same Windows Server 2003 machine. Here's the connection string:
Data Source=camresitva01;Initial Catalog=ws_comm;Integrated Security=True;User Instance=False;Context Connection=False
I did wonder if it was to do with the code access security (CAS) security settings mentioned in the .Net Security Blog http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx But I have now modified the policy on both machines (development and target) to allow full trust for all Intranet assemblies, and it still fails with the same error.
Cheers,
Tim.