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.
Related
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.
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.
I am not able to connect to https://test.salesforce.com/services/oauth2/token form SoapUI (ver 5.2.1). I have tried the PRO version and other older versions (4.6.xx) as well.
I can access the website from the web-browser. The GET to this URL gives me the response where as SOAPUI says HttpHostConnectException connection to https://test.salesforce.com/ refused.
I have checked that there is direct connection available from my PC to this address. I have tried adding https.proxyHost and https.proxyPort settings in soapui.vmoptions and sopaui.bat but of no use.
I have also tried playing around with Preemptive Authentication settings in SOAPUI without success
My organization has firewall which has white listed this address. I have also confirmed that firewall settings does allow to connect thru non standard clients (such as ApacheHttpClient).
If I use a Java Program using URLConnection using the proxy, it works.
At this point it seems to me that SOAPUI is not honoring the proxy settings.
Please share if anyone has similar experience and how did they resolve it.
Regards
Ash
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
I have set the ActiveDirectoryMembershipProvider connectionProtection attribute to secure, according to MSDN documentation states that when this is set to secure the following holds:
"The ActiveDirectoryMembershipProvider class will attempt to connect to Active Directory using SSL. If SSL fails, a second attempt to connect to Active Directory using sign-and-seal will be made. If both attempts fail, the ActiveDirectoryMembershipProvider instance will throw a ProviderException exception."
The code works and queries can be made against the LDAP but one issue that has me a little confused is that my connection string is prefixed with LDAP and not LDAPS. Changing this to LDAPS results in the following error:
"Parser Error Message: Error HRESULT E_FAIL has been returned from a call to a COM component."
What is happening here? In the first instance where the connection string is simply LDAP is SSL being used? The documentation indicates that if it is not, an exception should be thrown. If not, then what would be the likely cause for this error in this context?
As far as I know, all the LDAP DN's (distinguished names) always have an LDAP only prefix - whether they're over a secure link or not. The secure aspect typically shows up by means of the port on the server being used, 389 being the default for non-secure, and 636 being the default for a secure communication.
But the spec of the LDAP distinguished names doesn't have a LDAPS prefix, really. I've done a lot of LDAP work a few years ago, and I do remember having to deal with different ports for trusted or secured communications, but I never once had a full-qualified LDAP path have anything else but an LDAP:// prefix (case sensitive, too!).
The LDAP:// prefix is used both for clear and SSL connections, to check whether the communication is indeed under SSL try step 3 of this blog entry http://erlend.oftedal.no/blog/?blogid=7