We are using SharePoin 2013SP1 in-premise with OWA-2013, WOPIZone is set to external-http in SP, view/editing/adding of office files works behind the load-balancer (LB) but when viewing from client (outside LB) blank page is displayed for any office files.
When launching the URL of OWA check "http:///hosting/discovery" from the client I get the XML file displayed on the client browser.
Check the OWA and SP logs and could not find any exception, the file checking is performed and replied successfully (compared this with a good request and failure request both seams same).
hence requested network team to check on firewall, who has given the below info.
Network Findings:
we found that IPS signature HTTP: RFC 2397 Data URL Scheme Policy blocked the traffic.
It was found that the reply from server was blocked due to DATA URI packet is transferred which is blocked at firewall.
Question:
1) Can provide more info on this DATA URI base64 encoding data reply from OWA server. When network team want to open this policy what info I should provide (origin source, uni/bi drection, etc).
2) Any other such policy to be opened for view/adding/editing office files using OWA from client.
3) In the event this rule/policy is marked as "HIGH" in terms of security then any other work-around for viewing office files through OWA.
Thanks,
Hari
Related
I'm following the guidance from Microsoft on decorating traffic to avoid throttling. This guidance specifies that you set a specific User Agent on outgoing requests from the application to SharePoint via CSOM when making API calls.
I have made this change, and would like to now verify that the User Agent is in fact appropriately modified on API calls to SharePoint.
My provider-hosted application is hosted on Azure, and while I can see CSOM calls to SharePoint (https://(mytenancy).sharepoint.com/sites/(mysite)/_vti_bin/client.svc/ProcessQuery) in the Application Map as a dependency, I can't figure out how to view the actual outbound request so as to examine it for the User Agent string.
How can I view the User Agent string on outbound requests from my Azure application? How can I verify that I've set the User Agent string on my calls to the SharePoint API?
Additional Info:
I have tried running the application as well on localhost and employed the use of Wireshark and Fiddler, but I'm only picking up requests to client.svc/ProcessQuery with my browser's User Agent string. I get the feeling I'm not even seeing all the CSOM requests.
User Agent is used for determining browser and browser version , however it seems to be dropped in processing and not available in search or export.
Please have a look at below links for further details.
UserAgent not transfered
UserAgent, Lat/Long and URL expansion data removed
Hope this information helps.
To provide feedback for the team on this specific feature , please refer to this link and upvote.
Support for viewing Raw body requests is something being considered by the Product team. Please refer here for more details on it.
Security team has requested access logs of our bomgar appliance to be sent to their qradar (enterprise security information and event management (SIEM) product) server over port 514.
Will the events be properly sent when filling out the URL field shown below in the 'outbound events' tab? example. 127.0.0.12:514
enter image description here
Yes, that should be fine if it is over UDP(514 default). But, if the syslog server is configured for TCP then the default port is 6514 (well-known port). So make sure this specific configuration?
Make sure the topology is in place as mentioned in RFC 5425 under Deployment Scenarios.
I want to perform load test on some of the web services through VS2012. To do that we need to access the URL of the web service, but I am unable to do that since when i try to access the URL its displaying the below message
Your connection is not private
Attackers might be trying to steal your information from 116.50.77.22 (for example, passwords, messages or credit cards).
advanced
This server could not prove that it is 116.50.77.22; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
Proceed to 116.50.77.22 (unsafe)
How can i handle this, how can i install the security certificate or is there some other way i can access the given URL
This error message appears to be from the Chrome browser when it detects an SSL certificate issue. I assume that the URL for the web service begins with https://116.50.77.22 (secure HTTP).
Normally SSL certificates are issued to a computer host name or internet domain name versus an IP address. You may be seeing this message due to a name mismatch, and instead of using the IP address should use the name specified in the SSL certificate. You can view more details about what is causing the error by manually browsing to the web service URL, and if prompted with the original error choose to "Proceed to 116.50.77.22". You should then be able to click on the padlock icon in the address bar as shown below, and on the Connection tab you should see details similar to those shown. If you see "Server's certificate does not match the URL", click on the "Certificate information" link to view details on the SSL certificate being used by the server. The name you see after "Issued to:" is the name associated with the certificate and should be the name used in the URL. For example if you see "Issued to: M23458" you should use a URL beginning with https://M23458/ to access the web service.
If you see other errors listed under the Connection tab, my advice would be to search Stack Overflow for specific guidance in dealing with each one. You may need to resolve all before you original error message (your connection is not private...) will go away, and each one will require a different set of steps to address.
I'm new to setting up smtp, and I'm trying to figure out how to secure my server, but I'm getting a little turned around with all the security options - hopefully someone can help me clear this up. I'm using Windows 2008 R2 sp1 with IIS 7.5 if that makes any difference.
So what I'm seeing is, in the properties of the smtp virtual server I have an Access tab with an Authentication button. Seems to make sense, I pick Integrated Windows User, but then on the Delivery tab, I see an Outbound Security button which presents the same set of options again. I select Integrated Windows User.
Then, following the instructions I found online to setup smtp, I created a new domain under the smtp virtual server which then gave me ANOTHER Outbound Security tab with the same set of options. What are all these settings for? I've scoured google and couldn't find anything differentiating the 3 (maybe more?). I've found various sites that will tell me what one does or another, but they all seem to be doing the same thing and no site addresses that. Does one override another? Like a default for the server, but then specific ones for the domains or something like that? What's the difference between the Authentication and Outbound Security? What's the difference between the Outbound Security for the domain and for the main smtp server?
Oh, and one more question while we're semi on the topic - is the setup for domains mainly used for remote access? Like, it would be unnecessary for localhost use?
You have two sets of authentications: inbound and outbound.
The Access tab lets you limit who and from where are allowed to access your SMTP server (i.e inbound), while the Outbound Security in turn lets you provide credentials that the SMTP service will use when delivering mails to another SMTP server (e.g. if relaying all outgoing emails to a smarthost that requires authentication).
You can furthermore set up remote domains, i.e. have emails for a specific domain be delivered to a specific server using specific credentials.
It is highly recommended to have all your outgoing emails forwarded to a smarthost that acts as an official email server for your sending domain, otherwise you risk your emails being classified as spam because they are sent from an unknown server.
Docusign connect service is not posting data to the url specified in the connect service option. Actually if i resend the data from log it works but it do not works on its own.
Please help me
Thanks
Usually when DocuSign Connect is not publishing to a URL it is caused by one of a few things:
Your server is not listening on the correct port(s).
You are not testing for the correct events.
You do not have the user (sender) configured for Connect.
Your server is not publicly accessible.
Your firewall or network security is not letting the requests going through.
Your server has crashed.
A potential bug with DocuSign Connect.
Possible resolutions:
If testing in DocuSign demo environment (demo.docusign.net) ports 80 (http) and 443 (https) are allowed. If testing in production environment (www.docusign.net) only 443 - https is allowed.
Make sure you are testing for the correct event triggers - this can be confirmed on your Connect settings page. Login to the Console and go to Preferences -> Connect -> (select one of your Connect configurations). On the following page you'll see how to select events that you want Connect to push on, as well as for which users.
Followup answer to 2 - you need to also make sure you have the correct account members enabled for Connect on the Console -> Preferences -> Connect page.
You can not use a localhost address for the Connect URL - it must be a publicly accessible URL.
Your network administrator might have a firewall (physical or virtual) or other security software setup that is stopping the requests from going through. Check your security settings and test that the proper ports are enabled, etc.
Ensure that your server is still up and running and that it hasn't crashed.
Although DocuSign Connect has been around for some time it still occasionally exhibits a bug or two. If not one of the other potential reasons then provide the failure log in your post and someone from DocuSign will follow up.
If you are running into issues with DocuSign Connect hopefully one of the above remedies resolve your issue.