none
The server principal "XXXXXX" is not able to access the database "XXXX" under the current security context RRS feed

  • Question

  • Hello Team,

    We are suddenlty facing the above error in Live SQL server environment..  below is the flow of the application to give a quick view

    1. front end application connect to SQL Server A - DB1 with Service account SVC_xx   

    2. SVC_xx execute a stored procedure "GetData" against SQL Server A - DB2 . inside the GetData Stored procedure there is a command which will run the SQL statement in different service account (SVC_yy) context using " with execute as SVC_yy " command.

    the above senarios working fine until yesterday afternoon (from last couple of years), suddently its broken and giving the below error. Also note that TurstWorthy is already enabled on database server..

    Error Detail - "The server principal "XXXXXX" is not able to access the database "XXXX" under the current security context."

    any one faced this kind of issue? if so please advise... any help on this regard is greatly appreciated..

    Thursday, June 13, 2019 12:25 PM

All replies

  • That message is coming directly from your DB2 server. There are many reasons for that message.  I would contact your DB2 DBAs to research the logs to find the problem.

    Thursday, June 13, 2019 12:45 PM
  • yes DBA is working on this but we need some input on this.
    Thursday, June 13, 2019 1:12 PM
  • If EXECUTE AS worked previously to permit cross-database access, this means that the following were true:

    1) The database DB1 was marked as TRUSTWORTHY.
    2) The owner of the database DB1 had been granted AUTHENTICATE permission in DB2.

    TRUSTWORTHY is often seen as a security risk, and indeed it is when used incorrectly. I recommend strongly against using EXECUTE AS + TRUSTWORTHY to give server-level access in stored procedure. For cross-database access, it is sometimes a good option, if done correctly. It is absolutely imperative that the database is not owned by sa or someone else that is not sysadmin.

    If this just a matter of an occasional cross-db access, certificate signing is a better option, but that option is less palatable when there is cross-access all over the place.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Thursday, June 13, 2019 9:56 PM
  • Unfortunately, that is a generic login failure message from DB2 and does not help diagnose the problem in any way.  The DB2 logs should indicate exactly why DB2 refused the connection.

    Friday, June 14, 2019 11:04 AM
  • Unfortunately, that is a generic login failure message from DB2 and does not help diagnose the problem in any way.  The DB2 logs should indicate exactly why DB2 refused the connection.

    Tom, I think you are a little confused here. DB2 in this context is simply an SQL Server database. There is no linked server to any product from IBM involved here. The error message in question is a message from SQL Server. See my previous post in thrread for more details on what is going on.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Friday, June 14, 2019 9:04 PM
  • Oops. You are correct.  I misread the OP as "DB2" meaning the IBM DB2 database engine.  

    Sorry.

    Sunday, June 16, 2019 10:34 PM