I have an aspx page embedded in Dynamics CRM. The aspx page uses openId and an adfs application group to authenticate and has been working up until security update KB4493473 (it is an assumption that the update is causing the issue). Prior to the update, when the user loaded the CRM form, the iframe would seamlessly load without issue or authentication prompts.
Since the update, the console gives this message: 'https://sts...... &x-client-SKU=ID_NET451&x-client-ver=5.2.1.0' in a frame because it set 'X-Frame-Options' to 'deny'.
I have not found any way to have adfs NOT send that x-frame header, is there any workaround here?
We had a similar problem since some week on a project I work on (iFrame integration not working any more because of ADFS, apparently since May Windows cumulative update has been installed)
Luckily, a colleague found a workaround with this ADFS PowerShell command :
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
This command is documented for ADFS 2019 (but works on ADFS 4 too) : https://learn.microsoft.com/fr-fr/windows-server/identity/ad-fs/operations/customize-http-security-headers-ad-fs
Hope this will help.
Regards,
Related
I am trying to auto login for specific url like webdav url for document.
We want to modify documents uploaded to document library.
We are passing webdav url to ms office to open document. It is our intranet project and we are using ntlm.
I am unable to pass credentials from ms office to our liferay server.
When we click webdav url from our browser where I logged in already then it redirect to office and when office tries to open that document from liferay server then it is asking credentials, as I am already logged in then it should not ask credentials at the time of opening documents using ms office.
I am thinking if we do autologin for webdav url like url="/webdav/*" and able to do autologin then my issue would resolve.
Please help me on this.
I am using liferay 7.2 CE.
Windows
This is a long-standing issue that is not quite related to Liferay. The fact is that when you authenticate in Liferay from the browser it stores a session cookie inside that browser. When you open the webdav url, it's actually ms office that contacts the server and then it doesn't know about your browser cookies. So it does ask authentication on its own.
Now you are using NTLM which is Microsoft own SSO protocol, would it be nice that it does authenticate you on a Microsoft product. It's been a very long time since I had this exact same issue (2014, Liferay 6.1) but I believe NTLM info is only sent in network trusted sites and by default any site is not. You have to make change to your domain controller to allow them.
Next in that time, I think the Liferay NTLM filter was not called on a webdav path, we did have to create a hook to apply it. I don't know if it has been changed since then.
Additional info asked in the comments:
filter hook mapping documentation:
https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/servlet-filters#step-2-map-urls-to-your-servlet-filter
The ootb ntlm filter is here: https://github.com/liferay/liferay-portal/blob/7.2.x/modules/apps/portal-security-sso-ntlm/portal-security-sso-ntlm-impl/src/main/java/com/liferay/portal/security/sso/ntlm/internal/servlet/filter/NtlmFilter.java
I was trying to setup OAuth workflow using the sample application as given here
However for some reason, after I enter my okta user Id and password, I never gets the control back on my call-back URL and application just hangs indefinitely.
However the normal Javascript Singn-in widget (check this link) with the minimal authentication does work and I get the control back to the redirect URL. But this is not for an OAuth2 workflow... which is completely useless for me. Because all it does is provide authentication service using Okta tenant app and it will redirect you to your App URL. This does not provide any authorization grant workflow or other OAuth2 complex workflow. May be useful for some application but not for enterprise app where you want to retrieve user profiles, and create a login session based on user profile data retrieved from OKTA.
So my question is why is the OAuth workflow not working using the PHP application that uses JS sign-in-widget? And why there are no instructions or warning on this page for this costly service (this is not free and many org is probably paying for this)?
I spent almost a day trying to setup my Authorization server as per the instruction given on this link, but nothing works. Any idea what must be going wrong ?
Does this entire example works only after contacting OKTA support to enable the Authorization server feature? Because, I also saw a documentation here that says that this is Early Access (EA) feature (and it is probably recently added in OKTA? Extremely frustrating experience).
BTW I sent email to their customer support to enable this Authorization server feature just in case if I am missing something. If this does not work then I will have to create my own OAuth2 server using Laravel 5.4 PHP framework, which is probably the quickest solution and 100% free.
I also tried to test the Authorization server setup as per the instructions provided here.
I was successful in getting the following end point working:
/oauth2/:authorizationServerId/.well-known/openid-configuration
But I am unable to get any scope and claims using api end-point:
/api/v1/authorizationServers/:authorizationServerId/scopes
So in short, I am so far unable to test my Authorization server to get my authorization grant workflow working.
Where can I look for some troubleshooting advice?
Is there another way to check whether I have configured my OKTA Authorization server properly?
I found out that the JS script provided for the PHP sample is not right for the workflow I am working on. So after changing that JS Script, things started to work.
Edit: Also please note that Setting up Authorization server is a new feature (It is Early Access feature) in OKTA. It is not enabled by default. So you need to contact OKTA support team to enable the Authorization service endpoint and functionality provided by it.
Whenever i try to register for Azure Free Trial, i feed all information and as soon as i land on Verification by Card page, it loads and then instantly shows me Session expired. I tried using different ID, different network and also different city to perform the action. Azure support does not work and googling doesnt help much either.
Is anyone else experiencing same or i am only one with such a problem.
I have also attached the screenshot of the issue.
Azure Session Expired.png
I would assume only two thing could cause this.
1. The Browser.
Can you do a clean fresh install of your preferred browser? Maybe there is a cookie issue. Microsoft has a notorious browser past. Are you using IE? If not true installing IE.
2. The Site's Code
Nothing can be done there. Just call Microsoft Support.
I hope this helps.
Best,
Tim
I doubt there's a global access issue with Azure, but you can double-check the status here.
It looks like a trouble with your current device configuration.
Check that your clock is correct. Your browser may remove cookies or
reject certificates because of wrong clock.
Check your browser-specific settings for limitations and security measures like disabled Javascript or enchanced security. It's also worth checking the addons and extensions for the same reason.
If you're on Windows, check Internet Settings or try to add the site to Trusted Sites list. A few months ago I had to add Microsoft sites to the Trusted Sites list on Windows Server box to solve a similar issue.
The simplest solution would be to try another device.
I had the same problem. Trying different approaches to solve the issue ultimately had the same outcome...I couldn't create an Azure subscription when logging in using my O365 credentials.
Working with Microsoft Support the approach that successfully worked for me was to open an InPrivate Browser session. Navigate to https://account.azure.com/, which causes a credential challenge, which you should use the O365 credentials. Ultimately a successful outcome.
BTW> I could only engage MS Support by submitting a Support request. MSFT were responsive in that I was contacted within 60min, with a suggested resolution.
Sometimes, the login screen will appear if the user clicks the back button and then chooses another link, instead of the content that should be displayed. It's like the application suddenly thinks the user is not authenticated. The user then has to re-authenticate to continue browsing. This happens while the user is actively browsing, so no timeout should occur, and after authenticating, the content is shown (so it's not an authorization problem).
This problem is unfortunately quite difficult to reproduce. The user who has experienced the problem most often is using Windows XP with IE 7, but the problem has also appeared with Windows XP and IE 8. I can't seem to reproduce the problem on Windows 7 with IE 9 or Chrome 18, but because the problem is difficult to reproduce, I can't say confidently that the problem is browser or browser version dependent.
Our ASP.NET MVC 3 app uses Forms Authentication with role information stored in a SQL Server database, and membership information in Active Directory. Hosting environment is IIS 7.5 on Windows 2008 R2.
Has anyone else seen this problem, and know of a workaround?
On the server, I guess that you are using a custom IPrincipal which you need to reattach to the request thread for each request? Are you doing this in an HTTPModule or in global.asax? What page event are you hooking into to authorize the thread?
I have noticed differences in authentication being available in different runtime contexts dependent on which event I use. I now always use OnAuthorizeRequest and check that application.Context.User != null.
But the symptoms you are describing sound more like the authorization cookie is missing from the request intermittently.
Add some debug logging for each request and monitor cookies and authorization to see if you can detect the conditions that cause it.
I have an ASP.NET MVC 3 web site that uses Windows Authentication running under IIS7.5. This web site also checks manually for groups in AD using the GetRolesForUser method of a custom RoleProvider. This isn't anything special, and has been working fine for a few months now.
However, we now have a user that had their Active Directory user name changed. They still have the same actual AD account, but to them their login name is now different.
Unfortunately this has broken the web site for this user. I'm using Elmah to log errors, and I have noticed that REMOTE_USER is using the old account name, and LOGON_USER is using the new account name. It looks like the username parameter of the GetRolesForUser method is getting the old account name - so I assume it is using REMOTE_USER.
Should I be targeting the web server or the web site for a fix? I've read that LOGON_USER and REMOTE_USER are only different if there is an authentication filter installed. I'm not aware of anything like this on the web server (although I'm not sure exactly where to look), but does MVC3 add this somehow?
Typical, after I posted, my Google-Fu kicked in.
Seems like this is a known issue (by design) with the local sid cache:
http://support.microsoft.com/kb/946358
Resolution is to follow the registry change in article (and undo it again?), or reboot the web server. I have read that a IISRESET might fix this too.