Cannot generate SSPI context on laptop from different domain

Hi All,
I have Domain A with several SQL servers installed. One WinXP Pro laptop
user reports that he can't connect to any SQL server instances using Windows
authentication (the servers run win2k3 OS SP1 with SQL 2000 sp4 & 2005 sp1)
and gets the error:
Cannot generate SSPI context. (.Net SqlClient Data Provider)
His laptop is unique in that it's part of another domain, Domain B which has
no trust relationship with Domain A, nor should it. When he is in the office
at Domain A, he logs in to his laptop using cached domain credentials for
Domain B,and has entered a Managed Network Password entry for the SQL servers
in Domain A.
It appears that if I have him log into his laptop using a local account
rather than his domain account (from Domain B) the Managed Network Password
entry works and he can successfully connect to the SQL servers on Domain A.
Any suggestions on how I can get the Windows security token of the user
account to successfully connect to SQL Server in this situation where he is
using cached domain credentials (Domain B) with a Managed Network Password
(For Domain A). I would prefer not to make a trust between the domains while
still allowing him to connect to SQL using his existing laptop profile.
Thanks!
Hi,
I understand that you would like to establish a connection from your laptop
computer in domain B to your SQL Server instance in domain A. The two
separated domains are non-trusted.
If I have misunderstood, please let me know.
As far as I know, if two separated domains have no trust relationship, any
one of the two domains could not connect to the other's SQL Server
instances with Windows Authentication by using its peer domain's user
account. To establish a connection, you can create a same local user
account with the same password on both of the computers which belong to the
two different domains. Cached domain account may have permission to access
the share resources in domain B; however it could not be used to connect to
SQL Server instance. That is not secure.
Appreciate your understanding on this limitation. If you have any other
questions or concerns, please feel free to let us know. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== ===
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Hi,
I am interested in this issue. Would you mind letting me know the result of
the suggestions? If you need further assistance, feel free to let me know.
I will be more than happy to be of assistance.
Charles Wang
Microsoft Online Community Support
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Hey Charles,
Thanks for the suggestion and explanation.
If I understand the workaround you suggest it's similar to the workaround I
implemented in that the user logs into his laptop using a local account
rather than his domain account (cached from Domain B), I then added a Managed
Network Password entry for a domain user account for the user in Domain A and
he can then successfully connect to the SQL servers on Domain A.
The problem is caused by the fact that the laptop is part of Domain B and
there is no trust relationship set up between the domains. I wanted to solve
the problem by getting the Managed Network Password entry to work while he is
logged in to his laptop with his domain account cached from Domain B.
However, I understand from your explanation that this is not feasible.
"Charles Wang[MSFT]" wrote:

> Hi,
> I am interested in this issue. Would you mind letting me know the result of
> the suggestions? If you need further assistance, feel free to let me know.
> I will be more than happy to be of assistance.
> Charles Wang
> Microsoft Online Community Support
> ================================================== ====
> When responding to posts, please "Reply to Group" via
> your newsreader so that others may learn and benefit
> from this issue.
> ================================================== ====
> This posting is provided "AS IS" with no warranties, and confers no rights.
> ================================================== ====
>
|||Hi Matt,
Thanks for your response.
Appreciate your understanding that this is a by design limitation. If it is
allowed, SQL Server may face many security issues. At least a simple
scenario that we can imagine is that any other users can use this cache
accout to attack SQL Server.
Your workaround is similar as my suggested workaround. Both of them are
safe, since any user who wants to use the user account to log in SQL Server
must know the correct password. For a cache account, we may just know its
user name, but do not know its password, so there may be potential security
problem if it is allowed to be used to connect to SQL Server.
Please feel free to let me know if you need further assistance on this
issue. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== ===
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====