Since you can login from the same server, and not another, and you're running on Windows, could a problem be you have Windows Firewall running and blocking inbound connections?
By default Splunk will install with the web-gui listening on Port 8000.
Port 8089 will be the splunkd admin port - normally you do not need to worry about the admin port at this point because you probably aren't using the REST interface from the outside, running a Deployment Server, and some of the more "enterprise" features.
If you are wanting Universal Forwarders to connect and send data in, and you've been following some of the Splunk Documentation, I am going to assume you created a TCP Input on Port 9997
So in general if you're having connectivity issues from outside the server, you probably have something blocking 8000, 8089, and 9997.
Here is more info on some of the typical/default Splunk ports that are used:
https://answers.splunk.com/answers/118859/diagram-of-splunk-common-network-ports.html
As far as the password issues, my only thought is a typo was made typing in the password when changing from the default of admin/changeme when installed. Then, when you login again you aren't replicating that typo. Plus, I can't think of a normal situation where I've had this happen. I think the only time I've ever manually touched the Splunk internal passwd file is when I forgot the admin password and had to reset it to changeme. In this case I followed the steps outlined in one of your links - backup file, delete original, restart, new password, copy everything from backup file back into the new passwd EXCEPT for the admin user. Also, long term, if you do not hook Splunk up to an LDAP provider you will hate managing users/roles/etc. Not because Splunk has any issues...just because that's what LDAP is for and you want to do Splunk, not user-management.
The only other thing I can think of that happened with the passwd file is if after the fact the Splunk secret got messed up...this is generated on install, and is used for hashing things from then on. If you changed the password, messed with the secret, then nothing can hash the same that is bad. And if you chose to mess with the secret on purpose I would highly suggest rethinking that because you enter dangerous territory and really need to know what you're doing it for (e.g. have a shared hash-result across all of your Splunk instances). I've never messed with this personally...
So overall I am going to lean towards some sort of environment issue right now, because in my experience doing Splunk Administration/Architecture I haven't seen these things under normal circumstances, e.g. not, "Whoops I broke it by messing around just to see what happens..."
... View more