SQL security over the LAN
-
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
-
The AD authentication process is secure... Kerberos and all that which MS SQL server can use. After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.
-
@Obsolesce said in SQL security over the LAN:
The AD authentication process is secure... Kerberos and all that which MS SQL server can use. After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.
Not if you don't use one.
-
@tonyshowoff said in SQL security over the LAN:
@Obsolesce said in SQL security over the LAN:
The AD authentication process is secure... Kerberos and all that which MS SQL server can use. After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.
Not if you don't use one.
One of what? AD? MS SQL? Authenticated app?
I didn't read all 50 replies yet.
-
After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.
Not if you don't use one of those. Having the option doesn't mean it's setup automatically, which I imagine you know, but I'm saying it rhetorically to point out the unfortunate situation.
-
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
-
I think a lot of the aspects of this application are catering to customers that may only use SQL express. i've been looking, but I have not found yet, if express allows for encrypted connections. I have read that some of the encryption methods such as TDE are not in express though, and I wonder if they (the application developers) do what they do because they want to also let the application be used by express. I get the feeling that probably about half of their customers use SQL express and not the full meal deal.
I got a reply from their support this morning basically telling me that "security was solely my responsibility" and I am just SOL. It's about what I expected.
-
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user. This isn't really as big of an issue today as the licensing has become much more free, but many years ago there was a much harder limit on user connection count and how many different users could be connected and it was limited to version of both SQL Server and sometimes even the OS, and the licensing that, that implies. My guess is they may be having their application work with a newer version of SQL Server but I doubt they're using any features not also available on SQL Server 7 from 1998... and that isn't meant to be a joke, from what I've seen that tends to be the standard.
-
@tonyshowoff said in SQL security over the LAN:
My guess is they may be having their application work with a newer version of SQL Server but I doubt they're using any features not also available on SQL Server 7 from 1998...
I fully expect this to be correct. The minimum requirements specify SQL 2012 and newer, but I would bet money they it would run on older versions too, at least to 2005.
-
@Donahue said in SQL security over the LAN:
I think a lot of the aspects of this application are catering to customers that may only use SQL express. i've been looking, but I have not found yet, if express allows for encrypted connections. I have read that some of the encryption methods such as TDE are not in express though, and I wonder if they (the application developers) do what they do because they want to also let the application be used by express. I get the feeling that probably about half of their customers use SQL express and not the full meal deal.
I got a reply from their support this morning basically telling me that "security was solely my responsibility" and I am just SOL. It's about what I expected.
Given the extreme limits of Express, that feels unlikely.
-
@scottalanmiller said in SQL security over the LAN:
@Donahue said in SQL security over the LAN:
I think a lot of the aspects of this application are catering to customers that may only use SQL express. i've been looking, but I have not found yet, if express allows for encrypted connections. I have read that some of the encryption methods such as TDE are not in express though, and I wonder if they (the application developers) do what they do because they want to also let the application be used by express. I get the feeling that probably about half of their customers use SQL express and not the full meal deal.
I got a reply from their support this morning basically telling me that "security was solely my responsibility" and I am just SOL. It's about what I expected.
Given the extreme limits of Express, that feels unlikely.
can you elaborate? what part felt unlikely?
-
SQL Express supports the transport encryption method I gave instructions for.
-
@tonyshowoff said in SQL security over the LAN:
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user.
I can't speak to there possibility being a point in time when this was true, but it is not true now. You have to get CALs for each actual person, even if they themselves are not in direct communication with the MS SQL Server
-
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user.
I can't speak to there possibility being a point in time when this was true, but it is not true now. You have to get CALs for each actual person, even if they themselves are not in direct communication with the MS SQL Server
I agree, CAL's are about a legal obligation, but they don't actually affect the functionality of SQL. If we had an application server that was the only thing that directly accessed the database, we would still be obligated to have CAL's that cover the use of the application. In our case however, we are licensed for core on SQL and do not use CAL's.
-
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user.
I can't speak to there possibility being a point in time when this was true, but it is not true now. You have to get CALs for each actual person, even if they themselves are not in direct communication with the MS SQL Server
I am aware but it isn't relevant, that's just why people do it in the ERP world in addition to having license control over their own client application. There's no inherent transparent encryption with a third party library connecting to SQL Server though. It should be straight forward from the development perspective considering they must be using a fairly modern one to be using SQL over SMB2, but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
-
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
-
@Donahue said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
In general, actual software developers have no idea what IT is. They shouldn't. Otherwise they would be in IT. A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
-
@JaredBusch said in SQL security over the LAN:
A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
LOL
-
@JaredBusch said in SQL security over the LAN:
@Donahue said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
In general, actual software developers have no idea what IT is. They shouldn't. Otherwise they would be in IT. A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
Actually you're describing how bad software is written, in my experience of 22ish years programming professionally, the programmers who know about IT and hardware do the best over people who know neither. I'm not an IT person, and yet I get hired to do things a lot of IT people couldn't figure out, largely because they were inexperienced, and it's not my job, I just understand networks, domains, and so forth enough to get by but it also had helped me write good client-server programs, know how to authenticate and deal with AD, and so on. And I'm not the only one, a lot of good programmers do this work a lot, either as favours or between projects.
Just because a development company has an IT person doesn't mean it's because the programmers need them because they don't understand IT, it's usually because the programmers are too busy to deal with IT problems. Good programming talent is incredibly hard to find, not necessarily because it's rare, but because the market is overflooded with incompetence, just like IT is, especially with outsourcing to the third world and young people who think they know everything because they've changed video cards or configured printers (this applies to IT and programming). Just look at Spiceworks.
If you want good programming with concepts of how security works such as GPO, and good network design (such as IRC networks, MySQL clusters, etc), and an understanding of load balancing, how infrastructure works and how it relates to your programming, how data travels over networks and why encryption matters, etc you need a solid IT understanding. You can't just try to find some IT person who happens to know what you need to know so you can write your programs, then try to explain to them any issues or design questions you have with your project only for them to have no idea how to program. You need to be able to answer these things yourself and all good programmers are very good IT people, some of us just can't crimp rj45 connectors, I can't see those tiny ass wires!
I have known programmers who don't know the first thing about IT, they were all terrible, wrote terrible software, and shrugged at essentially all security concepts. The descriptions in posts above about the incompetence of companies not understanding network encryption (that ERP company) and not understanding the basics of network latency (Eaglesoft) and not understanding why a program needing local admin rights is stupid (Eaglesoft) are not virtues to suggest they should fall on some IT guy to solve the problem rather than the programmer know what he's doing.
Anyway, it's like suggesting IT people are best that don't know scripting because then they'd be in programming. While really experienced IT people will certainly know things even good programmers don't, they do have a hell of a lot of knowledge overlap, it comes with the territory.
-
@tonyshowoff While it would be great if everyone knew this, that is unrealistic.
The best software comes from a team with software development done by programmers and someone form IT to apply the needed skills to the development process.
All the examples above are absolutely not done this way. That is the problem.
For a small software house, they won't have the overhead for that separate person, so yeah, then they need someone like you to wear both hats.
