I have client who has installed our Silverlight app. The app works fine when running from the IIS server. It also works from a client machine - but only if the user is logged in as local admin. If they log in with a non-admin account, they get a blank screen where the silverlight app should be.
When I look in the server logs I see that the XAP is being blocked, getting 401 response code.
Any suggestions? It feels like this has to do with accounts, which I am no expert in.
There is probably something wrong in the IIS security settings.
Is Anonymous authentication activated in IIS?
Related
I am using Blazor WebServer with Identity Server template, downloaded from ABP.IO
When run locally, it all works fine. Login is success and able to see the post login page.
Once deployed to Azure App Service, Identity page shows correctly and even able to login. On the Blazor page, click on login, enter credentials, redirects back to the logged out page, but seems session is created, and login button shown. there is no error logged in the log files and console also has no errors.
Redis is running as Azure Redis Cache and there are no reported errors. I have deployed to below URL on Azure using the default template. Nothing confidential so I can share. The credentials are also the default credentials for abp.io.
Blazor: https://shoutout-core-dev.azurewebsites.net/
Identity: https://shoutout-identity-dev.azurewebsites.net/
It seems that there is no error already. Because when I make a request via swagger, I can access the necessary user information. As you stated, actually the session was created.
But there is a problem with the UI. To test the problem, after publishing the application in your local, can you run ASPNETCORE_ENVIRONMENT with the Production environment variable?
In addition, we need your ABP version information and your steps while publishing in local so that we can repeat the error.
this problem probably occurs on chrome. If you try to use firefox, you will pass the problem.Also, you can check this link for the fix on the chrome :
https://community.abp.io/posts/patch-for-chrome-login-issue-identityserver4-samesite-cookie-problem-weypwp3n
I am developing an ASP.NET MVC website. It is hosted in Azure and users are authenticated with AAD for our single tenant. I intend to make the website available in a Teams app, so that my coworkers can navigate to my website via the Teams Windows app and the mobile app.
I follow these steps to integrate security in a web browser: https://learn.microsoft.com/en-us/learn/modules/msgraph-build-aspnetmvc-apps/5-exercise-add-auth
I followed these directions to integrate security with Teams: https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso. I'm not sure that I did this correctly.
At this point, I can:
Login with a web browser
Login via Teams mobile app
Load Teams in a web browser then load my app (not a use case that I need to support, but this worked and I was not prompted to login. I assume that I wasn't prompted to login because I was already logged in directly in another browser tab).
I cannot:
Login via Teams Windows app -- This is my primary use case unfortunately.
When I try to login with the Teams application on Windows (using the same pages and forms as on mobile), the page just disappears. I'm not prompted with the usual Microsoft login page.
How can I diagnose the cause of the problem? I don't see any obvious errors reported in Teams. Is there any way to get access to the root error?
EDIT:
login.microsoftonline.com is reporting "Your browser is currently set to block cookies. You need to allow cookies to use this service." I'm now aware of the SameSite changes (https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-handle-samesite-cookie-changes-chrome-browser?tabs=dotnet) and I've implemented the recommended SameSiteCookieManager code to address the SameSite issue.
I'm still running into the same issue. No exceptions or errors reported except that Teams does not accept cookies.
May have to break this down further, here's how I would decipher it.
First of all, you will have to figure out if the issue is with Teams or on the Auth side.
Figure out which line of code is executing last? You can debug or write to terminal/logs.
Do you see any exceptions? Ideally debuggers can help or you can add some code to catch any exception.
If it's failing before executing any code, do you see any http requests going out, you can use fiddler for this. See if you are seeing any error codes.
If you are using Windows then check Event Logs for any errors or exceptions for Teams App. Look at the Application logs.
Look out for Audit logs and sign in logs and check if you see any activity in your tenant when you run this app.
https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitor
Some other points would be to check if you can repro this with a sample app or a different user(elevated user). If there is any additional info do share.
My company is using this service Aha! Ideas for internal idea-sharing. Everything is set up correctly with Aha! and the page site loads and requests the email for the user. Once they put it in the Microsoft credentials from the host machine so an SSO and they are redirected to the secure page. On machines where the user has not authenticated against our domain on the workstation, they are redirected to the Microsoft login and after they login, the user is redirected to the site.
So Great!! that is all working perfectly.
Now, I go into App Studio in Microsoft Teams and set up the site to load as an App in the Sidebar. I have added the main URL as a tab, I have set up the Valid Domains and included login.microsoftonline.com and I have set ADD App ID to the one used in the SAML2 setup of Aha!.
When I load the app I get the page requesting my email, this is from Aha!, and when I submit it should use SSO from Teams to log me in. I am logged in to Teams using my company Microsoft Account. At a minimum, it should redirect to the login.microsoftonline.com and request my username and password. Instead, I get nothing but a blank page.
Anyone have any ideas as to why it's not working, or what I might have done wrong?
'SSO' in the truest sense with Teams -definitely- won't work - it requires changes to the app itself, which you don't control, but even aside from that, depending on how the app ends up doing it's authentication, this still might not work, as you're seeing. Is there maybe a chance Aha! is working on Teams integration?
I have been updating a system that has been in place for sometime and finding some clients have issues with login on mobile devices.
I have a test system in place and setup Application in Azure AD and noticed during testing if I login with incorrect credentials, login.microsoftonline.com will show:
Sorry, but we’re having trouble signing you in.
AADSTS50020: User account...
When login to the clients live systems I don't see this error and just get returned to the home page of the application.
The only difference is the client apps are configured with credentials for there Azure AD instance and I cannot access them. These where also built on the legacy App Registrations but that shouldn't be issue (ha). The server side is the same implementation.
Why am I not seeing the AADSTS errors in productions sites?
If you are not seeing any error and are just getting returned to the homepage it seems more likely to be an issue with the Redirect URI or the app registration configuration.
Please confirm that the redirect URIs in your application and in your registration are what they are intended be.
Also, ask them to check the developer tool logs when signing in to see if anything shows up. It might be failing but not triggering the error message.
I setup a test Server 2008 box with Active Directory and ADFS 2.0. I have an ASP.NET app which uses WIF to federate identity. ADFS is configured to use Active Directory for identity info. I used WIF to configure the client app to use the ADFS endpoint.
When I attempt to load the ASP.NET app as a user from the browser I am redirected to the ADFS endpoint and am prompted for credentials. I have attempted to login with several users accounts, even resetting passwords but the credentials never seem to be correct and a 401 Unauthorized is returned. I can login to other systems successfully with the same credentials.
I have enabled debug trace in verbose mode and enabled auditing in verbose mode but I can't find any errors or info to help me figure out the issue.
How can I get more info to narrow down the problem?
UPDATE:
I found that this issue is caused by my testing environment. My dev machine is on our corporate domain (acme.com). I created two 2008R2 VMs for a test Domain Controller (notacme.com) and Web Server.
If I attempt to access the website from a computer on the acme.com domain the error described above occurs. If I attempt to access the website from a computer on the notacme.com domain it works.
What can I do to access the website from a computer on the acme.com domain?
Apparently this was caused by the Extended Protection feature built into ADFS. In trying to troubleshoot this issue I had Fiddler running to track the requests/responses but at one point I swear I turned it off to test as well but it still didn't work. Apparently I didn't fully remove the Fiddler proxy because after a IE reboot and with Fiddler not running it worked in IE but found it still didn't work in Firefox or Chrome. This led me to a TechNet article which described the behavior I've been seeing in conjuction with using Fiddler.
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
In my experience, every sign-in failure in IIS (including AD FS) is logged in the 'Security' event log as an 'Audit Failure' event, which contains more details. So I would search in the event viewer on the AD FS system, and see what those events have to say. Also in the event viewer, check the 'Applications and Services Logs' -> 'AD FS 2.0' -> Admin event log.
It looks like you did try to look at the HTTP traffic, e.g., using Fiddler. That's good. I presume the problem also occurs when Fiddler is not used?
(Do you perhaps have the problem of a repeated sign-in form, after you entered correct user name and password? Then look at the following answer: ADFS authentication - IE8 works, Chrome fails.)
(I have also seen a case where the initial authentication was successful, resulting in 'Audit Success' events, and then a 401 resulted from a later redirect. Also in this case the event logs on the AD FS system helped.)