First of, sorry for not posting any actual code, but I just want to be pointed in some direction. Might post code later if needed.
So, I have 3 applications running in IIS
1 - Application itself
2 - Authentication and Access Management
3 - NTLM
All use application pool with framework 2.0 Classic Mode.
1 and 2 uses annonymous and form authentication,
3 uses windows authentication.
The flow is, when you access 1 or 2, it redirects to NTLM for auth and returns with the authentication.
If I access the first one its all good, it goes to the ntlm and even if I dont have a valid windows account it returns to the app login page.
When I try to access the second one I get a redirect loop from the ntlm to the login page to the ntlm and so on...
Both have the same configuration.
I know this might not be very explicit, but I going insane over this and don't now where more to look.
Weird as it may sound, when setting the machineKey on web.config, I put decryption="Auto", which is totally normal... because it's the same setting in IIS console. But that was causing the error in event viewer saying invalid ticket.
Still can't figure out why... anyway if someone come across this same weird issue, here you have what I have done. I took out that "decryption" setting from web.config
Related
I have a question regarding SQL Server Reporting Services 2019:
We have received a HTTPS-certificate and added a URL for both Web Service and Web Portal. When we try to access either /Reports or /ReportServer on HTTP we can get through with no problem, but when we try to access on HTTPS then we are met with a logon dialog which will give three attempts at log on before displaying a white page. All attempts at entering a valid combination of user name and password returns a 401 error.
We've tried removing and reinserting all bindings for HTTP, HTTPS, SSL, changing logon mechanism in the config file to use Kerberos, NTLM or a combination of those but nothing works.
Does anyone what the source of this problem might be and how to solve it?
We figured out what the problem was. Authentication issues did not behave the same for HTTP and HTTPS. My test user wasn't a member of the correct user group. Once we gave it "System User" access then we could log in.
My current setup is like this. The entire project was built using the official docs here - https://identityserver4.readthedocs.io/en/latest/
API Server
Auth Server with local login, google login and github login
Console based c# client
JS based client
MVC based client.
(all of it, as described in the official docs)
Locally, all of them work beautifully. Able to login, access api endpoints, logout, redirect, the whole thing works smooth.
I have deployed all 5 of them to five different azure web apps. They all have the standard xyz.azurewebsites.net domains ready to use. Now, I have run into some problems.
the console C# client is able to talk to the deployed auth server, collect token using a local account on the auth server and make calls to the deployed API server. Based on this, I assume that both the api server and the auth server working hand in hand, as they should.
Problem #1 - the JS client keeps saying
'The login is blocked because of CORS Missing Allow Origin '
Problem #2 - the MVC client loads the auth server, and then the auth server gives me this error.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Note : I have set the CORS policy on the auth server, both these clients, under client definition as follows. I am not too concerned about keeping the auth server open, so dont mind if any and every domain can call the auth server.
AllowedCorsOrigins = { "*.*" },
Also Note : I have set the URLS in the code before deployment. all loclahost:port number lines have been replaced correctly with the corresponding now published URLs.
So, what am I missing out here?
Update 1
I was able to solve the CORS issue. Have posted a answer here on another question.
Not able to enable CORS for identity server 4 in asp.net core
Update 2
So, now, both the JS client and the MVC client, are giving identical errors.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Update 3
I have opened an issue which has log details.
https://github.com/IdentityServer/IdentityServer4/issues/4691
I am not sure if this counts as an answer, but posting for my own question, as it might might help others. Also, this is only a guess at this point.
I found out that the redirects were permanently stored in the database I used with EF migrations. That mean, local in memory redirects were being overwritten anyway by the database stored migrations. I believe this is the issue.
I also realized that the console app is working fine for it does not depend on redirect URLs where as the JS and MVC based clients dont work because they do depend on redirect URLs.
At this point, the best thing to do and for you (if you used EF migrations to store your auth server configuration) on database would be start over and switch to in memory only. Alternatively, you can try and update the database to suit your deployment requirements.
Ultimately, I believe, unless it is absolutely necessary, keep the auth server config (like redirects and CORS settings) in memory as they dont take up much value and are rarely changed.
I was investigating how to get status code 500 error messages to give me more information when these occur and happened upon the MSDN post about using the ClientHttp stack.. Which was all just so magical seeming until the application got deployed on the staging servers and it seems to completely fail now with authentication
I'm guessing this is due to the whole cookie issue as it relates to the ClientHttp stack...
I'm using RIA services and when the application starts it runs 3 or 4 RIA WCF service calls preloading data in the background and now with the new ClientHttpStack an authentication dialog pops up pretty much every single time a request is made. We're using Windows Authentication so before it would just make you authenticate in order to access the page serving the XAP file... But now you login with Win Auth and then all the subsequent calls repetitively ask for your credentials...
I'm assuming the only way I can fix this is by doing this
http://msdn.microsoft.com/en-us/library/dd920298(v=vs.95).aspx
And then possibly adding an endpoint behavior onto the DomainClient so that before requests are handled it tacks on the cookies...
I've tried doing this for a bit now and I'm not really succeeding... When I run the app in FF or Chrome it still pops up with a whole bunch of login boxes. So I'm just curious if I'm barking up the wrong tree or if I should continue trying to figure out where I'm not quite propagating the cookies through
If you are using the ClientHttp stack, you'll need a place to store your cookie client side, said a HttpCookieContainer. It's just a wcf behaviour to be inserted in the ClientHttp stack. Please, have a look at this post from Kile McClellan and see if it helps you.
edit updated with new information
I've been trying to configure a ASP.Net site to use windows authentication impersonation, and use this to call Sharepoint 2010 web services.
I've enabled impersonation and windows authentication on the site, and given in a "classic" .net 4.0 app pool identity. I display the user that is logged in. When the site is run from the server, everything works fine - the user is impersonated correctly. Tried with several user accounts (but all local admins...). This can upload a file to sharepoint which records the "Created by" "Modified by" as the site user (and not the app pool identity). This is the situation I want.
When run from a client machine, it fails. The page is loaded, but it seems to fail when it tries to access the Sharepoint lists service with a 401 unauthorised. Further inquiries have shown me the following info the Sharepoint weblogs when calling the list.asmx service:
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 0 0 13
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 1 2148074254 3
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 1 5 1
From: http://support.microsoft.com/kb/969060 I know that: "The win32 status of "2148074254" (also defined as -2146893042 / 0x8009030E / SEC_E_NO_CREDENTIALS) means "No credentials are available in the security package." In other words, the client has not sent any credentials."
This looks like my web site is not passing the impersonated credentials to the Sharepoint site. Is there any way of solving this? Because it works from the server I'm sure it can work, but I'm at my wits end trying to find a solution.
This is caused by windows authentication using NTLM rather than Kerberos (I thought it was using Kerberos...).
I'm looking into getting Kerberos properly configured, but this is a big task. In the meatime I have simply moved the site and it is now hosted on the same SharePoint web front end as the web services it is contacting. Now there is now double hop, no need for deleaged credentials, and so it works :)
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".