Security

Question

Post reply

Security

Steve Jones - SSC Editor

SSC Guru

Points: 736078
More actions
January 5, 2009 at 11:58 pm

#63625

Comments posted to this topic are about the item Security

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply

free_mascot One Orange Chip Points: 27169 More actions · Answer 1

I guess; "A user to act like another user"

looks correct answer as per the following MS article:

http://msdn.microsoft.com/en-us/library/ms188304.aspx

---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."

ChiragNS One Orange Chip Points: 26137 More actions · Answer 2

According to BOL the answer seems to be the first option.

"Keep Trying"

Hugo Kornelis SSC Guru Points: 64790 More actions · Answer 3

Hi Steve,

Impersonation is a generic term for using the security settings of a user that you are not authenticated as. This term is used *both* for

(a) database users impersonating other database users (using the EXECUTE AS command, or executing stored procedures with the EXECUTE AS clause), which requires the aptly named IMPERSONATE permission - see also the link free_mascot posted; and

(b) the SQL Server service connecting to another instance under the context of an authenticated Windows user.

So both the first and the third answer are correct.

Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
Visit my SQL Server blog: https://sqlserverfast.com/blog/
SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

Ralf Dietrich SSChasing Mays Points: 660 More actions · Answer 4

Hi Steve,

next time I suggest to have check boxes instead of radio boxes.

You show us two correct answers!

Ralf

I feel sorry with all of us - whom was using the first correct answer

dgabele SSCertifiable Points: 5295 More actions · Answer 5

Could someone explain why the first answer would be incorrect?

I felt it was a correct answer based on SQL 2005 BOL:

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/6d156257-8c80-4062-a6a0-acc6797b293f.htm

SQL Server 2005 supports the ability to impersonate another principal either explicitly by using the stand-alone EXECUTE AS statement, or implicitly by using the EXECUTE AS clause on modules. The stand-alone EXECUTE AS statement can be used to impersonate server-level principals, or logins, by using the EXECUTE AS LOGIN statement. The stand-alone EXECUTE AS statement can also be used to impersonate database level principals, or users, by using the EXECUTE AS USER statement.

Implicit impersonations that are performed through the EXECUTE AS clause on modules impersonate the specified user or login at the database or server level. This impersonation depends on whether the module is a database-level module, such as a stored procedure or function, or a server-level module, such as a server-level trigger.

Thanks!

John Laskey Right there with Babe Points: 734 More actions · Answer 6

I believe there is more than one correct answer to this question... I think this depend on your perception of Impersonation.

SanjayAttray SSChampion Points: 13157 More actions · Answer 7

I think answer should be option 1 and 3.

-- Impersonating allows a member of the sysadmin fixed server role or db_owner fixed database role to impersonate another user

http://blogs.msdn.com/sqlclr/archive/2006/06/16/635003.aspx

SQL DBA.

Steve Jones - SSC Editor SSC Guru Points: 736078 More actions · Answer 8

I'll correct the answers to show both as correct.

As usual, I started with a topic in BOL, in this case impersonation, which didn't mention the EXECUTE AS clause. Though I should have checked that section to see if it applied as the same term.

Points will be awarded back.

SQLBOT SSCrazy Eights Points: 8014 More actions · Answer 9

A SQL Server Central points Bailout!

:blink:

What is this world coming to?

I'll confess that I'll be a benefactor to Steve's 700 billion point bailout package.

Looking forward to the forums stimulus package, too!

~BOT

Craig Outcalt

Tips for new DBAs: http://www.sqlservercentral.com/articles/Career/64632
My other articles: http://www.sqlservercentral.com/Authors/Articles/Craig_Outcalt/560258

Steve Jones - SSC Editor SSC Guru Points: 736078 More actions · Answer 10

More like a 660 point bailout today!

Hey, unlike some of the others who are getting "bailed out," I'll take responsibility for my mistakes.

SqlOnMyMind SSCertifiable Points: 5062 More actions · Answer 11

Ok, this is weird: I selected option 3, the SQL Server instance to act like a login, but then I was told I selected the wrong answer....

I think I must have answered the question just as you were changing the possible correct answers.

Anipaul SSC-Insane Points: 24681 More actions · Answer 12

I guess the answer 'A user to act like another user' and then thought there may be another one correct and started google it... 🙂 Ultimately I got it correct.

TomThomson SSC Guru Points: 104773 More actions · Answer 13

I reckon the second option is also correct - see http://msdn.microsoft.com/en-us/library/ms189811%28SQL.90%29.aspx. Access to a linked server may map a local login to a remote login, or use the local login directly (or of course disregard the local login altogether).

Maybe someone can explain why it isn't correct?

Tom

TomThomson SSC Guru Points: 104773 More actions · Answer 14

Hugo Kornelis (1/6/2009)
Hi Steve,
Impersonation is a generic term for using the security settings of a user that you are not authenticated as. This term is used *both* for
(a) database users impersonating other database users (using the EXECUTE AS command, or executing stored procedures with the EXECUTE AS clause), which requires the aptly named IMPERSONATE permission - see also the link free_mascot posted; and
(b) the SQL Server service connecting to another instance under the context of an authenticated Windows user.
So both the first and the third answer are correct.

In your (b), when you say "an authenticated Windows user" are you referring to the user under which the local SQL service is running, or the the user under whose authority the system process that needs the connection is running, or the user being impersonated for connection to the remote service? If it's either the second or third of those, it may not be an authenticated Windows user: it can also be an authenticated SQL user; and if it's the third, it could also be an authenticated Unix user or an authenticated z/OS user or many other things.

Tom