Sql-server – SSMS login to different domain

This is expected. LUA strips administrators membership from your token. From Getting Started with User Account Control on Windows Vista:

To help prevent malware silent installation and computer-wide infection, Microsoft developed the UAC feature for Windows Vista. Unlike previous versions of Windows, when an administrator logs on to a Windows Vista computer, the user’s full administrator access token is split into two access tokens: a full administrator access token and a standard user access token. During the logon process, authorization and access control components that identify an administrator are removed or disabled, resulting in a standard user access token. The standard user access token is then used to launch the desktop, the Explorer.exe process. Because all applications inherit their access control data from the initial launch of the desktop, they all run as a standard user as well. Contrasting with this process, when a standard user logs on, only a standard user access token is created. This standard user access token is then used to launch the desktop.

Since your local desktop token has the administrator membership removed, it cannot log in locally to SQL Server if you expect to log in through builtin\Administrators. On remote access your token preserves the Administrator membership and you gain access.

The solution is to grant SQL Server login rights through an explicit domain group account and add all users that require access to your SQL instance to this domain group. Do not rely on Administrators membership, is a bad practice.

I cant comment (not enough rep on this site) so I have to submit this as an answer.

1) I have successfully set up a SharePoint SSRS portal using forms authentication (FBA). The SSRS part was not hard - very straightforward actually, just perform the SSRS install as SharePoint integrated. However, the SharePoint FBA part was very painful (not difficult, just lost a lot of hair and sleep over little stuff you didnt think would be necessary and couldnt find straight answers to.)

I know that you can use Report Builder 3.0 to save to a SharePoint site. I have not tried that using the FBA SharePoint portal. I dont work at that company anymore, so I dont have access to test that either. I would think it is very possible though. The portal I set up was accessed by non-domain users, which is why I had to use FBA. I was using SharePoint 2007 and SQL Server 2008 R2.

I know the following link tells of the permissions needed for Report Builder to save to a SharePoint library: http://technet.microsoft.com/en-us/library/dd255209(v=sql.105).aspx

2) I did find a specific blog post about using Basic Authentication: http://blogs.msdn.com/b/bobmeyers/archive/2006/09/28/how-to-enable-report-builder-for-non-domain-users.aspx.
There is also an article on MS technet titled: "How to: Configure Report Builder Access"

3) Another thing that is worth trying - You can use a domain account for report viewing only, then use the ReportViewer Web service/API/webpart/etc to have a report embedded within a web application. That way, the report connects using the username/password specified, not the user viewing the application. That has worked for an application I helped work on that was exposed on a DMZ web server, but used an SSRS report that was on the internal network. In that case, the SSRS instance was a Native install. If you are using .NET - you can use Visual Studio. It already has controls built in.

The only think I dont know about in this case is the use of Report Builder. Just thought I would mention it because it might help spur some thoughts.