I am currently working on a web app that will only be used internally. Part of the application requires employee information that is currently stored in our Active Directory. I have a sql server database already set up that I was going to store the info in but I'm not sure if it's needed. I can query the AD anytime to get the info I need so is it necessary to store it a second time in sql server? Will there be any significant performance issues if I am running occasional queries against AD vs. sql server? It's probably simpler to store everything in my sql database but I wanted to get some other input/advice as I have never worked much with active directory. (Also, this is not a data/network heavy app - less than 25 people will be using it)
Honest disclosure - I also don't have substantial AD experience.
If you duplicate the information from AD into SQL server, then you face the problem of detecting when it changes and updating the SQL copy. Your SQL copy will, somehow, lag or differ from the authoritative information in AD and your application will become known as inaccurate. Caching and ensuring cache accuracy is a very hard problem. Why take it on if you don't need to.
For light usage, I think an AD domain would handle it fine. If I understand it correctly, the domain controllers are load balanced across several servers. It does this for authentication, but I'm not sure about queries.
A Directory is an entity built to be simply interogated using LDAP. The main objective of a Directory is to centralize users informations just in order to avoid duplication in multiple databases.
So the answer is SURE use your Directory and interrogate it using LDAP (via ADSI in your case).
You need to duplicate entries in a database if you begin to plan frequent updates on user datas.
Related
I have a WPF application that:
Takes user input, stores it into a database
Reads from a database and displays it on the screen
Currently is just using SqlConnection method to execute and query a SQL Server database
When deployed, this application will have multiple within network users that should be able to connect to the application and read/write to it as well. Of course, this database is user access controlled, and the end users don't have access to the SQL Server instance. The only ways I can think of connecting are:
Using a generic account that has access to the database and then including that in the connection string.
Creating a REST API to pass requests to the database, bit unsure on details.
What would be the best way to go about this?
REST API would add a level of complexity and additional infrastructure requirements to your application. It would also add an opportunity to use the application outside your network, so that may be a plus. However, if that's not the anticipated use case, it's probably overkill
Also, REST would still need an account to access the database, so it's not really better than your first idea. Depending on the WPF part, you may also have to change the access to the data (for example, using web service clients instead of EF).
Perhaps you can add your users to the database and give them limited privileges to only access selected tables, views or stored procedures. This can add a fine grained control of who and what on the database level. However, this requires a bit or lot of work, depending on the number of your users.
So, your first idea is the easiest one and can probably be expanded to the separate database accounts for your users, while REST probably requires a bit of additional work and setting up the web server etc.
I'm working on a desktop app that was developed about 5 years ago using C# and mssql server 2000.
This app uses OPENROWSET to load some xls files, and it worked just fine til the institution in where I work upgraded databases (to something like msserver 2019 or sort of), and OPENTOWSET stop working.
Despite knowing there's plentiful of procedures and recipes to fix this issue (which I cannot apply coz database runs on server), my company's DBA is telling me the only way to fix such problem is to give admin-privileges to the app-user, and he cannot do that because of safety rules - dropping the problem to me. Now I have to replace OPENROWSET with something else.
So the question is: is that true?
There's no way for a skilled DBA to make OPENROWSET work on a remote DB with regular/non-admin user, fixing those errors about permissions and linked servers?
Is OPENROWSET "mature-or-safe-enough" to make it run on nowadays production servers?
It looks like you are attempting to open excel files from within your database. In which case, the default setup would not allow this:
https://learn.microsoft.com/en-us/sql/t-sql/functions/openrowset-transact-sql?view=sql-server-ver15#remarks
OPENROWSET can be used to access remote data from OLE DB data sources
only when the DisallowAdhocAccess registry option is explicitly set to
0 for the specified provider, and the Ad Hoc Distributed Queries
advanced configuration option is enabled. When these options are not
set, the default behavior does not allow for ad hoc access.
When accessing remote OLE DB data sources, the login identity of
trusted connections is not automatically delegated from the server on
which the client is connected to the server that is being queried.
Authentication delegation must be configured.
It sounds like this may possibly have been configured way back in the past for previous databases, but the DBA who now sees this regards it as a bit of a security problem. Whether or not he is right depends very much on how you use this, but it does sound like something that would be better avoided.
It may be better to load the excel files in your C# application and then send the BULK data to sql server to just save.
I am working on a C# winform project and during several operations I save and retrieve data to and from my google cloud SQL database.
In order to implement this, I set up the SQL instance, allowed the public 0.0.0.0/0 IP (so I can use this app from different PCs) and created a database user with a strong password. In the connection string in my c# project I connect to the IP with the created database user + Password.
Now my question is, how save is this? For my project and the enduser it is essential, that the data is as save as it can be. The only safety I have now is basically my google account Password and the database user Password.
Would there currently be a way to bypass that and retrieve data without me noticing?
best regards
Steffen
This was fine "back in the days".
Now, it is good practice to have a front-end proxy that uses APIs to serve data to the application.
If you can build and application that will run in the Cloud, next to your database, it would be best. Have that application authenticate users of the Winform Application and send them the information they need through API calls.
Without this, and having your application access directly the database you will have 2 issues:
lower security
high latency (and this will probably be more problematic). Database requests don't really like latency.
On top of it, you could use that server-side app to cache data and do some consistency checks.
However, for DEV purposes, direct connection is acceptable. Just don't put production data there.
I'm going to develop a POS system for medium scale company
and the requirement for me is to make all data on time for all of their branches
while in my mind, move the server from local to web would solve this problem
but, i never done any online server for window application
may i know what is the best option for use as secure database ?
such as SQL can handle this well ?
i tried to google but all of the result return is not what i want
may i know what will you do when you facing this problem ?
my knowledge on coding is just VB and CS
also SQL for database
i would like to learn new if there is better option
i hope it is impossible to access by anonymous and it is store secure at back-end only
What you probably want to do is create a series of services exposed on the internet and accessed by your application. All database access would be mediated by these services. For security you would probably want to build them in WCF and expose them through IIS. Then your Windows application would just call these services for most of its processing.
If you design it properly you could also have it work with a local database as well so that it could work in a disconnected manner if, for example, your servers go down.
Typically you don't move the server off of the site premises.
The problem is that they will go completely down in the event your remote server is inaccessible. Things that can cause this are internet service interruption (pretty common), remote server overloaded (common enough), basically anything that can stop the traffic between the store location and your remove server will bring them to their knees. The first time this happens they'll scream. The second time and they'll want your head due to the lost sales.
Instead, leave a sql server at each location. Set up a master sql server somewhere. Then set up a VPN connection between the stores and this central office. Finally, have the store sql boxes do merge replication with the central office. Incidentally, don't use the built in replication, but an off the shelf product which specializes in replicating sql server. The built in one can be difficult to learn.
In the event their internet connection goes dark the individual stores will still be able to function. It will also remain performant as all of the desktop app traffic is purely to the local sql box.
Solving replication errors is much easier than dealing with a flaky ISP.
I would recommend you to check Viravis Platform out.
It is an application platform that also can be used just as an online database for any .NET client with the provided SDK. It has its own generic windows and web clients and some custom web solutions for some specific applications.
You may be using it as a complete solution or as a secure online database backend.
Greetings!
I'm needing to deploy a compact database with an application I am working on. The database acts as a cache for data the app has already seen, and that data will never change, so the cached values will never become outdated. I've chosen SQLite, and I'm writing in C#.
I'd like to protect the database files so they cannot be easily accessed or edited by the user - keeping access to my application only. Now, one option is to use password protection which is fine except that with tools like Reflector one could easily view a near original version of the source and check the passwords/how they are generated per file and replicate this.
Are there any suggestions on how to achieve this result or something close? Have people done something like this in the past?
Thanks!
Security by obscurity.
If your apps can decrypt it, then your user can do it too.
If you want to keep it secure, you'll have to keep it for yourself. Your best bet is to store the database on a server and make it available via a web service. Perform access control checks on your own server so that the application can only access the parts of the database it has to see.
I don't have a clearcut answer for you (obfuscate your code during release deployment, make the password obscenely long) as the golden rule stands: If they have physical access to the executable (substitute machine/car/door) they can get in if they want(and have skills).
All you can do is make things difficult for them.
This area is not my forte, but one thing I could suggest is to just think about what data you are actually sending and determine if there is any way that you can limit any of the more sensitive data from being transmitted to the client in the first place.
If your concern is over sending things like ID numbers account numbers to the client, then perhaps you could translate those values into a client-only version that is meaningless outside of your application. Your server could have a table that contains the translation between the real values and the client-only values.
Let's say you have this table stored in your server's database (not the client database!)
RealAccountNumber ClientOnlyAccountNumber
981723 ABC123
129847 BCD234
923857 CDE345
...
So the client only sees the account numbers in the ClientOnlyAccountNumber column, and when a client sends a request to the server for an action to be performed on account "ABC123", the server knows to translate that into account number 981723.