As part of a project we are implementing Azure OAuth authentication for a SQL Server instance hosted in the Azure cloud. We are using the MS-TDS (Tabular Data Stream) protocol to create the federated authentication packet which contain the access token data and the other parts needed in the packet.
We are now stuck at a point where no matter what we do, we are not able to get a successful response. As of now we are getting the below error from the server
(47089) Reason: Login failed because Azure Dns Caching feature extension is malformed
Even though we are not populating anything related to DNS Caching in the packet knowingly. A major part of the problem is that we don't understand the error much by itself. We have looked over the internet and haven't really found much help yet. Do we have any resource we can refer to be able to understand this better? I mean the packet itself is huge and it is proving to be really difficult to debug this without any kind of documentation from Azure side.
Any help on this is much appreciated.
Related
We have a Logic App trying to access the Storage Account Queue, secured by a private endpoint. Both resources are in the same SNET. We have configured our Managed Identities correctly and given Storage Queue Data Contributor access to the storage account. When trying to put a message in the queue, we are getting the error:
SSL connection could not be established, see inner exception.
We checked this Microsoft documentation but are not aware of what certificate they are talking about. Please check the error screenshot below.
It turns out that we need to whitelist the IP addresses in our company's firewall. However, there is a catch. According to this community post, we required our logic app and storage accounts in different regions. Since the move was not possible, we changed all our connectors to built-in connectors instead of Azure public connectors. Changing to the built-in connectors came with its own challenges, but we were able to achieve our purpose.
is it possible tracking all authentication requests on AD Server? no matter the requests go through LDAP, Kerberos or NTLM, and getting know the source IP address and account name?
That information is already in the Event Viewer on each of your domain controllers.
If you search online, you may be able to find some software that can be installed on each DC that will consolidate all that information for you to make it easier to look at and search. But I've never done that, so I can't recommend anything.
I am about to start developing a website for clients ReactJS. This website will communicate with the server to retrieve sensitive data. The server is only accessed through HTTPS so it is safe. However, I am wondering if I should be adding an additional security layer by encrypting the data server sends and then decrypting that on the client side. I am going to use code scrambler so people (possibly) won't see what or how I decrypt. Or is it completely worthless doing that?
Anyone who's been in something similar before and can help me see through, please?
Thanks.
I have been making requests to my cloud REST Service over the two past weeks. Everything was fine until yesterday.
Over the past days, I kept re-publishing my service to the cloud to test some of its operations with a client. I DID NOT change anything in my web.config, just some method bodies.
Yesterday, by making the simplest GET request to my service, through my browser or Advanced Rest Client, i started getting the following error:
The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service. The exception message is 'The underlying provider failed on Open.'. and so on
I suspect after doing my research that this means I clearly have a connection error with my database which I don't get since it was working fine so far.
I also tried to Stop and Start my service in the Azure Production Enviroment but without any luck. Also the server firewall is configured as it should be.
Any answers would be much appreciated.
Thanks.
In my experience these generally tend to be azure service outages. There is currently 'Scheduled maintenance' occurring on all DB instances which may be affecting you.
http://www.windowsazure.com/en-us/support/service-dashboard/
I am working on writing a OMS implementation. I have verified that service is compliant with the service and schema definitions.
When trying to set up the account in Outlook 2007 to test the service, it allows me to use an https address, but not an http address.
According to the documentation (http://msdn.microsoft.com/en-us/library/bb277363.aspx) "The URL of the OMS Web service can be either http or https, but it is https if not otherwise specified"
I have not been able to find any doucmentation that would explain why Outlook will not even let me try to do anything in the wizard if the service url does not start with https.
The error that it returns when a http address is entered is:
The web service address is incorrect or corrupted. Check the web service address or contact your administrator
I have also tried creating a temporary cert on my local machine to test the service, but outlook is rejecting the cert because it is not valid.
Is there any way to test the service or run it over http?
You are not alone in seeing this error, we've also come across this issue, one of the 3! comments on the msdn documentation also reports an issue with using http (http://msdn.microsoft.com/en-us/library/community/history/bb277363.aspx?id=2)
Apart from exposing your service as https there doesn't seem to be a way around this :(
Connection Security
To protect the information as it is
transferred over the Internet, OMS Web
services are required to support SSL
(Secure Socket Layer) encryption. SSL
can be used to establish more secure
connections on untrusted networks,
such as the Internet. SSL enables
encryption and decryption of messages
exchanged between client and server,
thereby helping to protect messages
from being read during transfer.
http://msdn.microsoft.com/en-us/library/bb277361(v=office.12).aspx#OfficeOutlook2007OMSMobileServicesGuidelinesPt1_CommunicationProtocols