Setuser / Execute As for user from trusted domain

  • Is there a way that I (sa-level user) can do a setuser or Execute As a DomainB\User AD account, where DomainB is trusted by mine (Domain A), but does not trust mine?

    Thanks!

  • Since I am not versed in Active Directory, maybe I should not answer, but my gut feeling is no. The login has to be validated by other domain, and if the service account for SQL Server is not welcome there, I guess it gets difficult.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • Hmmm....I wonder if we changed the SQL Server account to one from the other domain?

  • Well, if you have sysadmin privs, that eliminates the complexity of SQL permissions. All you have left is to deal with the domain permissions. I don't know for sure, but I would think you could not do it. It is simple enough to try. Connect with your login with sysadmin privs, then:

    execute as login = 'domain_name_2\user_on_domain_2';

    select count(*) from sys.objects;

    revert;

    If you succeed, you can do it. If not, you cannot. If you would, please post the results. I've not tried this before and am interested to know if it'll work or not.

  • Using my credentials (I'm a member of local admin on domain_1 SQL servers, and member of sysadmin on the SQL Servers. I'm an average user on domain_2.)

    Msg 15404, Level 16, State 19, Line 1

    Could not obtain information about Windows NT group/user 'domain_name_2\user_on_domain_2', error code 0x5.

    (Yes, I changed 'domain_name_2\user_on_domain_2' to a real account :-P)

    This makes sense, as our domain is not trusted.

    But what I'm up against is, our users must now login to the Domain_2. This is making it difficult to troubleshoot db access and permission issues.

  • Well, you got the result I expected to see. Thanks for the feedback.

    I'm no expert in cross-domain trust relationships, so I'll let someone who knows more about it than I do chime in.

Viewing 6 posts - 1 through 5 (of 5 total)

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