Please bear with me as you read this description. I am trying to finish up
and productize some code that I inherited from a
contract programmer that allegedly knew what he was doing. I know that I do
n't know what I am doing.
I have an application that is written in C# for .net. It has a client porti
on, a server portion and a database back end. The
client connects to remote objects that are hosted in IIS on a server. These
objects connect the database on a 3rd system via
SQLDMO in .Net
Both the server and the SQL server systems are Windows 2003 systems.
The database is set for NT security only.
The server system is trusted for delegation. It also does impersonation.
We have a Domain Local security group (Win 2K style mixed mode Active Direct
ory) that contains users from both the AD group and a
NT 4 domain that has 2 way trust to/from the AD group.
I can access the databases on the SQL server from the client, but I am the o
nly person that can.
If someone in the NT 4 domain attempts to access, we get an error telling th
at NULL is not associated with the group.
.... Login failed for user "(null)". Reason: Not associated with secure S
QL Server connection.
If someone in the AD domain attempts to access, we get an error telling us t
hat login failed.
.... Login failed for user "domain\userid". The actual domain and userid
is listed.
I don't have any idea where this has gone wrong.
Any suggestions will be appreciated.
Thanks
---
Roy Chastain
KMSystems, Inc.Hi Roy:
The problem is not very clear.
I think we should first ping each other by IP to see if it work righ.
Then we should try to telnet each other by 1433 port.
But I guess the problem is caused by the domain or workgroup problem.
Best Wishes
Wei Ci Zhou|||You are right the problem is not very clear, because I don't know enough to
explain it correctly, however, there are some things
in my post that I though were more obvious then your response indicated.
There is connection.
1) - I can access the database
2) - The people that can not access the database are getting a response from
SQL. (Therefore connectivity)
Yes, it is a security issue, but I have no idea about how to resolve a secur
ity issue with SQL.
The database is supposed to be created with the domain group that we all bel
ong to being the owner of the database. I have not
been able to find that code in our application. I know it is there somewher
e, because the application does create the database.
Perhaps someone could tell me what to look for to find the database creation
and owner setup.
Thanks
On Fri, 26 Mar 2004 13:41:41 +0800, "Wei Ci Zhou" <weicizhou@.hotmail.com.dis
scuss> wrote:
>Hi Roy:
> The problem is not very clear.
> I think we should first ping each other by IP to see if it work righ.
> Then we should try to telnet each other by 1433 port.
> But I guess the problem is caused by the domain or workgroup problem.
>Best Wishes
>Wei Ci Zhou
>
---
Roy Chastain
KMSystems, Inc.|||Hi Roy,
As for the connectivity problem of SQL Server, there is some general steps
for us for testing.
1) ping Server_IP
2) telnet Server_IP 1433
Note that the Port 1433 is default por number fro SQL Server, You can check
the actual port number the SQL Server is using by Server Network Utility.
You can get it by check the properties of TCP/IP ( which should be enabled
protocol).
If now there is no problem of it. Then SQL Server is running properly and
you could use the Query Analyzer and ospl tools to connect from where you
need to connect the database with related credential informations. You
could also use the SQL Server Profiler to catch the connection information
from the outside. You could monitor the Audit: Login, Audit:Logout;
Sessions: ExistingConnections.
If no problem of it. Then the SQL Server is with the right configuration
for connectivity. It might be a IIS configuration problem, so, you could
ask for some information in the IIS newsgroup and our engineer there will
provide more
information on this issue.
http://msdn.microsoft.com/newsgroup...microsoft.publi
c.inetserver.iis
Hope this helps.
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Could you be so kind as to tell me how to use the SQL Server Profiler to mon
itor as you suggest.
On Mon, 29 Mar 2004 03:51:27 GMT, v-baiwei@.online.microsoft.com (Baisong Wei
[MSFT]) wrote:
>Hi Roy,
>
>As for the connectivity problem of SQL Server, there is some general steps
>for us for testing.
>1) ping Server_IP
>2) telnet Server_IP 1433
>Note that the Port 1433 is default por number fro SQL Server, You can check
> the actual port number the SQL Server is using by Server Network Utility.
>You can get it by check the properties of TCP/IP ( which should be enabled
>protocol).
>If now there is no problem of it. Then SQL Server is running properly and
>you could use the Query Analyzer and ospl tools to connect from where you
>need to connect the database with related credential informations. You
>could also use the SQL Server Profiler to catch the connection information
>from the outside. You could monitor the Audit: Login, Audit:Logout;
>Sessions: ExistingConnections.
>If no problem of it. Then the SQL Server is with the right configuration
>for connectivity. It might be a IIS configuration problem, so, you could
>ask for some information in the IIS newsgroup and our engineer there will
>provide more
>information on this issue.
>http://msdn.microsoft.com/newsgroup...ft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
---
Roy Chastain
KMSystems, Inc.|||I have been doing some network snooping. I have code that identifies all SQ
L servers on the network. It does a broadcast on UDP
1434 and it get responses from several servers including the one in question
.
I have client code that will connect to the server in question and that code
will display the list of databases on the server.
Somehow the code in the client knows to use port 1175. This works. The cli
ent can query the database and that query is submitted
on port 1175 and it works.
I installed the SQL Web Administration tool today. Needless to say it does
not connect to the server in question. It will
connect to at least one other server on my network.
On Mon, 29 Mar 2004 03:51:27 GMT, v-baiwei@.online.microsoft.com (Baisong Wei
[MSFT]) wrote:
>Hi Roy,
>
>As for the connectivity problem of SQL Server, there is some general steps
>for us for testing.
>1) ping Server_IP
>2) telnet Server_IP 1433
>Note that the Port 1433 is default por number fro SQL Server, You can check
> the actual port number the SQL Server is using by Server Network Utility.
>You can get it by check the properties of TCP/IP ( which should be enabled
>protocol).
>If now there is no problem of it. Then SQL Server is running properly and
>you could use the Query Analyzer and ospl tools to connect from where you
>need to connect the database with related credential informations. You
>could also use the SQL Server Profiler to catch the connection information
>from the outside. You could monitor the Audit: Login, Audit:Logout;
>Sessions: ExistingConnections.
>If no problem of it. Then the SQL Server is with the right configuration
>for connectivity. It might be a IIS configuration problem, so, you could
>ask for some information in the IIS newsgroup and our engineer there will
>provide more
>information on this issue.
>http://msdn.microsoft.com/newsgroup...ft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
---
Roy Chastain
KMSystems, Inc.|||Hi Roy,
As testing the connection to SQL Server, as you application will use the
specific credential information to connect to the SQL Server (windows
authentication or SQL Server authentication), you could use profiler to
catch this login information in Profiler:
When new a trace in the profiler, you could trace Audit Login and Audit
Login Failed in the Security Audit Event, and you will get all the
connection information of it.
You could refer to this article:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/?id=827422
Monitoring with SQL Profiler
http://msdn.microsoft.com/library/d...-us/adminsql/ad
_mon_perf_86ib.asp
Hope this helps
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Hi Roy,
I am reviewing your post and I provide you some links for connectivity to
SQL Server. I wonder if it is helpful or if you still have questions about
it. For this question, the first step we do is check that the credentials
used to connect the SQL server is valid. ( information are valid as SQL
logins). If yes, then the problem might be related to IIS configuration or
some Windows security policies. You could ask for help from:
http://msdn.microsoft.com/newsgroup...microsoft.publi
c.inetserver.iis
Hope this helps
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||I gave up and opened a support incident yesterday. After 4 hrs on the phone
we thought it was resolved, but we were wrong.
On Thu, 01 Apr 2004 01:28:07 GMT, v-baiwei@.online.microsoft.com (Baisong Wei
[MSFT]) wrote:
>Hi Roy,
>I am reviewing your post and I provide you some links for connectivity to
>SQL Server. I wonder if it is helpful or if you still have questions about
>it. For this question, the first step we do is check that the credentials
>used to connect the SQL server is valid. ( information are valid as SQL
>logins). If yes, then the problem might be related to IIS configuration or
>some Windows security policies. You could ask for help from:
>http://msdn.microsoft.com/newsgroup...ft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
---
Roy Chastain
KMSystems, Inc.
