none
Bug in security context? RRS feed

  • Question

  • I new up my entities with the signature:        

    public MyEntities(string connectionString) : base(connectionString, "MyEntities")

            {
                this.ContextOptions.LazyLoadingEnabled = true;
                OnContextCreated();
            }
    This call (connectionstring) has an explicit user and password AND integrated security OFF or false.  I am logged in on the PC as admin (local admin - w/domain account) and have a token (mapped drive) to the db server on which the same login is administrator AND sa.
    I also have a remote connection to db server.  I also am running SSMS from the local server connected to the dbserver.
    I then run my app and make the call for new entities, using signature above (explicit connection string), and guess who sql profiler reports and the log file aduit says is logged on?  "sa",  but then I insulate the dbserver from all these connections the exact same app now connects as designated user.
    It appears something is overriding my explicit request for a named user, without integrated security?
    Thursday, November 10, 2011 4:14 PM

Answers

  • Hi,

    A SQL Server group is likely better. I doubt the issue is at the EF level as authentication is handled at a lower level. I don't remember to have seen the exact same thing but if I remember I saw once that you can't connect on the same server from the same machine using two accounts. So IMO it could be that the network layer just reuse the identity under which you are already connected to the server.

    Using an alias (http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/) could be a way to check this (i.e in this case whatever handles the connection won't see that both names are actually the same server and then should establish the expected connection).

    If you need further help try rather a group at http://social.msdn.microsoft.com/Forums/en/category/sqlserver.

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    Thursday, November 10, 2011 11:07 PM
  • Have you tried with just a SqlCommand ? This is to find out if needed if it is happens at the EF level or at a lower level (which is IMO more likely as EF relies on the lower level provider).

    I tried something like :

    - using a domain account (which is a local admin but  not the local admin account itself), connect to a $ network share on the SQL Server
    - use a SSMS instance with the same domain account
    - use another instance with SQL authentication

    The profiler reports the correct LoginName depending on the SSMS instance I'm using.

    The thing it reminded me is http://support.microsoft.com/kb/173199/en-us so I suspect that some kind of interaction between your connections depnding on unkown conditons (do you have the same password for the local admin account than for your server and/or domain admin account) could be perhaps possible (something like when trying to establishing a connection to the SQL Server machine using a non integrated connection, it sees a connection is already established and it reuses this ???). Sorry for the poor help.

    If you confirm that it happens also for SqlCommand, a SQL Server group or even a network admin group could be better (in the worst case a network monitor could perhaps help ?)

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    Wednesday, November 16, 2011 10:49 AM

All replies

  • Hi,

    A SQL Server group is likely better. I doubt the issue is at the EF level as authentication is handled at a lower level. I don't remember to have seen the exact same thing but if I remember I saw once that you can't connect on the same server from the same machine using two accounts. So IMO it could be that the network layer just reuse the identity under which you are already connected to the server.

    Using an alias (http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/) could be a way to check this (i.e in this case whatever handles the connection won't see that both names are actually the same server and then should establish the expected connection).

    If you need further help try rather a group at http://social.msdn.microsoft.com/Forums/en/category/sqlserver.

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    Thursday, November 10, 2011 11:07 PM
  • Hi,

    I am writing to check the status of the issue on your side.  Would you mind letting us know the result of the suggestions?

    If you need further assistance, please feel free to let me know.   I will be more than happy to be of assistance.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, November 14, 2011 1:58 AM
    Moderator
  • The one suggestion was to try an alias to see if the names listed in profiler would be different.  As I described in the original post, I have already proved the connection is being altered, as I did a test case by eliminating all connections and then running the same application from the same client.  I am not out to prove that the security infrastructure works as planned.  If I have a client running WITHOUT integrated security and an explicit SQL user used, I would expect the security infrastructure to honor this and allow that connection to perform what only what that user has been granted, not what some other token from the same resource is allowed.
    Tuesday, November 15, 2011 4:39 PM
  • Have you tried with just a SqlCommand ? This is to find out if needed if it is happens at the EF level or at a lower level (which is IMO more likely as EF relies on the lower level provider).

    I tried something like :

    - using a domain account (which is a local admin but  not the local admin account itself), connect to a $ network share on the SQL Server
    - use a SSMS instance with the same domain account
    - use another instance with SQL authentication

    The profiler reports the correct LoginName depending on the SSMS instance I'm using.

    The thing it reminded me is http://support.microsoft.com/kb/173199/en-us so I suspect that some kind of interaction between your connections depnding on unkown conditons (do you have the same password for the local admin account than for your server and/or domain admin account) could be perhaps possible (something like when trying to establishing a connection to the SQL Server machine using a non integrated connection, it sees a connection is already established and it reuses this ???). Sorry for the poor help.

    If you confirm that it happens also for SqlCommand, a SQL Server group or even a network admin group could be better (in the worst case a network monitor could perhaps help ?)

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    Wednesday, November 16, 2011 10:49 AM
  • Mr. Chen has swept this under the rug, that is ok I guess. But a final comment, I do think, yes, it is related to http://support.microsoft.com/kb/173199/en-us. The integrated security mechanism says "hey, you are connected by virtue of this token, so lets reuse it"? Then add on connection pooling and what not, a single non-integrated sql user doesn't seem to have a chance. Realistically, the scenario, shouldn't occur, but it is not far fetched to have a service or two with different integrated logins coming from the same resource/box that a non-integrated, sql user application user is coming from (my original scenario).
    Monday, November 21, 2011 3:51 PM