We have an ASP.NET v4.0 IIS Webapp and we are getting this error a few times a day and it requires a reboot of the domain controllers to fix. There are no real issues with the trust that I can see. With two servers running the web app one can work while another shows this error. The issue happens when we contact Active Directory to get a users roles so that we can build a menu. When the issue comes up, I cannot remote debug the app.
This is the line that starts off the error:
System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection
sourceAccounts, Boolean& someFailed) +1085
I have tried unjoining and rejoining the web server to the domain. And have followed this kb article https://support.microsoft.com/en-us/help/324383/troubleshooting-scecli-1202-events that talks about users with spaces in their name. So far no luck.
Is there anything else I can check? Are there some safeguards I can put into the app to help mitigate this issue?
The issue that we had was caused by our application checking to see if a user was in a security group that did not exist. Once we updated it so that it only validated against existing security groups, the problem went away.
Sometimes if you are not connected to domain also cause this issue, I solved.
Related
I have very strange problem. I use ZfcUser as authentication module. I made a lot of projects on lot of different environments using ZF3 and ZfcUser module. I have nevere experienced such kind of problem which I will explain bellow. In my current project I cant login into system on production server. I succesfuly log from local env, or other test environments.
I try to investigate whats going on. I went to login page on production, entered my credentials and system redirects me to home page. No errors, no warnings... notihnig. But I was not logged in. I check the identity from the framework (identity()) - it was null. I thought that may be it is server issue with the php sessions. I checked the sessions on server. It appears that the problem was not there.
The framework succesfully stored the data it needs in sessions. I found the Zend_Auth key, the identity key and the value for logged user. It seems that with php sessions everything is OK.
I am powerless and cant even think about what is going on here and where is the problem. No errors are thrown. I trace the execution of code on local and production environment. Everything is same. The frameworks seems to work properly. But the IDENTITY is allways null
Found the problem.
So, the site was runing under a subdomain. Let say sub.domain.tld. This site is different from main domain which is domain.tld. In the programm code, the favicon of application was requested form the domain.tld not from the sub.domain.tld.
As a result when you hit the http://sub.domain.tld the browser stores two PHPSESSID cookies. One under sub.domain and another under domain.tld which couses Chrome to messed up
Interesting is that, Firefox and IE didnt messed with the sessions and the site was working porperly. I dont say that Crhome is guilty. Obviously the programm code was cousing the problem. But Chrome recognize that one domain is sub domain of the other
Thats why, when I was trying to run project on different environments as local setup or different domain e.g. test.different-domain.tld, ther were again two PHPSESSID cookies set, but in this time Chrome didnt messed up with the sessions becouse test.different-domain.tld is not recognized as subdomain of domain.tld
Very small and silly mistake, but cousing big problems
I just created a webform that is hosted in my Azure subscription. I set it up with authenication via my works Azure directory for authenticating users. In debug this works fine and I am able to login with my work credentials and then view the website via local host.
I have published this to my Azure and it says it is running and working fine. So when I try to connect to the website it continuously redirects me to the localhost resulting in an error.
I have checked the web config.
Here is the google network chain of events when it occurs.
I am really lost as to what is wrong and what I need to do to fix this so any help would be greatly appreciated. I'm sorry I can't offer more but I don't even know what is wrong to begin with or where to look. Is there some setting in Azure that I need to add the website too?
I have solved this issue. Since it was such a pain I will keep this up as I couldn't find any answers on this. It was actually quite simple.
You have two options. The one I did and which worked was changing the publish profile as below:
Add the domain where the authentication is occurring. So if you have your web app hosted by a different azure account that which is authenticating the users, use the one that is authenticating.
This will create two versions of your app on the site one for local host and one for the actual site.
The second option(I have not tried this but it should work) is to go to the Azure account where you are authenticating the users and go to applications and then configure. Change the APP URL from local host to the url you are trying to get to.
Here is an excellent link that explains how to do this clearly.
Click this link for detailed explanation
I also had this issue and took these steps to resolve
navigate to the app registration in AAD
Open the manifest
Change the ReplyUrl to the url of the app (e.g. http://appname.azurewebsites.net)
Then I got the error
Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.
Next I cleared all cookies from the browser, and this changed the error to just
Bad Request
So I went back to that ReplyUrl and changed it to https://appname.azurewebsites.net/.auth/login/aad/callback and now it appears to work.
Note I also had to make sure I didn't have the site open in any other tabs before it started working
I had this issue when I switched an app from our company Azure over to a customer's Azure. In my case I'd forgotten to update the ida:ClientId, ida:AADInstance and ida:TenantId, which then meant that the value I'd set for ida:PostLogoutRedirectUri was ignored (I think) and instead my app redirected to localhost.
Once I changed those ida values to the values from the app settings and subscriptions settings on our customer's Azure it all worked as expected.
It took a while to track down all the values in Azure portal as they are all called something different, or aren't named at all:
ClientId can be found at Azure Active Directory > App Registrations > YourAppName. It's called 'Application ID' in Azure
Domain can be found on Azure Active Directory > Overview. It's currently in the top left in the format somename.onmicrosoft.com
TenantId this is the Azure AD instance ID, get that from Azure Active Directory > Properties and then it's called 'Directory ID'
I spent a lot of time trying to work out where the localhost port that was being redirected to was in the code, but it simply isn't there as far as I can see, so I have no idea how Azure was choosing what localhost address to redirect to!
You need to set another parameter in configuration that is replyUrl and assign to your web app, other wise it takes the url from which it was originated.
I was able to fix this by changing my Startup.Auth.cs file redirectUri from "https://localhost:44316/" to https://myapp.com/
I am using msdeploy to push out website code to 4 different servers (test and production servers). Works fine on the first 3, but the 4th is giving me an ERROR_CERTIFICATE_VALIDATION_FAILED error. I am using the -allowUntrusted option.
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:iisApp="E:\workspace\testDeploy\outproject\_PublishedWebsites\<webfolder>" -dest:iisApp="mycompany.com",ComputerName="https://<hostip>:8172/MsDeploy.axd",UserName="<userid>",Password="****",AuthType="Basic" -allowUntrusted -enableRule:AppOffline -skip:objectName=filePath,absolutePath="^.*<webfolder>\\web.*\.config$|^.*mycompany\.com\\web.*\.config"
Error Code: ERROR_CERTIFICATE_VALIDATION_FAILED
More Infenter code hereormation: Connected to the remote computer ("<hostip>") using the specified process ("Web Management Service"), but could not verify the server's certificate. If you trust the server, connect again and allow untrusted certificates. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED.
Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Error: The remote certificate is invalid according to the validation procedure.
Any idea what I am missing?
Adding <AllowUntrustedCertificate>True</AllowUntrustedCertificate> to my pubxml file seemed to fix the problem initially.
Upon re-publishing days later though, I got the same error. I went into the Publish Settings, re-entered my password and the publish succeeded.
I'm now thinking my initial problem was solved by re-entering my password, not by adding <AllowUntrustedCertificate>True</AllowUntrustedCertificate>.
-allowUntrusted did not worked for me.
I used this:
/p:AllowUntrustedCertificate=True
Adding this solution as none of the others worked for me...
I had to add these lines to publish profile:
<UseMSDeployExe>True</UseMSDeployExe>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
After adding those, publish still failed. Then I opened the publish profile settings, clicked validate connection, and saved. Only then did publish succeed.
I fixed this by going into the publish settings, then clicking "Validate Connection" at the bottom. Then this error goes away.
The problem was with the password for the user on the destination system.
I saw on another post that someone moved the -allowUntrusted flag before the -dest entry. I tried that and I started getting a ERROR_USER_UNAUTHORIZED message. Everything was correct with the password as it was entered, but it started with an * character and also had a single quote in it. I generated a new password for the user that didn't use those special characters and changed it on the remote system. After that, everything worked fine.
I was able to run the command as shown in the initial post without any error.
If you are getting a ERROR_CERTIFICATE_VALIDATION_FAILED or ERROR_USER_UNAUTHORIZED and everything is set up properly, try changing the password assigned to the user on the destination system. It would seem that some passwords just won't work.
Another Potential Solution - Deploying Web Jobs specifically
I know this is an old post, but I ran into this issue with VS 2019 when deploying my Azure Web Jobs. None of the above worked for me. What did end up working was re-authenticating using the tooling after updating the publishing profile. The way I resolved it was by right clicking the solution and selecting "Publish as Azure Webjob.." Even after creating a new publishing profile it still failed. I then added the following my publishing profile.
<_DestinationType>AzureWebSite</_DestinationType>
<UseMSDeployExe>True</UseMSDeployExe>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
I tried publishing it again and it failed. Then I re-authenticated by clicking the edit password link shown below.
When you do, you'll see the following screen. Click on the "Attempt to retrieve credentials from Azure" link.
Don't forget to hit the save button at the bottom after retrieving the creds from Azure. Once you do, go back and try publishing again. It should work just fine.
NOTE: If you just pulled down/created your publishing profile for the first time, do not click the edit button under the name of the Publishing profile and validate the connection that way as shown below.
If you do, it may remove the username/password from the UI for the publishing tooling shown in my first image above. If it disappears, you need to start this process all over again by deleting your profile, creating a new one and finally following the steps above in order. I don't know why it does this, but just something I noticed.
I notice you used the IP address for the deployment server:
-dest:iisApp="mycompany.com",ComputerName="https://<hostip>:8172/MsDeploy.axd"
This caused the certificate validation error for me because the SSL certificate was issued for the domain name, not the IP address. Changing to domain name instead of IP address fixed it.
Just want to add my 50 cents and my solution so it may help someone else.
what i did yo solve this is to use remote desktop to connect to the host machine
and when asked to accept the machine certificate ( after input login and password ) i marked remember this at the bottom.
hope this help someone
I have an ASP.NET web site that responds with multiple skins depending on the domain that it is accessed via.
The problem is that authentication and some other features seem to suffer random glitches where the user is sent back to the log in screen, or other session controlled values appear to have been lost - but only when accessed via one of the domains. The other domain does not suffer the same issue.
On our test system, the issues DOES NOT exist when accessing via any domain. On live, the issue will happen at varying times during the session, even with identical steps followed. It is for these reasons that I don't think it is a bug in the application software.
On the live system, where the issue is, two websites are set up in IIS, each with bindings to the required domain. One accesses the site through a virtual directory at http://mysite.com/myvirtualdir, the other accesses the site at the root path at http://myalternatesite.com/. I don't think that the virtual directory is the issue however.
I've now solved my problem, though still not sure what the exact cause was.
I opened up website properties for the two websites in IIS, the one that worked and the one that didn't and compared properties.
For anyone else trouble shooting this issue, these are the steps that I took, in order of how likely I think they were to be the cause of the issue.
Second website was using Default app pool. There is nothing particular about the Default app pool settings on this server that would cause session to be lost from what I can see, but I have now changed to use the same app pool as the site that was working all along.
Disabled windows authentication to match the working website.
Changed default documents so that only the required document was listed.
Limited connections to 500 to match the working website.
Hope this is of use to somebody else.
I have been trying to configure a small website on a Windows Server 2008 running IIS 7. Unfortunately, when trying to load the website I keep getting the error: Server Error 401 - Unauthorized: Access is denied due to invalid credentials.
The permissions on the website folder include read, write, and execute for user ASP.NET v4.0. I even clicked "Check names" before adding the user to folder, to make sure that I spelled everything correctly. But the error continues to show. Also, I noticed that everything works okay if I add "Users" to the permissions for the folders containing the website, but I don't see why this should be necessary. I only want to give ASP.NET v4.0 access to the folder.
Some other noteworthy points include that I'm using the ASP.NET v4.0 application pool, that the managed pipeline is integrated, and that load user profile is set to true.
If anyone has any ideas, I'd appreciated the help. I'm stumped!
EDIT: Does it matter that the website is on the d: drive? I just assumed this wasn't important...
I find I always need to give IIS_IUSRS access.
I'd recommend you to use the Process Monitor to detect which user is actually accessing the file.
Here you'll find an explanation about how to achieve that.
Open IIS7 on the server. Highlight the site, and double-click on the Authentication icon in the Security Section. Check that Anonymous Authentication is enabled.
Some troubleshooting links for this particular issue:
http://support.microsoft.com/kb/902160
http://support.microsoft.com/kb/907273