There are two AD accounts, admin1 and admin2. Both are logged in to identical machines, both open SQL Server Management Studio and log in as the same SQL user to the same SQL server (using SQL Server Authentication, NOT using Integrated Security), and both run an identical query: "SELECT * FROM View1". However, admin1 receives many results (the correct result set), whereas admin2 receives an empty result set. This happens on every computer in the domain, regardless of windows version, wired/wireless connection, etc.
Why is this happening? Shouldn't SSMS be Windows account agnostic when using SQL Server Authentication? Any help would be appreciated.
The issue I had was a result of Microsoft Dynamics CRM, not SQL Server itself. I was using Filtered views, which return zero results to any user not using Windows authentication. I am not sure how I got the results I mentioned above, but trying again another day, I was never able to get results with SQL authentication, no matter what Windows account I was using. Likewise, I was always able to get results when logged in with Windows authentication.
You can either use the raw tables or hack the underlying view framework by inserting records manually that show the domainname as your SQL Server Authentication login id and granting not the CRMReaderRole but the standard DQL Role. Take a peek at the wonderful fn_FindUserGuid function which looks up the SystemGuid which the views all inner join to. Just fabricate this record and a few others and your good. If you reverse engineer their system you will see there is a way to trick the system.
Its essentially just the SystemUserBase, SystemUserPrincipals, UserSettingsBase.
Obviously this is not Microsoft recommended. ¯(°_°)/¯ But when you need an ODBC connection on a shared server which provides generic reports to many users outside of the wonderful CRM world you need to do this. You will NOT find another way outside of replicating data to another database but of course keep in mind dynamics is wonderfully dynamic and changes often. Good luck syncronizing environments.
In my opinion this system was obviously designed this way to sway users towards Microsoft products. Not saying I wouldn't do the same if I owned Microsoft. When you're forced to hack your forced to hack.
Related
I've heard it said many times that the Windows Authentication is preferred over SQL Server authentication when it comes to securing SQL Server, however, this has always struck me as counterintuitive since if a user's Windows Authentication requires them to be able to modify tables, then there's no way to prevent this activity should they log in using SSMS - bypassing the application logic.
I've used server triggers in the past to prevent this but I've also had a couple scenarios where this left us unable to log on to the SQL Server. I also get that many people would argue that, for this reason, all updates to the database should be done via stored procedures - which isn't an option for us since many of our applications are COTS.
How have others handled this? Am I the only one who sees this as a problem?
I'm currently creating an SQL database that will eventually be accessed by web applications, both mobile and desktop platforms.
Setting up the SQL database is easy.
What I'm currently having trouble with is how I'm going to allow clients to access to information in the database without having direct access to the database, for security purposes.
For example, let's say I have a list of employees, and I'm creating employee profiles for a mobile application. I would like for the mobile application to be able to use a function such as get(employee_name), which will call the database and retrieve the information about the employee in the form of a JSON.
How would I go about doing this?
To see a very nice solution on using JSON on sql server tables please look at Phil Factors article Consuming JSON Strings in SQL Server at:
https://www.simple-talk.com/sql/t-sql-programming/consuming-json-strings-in-sql-server/
I have to execute some queries in Firebird, but I need to hide "query source" from viewing in mon$statements or any other log in database.
That's because the query has some business rules that I can't expose to other people.
Is there any way to do it? Or some "trick" that I can use?
There is no way to do this. However MON$STATEMENT only shows your own queries, unless you are SYSDBA, the owner of the database, or a user with the RDB$ADMIN role (then you can see all queries). Other then MON$STATEMENT, there is also the trace facility which allows people with sufficient access to see queries (either on the server or through the service api). People with insufficient access to the database can still see queries if they can see the network traffic between the application and the database server.
The only way is to not give any form of access to the database server to people who should not be able to see the queries. This can be done by hosting the application as a webapplication, or putting a webservice or other form of middleware between the database and the real application.
When developing an application where users connect with their native database logins, I don't need to care about SQL injection right? The reason being the users can execute any SQL they want anyway. (There are places where admins execute CREATE LOGIN and CREATE USER statements and these have to be dynamically built.) I'm talking about a native Windows application on the LAN.
Well, SQL injection is a possibility to execute SQL, so with the SQL shell access, everything required for "SQL injection" is already authorized. However you still need to care if users run as non administrators, probably being restricted which tables they can access, and your system sends some additional SQL commands while logged in with higher rights (create user, etc). Use prepared statements for such a code.
If you mean that you are building a web application, and using users' database credentials to connect to the database, yes, you do need to worry about SQL injection.
Most databases restrict permissions based on objects - tables, views, stored procedures etc. So, a user logged in as "Bob" might have access to table "sales", but not table "payments".
The database does not restrict access to rows in tables (for instance). So, a user connected as "Bob" who can exploit a SQL injection bug in your code can delete every record in the "sales" table. You probably don't want that.
If user "Bob" also has direct SQL access, they could, of course, simply run that statement at a SQL command line - but usually, web applications are available where direct SQL access is not. Your web app may be put on the intranet to begin with, but you can't guarantee that won't be opened up in the future.
Given how easy it is to prevent SQL injection attacks when you're building the app, and what a pain it is to fix them later on, I see no real reason not to prevent them in the first place.
As a matter of fact, "SQL injection" is a common misconception.
Being unable to properly format their queries, folks invented an "sql injection" thing as an excuse.
While properly formatted query will serve 2 purposes at once:
it will always be syntactically correct, no matter what data sent in.
as a side effect it would be invulnerable to that notorious "SQL injection" thing.
I doubt you want your queries to fail because of some unexpected symbol. So, no matter of some "injection", you have to properly format it. But once formatted, there will be no injection anyway. So, you have to concern about format, not injections.
I also have a feeling that letting users to login with database credentials is not quite a good idea.
I have to access some customers databases being hosted in a shared environment. There are numerous databases being hosted on any given customers instance. So everytime I access a database I have to scroll and search.
I would like to be able to configure Management Studio to just go directly to the database I want to work with for a given connection and hide all others on that connection/instance. But i still want to be able to see databases on other instances i might be working with, i.e. local using the same Object Explorer.
If that not possible is there any reason why the web hosting provider would grant their customers the VIEW ANY DATABASE permission? Im assuming thats why I can see all the other dbs?
If i cant configure Management studio to do what i want as per (1) then I was going to email the provider and ask that they prevent me from seeing them from the "server" end. Would this be an easy thing for them to do? If they REVOKE the VIEW ANY DATABASE permission then that should solve my "problem" right? But would it create any others?
You will require access to the master db to effect the outcome you want. There are no options to configure Sql Server management Studio (SSMS) to do what you want.
So (1) is out.
(2) however is a go so long as your service provider play alongs. You are right they will have to
DENY VIEW ANY DATABASE TO youruseracount
which will require access to the master db. But before they do this they will have to set youruseraccount as the owner of your database.
sp_changedbowner 'youruseraccount'
The side affect of all of this is
a. You wont be able to see any other databases in the instance which is what you want.
b. Only one user will be able to use SSMS to admininster your database with the 'View Only My Db' list. This is because only one user can be the Database Owner.
..
Richard
2 articles describe it (no point if I copy/paste, really)
One and Two