The forums will load, but when we try to log in, it appears to authorize the credentials, but then we are presented with the "you must login or register" message again. There are no errors in the event log, nor in the IIS application, nor in the IIS logs.

We downloaded the source code, applied our config files, and ran it in Visual Studio on it's built-in IIS Express, and the login functionality worked exactly as expected. We performed a fresh compile from this working code, published it to the new site, and we experience the same issue where authentication succeeds but reverts to logged out condition.

We have tried changing the redirect on login as per several posts found here, but to no avail - the results are the same. We are now at our wits' end. Please help.

No that can not work. You need the same key you use on the first server. If you need help let me know there exist one code example on StackOverflow on how to get the current machine key

http://stackoverflow.com/questions/1755130/getting-the-current-asp-net-machine-key 

The initial installation was on a Windows 10 box on a separate network. This is the dev environment.

The second installation, with which we are having the issue, is on a fresh Windows 2012 Server box, which is our production environment. We ran a build of the code with the same config files from the dev box and it worked fine. We were able to log in with the administrator account. When running the installed version on this same box, with the same config files, logging in doesn't work and generates no errors.

We attempted to use a new machine key as we thought was suggested in your last post and had the same result.

Login SEEMS to be successful but the cookie doesn't seem to be generated and the account doesn't seem to stay logged in.

Below is from original web.config:

    <!--  Enable it if your application is hosted in a web farm or cluster (e.g. GoDaddy hosting) or you are using standard ASP.NET providers and encryption. 
          IMPORTANT: DO NOT USE THIS KEY! You need to generate your own machine key via http://yetanotherforum.net/key
    -->
    <!-- <machineKey validationKey="5B169A4270DB7D6A285CF068B81047D1A73A5FDDE9B204254AB86147B061C3C13DB6E84311E98EDFDD7FF50309DB9632A1C573A716CF120535EC3401BF7706D7"
        decryptionKey="910403AE3DEB5DD0AF73911DBB180518144AC983C1C7E7BDEE1CC8B6C74CBEF3"
        validation="SHA1" decryption="AES"/> 
    -->

And this is the machine key from the old server that we added at your advice:

	<machineKey validationKey="EC382F168EB82BD9FBC8D7CCC5D9F9ACC907F40E248F41E32C319F4A246235BD1838DD3E75E2E986731A6D1552022146E04898724ED669C21DE659CE0881D842" decryptionKey="8C1EFA68E43B0E0397FA7E6226550943B094ACBB9830B3BC" validation="SHA1"  decryption="AES" />

The login fails the same way in either case with no messages in the event log or IIS log.

I am beginning to wonder if there is a difference between the IIS settings for each environment, but a quick run through of the IIS configs doesn't reveal any obvious discrepancies. Unless we are being obtuse about something you've already explained, we don't know where to go from here.

We don't currently have an SMTP server set up on the production site, so I'll set that up and see what happens.

Ok if the new account also fails then the issue is not the machine key.

As you set in your first post it seems that the auth cookie is not correctly set. I assume you use for both servers the same web.config? At this point i really no have clue whats wrong. I remember that problem occured before but now i no can find the topic with the solution.

Name: .YAFNET_Authentication

Content: 132D19F6CD8A9F36308F24AB60BEE9D403C75A01BB9E519611E4DF27AE9F51CD8A0C0A5B1FE058F91E8B7280B9C25B8805C0D7EC4D81C8C4083D4C134A4FA7C20FE3A7DC447F69378372F8F38629580834533442

Domain: localhost

Path: /

Send for: Any kind of connection

Accessible to script: No (HttpOnly)

Created: Tuesday, August 2, 2016 at 1:24:40 PM

Expires: Thursday, September 1, 2016 at 1:24:40 PM

We have the web.config for the baseline app set up differently on the dev machine and we didn't think to look at the local one since we were focusing so hard on the forum app. This is probably a good lesson in managing nested web applications, each with their own config files.

This thread  inspired the solution to this issue.