SIMS communication with SQL server

[dhicks]

Hello All,

I'm confused about how, exactly, SIMS operates, and I just want to make sure I've got the right idea and avoid any potential security holes.

So, I understand that SIMS is a client-server based application, with a Windows-based GUI application that talks to a SIMS server. This SIMS server stores its data inside an MS SQL server. As far as I can figure out, the SQL server doesn't have to accept connections off anything except the SIMS server. If the SQL server and SIMS server are on the same machine, the SQL server doesn't even need to accept any network connections whatsoever, it just needs to be able to talk to SIMS via ODBC or whatever.

Is the above correct? Am I assuming wrong here - does the SIMS client, for some reason, write directly to the SQL server? If the SQL server is needed to be available to accept connections from places other than the SIMS server, is there some way (perhaps using a VPN in some way?) to reduce any security risk?

--
David Hicks

[russdev]

I will ask my capita friends...

Russell

[Ric_]

@dhicks: Run WireShark on a machine running SIMS and see what it does

[sahmeepee]

There is no SIMS server application as such - when people talk about their SIMS server they're basically talking about a SQL server hosting their SIMS database and support files.

SIMS.net also has a document management server which complicates things slightly. That does run as a service, but needn't be on the same server as your SQL Server.

My understanding is that for most SIMS use, the SIMS.net client is writing pretty much directly to SQLServer.

[superfletch]

As far as I can figure out, the SQL server doesn't have to accept connections off anything except the SIMS server. If the SQL server and SIMS server are on the same machine, the SQL server doesn't even need to accept any network connections whatsoever, it just needs to be able to talk to SIMS via ODBC or whatever.

David Hicks

I'm with you scary avatar dude from Greater Manchester, 'cept one detail!!

The SIMS Server Machine (Not SQLServer) may need to accept network connections to provide a mapped drive to anyone running the old launcher modules.

This might also be necessary if you are delivering SIMS .net's connect.ini via a mapped drive for any reason. Apart from that I think the SQL Server authenticates everything else via the logins listed in the SIMS.mdf / Master.mdf,

DocServer certainly makes things even more fun, I'd love to get a crystal explanation on it....

[DMcCoy]

Old launcher, Nova and clients checking for updates will need file access in fact.

[sahmeepee]

Old launcher, Nova and clients checking for updates will need file access in fact.

Yes superfletch/dmccoy, I wasn't very clear... sql ports and smb share ports are both required. I'm not sure how the docstorage files are delivered exactly as I believe they are encrypted and not with standard windows/ntfs encryption, so they may not be served up directly over smb.

[dhicks]

> I think the SQL Server authenticates everything else via the logins listed
> in the SIMS.mdf / Master.mdf,

Ah, I was hoping it did something like that - SQL Server not letting anything connect to it except explicitly allowed machines. Hmm, looks like some point over the winter holiday I'd better double-check our SIMS server and see what, exactly, can connect to what.

--
David Hicks

[russdev]

Well here goes direct from horses mouth as to say...


SIMS .net is a 3 tier application.
It has a database which sits in a Microsoft SQL Server.
It has a Business Layer containing the business logic which sits in
DLL's.
It has a User Interface Layer (the SIMS application that you interact
with as a user).
Both the Business and User Interface layers sit on a Client machine and
reside in the SIMS .net directory.
When SIMS .net is run, a connection is made to the SQL Server from the
client.
The SIMS file server is not used by SIMS .net applications for
connecting to the SQL Server.

Hope that helps

Russell

[dhicks]

[russdev wrote:]
> SIMS .net is a 3 tier application.

Thanks very much for the explanation, that makes things a bit clearer.

--
David Hicks