The iDRAC login failed with two words and nothing else: “Login Failed.” There was no other message and no indication of what had changed. The ESXi hosts were running normally, and iDRAC itself was reachable.
What made it more confusing was that the original password still worked on one of the four hosts.
What I Was Trying to Do
We had just finished adding disks to a vSAN cluster as part of a capacity expansion. The last step was to confirm the new disks in iDRAC, across all four hosts.
On three of the four hosts, the login page came back with “Login Failed.” The fourth host accepted the original password. It hadn’t been changed, and we still don’t know why only three of them were.
First, I Checked Host and iDRAC Reachability
The ESXi hosts themselves were running normally, so this wasn’t a host outage. I checked iDRAC separately: it responded to ping, its HTTPS interface on port 443 was reachable, and the login page loaded. That made a basic iDRAC connectivity problem much less likely and moved the investigation toward authentication.
The fourth host helped too. Because one host still accepted the original password, a shared network or iDRAC-wide problem was less likely, and whatever differed was specific to those three hosts.
I also tried SSH from MobaXterm, entering the password three times, to rule out a browser or session problem. The web interface returned “Login Failed” and SSH ended with “Permission denied.” The messages were different, but both access methods failed at authentication, with no further detail.
We Were About to Reset the Password
While I was still working through it, the customer’s IT manager contacted us. They couldn’t log in either.
We decided to reset the root password. While I was reaching out to coordinate the reset, the customer’s IT manager confirmed that they had changed the password on those hosts earlier, and that the new credential had never been passed to our operations team.
I logged in with the password they gave us, and we’re still using it for now. Fortunately, the issue didn’t delay the vSAN work.
What We Changed Afterward
The incident led us to conclude that the responsibilities between the customer and our team needed another look.
The plan is for the operating team to keep the root credential and give the customer a separate account for the access they need. That plan is still being coordinated internally, and the root password reset itself has not been done yet.
What I Took From This
- Separate host health from management access. ESXi being reachable showed the host was running. It said nothing about iDRAC, which needed its own checks.
- Test more than one access method. The web and SSH messages differed, but both failing at authentication ruled out a browser or session problem.
- Ask who maintains and last changed a credential before resetting it. The conversation about coordinating the reset is what surfaced the answer.
- Shared privileged credentials need explicit ownership and change communication. The password was changed on three hosts and the new credential never reached the team operating them.
Related reading: I Gave a Good Handoff Once. I Didn’t Get One. on operational handoffs, and The Server Was Up. The Database Wasn’t.
Frequently Asked Questions
iDRAC says “Login Failed” but the host is running. What should I check?
If ping and HTTPS are reachable, basic network connectivity to iDRAC is working. That doesn’t prove the account is valid. At that point, check the credential, the account state, recent password changes, and another access method such as SSH before treating it as a hardware problem.
Should I reset the iDRAC root password right away?
Before resetting it, check whether the credential was recently changed and whether another team maintains the account. In this incident, that check avoided an unnecessary reset.