If I execute a query from vscode that fails, why should Azure issue a security threat for this? How should I prevent this from happening (other than never submitting a query that fails, lol)? Is this a permissions issue? Can I have the admin suppress this type of 'threat' from my machine/login? This also happens if there is a failed query from python/sqlalchemy. This doesn't happen often but it is rather annoying to have to explain.
Threat: Potential SQL Injection
Edit:
Description
Threat
This seems like a bug. I've reported this to someone on the product team to check. Can you send an example of this with a screenshot to me at AzCommunity#microsoft.com so that I can bubble this up?
Related
I am facing a problem with logging into TFS. I get the following error:
Exception Message: TF246017: Team Foundation Server could not connect
to the database. Verify that the server that is hosting the database
is operational, and that network problems are not blocking
communication with the server. (type SoapException)SoapException
Details:
Hi the below steps worked for me.
Select Application Tier in the TFS Administration Console.
In the Application Tier Summary which contains the Service Account details.
Click Reapply Account.
I know this is old, but here was my situation:
We have 11 collections on our instance, 2 were failing with this error, showing me it wasn't an access / connection issue. Checking Event Viewer (as #Andy Li-MSFT suggests) showed it was
A timeout occurred while waiting for memory resources to execute the query in resource pool 'default' (2). Rerun the query.
Checking task manager showed the culprit - elastic search was using well over 2GB of memory. I killed the service, the collections applied the patch quickly without issue.
Looks like I need to ask our server admins to give us a bit more memory....
Please check below thing to narrow down the issue:
Make sure you are the member of the Administration Console Users.
Otherwise you cannot access the Admin Console.
Make sure the SQL Server is stated and available, and the network
connectivity is OK.
Check the Service Account, make sure the Service Account has been added in
SQL Server.
You can also refer to the solution in below link to fix the issue:
https://www.ganshani.com/alm/tfs/visual%20studio/solved-tf246017-team-foundation-server-could-not-connect-to-the-database/
If above solution can not resolve the problem, please check the Event log. The Windows Event Log is a good candidate where to look for the potential cause.
For me I've solved the issue by changing the recovery mode Simple -> Full in the database.
Please refer to: https://www.mssqltips.com/sqlservertutorial/3/sql-server-full-recovery-model/
I have an application with claims based authentication and recently I have been having an issue where at random I lose authentication. The application usually gets it's Identity, Claims information from System.Security.Claims.ClaimsIdentity and it authorizes fine. For some reason after clicking around different pages I lose authentication and it seems to be looking in System.Security.Claims.WindowsIdentity and it exits with a null exception as there is now no more authorization information. I am also using IdentityServerV3. I apologise for the lack of specific technical data but was wondering if anyone has ever had this issue. There is no specific time that this does this after as I first thought it might be expiring. It happens very randomly. I have included screen grabs:
This was when I was authorized
and this was 10 seconds later
If you need any further infromation let me know and thanks in advance!
I had similar issue where losing authentication randomly, caused by three reasons I can remember,
1) multiple threading - code was executed by a different thread that doesn't have identity context
2) cookie size exceeded browser limit authentication cookie get chunked when pass back to server
3) identity server hosted in multiple instances and identity server configured to store token in memory.
Regarding your case, my gut feel which might be completely red herring, is the 1) which the thread executing your code 10 sec later is under a different identity context , I would suggest try to verify any path of your code can by multiple threading first, at the mean time check the thinktecture log that can be found in output window if you are using default logging provider to see if anything suspicious
Hope it helps
The following best practice checks fail when Cassandra's PasswordAuthenticator is enabled:
Search nodes enabled with bad autocommit
Search nodes enabled with query result cache
Search nodes with bad filter cache
My values are in compliance with the recommended values; and I have confirmed that the checks indeed pass when I disable authentication in Cassandra. What's weird is that there are 6 checks under the "Solr Advisor" category of the Best Practice Service and only these 3 are failing when authentication is enabled.
Is this a known bug in Opscenter? I'm using v5.0.1 but I've seen this since v5.0.0.
Where can I file bug reports like this? Does Datastax have a public bug tracker?
PS:
I actually feel that this question is more appropriate under ServerFault but I don't have enough reputation in that site to create the tags "datastax" and "datastax-enterprise". Can somebody do so please and move this question?
When Cassandra is using PasswordAuthenticator, then the http routes that opscenter agent uses to determine the solr schema settings also become password protected (however the agent does not try the password properly). This is a bug in the opscenter agent, and can be referenced as OPSC-3605.
Unfortunately Datastax Enterprise does not have a public bug tracker. If you're a DSE customer, probably the best method you can use is to go through DSE support.
While I was following the guide http://msdn.microsoft.com/en-us/library/vstudio/jj920163.aspx to add Bugs to the task board I ran into an unexpected issue.
Adding the fields to the WIT was successful but when I started adding the form fields I received a very strange error:
Failed to save the 'Bug' Work Item Type to the server. Please contact
your administrator. There was an error contacting the server.
Technical information (for administrator): HTTP code 200: OK
Now I played around trying to find what field was causing the error... I tried every field seperatly and when added seperately they worked, then I tried adding them in pairs, this worked as well, then I tried adding all of them and even this worked!
BUT: When I try to add all of them in a clean group and column I get the error!
This leads me to believe there is some sort of maximum amount of elements in the layout form of a WIT? For now we have left all the fields added to another category but I wanted to ask if someone else had run into this issue and if there is a solution for this?
Since these are all stored as columns in a SQL Server table, the maximum you can add is 1024 (less the TFS standard, which might be around 33 columns?)
If you think this is the problem, check the Tfs_Warehouse..DimWorkItem table and see if you exceed the maximum.
Any chance you can get more information from the event viewer log on the app server, or provide more information about your bug? That message isn't very useful.
For reference -
http://blogs.msdn.com/b/eugenez/archive/2009/05/07/work-item-customization-tidbits-limits-of-complexity-part-13-of-x.aspx
Today we figured out what was going on by using fiddler and more closely monitoring the exchange between Visual Studio and our TFS server. Apparently the request was hitting the Application Firewall that was installed on the TFS server. This is the reason why you receive the vague error HTTP code 200: OK. The Application Firewall replies with a plain HTML page containing a blocked request ID (so you can pass it to your system admin). Once we passed this ID on to our networking team and they adapted the rules there was no longer an issue.
I hope this helps anyone who unexpectedly runs into an Application Firewall on your TFS server like I did.
I have been tasked with changing the password to all service accounts within the organization, and would appreciate a few pointers from sombody who has tackled this before..
I have identified each service account- as well as each machine and service using that account. What I would like is some guidance as to how this process is actually executed. This is a production environment, and I don't want to go breaking things during work hours.
Is the process as simple/tedious as changing the service account password, then logging onto each server, locating each service and changing relevant info under the "Log on" tab?
is there a better way of doing this? Thank you for the advice/guidance.
Thats pretty much it.
What I would suggest tho is duplicating the accounts with the same permissions (but affix '2013' on the end or something) and then while you go around changing the passwords, redirect the services to that account as well.
The reason for this is that, at least a few times, some random legacy application has gone down during service account resets purely because noone knew it was using it/had missed it in the refresh/didn't know about it. This way everything you touch should be OK, and you can then monitor the now 'legacy' accounts for any use.
/edit
Actually changing the username/password CAN be scripted, but that all depends on how cautious you want to be about the change and whether you want to be able to easily halt the execution! See http://gallery.technet.microsoft.com/scriptcenter/79644be9-b5e1-4d9e-9cb5-eab1ad866eaf for an example. (You will also need to think about what range of OSs you need to do this on - PowerShell will only work on some, VBS will for the others but then you have further considerations, and NT4...... ;) )