Authentication permissions

I'm fairly certain that I understand the difference between the AUTHENTICATE SERVER and AUTHENTICATE permission, but I'm not positive.

For these purposes, I'm leaving off the authorization portion as well as assuming a TSQL endpoint.

My understanding:

The authentication process is broken into two stages - connection and authentication. In order to successfully authenticate to an instance, the following must apply:

1. I must have CONNECT SQL permission

2. I must have CONNECT permission on the endpoint that I am using

3. The endpoint that I am using must be in a STARTED state

4. The login that I am using must be enabled

Once the connection is established, I need AUTHENTICATE SERVER permission in order to authenticate to the instance. (Or do I simply need AUTHENTICATE permission?)

AUTHENTICATE & AUTHENTICATE SERVER permissions are only used when using EXECUTE AS in cross database and server-access (respectively) scenarios.

When a new session is established in SQL Server, the server itself will perform the authentication and the no AUTHENTICATEAUTHENTICATE SERVER permission is checked.

When using EXECUTE AS USER, permissions are checked at the DB scope, therefore the DBO has absolute control over this type of impersonation, and the DBO is said to vouch for the token and becomes the authenticator. In case of a digitally signed module (marked with EXECUTE AS) the story is similar, but the certificate can act as an authenticator.

In order to avoid unintended escalations, by default these impersonated tokens cannot move outside the current database (i.e. cannot access resources outside it) unless the DB is marked as trustworthy or they come from a digitally signed module. Being able to get outside the DB is not sufficient, the authenticator must be trusted at the scope of the resource the impersonated context is trying to access; for example, if trying to access a table on another DB, the DBO of the target DB must have granted AUTHENTICATE to the authenticator of the impersonated context.

I strongly recommend reading the following topic from BOL: Extending Database Impersonation by Using EXECUTE AS (http://msdn2.microsoft.com/en-us/library/ms188304.aspx )

I hope this information helps,

-Raul Garcia

SDE/T

SQL Server Engine

sql