Not A Trusted Connection

I set up my SQLExpress server using Windows Authentication only. Now when I
try to create a user account using Username and Password, the connection
returns the error: Not a trusted connection. Does this have something to do
with my previous server setup or is there a general setting somewhere I need
to change?
Regards,
Fred Chateau
http://hotelmotelnow.com
Never mind... I found the setting.
Regards,
Fred Chateau
http://hotelmotelnow.com
"Fred Chateau" <webmaster@.hotelmotelnow.com> wrote in message
news:u323BNenHHA.588@.TK2MSFTNGP06.phx.gbl...
>I set up my SQLExpress server using Windows Authentication only. Now when I
>try to create a user account using Username and Password, the connection
>returns the error: Not a trusted connection. Does this have something to do
>with my previous server setup or is there a general setting somewhere I
>need to change?
> --
> Regards,
> Fred Chateau
> http://hotelmotelnow.com
>

Not A Trusted Connection

I set up my SQLExpress server using Windows Authentication only. Now when I
try to create a user account using Username and Password, the connection
returns the error: Not a trusted connection. Does this have something to do
with my previous server setup or is there a general setting somewhere I need
to change?
Regards,
Fred Chateau
http://hotelmotelnow.comNever mind... I found the setting.
Regards,
Fred Chateau
http://hotelmotelnow.com
"Fred Chateau" <webmaster@.hotelmotelnow.com> wrote in message
news:u323BNenHHA.588@.TK2MSFTNGP06.phx.gbl...
>I set up my SQLExpress server using Windows Authentication only. Now when I
>try to create a user account using Username and Password, the connection
>returns the error: Not a trusted connection. Does this have something to do
>with my previous server setup or is there a general setting somewhere I
>need to change?
> --
> Regards,
> Fred Chateau
> http://hotelmotelnow.com
>

No Windows, Only SQL Server Authentication

Greetings,
I am unable to log onto the MS SQL Server 2000 using my Windows Login name
and Password from the MS command prompt program locally on a new test
installation Windows Enterprise Server 2003 system. However, if I use an
SQL Server Login and Password, it works every time. The command string I am
using is:
"osql.exe -S (local) -U login_name -P password"
When successful (SQL Authentication), an SQL command prompt is returned.
When unsuccessful (Windows Authentication), the following message is
received:
"Login failed for user login_name"
The SQL Server 2000 installation is enabled for both Windows and SQL
authentication and has been updated to the latest service packs.
The installation is a new test set up to experiment with Web Services using
MS SQL Server. The original problem was the installation of the
"wscrRecordStore" demonstration data base from the book, Programming
Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem was
reduced to the simple command line issue above in order to troubleshoot it.
Since I am also the Windows and SQL Server system administrator, I have
tried a wide variety of different login strategies. Only users set up with
SQL Authentication seem to be able to access the SQL Server programatically.
What's the problem? This seems to be a straight forward but stubborn
failure.
Richard Scott
Critical Connections, Inc.To establish a Windows authenticated connection from OSQL, you need to
specify the -E parameter instead of -U and -P. This will use the account of
the currently logged in user. For example:
OSQL -S (local) -E

> Only users set up with SQL Authentication seem to be able to access the
SQL Server programatically.
Your connection string needs to specify the type of authentication desired.
Assuming you are using SqlClient:
Windows authentication:
Data Source=MyServer;Integrated Security=SSPI;Initial
Catalog=MyDatabase
SQL Server authentication:
Data Source=MyServer;User ID=MyLogin;Password=MyPassword;Initial
Catalog=MyDatabase
Also, see the article below for additional information on establishing a
trusted connection from ASP.NET:
http://support.microsoft.com/defaul...989&Product=sql
Hope this helps.
Dan Guzman
SQL Server MVP
"Richard Scott" <rtscott@.pacbell.net> wrote in message
news:6XL6c.12481$zh1.7776@.newssvr27.news.prodigy.com...
> Greetings,
> I am unable to log onto the MS SQL Server 2000 using my Windows Login name
> and Password from the MS command prompt program locally on a new test
> installation Windows Enterprise Server 2003 system. However, if I use an
> SQL Server Login and Password, it works every time. The command string I
am
> using is:
> "osql.exe -S (local) -U login_name -P password"
> When successful (SQL Authentication), an SQL command prompt is returned.
> When unsuccessful (Windows Authentication), the following message is
> received:
> "Login failed for user login_name"
> The SQL Server 2000 installation is enabled for both Windows and SQL
> authentication and has been updated to the latest service packs.
> The installation is a new test set up to experiment with Web Services
using
> MS SQL Server. The original problem was the installation of the
> "wscrRecordStore" demonstration data base from the book, Programming
> Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem
was
> reduced to the simple command line issue above in order to troubleshoot
it.
> Since I am also the Windows and SQL Server system administrator, I have
> tried a wide variety of different login strategies. Only users set up
with
> SQL Authentication seem to be able to access the SQL Server
programatically.
> What's the problem? This seems to be a straight forward but stubborn
> failure.
> Richard Scott
> Critical Connections, Inc.
>|||Not sure if this applies to you, but vefiry that the user who is attempting
to connect actually has a login established in SQL Server. You can do this
by expanding the Security folder in Enterprise Manager and looking at the
Logins.
Rand
This posting is provided "as is" with no warranties and confers no rights.

No support for SQL Server Authentication and SSIS !!!!

Hi

I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.

Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.

Thanks

I have no problem with SSIS and SQL-Server-Authentification.|||

I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.

I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.

|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||

This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.

This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)

Anyone find a way around this?

Joe.

|||

I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.

I also have problems with restricted VPN access with locked down ports at the client.

Thanks

|||

I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!

I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).

The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.

Thanks in advance for any help / suggestions / comments.

|||

If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.

-Jamie

|||

Aranda wrote:

The bigger problem is now that the clients can never run the SSIS package remotely.

SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.

The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.

What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.

|||

I just came across this.

I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?

No support for SQL Server Authentication and SSIS !!!!

Hi

I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.

Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.

Thanks

I have no problem with SSIS and SQL-Server-Authentification.|||

I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.

I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.

|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||

This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.

This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)

Anyone find a way around this?

Joe.

|||

I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.

I also have problems with restricted VPN access with locked down ports at the client.

Thanks

|||

I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!

I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).

The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.

Thanks in advance for any help / suggestions / comments.

|||

If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.

-Jamie

|||

Aranda wrote:

The bigger problem is now that the clients can never run the SSIS package remotely.

SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.

The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.

What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.

|||

I just came across this.

I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?

No support for SQL Server Authentication and SSIS !!!!

Hi

I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.

Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.

Thanks

I have no problem with SSIS and SQL-Server-Authentification.|||

I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.

I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.

|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||

This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.

This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)

Anyone find a way around this?

Joe.

|||

I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.

I also have problems with restricted VPN access with locked down ports at the client.

Thanks

|||

I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!

I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).

The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.

Thanks in advance for any help / suggestions / comments.

|||

If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.

-Jamie

|||

Aranda wrote:

The bigger problem is now that the clients can never run the SSIS package remotely.

SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.

The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.

What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.

|||

I just came across this.

I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?