We are developing an application to change the password for users in our UCCE environment. I have found where this data is stored and I can update the password for a user.
However it seems to only work on the web based applications in out UCCE environment and not the physical applications like CAD and CSD. For the life of me I cannot figure out why this is happening.
Has anyone ever done this successfully?
This is the response I got from Cisco
Hi all,
First, you could have some LDAP issues, but sync does go out and check for changes every 10 minutes. You could have an LDAP sync issue. Second, the supervisor password is not stored in the same table. The table I mentioned is for agents. The supervisor password is stored in a couple different places including updating the AD, and I don’t believe it’s as easy to change as the agent table. Also, the password is not updated at the desktop – it is only stored in LDAP and validated when an agent tries to log in
Also, just by changing it in SQL, I’m not sure that that’s all to having it populated across to the other logger, HDS, etc (in fact I’m pretty sure it won’t). The normal way would be to make a change in the AW which would then push that change to the router (via UPCC.dll) which sends the change to the loggers to update their database, and finally back to the AW as a confirmation as well as the other AW/HDS’s. There’s certain checks/procedures for changes to be populated – one being the recover key on each server.
By what you are trying to do, you most likely will be causing corruption across all the databases because they are dependent on the recovery key to ensure they are all in sync. So I’m not so sure that changing it in SQL is a very good idea, nor would it be supported by Cisco or Calabrio. You most likely will be corrupting the database since you are bypassing the way the Central Controller keeps everything synchronized.
Lastly, CAD wouldn’t have anything to do with this/these changes – it would only query the database and update LDAP, but as mentioned I think you are changing the agent password and therefore the supervisor is not being changed. I would seriously urge you not to try and change anything in SQL as we seen enough cases where the databases get out of sync and/or corrupted – not a lot of fun when that happens!
Hope that helps explain a bit more.
Thanks,
Chris
Correct
The Password change which you doing in SQL wont populated across to the other AW / HDS , ETC.
I’m 100% sure it won’t and you will face
The Recovery Key Mismatch Issue.
_Real_Time Table Data Mismatched Issue means synchronization Issue.
Related
I am designing a WPF desktop application and using Entity framework Code First to create and use SQL Server Database. My database will be hosted on One Server machine and will be running 24*7.
I want to provide a feature, where you can modify data offline(when you have no connectivity with SQL Server DB) and Save it somehow. And whenever your application will find connection with SQL Server, all changes can be moved to SQL Server DB.
Is there any way to achieve this by using Entity Framework ?
I want to emphasis on the part that I am using Entity Framework. Is this type of functionality already implemented by EF?? Or I have to do it manually, like have to write that in any file system and then manually merge it later to DB ?
You could figure out the specific exceptions that are generated when the SQL Server connection is lost, and embed your calls in try-catch blocks. If the server is offline, then in your catch block, pass the entity to a method that serializes the entity to JSON and saves it to the hard drive in a special directory or something. On your next successful query, check that directory to see if there are any saved entities that need to be saved.
Be specific with your catches - you don't want unrelated exceptions to trigger this code.
Some things to keep in mind - what if somebody else changed the data in the meantime? Are you intending to overwrite those changes? How did you get the data which needs to be saved in the first place if you are offline?
As long as you have all data loaded into DbContext/ObjectContext you're free to amend those data anyway you want. Only when SaveChanges() is invoked, the connection is really needed.
However, if you're going to load everything into the context, you seem to reimplementing DataSet functionality, which, in addition, allows for xml serialization/deserialization of the changes, so the changes can be even saved between sessions.
Not as trendy as EF, though :)
While I have never tried this with SQL-based data I have done it in the past with filesystem-based data and it's a major can of worms.
First, you have to have some means of indicating what data needs to be stored locally so that it will be available when you're offline. This will need to be updated either all the time or before you head out--and that can involve a lot of data transfer.
Second, once you're back online there's a lot of conflict resolution that must be done. If there's a realistic chance that someone else might have changed the data while you were out you need some way of detecting the conflict and prompting the user as to what to do in that situation. This almost certainly requires a system that keeps a detailed edit trail on every unit of data that could reasonably be updated.
In my situation I was very fortunate in that it was virtually certain that if the remote user edited file [x] that overwriting the system copy was the right thing to do. Remote users would only be carrying the files that pertained to their projects, conflicts should never happen. Thus the writeback was simply based on timestamps, nothing more. Data which people in the field would not normally need to modify was handled by not even looking at it, modified files were simply copied from the system to the laptop.
This leaves the middle step--saving the pending writes. I disagree with Elemental Pete's answer in this regard--simply serializing them and saving the result them does not work because what happens when you read that data back in again? You see the old copy, not the changed copy!
My approach to this was a local store of all relevant data that was accessed exactly like the main system data was, all reads and writes worked normally.
Something a lot fancier might be needed if you have data that needs transactions involved.
Note that we also hit a nasty human problem: the update process took several minutes (note: >10y ago) simply analyzing what needed to be done, not counting any actual copy time. The result was people bypassing it when they thought they could. Sometimes they thought wrong, oops!
I'm currently writing a web app which would largely be used by developers, and I figured (from personal experience) that there would be times where it would be handy to run custom searches in an unrestricted way. I would like to let my users run arbitrary multi-statement SQL searches on their personal data (for an extra fee), so they can retrieve the data that's relevant to their question at the time.
Obviously, this is something that needs to be done with extreme caution, so I would like to make sure I'm going to tackle this the right way.
As I see it, the main points of concern are:
A malicious user could run a DOS (can track this via logging and remove their permissions)
Someone could run a function in a malicious way
Someone could access/modify data that doesn't belong to them (including database schema)
Someone could delete or modify data in a query (I would prefer they do that in a controlled manner)
What would be the safest way to go about providing this kind of ability to users safely?
This is dangerous territory (and I strongly recommend you weigh up this requirement carefully due to the obvious dangers you will be exposing yourself to), however I will try to give you the safest way to proceed if you must.
The only assumption I am making here is that you are running a current version of PostgreSQL and that you require users to remotely connect to the server (using their own tools) to execute their custom queries. Even if they will be entering them into a webpage, most of the same techniques will still apply as long as they each have a separate user log in for the database server.
First, (as NoBugs pointed out) to prevent users executing obvious malicious statements (like UPDATES, DELETES, DROPS, etc) you need to ensure that the user account connecting to the server has only SELECT permissions on the db(s) and table(s) they should be able to read from. Have a look in manual to see how to define roles for users, and grant specific permissions to those roles.
http://www.postgresql.org/docs/9.0/static/user-manag.html
http://www.postgresql.org/docs/9.0/static/database-roles.html
Note that you can only limit a user down to a particular table. If
users each need to be given access to different parts of a table, then
PostgreSQL (and nearly all DBMS's) will not support this out of the
box. Your only option would be to try and create some kind of SQL/TCP
proxy that intercepts requests, and modifies them somehow to limit
query results, before passing on to the database server. This would be
extremely difficult even for a very experienced developer!
To prevent (or at least detect) DOS attacks, you will need an external script or process to keep an eye on the resource usage of the database (and/or the entire server) every few seconds, and possibly build in a mechanism to restart the PostgreSQL service if it is maxed-out.
You will need to experiment with how long before you should intervene
carefully, as it is quite possible for a legitimate query to max
things for a few seconds.
As you mentioned, you would need to keep a careful log of who was trying to execute what, & when so, if necessary you can work backwards from a failure, to find out the culprit. You can really only rely on the system logs for this, which can be configured to write out to files, CSV, or Syslog.
I would suggest you pre-create some tools to help you quickly search
these logs to find what you need before you need to try and find it
(pun intended).
Finally you should also try to follow the other standard best practices for administration and security (all of which can be found in the manuals) including:
Only allow access for your users from specific ip's/hosts (dont give the general public any chance at connecting to your server. Your customers will need static IP's to access the system, but this is certainly worth considering to mitigate risks.
Keep a close eye on all of your standard administrative tasks for the server (especially backups, disk space, log file maintenance, index usage, etc.)
Make sure the user the sql is running as has permissions only to the tables/files the user should be able to modify.
There are also some other considerations - only allow trusted input (maybe use https in your api calls?) and know Mysql could access files and stuff you wouldn't want to let it access.
See also: http://www.greensql.com/article/protect-yourself-sqli-attacks-create-backdoor-web-server-using-mysql
What native technology exists to encrypt/decrypt a string in the database for reading into a single application?
Scenario:
I have a set of connection strings that I need to use to securely access a set of production servers, for a polling application. I would like to store those in a table in a database and pull them out as I need them via a service. That will give me the ability for a handful of users (with permissions) to edit/add those entries.
My target audience using this application are all developers, these are servers to monitor our production and staging environments for some specific SQL flaws that I may need to later fix. This is a devops application.
Knowing that my target audience is developers, and that these are production servers, I would like to "lock the door" to keep people from actively seeing the production passwords/useraccounts unless they need them (auditing purposes). I realize that a lock is only as good as the frame around the door, and is only to keep honest people and petty thieves out, and that anyone dedicated will eventually be able to get past whatever safeguards I try to set.
Problem:
What technology in C# exists to secure this information and still allow me to dynamically add/alter connection strings but still keeps the data in the database reasonably secure? I am willing to make some changes to a machine.config or the like, but I need to actively develop the application too, so would like if it could be done in either machine.config1 or web.config, to allow for local development before deployment to the devops servers.
I understand that some of my alternative suggestions are:
Use strong database passwords to keep people out
Use strong schema organization to keep people out
Trust the developers, they work for your org (see "audit trail". I need to make some stab at securing production credentials)
Don't let people have access to the server and store them in the web.config (already plan on this in the first place)
Ideally:
Ideally I would just use a private key for encryption/decryption on the application server, but I don't exactly know the most secure way to do this, other than base64. I know this is not encryption.
What technology exists in the .NET native stack to securely encrypt/decrypt a string that may contain special characters in a single application and what is an example usage of this technology?
If I knew a name and technique, I would not be asking this question.
1 using machine.config/web.config to indicate something inherent in the .NET stack. I'm open to any suggestions.
Saving connection information in a database table is going to be unsecure, always. At some point, you're going to have to decrypt the password, and send it to the server. Developers tend to be smart enough to figure out any "security by obscurity" approach, and get to the passwords at some point. Even if you encrypt the password in the DB (not too hard), as long as you pass it to the SqlConnection at some point, you still have to decrypt it somewhere on the user (developer) end.
Rather, the only way to do this securely, is to make sure the password actually never gets anywhere close to the developers (or anyone else). There's a few ways to handle this:
Use an external security provider, such as Windows authentication. This means you don't have to use any username or password at all.
Create some kind of a tunnel to send any required SQL. This is very easy if your developers only ever need to run SQL commands, and a bit trickier if they want to use productivity tools like Management Studio; however, even that's doable - SQL can run fine over TCP, and you should be able to emulate that quite easily. Only the tunneling server would have access to the actual credentials, your developers would only have credentials to the tunneling server (and limited ones at that).
Use the Linked servers feature. This allows you to link local users (your devs) to remote users (su on the target server or whatever). It should work just fine with all the usual security settings.
Out of these, I'd say linked servers might be the best. They're quite easy to use, they can be administrated by the select few, and they don't publish the password at all. You can also do queries that span servers this way - very handy for a maintenance tool :)
Windows authentication is incredibly useful, but usually only on LAN, since we're talking about having all the DB servers in a domain. VPN could help, but that's getting into complicated territory.
Using a tunnel isn't necessarily a bad idea, although I assume you'll run into a few issues before you get it working 100%. And in the end, that's what Linked servers do for you for free, so why not use that?
Now, if you really do want to go through with the encryption idea instead, you can pick from a plenty of .NET supported encryption schemes. AES should work fine - it's assymetrical, so knowing the encryption key doesn't mean you can decrypt the data (the decryption / private key should only be stored in a secure location and on the maintenance application server, in a place noone but the application itself can reach; do note that admins can reach anything, so if your people have administrator rights, this isn't going to work).
For an example, see the AesManaged class in System.Security.Cryptography - http://msdn.microsoft.com/en-us/library/system.security.cryptography.aesmanaged(v=vs.110).aspx
Most applications only need one database, but you can use the Manager to create as many as you need. Multiple databases are independent of each other. If your application supports switching between multiple users, each with their own separate content and settings, you should consider using a database for each user. Otherwise, it's usually best to stick with one database.
A co-worker and I are working on some Pharmacy software (in C#) which deals with the management of patient profiles, patient drug prescriptions, etc. All of these different sets of data are stored in a sql server database (we're using 2008 standard but future versions are fine too). Each store has its own sql server instance on a local machine.
Our Goal:
We want to have "Store A" be able to access "Store B's" databases if need be. Basically in the event that perhaps a pharmacy customer is out of town and visits one of the other pharmacy branches.
Things I've thought of:
My initial thoughts were to basically keep an online server instance of sql server which could be accessed through a dns link (or perhaps IP). I was trying to figure out the best way to keep these in sync and I came across sql servers replication. Problem is I was going to use Transactional Replication with updating subscribers but since it's deprecated It's not really a long term option anymore. Microsoft suggests using p2p replication, but that requires enterprise edition and we're really trying to avoid that if we can. I wanted to use a transactional type of replication since it does a much better job of keeping records consistent (not having to wait for something like a merge agent job to run every hour or something like that).
Something I've thought about more recently is maybe having an internet based sql server instance, which would contain nothing but linked servers back to each stores local machine. I wouldn't have to worry about sync problems if other stores just worked directly off each others local machines. But I've read of a lot of people saying that this is a horrible security vulnerability so I'm not sure if this is even a plausible idea but I think maybe there's some way to make this work?
Anyways so this is the basic gist of what we're trying to do. I don't know if replication or linked servers would be the better route to take.
Edit:
What about bi-directional replication? I was reading a little bit about this but I'm a little unsure about if this is what I need or not. I don't want to have to stagger primary keys between servers or anything, since they are pretty important in identifying prescription numbers and stuff like that. But if I could do bi-directional replication, that could be good too.
Not really an answer but I have more space...
SQL Azure is a the 'cloud' version of SQL Server. A VPN is a way of creating your own private network over the internet. Do some research on these terms. Many applications are going cloud nowadays. You should really consider the likelihood that there will be no internet access.
With regards to replication, you can 'roll your own' replication if you own this application and you are happy to support it.
The basic premise is:
Create a trigger on every table which writes the PK of every change to a log table
Create a process which manages copying and merging only changed info (based on the log table) using subscribers and publishers
I ran into real brick wall trying to connect to dynamic databases. And I don't know how to achieve this,
Here is my process, I have an application where it needs to be adaptable to changes in the work environment, say If the work places server crashes and they create a new database with the name db_new the application would connect to that instead of the old database name.
I already have a window that displays the databases from the server on a listbox where the user can specify which database to use for the application. But the issue is, how can I save the selected database name so that it can run after the new database is selected? ..
as in the administrator should be able to change the database the application uses if necessary and the application should keep on using that selected database till the administrator changes it back to a new one.
Please forgive if the question a bit vague, I just put it together in the best way I could, any help on this would be really great :)
EDIT:
And I cannot use text files or xml s as the database name the application uses should be stored in a secure manner. :)
First of all, you can very easily use a text or XML file: If you store the information in a file, that can't be downloaded by the user (as I assume you would), this is as safe as it can be: If somebody manages to break into the server and read the file, it's game over anyway.
That said, I would recommend you use MySQL proxy or a similar mechanism and point your WebApp at it - failing over to another database or changing the underlying database could then be handled at the proxy layer without the WebApp even knowing about it: The functionality need not be part of your application and in my book it shouldn't.
You haven't told us the language you are using. Therefore we cannot offer very good suggestions.
My first thoughts:
If this was PHP you could have the general app use something along the lines of,
$db->execute('sql statement here');
and then just have the administrator change the current $db when needed. That way $db->execute() will always be executed on the "current" database.
Edit: This should still work in C#. If you have the functions using the database call a variable that is the current db connection then you should be able to change the db connection to the proper database whenever you need while the rest of it continues running since it's just the same variable.