The result of the command was:
"The command completed successfully."
I want to thank you for taking the time to help with this issue. I will try
and continue to explain the detailed problem as this is an important issue
for my group as we do a lot of work with SQL Server and we don't join our
machines to every domain we work in, so this feature that was working in XP
is very important.
No, the client machine is not a member of the domain. Basically, one of my
questions is how has the functionality changed in the use of "Managed
Passwords" between XP and Vista. If I set a managed password up in Vista it
does allow my non-domain connected machined to access shares, but does not
allow mgmt studio to access the database. I can connect to the domain server
file systems fine. Also, the Managed Password does seem to work with SQL
Analysis Services. It appears to be a problem when trying to connect to the
database engine. By the way, the SQL Server is set for mixed mode
authentication and SQL logins work. I just can't get the mgmt studio to use
integrated security even though I have set up a managed password just like I
did in XP. This only doesn't work with Vista.
"Robert L. (MS-MVP)" wrote:
> Is the Vista the member of a domain or standalone computer? Try this
> command: net use \\sqlservername /u:domainname/username. Does that work?
> Please post back with the result.
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting on
> http://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access on
> http://www.HowToNetworking.com
>
>
> "pietrzbm" <> wrote in message
> news:142253D1-46D8-49DA-AD55-...
> >I was trying to use the "Manage Network Passwords" feature to pass the
> >domain
> > credentials. This used to work fine in Windows XP. All you had to do was
> > go
> > into "Manage Network Passwords" then enter the following:
> >
> > Server: Domain Server (ServerA)
> > UserName: Domain\userName
> > Password: Password
> >
> > Then when using Windows Authentication in SQL Server Management Studio, it
> > would use these credentials to gain access to that server without actually
> > having to have the client machine be a member of the domain. I have seen
> > various posts about this issue, and it appears that it may be in how Vista
> > handles access to the token. Is there some setting(s) that need to be
> > changed? Basically, when I try to do this in Vista it only allows access
> > to
> > file shares and does not seem to allow client applications to use the
> > credentials to access domain resources like XP did.
> > "Robert L. (MS-MVP)" wrote:
> >
> >> If your credentials are not being passed to the SQL server, you will
> >> receive
> >> error code was 18452. Which feature do you use to pass credentials to
> >> access
> >> domain resources?
> >> --
> >> Bob Lin, MS-MVP, MCSE & CNE
> >> Networking, Internet, Routing, VPN Troubleshooting on
> >> http://www.ChicagoTech.net
> >> How to Setup Windows, Network, VPN & Remote Access on
> >> http://www.HowToNetworking.com
> >>
> >>
> >> "pietrzbm" <> wrote in message
> >> news:96D532EF-435E-48FB-A64A-...
> >> > In Windows XP there was a feature for managing network passwords which
> >> > allowed machines that were not members of the domain to use domain
> >> > credentials to access domain resources, which I have used to connect to
> >> > SQL
> >> > Server(s) since I am a consultant that has many clients, I do not join
> >> > my
> >> > machine to any domain. However, when I tried to use this same feature
> >> > in
> >> > Windows Vista (Ultimate) it only allowed me to connect to file share
> >> > resources, and SQL Server Analysis Services, but it did not let me
> >> > connect
> >> > to
> >> > SQL Server Database Engine service. I keep getting "Login failed for
> >> > user
> >> > (null)..." The error code was 18452. Please let me know if this is a
> >> > bug
> >> > in
> >> > Vista. I need to be able to connect to SQL Server using Windows
> >> > Authentication from a computer that does not exist on a domain and the
> >> > SQL
> >> > Server does.
> >>
>