Here's what happens on the local server when application invokes HTTP request on local IIS.
request.Credentials = CredentialCache.DefaultNetworkCredentials;
request.PreAuthenticate = true;
request.KeepAlive = true;
When I execute the request, I can see the following series of HTTP calls in Fiddler:
Request without authorization header, results in 401 with WWW-Authenticate NTLM+Negotiate
Request with Authorization: Negotiate (Base64 string 1), results in 401 with WWW-Authenticate: Negotiate (Base64 string 2)
Request with Authorization: Negotiate (Base64 string 3), results in 401 with WWW-Authenticate: Negotiate (Base64 string 4)
Request with Authorization: Negotiate (Base64 string 3), results in 401 with WWW-Authenticate NTLM+Negotiate
Apparently the client and the server (both running on the same machine) are trying to handshake, but in the end authorization fails.
What is strange is that if I disable Windows authentication of the site and enable Basic authentication and send user/pwd explicitly, it all works. It also works if I use NTLM authentication and try to access the site from the browser specifying my credentials.
Well, after several hours of struggling I figured what the problem was. In order to be able to inspect network traffic in Fiddler I defined a Fiddler rule:
if (oSession.HostnameIs("MYAPP")) { oSession.host = "127.0.0.1"; }
Then I used "MYAPP" instead of "localhost" in the Web app reference, and Fiddler happily displayed all session information.
But server security was far less happy, so this alias basically broke challenge-response authentication on the local server. Once I replaced the alias with "localhost", it all worked.
Related
I am trying to do PKI based authentication over proxy.
It works well without proxy, but asa I add proxy info it returns 401 error.
proxies = {
'http': "http://10.192.72.155:8080",
'https': "http://10.192.72.155:8080",
}
def open_url(url, key, cert):
headers = {"User-Agent": "<custom>", "Accept": "<custom>"}
response = requests.get(url, headers=headers, cert=(cert,key), timeout=300)
print response.headers, response
open_url("https://api.example.com/product/LatestUpdate", "/usr/bin/dev_certs/test_cert.key", "/usr/bin/dev_certs/test_cert.pem")
The above implementation works well, untill I add proxies to the requests.get()
response = requests.get(url, headers=headers, proxies=proxies, cert=(cert,key), timeout=300)
which returns following error:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=""
Server: SomeServer
Connection: Keep-Alive
Content-Length: 35
The issue was my proxy setup, it was also decrypting HTTPS traffic, because of which it was not passing the original Certificate. It worked after I disable HTTPS decryption.
i have a page that is hosted on both HTTP and HTTPS, and it makes a HTTP call with jquery to a local http server on the client computer with the following code:
var url = "http://127.0.0.1:1234/Ping";
var ajaxSettings = {
url: url,
timeout: 1000
};
return $.ajax(ajaxSettings);
the client application has the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: Accept, Origin, Content-type
This works great when using http but when using https i get a error.
Is there any way to solve this? (generating a ssl certificate and registering it seems a bit overkill)
We have configured NTLM authentication using SSPI on apache due to which the authentication is three steps, where there are two 401 responses followed by 201/200 response.
Now in IE browser, this breaks because of - Why "Content-Length: 0" in POST requests?
Apache web server sends a 400 bad request response due to empty post request due to which POST on the server breaks.
How can I configure Apache to not treat this as 400 BAD request and process it normally?
I have a problem with WebDAV. I have to get a list of files. I have this request:
<?xml version="1.0"?>
<D:searchrequest xmlns:D = "DAV:">
<D:sql>
SELECT "DAV:displayname" FROM "address" WHERE "DAV:ishidden" = false AND "DAV:isfolder" = false
</D:sql>
</D:searchrequest>
Response:
401 - Unauthorized: Access is denied due to invalid credentials.
I have user and password (who has access), but I don't know, how I can put this data to XML request.
WebDAV uses an HTTP authentication.
So you put your credentials to an HTTP header, not to the WebDAV XML in the HTTP body.
The basic HTTP authentication works like:
You get a WWW-Authenticate header from the server
WWW-Authenticate: Basic realm="server"
You include the Authorization header to the next request. The value of the header is:
Authorization: Basic username:password
where the username:password is in Base-64 encoding.
Authorization: Basic dXNlcjpwYXNzd29yZA==
For details, see
Basic access authentication on Wikipedia
RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
I have implemented SSO through mod_auth_kerb in our apache-active directory environment and it works just as expected. However the following knowledge is bugging me :
I requested a Kerberos protected page from two client machines, one user belonged to the Kerberos-setup domain and the other user belonged to some other domain.
I then compared the HTTP packets on the two machines. On both the machines, after the request for the Kerberos protected page is sent, the server responds with the following HTTP packet :
HTTP/1.1 401 Authorization Required
Date: Wed, 05 Sep 2012 14:25:20 GMT
Server: Apache WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Kerberos Login"
Content-Length: 60
Connection: close
Content-Type: text/html; charset=iso-8859-1
However, after the above response from the server the client machine's browser belonging to the Kerberos-setup domain responds with a WWW-Authenticate : Negotiate 'token', whereas the other client browser(user belonging to some other domain) does not respond at all.
Now my understanding is, that the client belonging to the other domain should have also responded with its own TGT+Session key token, which the active directory should have rejected. But why this client does not respond at all to the server's WWW-Authenticate : Negotiate challenge is beyond my logic.
What is even more confusing is that the server's HTTP response(given above), does not contain any information about the domain it is linked to.
So on what basis is the client browser belonging to the correct domain decide that it has to respond to the server's WWW-Authenticate : Negotiate challenge, and on what basis does the client belonging to some other domain decide not to respond to the same ?
Note : Both the client machines have Windows 7 and active directory is a Windows 2008 server.
I am trying to understand mod_auth_kerb's implementation of SSO, and this particular knowledge is key to that.
The module has the option KrbMethodK5Passwd turned on. It sends a Basic header to collect you Kerberos credentials. This is pointless for a non-domain client. Disable this option.
There is a hierarchy of strengths of auth mechanisms, the browser is obliged to choose the best. This is: Negotiate, Digest, NTLM, Basic.