January 8, 2015 at 2:05 am
Is the windows user in any other domain group which has login to SQL?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 8, 2015 at 2:25 am
It is a member of other groups with server logins, but none of these are linked to users in the database. The permissions, etc. currently in the database are a bit of a mess as a result of our attempts to find a work-around and MS Support's attempts to investigate the problem.
January 8, 2015 at 2:31 am
Chris Wooding (1/8/2015)
It is a member of other groups with server logins, but none of these are linked to users in the database.
Sounds weird, but try taking that user out of all other domain groups that have SQL logins, and see if that fixes things.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 8, 2015 at 2:42 am
As I said, we've had to take the stance that we're not going to spend more time on it. This was the latest MS response (they think the problem may be related to the public account);
"That said, the results of the ‘mySP’ test rule out any Database-level aspects, and therefore likely any adherence to your application (unless it interacts at server role level), but the utter simplicity of our new failing test makes the situation even more puzzling. Also, we can see ‘public’ UserName in both failing and working SP execution within the trace, so this is something we must take into account."
January 20, 2015 at 1:26 am
In case it helps anyone with a similar problem, here is the closing summary from MS support.
Technical Summary : on one of your server, the observed EXECUTE permissions didn’t match the theoretical permissions set for a given login.
No reason was identified for this (DENY flags were checked at user, SQL group and Windows Group levels).
During the analysis it was noted that the TST1 Login mapped to the ‘PUBLIC’ DBUsername, which is unexpected (there should have been a TST1 username instead).
We also reproduced the problem outside the context of the application DB. The investigation perimeter had therefore become the SQL instance and the Windows AD context of the server.
We stopped the investigation before we could dive further on the ‘public’ login/user mapping.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply