I have spent the past month or so developing an application using Visual Studio 2015 Community Edition and SQL Server 2005 which is a Windows Forms application that accesses a database allowing the user to perform CRUD tasks.
My question/problem now is how do I allow for a user on a different machine but same local network, to sign into the application (generic username/password) and start interacting with the database/application without any user permission errors.
I understand how to create users and grant certain permissions to said users but I am wondering of a way to do this without having to create new credentials/permissions for each unique person that uses this application.
Related
I have an online instance of Dynamics 365 v. 9.0 with its basic OOB configuration. I need to synchronize a set of attributes from my local Active Directory users to Dynamics 365 system users entity. For this purpose, there aren't any logon or identity requirements between AD and CRM. The only need is to sync specific attributes like position of the user in the organization hierarchy.
Can I accomplish that without developing code?
You'll need an app that runs from your local network, since it will probably be difficult to configure any sort of cloud-based solution like Microsoft Flow or Zapier to talk to your local AD.
I'd recommend using Data Sync Studio from Simego (http://www.simego.com) for a code-less solution. It is a Windows program that would run from your local desktop or Windows server. It can connect to AD and Dynamics Online.
If this is a one-time migration, the trial version would probably work for you. If it is an ongoing synchronization, they have a server product that will run your sync jobs on a schedule.
Disclaimer: I am not affiliated with Simego in any way - I just like their product for things like this. :)
Microsoft recommends using Windows authentication when connecting a Windows application to an SQL server database.
http://msdn.microsoft.com/en-us/library/89211k9b.aspx
I understand this to mean that the database must have a user with enough permissions to manipulate data and that user links to the currently logged in Windows user. If this is true, how do I prevent the user from bypassing the application and simply modifying data directly in the database?
It seems like I am stuck between using Windows Authentication and potentially allowing users to modify data directly in the database, or attempting to hide the connection string password somewhere so only the app can modify this data.
If you're that concerned about it, you can implement a logon trigger on the server that for certain people (e.g. members of a certain Windows group), they can't log in unless the application name has a certain value. Note that this is weak security since it's pretty easy to set the application name (even in SSMS). It can/will slow down the logon process, though. So keep that in mind if that's a concern for you.
Alternatively, you can have your application authenticate to and interact with an application server, after which the application server connects to and interacts with the database. The application server can run as a service account, to which you'd grant the permissions you need. This way, the end users' accounts aren't in the database to do raw DML against the db.
But I agree with the other answer here: stored procedures are the classic answer to this question.
It is possible to create stored procedures / views etc and only allow the user permission on those. This prevents the user from accessing the database structure directly, and you maintain control over what the user can do (via creating the functionality in the stored procedures / views). If using windows credentials, I think that this would be the best solution.
This site explains how to grant there permission on stored procedures.
http://msdn.microsoft.com/en-us/library/ms345484.aspx
Here is the list of options, for posterity:
Windows authentication only
Pros: simple, No secret to hide.
Cons: user can easily modify data bypassing your app
Password in connection string
Pros: simple, prevents user meddling in your db's.
Cons: have to hide a password yourself, which is always the worst option.
Sprocs access
Create sprocs to access your data, grant access only to those sprocs. No one but the dbo can alter tables.
Pros: Tightest control over what both the user and the application can do to the data
Cons: Higher coupling of database and application; more expensive than the first 2 options.
Proxy
Create a second executable, whether a web or a windows service, with which your GUI application communicates. The 2nd executable can run with different, securely hidden credentials (IIS, Windows Services).
Pros: Decoupled database and executable, securely hidden secrets.
Cons: By far the most expensive solution.
Apologies in advance for the long post, I am trying to be as clear as possible. Is there a way to disable a user / Windows AD group accessing a database via SQL Server Management Studio (SSMS)?
I have an desktop application that uses a SQL Server 2005 database. The application runs as the user logged onto the machine (unfortunately we can't change that otherwise this would be simple). The database is permissioned with groups (but it would apply to users as well) to give access to the appropriate schemas and objects that the user requires. The users have (and need) the ability to select, insert, update and delete data to complete their process.
The application carries out a series of validation and auditing steps on the user input to ensure they are entering decent data (and for some additional business processing). A user could open SSMS and make these changes through the query editor avoiding the application completely which is what we are trying to avoid. What I am looking for is a way to stop the users updating the database through any tool other than the application provided.
I have found a couple of similar posts (including How to disable SQL Server Management Studio for a user) but these don't quite cover this issue as they work on restricting user access or using different logins.
The only solution I can think of at the moment is to have a set of tables where the user data goes initially and then another process picks this up, runs the application processes on and then puts the data into the master / source tables. Then I could restrict user access to the master tables.
This appears to be a good scenario for an application role.
What's a good way to manage and maintain SQL Server logins, server roles, and individual access rights across multiple databases that exist in multiple environments? What are your best practices?
Some info about my situation:
SQL Server 2005
We have N amount of "client" databases with identical schemas (in theory, at least)
We have a central "admin" database that references each client database and can hold configuration values
This "admin/client" pattern is duplicated across multiple environments (dev/qa/stage/prod)
Some users, like testers, need different rights based on evironment
We frequently have to pull client db backups from one environment to restore on another for development or testing purposes
We keep our stored procedures and scripts in source control and deploy in a build cycle
Right now my organization is chaotic and we don't follow good security practices. We have no formal DBA. However, if we got any more complex it would be a constant hassle to maintain it all the time. I could see migrating to a new server or recovering from disaster being extremely time consuming if we where to attempt configuring it directly through the management studio IDE.
First, to make restoring a database to a different server easier, make sure that your logins all have the same SID on all of your servers by using the sp_help_revlogin stored procedure from Microsoft to script the login on the first server you create it on and then use the script to create the login on your other servers. This keeps the database user mapped to the login correctly when you restore the database.
Having different permissions at the database level depending on the environment is going to be a hassle to a point no matter how you role this out. I have a stored procedure in master that gets called on my Dev Server as a part of my restore process that performs the additional GRANT's on the database to give the developers access to make changes. That's the best I have been able to come up with to solve similar problems.
A way to make the rights easier would be to create rolls in the database called Dev, QA, Test, Prod and grant the correct rights to those roles. Then as you restore the databases to each environment just drop the developers in the correct role.
We use active directory groups and enforce windows authenticated logins. From within SQL Server we can then define access based on the AD group the user is in by creating a single SQL Server login per AD group. Not sure if this is any better or worse than DB roles, but it means the roles are managed outside each database.
Propagating access to databases is then either a manual operation or a short SQL script to ensure the logins in the database point to a valid SQL Server login (which in turn is an AD group).
Generally this works well for the general case. We can use DB roles then to assign the builtin roles (e.g, db_datareader) to each AD group
Rarely someone needs some specific access to a database outside this model. We either end up opening it up to the group as a whole if it's not going to be invasive or critical or we'll end up creating a per-user account that has to be managed separately. We endevour to keep these to an absolute minimum, and clean them up every now and then so they're not abused/forgotten about.
We are building an hosted application that uses MS SQL Server Analysis Services 2005 for some of the reporting, specifically OLAP cube browsing. Since it is designed to be used by very large global organizations, security is important.
It seems that Microsoft's preferred client tool for browsing OLAP cubes is Excel 2007 and the whole infrastructure is geared around Windows Integrated Authentication. We, however, are trying to build an internet-facing web application and do not want to create Windows Accounts for every user.
It also seems that there are not many nice AJAXy web-based OLAP cube browsing tools (fast, drag-and-drop for dimensions, support for actions, cross-browser etc.) As an aside, we're currently using Dundas OLAP Grid but have also considered RadarCube and other more expensive commercial solutions and are still thinking of taking on CellSetGrid and developing it further - if you know of any other cheap/open solutions please let me know!
We are therefore planning on providing two modes of access to the cube data:
Through our own Web Application using one of these 3rd party Web-based OLAP browsing tools.
Direct access from Excel over HTTPS via the msmdpump.dll data pump, for when the web version is too slow/clunky or user needs more powerful analysis.
For the web app access, the connection to the SSAS data source happens from the web server so we can happily pass a CustomData item on the Connection String which indicates which user is connecting. Since we potentially have too many combinations of rights to create individual SSAS roles for, we have implemented dynamic dimension security that uses a "Cube Users" dimension in conjunction with the CustomData item from the connection string and limits the Allowed Set of various other dimension members accordingly (via other Many-to-Many dinemsion relationships with Measure Groups that contain the 'rights mapping')
See Mosha on Dimension Security:
http://www.sqljunkies.com/WebLog/mosha/archive/2004/12/16/5605.aspx
This all seems to work fine so far.
For the 'direct connection' from Excel, we set up the data pump for HTTP access
(see the MS Technet article) but have enabled anonymous access, relying again on the Connection String to control access since we don't have windows accounts.
However, in this case, the connection string is controlled by the user (we push a .odc file from the web app, but a curious user could view & change it), so we cannot rely on users to be good and keep the CustomData=grunt#corp.org from changing to CustomData=superuser#corp.org. As it turns out, this also causes the same problem with Roles, since these are also specified on the connection string if you are not using Windows Integrated Authentication.
The question therefore boils down to this: is there a way of getting basic authentication in IIS working without windows accounts in such a way that it can be used with the SSAS data pump to let SSAS know which user is connecting so that dynamic dimension security can be used successfully?
(This is my first q on StackOverflow and probably the most complicated question I've ever asked: let me know where I haven't explained myself very well and I'll attempt to clarify)
Basic authentication will work with local user accounts (non-domain) and even support passthrough authentication if the local accounts exist on different machines, however you should force SSL as basic authentication sends passwords in plaintext.
You can use non-windows accounts with basic authentication in IIS with add-on such as http://www.codeplex.com/CustomBasicAuth, but SSAS will still need to know who that user is and as far as I know SSAS uses only Windows authentication.
For a (relatively) cheap thin client front-end for SSAS look at RSInteract. For bonus points it will also consume SSRS reports and report models.
Any attempt to use dimension security will require SSAS to be aware of the user and have their access rights available to it. I don't see any way to get around maintaining user permissions.