| Groups | Blog | Home |
sql server clients : Why do I have to enable File and Printer sharing to connect through the XP firewall?
Hello,
I have a client app that connects to a remote instance of SQL Server 2005 Express. The client uses the SQL Browser to locate available SQL instances. The SQL instance has Shared Memory, Named Pipes, and TCP/IP turned on, and TCP/IP is configured to use a static port (5721). The firewall on the SQL machine has the following exceptions: 1434 UDP (SQL Browser) and 5721 TCP (SQL Server). I have no problems locating the SQL instance using Management Studio or with the SQL Browser in my client. However, I cannot connect either with Management Studio or my client unless I also turn on the "File and Printer Sharing" exception in the firewall. The BOL says that File and Printer Sharing is required if using Named Pipes through the firewall, but I don't understand where Named Pipes are being used when I try to connect. In my client (C# app) I'm using the SQLConnection class with a very vanilla connection string; the only addition the the port number of the SQL instance. Is SQLConnection using Named Pipes behind the scenes? Can someone explain what's going on here and suggest how I might get around having to turn File and Printer Sharing on? Thanks! Keith P.S. Everything works fine if the firewall is turned off.
"Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... [quoted text, click to view] > Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe on > the client to verify that TCP/IP (sockets) is selected higher than Named > Pipes. Sockets shouldn't require anything else but the TCP port. Unless > you are trying a Windows logins, of course. Also, since you specify the > port in your connection string, you shouldn't need the SQL Server browser > service on the server (unless it is needed for other purposes, of course). > Tibor, Thanks for the reply. Could you clarify what you mean when you said "Unless you are trying a Windows logins, of course." Are you saying that Windows Authentication/Mixed Mode uses Named Pipes to communicate with the domain controller? I was not aware of that. I am using mixed mode authentication. Thanks! Keith
"Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message news:E402B142-E357-4124-A897-43E4D1747848@microsoft.com... [quoted text, click to view] >> I was not aware of that. I am using mixed mode authentication. > > That is a server-side setting. What matters is how the client tries to > connect. IS the client connecting using a Windows account or using a SQL > Server account? I assume Windows account since I'm not passing any user/pw information in the connection string. [quoted text, click to view] > For Windows authentication, SQL Server need to enumerate the SIDs for the > account you pass with Windows (DC). The client should be able to connect > using TCP/IP Sockets, assuming the client user has logged into the AD in > the first place. If not, I assume that some AD validation is attempted > when the login to SQL Server is performed. (But I admit that AD is far > from my expertise...) The user(s) are already members of the domain. In this particular instance, the user is me and I'm a domain/olap admin. BTW I looked for "cliconfig.exe" so I could check the client-side configuration and didn't find it anywhere on my machines. What package/app installs it? [quoted text, click to view] > -- > Tibor Karaszi, SQL Server MVP > http://www.karaszi.com/sqlserver/default.asp > http://sqlblog.com/blogs/tibor_karaszi > > > "Keith" <keith@alh.com> wrote in message > news:O782RHJ9HHA.2004@TK2MSFTNGP06.phx.gbl... >> >> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote >> in message news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... >>> Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe >>> on the client to verify that TCP/IP (sockets) is selected higher than >>> Named Pipes. Sockets shouldn't require anything else but the TCP port. >>> Unless you are trying a Windows logins, of course. Also, since you >>> specify the port in your connection string, you shouldn't need the SQL >>> Server browser service on the server (unless it is needed for other >>> purposes, of course). >>> >> >> Tibor, >> >> Thanks for the reply. Could you clarify what you mean when you said >> "Unless you are trying a Windows logins, of course." Are you saying that >> Windows Authentication/Mixed Mode uses Named Pipes to communicate with >> the domain controller? I was not aware of that. I am using mixed mode >> authentication. >> >> Thanks! >> >> Keith >> >
Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe on the client to verify that
TCP/IP (sockets) is selected higher than Named Pipes. Sockets shouldn't require anything else but the TCP port. Unless you are trying a Windows logins, of course. Also, since you specify the port in your connection string, you shouldn't need the SQL Server browser service on the server (unless it is needed for other purposes, of course). -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi [quoted text, click to view] "Keith" <keith@alh.com> wrote in message news:ehaTWA$8HHA.3940@TK2MSFTNGP05.phx.gbl...
> Hello, > > I have a client app that connects to a remote instance of SQL Server 2005 Express. The client > uses the SQL Browser to locate available SQL instances. > > The SQL instance has Shared Memory, Named Pipes, and TCP/IP turned on, and TCP/IP is configured to > use a static port (5721). > > The firewall on the SQL machine has the following exceptions: 1434 UDP (SQL Browser) and 5721 TCP > (SQL Server). > > I have no problems locating the SQL instance using Management Studio or with the SQL Browser in my > client. However, I cannot connect either with Management Studio or my client unless I also turn > on the "File and Printer Sharing" exception in the firewall. The BOL says that File and Printer > Sharing is required if using Named Pipes through the firewall, but I don't understand where Named > Pipes are being used when I try to connect. > > In my client (C# app) I'm using the SQLConnection class with a very vanilla connection string; the > only addition the the port number of the SQL instance. > > Is SQLConnection using Named Pipes behind the scenes? Can someone explain what's going on here > and suggest how I might get around having to turn File and Printer Sharing on? > > Thanks! > > Keith > > P.S. Everything works fine if the firewall is turned off. >
[quoted text, click to view]
> I was not aware of that. I am using mixed mode authentication. That is a server-side setting. What matters is how the client tries to connect. IS the client connecting using a Windows account or using a SQL Server account? For Windows authentication, SQL Server need to enumerate the SIDs for the account you pass with Windows (DC). The client should be able to connect using TCP/IP Sockets, assuming the client user has logged into the AD in the first place. If not, I assume that some AD validation is attempted when the login to SQL Server is performed. (But I admit that AD is far from my expertise...) -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi [quoted text, click to view] "Keith" <keith@alh.com> wrote in message news:O782RHJ9HHA.2004@TK2MSFTNGP06.phx.gbl...
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message > news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... >> Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe on the client to verify >> that TCP/IP (sockets) is selected higher than Named Pipes. Sockets shouldn't require anything >> else but the TCP port. Unless you are trying a Windows logins, of course. Also, since you specify >> the port in your connection string, you shouldn't need the SQL Server browser service on the >> server (unless it is needed for other purposes, of course). >> > > Tibor, > > Thanks for the reply. Could you clarify what you mean when you said "Unless you are trying a > Windows logins, of course." Are you saying that Windows Authentication/Mixed Mode uses Named > Pipes to communicate with the domain controller? I was not aware of that. I am using mixed mode > authentication. > > Thanks! > > Keith >
[quoted text, click to view]
> I assume Windows account since I'm not passing any user/pw information in > the connection string. Then I assume you say something like "Integrated security = true", or "trusted connection". [quoted text, click to view] > The user(s) are already members of the domain. In this particular instance, > the user is me and I'm a domain/olap admin. If you have logged on to the domain, then ti sould work fine over the TCP/IP netlib. [quoted text, click to view] > BTW I looked for "cliconfig.exe" so I could check the client-side > configuration and didn't find it anywhere on my machines. What package/app > installs it? It is cliconfg.exe, not cliconfig.exe. It is part of Windows. -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi [quoted text, click to view] "Keith" <keith@alh.com> wrote in message news:e7Bo6gM9HHA.4784@TK2MSFTNGP05.phx.gbl...
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in > message news:E402B142-E357-4124-A897-43E4D1747848@microsoft.com... >>> I was not aware of that. I am using mixed mode authentication. >> >> That is a server-side setting. What matters is how the client tries to >> connect. IS the client connecting using a Windows account or using a SQL >> Server account? > > I assume Windows account since I'm not passing any user/pw information in > the connection string. > >> For Windows authentication, SQL Server need to enumerate the SIDs for the >> account you pass with Windows (DC). The client should be able to connect >> using TCP/IP Sockets, assuming the client user has logged into the AD in >> the first place. If not, I assume that some AD validation is attempted >> when the login to SQL Server is performed. (But I admit that AD is far >> from my expertise...) > > The user(s) are already members of the domain. In this particular instance, > the user is me and I'm a domain/olap admin. > > BTW I looked for "cliconfig.exe" so I could check the client-side > configuration and didn't find it anywhere on my machines. What package/app > installs it? > >> -- >> Tibor Karaszi, SQL Server MVP >> http://www.karaszi.com/sqlserver/default.asp >> http://sqlblog.com/blogs/tibor_karaszi >> >> >> "Keith" <keith@alh.com> wrote in message >> news:O782RHJ9HHA.2004@TK2MSFTNGP06.phx.gbl... >>> >>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote >>> in message news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... >>>> Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe >>>> on the client to verify that TCP/IP (sockets) is selected higher than >>>> Named Pipes. Sockets shouldn't require anything else but the TCP port. >>>> Unless you are trying a Windows logins, of course. Also, since you >>>> specify the port in your connection string, you shouldn't need the SQL >>>> Server browser service on the server (unless it is needed for other >>>> purposes, of course). >>>> >>> >>> Tibor, >>> >>> Thanks for the reply. Could you clarify what you mean when you said >>> "Unless you are trying a Windows logins, of course." Are you saying that >>> Windows Authentication/Mixed Mode uses Named Pipes to communicate with >>> the domain controller? I was not aware of that. I am using mixed mode >>> authentication. >>> >>> Thanks! >>> >>> Keith >>> >> >
"Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message news:EBDE3F42-3AF0-4A34-8EB3-C67C8D771FE9@microsoft.com... [quoted text, click to view] >> I assume Windows account since I'm not passing any user/pw information in >> the connection string. > > Then I assume you say something like "Integrated security = true", or > "trusted connection". Yes, trusted connection. [quoted text, click to view] > >> The user(s) are already members of the domain. In this particular >> instance, the user is me and I'm a domain/olap admin. > > If you have logged on to the domain, then ti sould work fine over the > TCP/IP netlib. > > >> BTW I looked for "cliconfig.exe" so I could check the client-side >> configuration and didn't find it anywhere on my machines. What >> package/app installs it? > > It is cliconfg.exe, not cliconfig.exe. It is part of Windows. My apologies, now I see it. I verified that TCP is before Named Pipes, and even disabled Named Pipes but I still can't connect using either my client app or Management Studio. (error 26 : Error location server/instance specified) after easily locating it with the browser. In my client I even tried to force a protocol in the collection string using tcp:<server/instance> and also Network Library=DBMSSOCN but with no luck. I'm in the process of trying all these permutations on a clean(er) machine, but in the mean time do yo have anymore suggestions? Keith [quoted text, click to view] > --
> Tibor Karaszi, SQL Server MVP > http://www.karaszi.com/sqlserver/default.asp > http://sqlblog.com/blogs/tibor_karaszi > > > "Keith" <keith@alh.com> wrote in message > news:e7Bo6gM9HHA.4784@TK2MSFTNGP05.phx.gbl... >> >> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote >> in message news:E402B142-E357-4124-A897-43E4D1747848@microsoft.com... >>>> I was not aware of that. I am using mixed mode authentication. >>> >>> That is a server-side setting. What matters is how the client tries to >>> connect. IS the client connecting using a Windows account or using a SQL >>> Server account? >> >> I assume Windows account since I'm not passing any user/pw information in >> the connection string. >> >>> For Windows authentication, SQL Server need to enumerate the SIDs for >>> the account you pass with Windows (DC). The client should be able to >>> connect using TCP/IP Sockets, assuming the client user has logged into >>> the AD in the first place. If not, I assume that some AD validation is >>> attempted when the login to SQL Server is performed. (But I admit that >>> AD is far from my expertise...) >> >> The user(s) are already members of the domain. In this particular >> instance, the user is me and I'm a domain/olap admin. >> >> BTW I looked for "cliconfig.exe" so I could check the client-side >> configuration and didn't find it anywhere on my machines. What >> package/app installs it? >> >>> -- >>> Tibor Karaszi, SQL Server MVP >>> http://www.karaszi.com/sqlserver/default.asp >>> http://sqlblog.com/blogs/tibor_karaszi >>> >>> >>> "Keith" <keith@alh.com> wrote in message >>> news:O782RHJ9HHA.2004@TK2MSFTNGP06.phx.gbl... >>>> >>>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> >>>> wrote in message >>>> news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... >>>>> Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe >>>>> on the client to verify that TCP/IP (sockets) is selected higher than >>>>> Named Pipes. Sockets shouldn't require anything else but the TCP port. >>>>> Unless you are trying a Windows logins, of course. Also, since you >>>>> specify the port in your connection string, you shouldn't need the SQL >>>>> Server browser service on the server (unless it is needed for other >>>>> purposes, of course). >>>>> >>>> >>>> Tibor, >>>> >>>> Thanks for the reply. Could you clarify what you mean when you said >>>> "Unless you are trying a Windows logins, of course." Are you saying >>>> that Windows Authentication/Mixed Mode uses Named Pipes to communicate >>>> with the domain controller? I was not aware of that. I am using mixed >>>> mode authentication. >>>> >>>> Thanks! >>>> >>>> Keith >>>> >>> >>
I'm out of ideas, I'm afraid. Sounds to me more like a Windows/network/security issue to me, which
is a bit out of my expertise.-- -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi [quoted text, click to view] "Keith" <keith@alh.com> wrote in message news:u1o5Qai9HHA.1188@TK2MSFTNGP04.phx.gbl...
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message > news:EBDE3F42-3AF0-4A34-8EB3-C67C8D771FE9@microsoft.com... >>> I assume Windows account since I'm not passing any user/pw information in the connection string. >> >> Then I assume you say something like "Integrated security = true", or "trusted connection". > > Yes, trusted connection. > >> >>> The user(s) are already members of the domain. In this particular instance, the user is me and >>> I'm a domain/olap admin. >> >> If you have logged on to the domain, then ti sould work fine over the TCP/IP netlib. >> >> >>> BTW I looked for "cliconfig.exe" so I could check the client-side configuration and didn't find >>> it anywhere on my machines. What package/app installs it? >> >> It is cliconfg.exe, not cliconfig.exe. It is part of Windows. > > My apologies, now I see it. I verified that TCP is before Named Pipes, and even disabled Named > Pipes but > I still can't connect using either my client app or Management Studio. (error 26 : Error location > server/instance specified) after easily locating it with the browser. > > In my client I even tried to force a protocol in the collection string using tcp:<server/instance> > and also Network Library=DBMSSOCN but with no luck. > > I'm in the process of trying all these permutations on a clean(er) machine, but in the mean time > do yo have anymore suggestions? > > Keith > >> -- >> Tibor Karaszi, SQL Server MVP >> http://www.karaszi.com/sqlserver/default.asp >> http://sqlblog.com/blogs/tibor_karaszi >> >> >> "Keith" <keith@alh.com> wrote in message news:e7Bo6gM9HHA.4784@TK2MSFTNGP05.phx.gbl... >>> >>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message >>> news:E402B142-E357-4124-A897-43E4D1747848@microsoft.com... >>>>> I was not aware of that. I am using mixed mode authentication. >>>> >>>> That is a server-side setting. What matters is how the client tries to connect. IS the client >>>> connecting using a Windows account or using a SQL Server account? >>> >>> I assume Windows account since I'm not passing any user/pw information in the connection string. >>> >>>> For Windows authentication, SQL Server need to enumerate the SIDs for the account you pass with >>>> Windows (DC). The client should be able to connect using TCP/IP Sockets, assuming the client >>>> user has logged into the AD in the first place. If not, I assume that some AD validation is >>>> attempted when the login to SQL Server is performed. (But I admit that AD is far from my >>>> expertise...) >>> >>> The user(s) are already members of the domain. In this particular instance, the user is me and >>> I'm a domain/olap admin. >>> >>> BTW I looked for "cliconfig.exe" so I could check the client-side configuration and didn't find >>> it anywhere on my machines. What package/app installs it? >>> >>>> -- >>>> Tibor Karaszi, SQL Server MVP >>>> http://www.karaszi.com/sqlserver/default.asp >>>> http://sqlblog.com/blogs/tibor_karaszi >>>> >>>> >>>> "Keith" <keith@alh.com> wrote in message news:O782RHJ9HHA.2004@TK2MSFTNGP06.phx.gbl... >>>>> >>>>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message >>>>> news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33@microsoft.com... >>>>>> Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe on the client to >>>>>> verify that TCP/IP (sockets) is selected higher than Named Pipes. Sockets shouldn't require >>>>>> anything else but the TCP port. Unless you are trying a Windows logins, of course. Also, >>>>>> since you specify the port in your connection string, you shouldn't need the SQL Server >>>>>> browser service on the server (unless it is needed for other purposes, of course). >>>>>> >>>>> >>>>> Tibor, >>>>> >>>>> Thanks for the reply. Could you clarify what you mean when you said "Unless you are trying a >>>>> Windows logins, of course." Are you saying that Windows Authentication/Mixed Mode uses Named >>>>> Pipes to communicate with the domain controller? I was not aware of that. I am using mixed >>>>> mode authentication. >>>>> >>>>> Thanks! >>>>> >>>>> Keith >>>>> >>>> >>> >
Don't see what you're looking for? Try a search.
|
March 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |