I am trying to understand the specific connection and error states of the Azure IoT C SDK.
I can register with IoTHubClient_SetConnectionStatusCallback for the callback in order to receive the IOTHUB_CLIENT_CONNECTION_STATUS and the IOTHUB_CLIENT_CONNECTION_STATUS_REASON.
The value for the first one are IOTHUB_CLIENT_CONNECTION_AUTHENTICATED and IOTHUB_CLIENT_CONNECTION_UNAUTHENTICATED, which I assume simply means "connected" and "not connected". The reason is more interesting however:
IOTHUB_CLIENT_CONNECTION_EXPIRED_SAS_TOKEN
IOTHUB_CLIENT_CONNECTION_DEVICE_DISABLED
IOTHUB_CLIENT_CONNECTION_BAD_CREDENTIAL
IOTHUB_CLIENT_CONNECTION_RETRY_EXPIRED
IOTHUB_CLIENT_CONNECTION_NO_NETWORK
IOTHUB_CLIENT_CONNECTION_COMMUNICATION_ERROR
IOTHUB_CLIENT_CONNECTION_OK
So my first question is: What are the semantics for the respective reasons? When do they occur? What does the communication error entail? The error is so generic it could simply mean "any error we didn't want to specify explicitely".
My second question goes beyond that. I am trying to use X.509 certificates. However, due to certain requirements I may have certificates that are no longer valid or deleted device ids. Can I somehow distinguish those cases by using the available reasons? When I tried to connect with a non-existing Id I simply got IOTHUB_CLIENT_CONNECTION_COMMUNICATION_ERROR. From my point of view, I no longer need to try to connect to the IoT Hub, since my device doesn't exist. But a communication error may be anything at all. The same issue appeared when I tried to connect with an invalid certificate or private key.
Every time I try I simply get the errors:
Error: Time:Thu May 25 12:04:00 2017 File:~/azure-iot-sdk-c/iothub_client/src/iothubtransport_amqp_messenger.c Func:process_state_changes Line:1563 messagesender reported unexpected state 4 while messenger is starting
Error: Time:Thu May 25 12:04:00 2017 File:~/azure-iot-sdk-c/iothub_client/src/iothubtransport_amqp_device.c Func:device_do_work Line:848 Device 'MyDevice' messenger failed to be started (messenger got into error state)
From those information I cannot determine when to connect or reconnect.
thanks for your questions.
The reasons you listed above are triggered by the following conditions:
IOTHUB_CLIENT_CONNECTION_EXPIRED_SAS_TOKEN
The SAS token (provided by the user) expired, and no longer can be used to authenticate a device against the Azure IoT Hub. Solution: provide a new valid SAS token.
IOTHUB_CLIENT_CONNECTION_DEVICE_DISABLED
Device could not be authenticated because it is disabled by the user on the Azure IoT Hub (see field State in Device Explorer)
IOTHUB_CLIENT_CONNECTION_BAD_CREDENTIAL
Device key provided by the user was considered invalid based on response from Azure IoT Hub upon attempt to authenticate
IOTHUB_CLIENT_CONNECTION_RETRY_EXPIRED
The Azure IoT Hub Client has a feature called RetryPolicy (which can be set using IotHubClient_SetRetryPolicy). It has a property that limits the maximum time the client can attempt to reconnect when failures occur. If that maximum time is reached, the Connection Status is invoked with status UNAUTHENTICATED and reason RETRY_EXPIRED.
IOTHUB_CLIENT_CONNECTION_NO_NETWORK
IOTHUB_CLIENT_CONNECTION_COMMUNICATION_ERROR
If retry policy is disabled, these error reasons might be provided to indicate there is a network connection issue.
IOTHUB_CLIENT_CONNECTION_OK
Provided with status AUTHENTICATED.
Related
I have been developing Standard Logic Apps with SQL Server successfully for some time, but suddenly can no longer connect. I'm using Azure AD Integrated as my Authentication Type, which I know is OK as I use the same credentials in SSMS. If I try to create a new credential, it is apparently successful but on save the Logic App says "The API connection reference XXX is missing or not valid". Something has changed, but I don't know what ... help!
per above, this was submitted to M/S and has been resolved as follows: the root cause is if a Logic App Parameter name includes an embedded space the problem with SQL connections is triggered. This is a pernicious problem, as the error message is quite unrelated to the root cause. Further, since embedded spaces are supported in Logic Apps e.g. in Step Names, it is easy to assume the same applies across the board.
I am writing an ISAPI Extension on Windows 10 using VS 2017 and regular C.
It works great but now I am having trouble with error handling. I am purposely encountering an error to make sure the error message is correct. When the client app (not a browser) and IIS are on the same machine I get my expected error message. When I connect to a copy on another pc, I get the IIS generic html for the 500 status.
Here is where I generate the header:
// Send HTTP headers
SendHttpHeaders(pECB, "500 Internal Server Error", "Content-Type: text/plain\r\n\r\n");
SendHttpHeaders is my wrapper function for sending the headers. I s
Here are the last two lines of code:
pECB->dwHttpStatusCode = HTTP_STATUS_SERVER_ERROR;
return HSE_STATUS_ERROR;
Why am I not getting my custom message?
Unless IIS is configured otherwise, detailed error messages are only shown to browsers connecting from localhost.
While the linked post describes how to control this behaviour, note that this blocking is intended as a security feature, and (as they mention) depending on your site implementation, this can expose internal details to public view when error conditions are triggered (i.e. ones you are not expecting to make use of this behaviour, such as from a bug). This may or may not be a security concern depending on your operating environment (eg. public internet vs corporate intranet), data sensitivity, etc.
We currently have ADFS 2.0 with hotfix 2 rollup installed and working properly as an identity provider for several external relying parties using SAML authentication. This week we attempted to add a new relying party, however, when a client presents the authentication request from the new party, ADFS simply returns an error page with a reference number and does not prompt the client for credentials.
I checked the server ADFS 2.0 event log for the reference number, but it is not present (searching the correlation id column). I enabled the ADFS trace log, re-executed the authentication attempt and this message was presented:
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
As the message indicates that the request is not well formed, I went ahead and ran the request through xmlsectool and validated it against the SAML protocol XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) and it came back clean:
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
So, I'm thinking that ADFS isn't playing full compliance with the SAML specification. To verify, I manually examined the submitted AuthnRequest, and discovered that our vendor is making use of the 'Extensions' element to embed their custom properties (which is valid, according to the SAML specification) (note: "ns33" below correctly namspaces "urn:oasis:names:tc:SAML:2.0:protocol" elsewhere in the request)
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
If I remove the previous element from the AuthnRequest and resubmit it to ADFS, everything goes swimmingly. And, in fact, I can leave the 'Extensions' container and simply edit out the vendor namespaced element, and ADFS succeeds.
Now, I guess I have 3 questions:
Why was the reference number not logged to the ADFS log? That really would have helped my early debugging efforts
Is it a known issue that ADFS's SAML handler cannot handle custom elements defined within the Extensions element, and if so, is there a way to add support (or at least not crash while handling it)? My vendor has offered to change the SAML AuthnRequest generated to omit that tag, but said that it 'may take some time'-- and we all know what that means...
Does anyone think that installing ADFS hotfix rollup 3 will address this situation? I didn't see anything in the doc to indicate the affirmative.
Thanks for your feedback.
When facing a MSIS7015 ADFS error, the best place to start would be enabling ADFS Tracing. Login to the ADFS server as admin and run the following command. If you have a very busy ADFS server, might be wise to do it when the server is not as busy.
C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc
In Event Viewer select “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Go to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging.
Process your ADFS login / logout steps and when finished, go to the event viewer mmc find the sub tree AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
Look for EventID 49 - incoming AuthRequest - and verify values are not being sent with CAPs value. For example, in my case, it was I was receiving the following values: IsPassive='False', ForceAuthn='False'
In my case, to address the issue, all I needed to do was create incoming claim transformer rule - for the distinct endpoints.
Once the CAPs were transformed to lower case true and false, authentication started working.
I'm using kerberos 1.5.0.3 api to develop an authentication system similar to kinit command.
I have two systems, one which has only IPv4 and the second one having both IPv4 and IPv6 (but IPv6 is unconfigured on this client, but configured on server)
This functions works fine on the first machine and doesn't work on the second machine.
The first type of error when kerberos cache is not present is thrown by krb5_get_init_creds_password: 96C73ADC
When I manually do kinit and suppose the ticket is valid, then I try stuff out I get the error 96C73AB9 by the krb5_get_renewed_creds() call.
I referred to the error codes here: Kerberos Error Codes
Any help is much appreciated even though I'm familiar with Kerberos API, this is my first attempt in writing code which will work on multiple kinds of environments.
Background
We currently have a SilverLight form that posts data to a second common form that multiple applications use, which then runs the need business logic to place the data into a database.
We have several national and international offices where this form is used.
There is one office location (CO) where this form is consistently producing intermittent error messages and based off log data, it is only happening in this office.
Error Symptoms
Initially users will typically report that there is an error and when I log into their machine using MS Communicator, 80% of the time it would start working.
I started installing Fiddler on their machines to try and capture more information but 100% of the time I did that, the form started posting successfully. The users being resourceful, simply start Fiddler anytime the form doesn't post and it works fine.
I also asked users to go through Citrix which is hosted in the TX office and the form posts fine.
Error Details
I used OPNET to better monitor the traffic and I found that when user's simply open IE the authentication handshake fails.
Client => Server = 401
Client <= Server = Authentication Token
Client does not respond
When we use fiddler, the handshake is successful.
The error returned by SilverLight was a very generic [HttpWebRequest_WebException_RemoteServer] message.
Question
What would cause the handshake to work sometimes by itself, always with fiddler and CITRIX, and sometimes it doesn't.