The Referenced Account Is Currently Locked Out And May Not Be Logged Into

14 views

Skip to first unread message

Hercules Montero

unread,

May 29, 2024, 12:34:29 AM5/29/24

to adnemviness

I works as IT Administrator. Today morning when I come to work I was getting error message " The referenced account is currently locked out and may not be logged into " so I was not able to login to my domain computer. My manager helped me to reset the password and then I am not able to login.

I am checking Security windows logs and filter with Audit Failure and found Hundreds of Audit failure logs with my username. It says Kerberos pre-authentications failed. Event ID: 4771. FYI, I never try to login since yesterday.

The referenced account is currently locked out and may not be logged into

DOWNLOAD ===== https://t.co/g2yW54hjIi

Then connected to the VM using RDP
But while connecting to domain when we enter credentials, we get an error saying "The referenced account is currently logged out, and may not be logged on to."

yeah, literally not the only reason
been getting this lie of an issue for months now with my 100% personal network share with this popup happening every time I reboot a device connected to the share

the only reason it should lockout an account because of connection issues is wrong password(dns settings should not factor in since it should just say "wait till later since we can't connect to microsoft to verify the password right now"), but that literally can't be the case since it was connected and working 100% prior to reboot, and it locks out after reboot, almost like it tries to connect before the boot finishes initializing the network stack, a clear bug

In addition to being thrown by the account lockout threshold policy, this is a Windows error that typically occurs when a password is repeatedly entered incorrectly, when there are expired passwords, or if there are incorrect DNS settings.

In your case it sounds like there could be a device or service using old credentials that keeps using the old password and trying to log in. You should be able to verify this by checking the event log on the server.

sadly irrelevant to my situation, 0% virtual, I have a win-10 "server" and wind 10 "client" on the SAME subnet, the issue is due to Microsoft coding the share reconnect to happen before netcode is fully ready, causing the microsoft account login to fail, but rather than fail with a specified "can't verify" error it fails with a "wrong password" error
they need to enforce a netcode wait into any logins involving online authentication, if it can't connect to a server it is impossible to say honestly if the password is wrong, so don't lie and say it is

it seems like the only valid solution is to never use microsoft accounts in "automatic reconnect" mode
the code for reconnecting network shares ignores if a connection is valid or not, so instead of saying "can't verify the login details, wait 30 seconds and try again" it just lies in a lazy manner and says "wrong password" which incorrectly trips brute force connection protections
the only way to ensure this doesn't happen is to create a local login that may or may not be given a desktop via policies, then exclusively use that login for network shares and possible other RDP type utilities(like my megaraid management software for instance)
maybe if microsoft actually listened to user feedback they would never have created any OS after windows 7(windows 8 was a decent idea but should have only existed as 8.1 because the metro theme was worthless if you installed it on a desktop, and edge was doomed to be rejected by power users because built-in browsers are permanently tarnished in all eyes)
but microsoft doesn't care what the end-user thinks, they will pretend like they know why updates were often ignored for months on end, despite their reason being 100% false

we ignored updates 10 years ago because some of us didn't have broadband, and SSD's were not cheap yet so the performance hit was unacceptable and you demand a reboot for everything when you can just selectively restart the affected services
but they won't look at the reasons stuff is broken, they will pretend like it is something else that is clearly isn't

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

The process of updating Data Protector Clients from the DP GUI is working on the first set of clients and then the process is breaking and causing the AD account to lock up. Username and Password are correct, otherwise it wouldn't have worked with any of the clients. I repeated the issue with another account as well.

I've seen this before. In my case this was a cell backing up clients from Test Dev Prod environments where each environment had the same domain name (with the same dp account name) but each domain is actually a totally separate entity / segragated network (clients were imported using a 2nd NIC and specific FQDN server.domaintype.company.com - e.g. server2.prod.mycompany.com)

I am noticing that during the DP component upgrade process that if I select the local domain on the first credential and use the local adminsitrator password, which is the same for my machines, that it may pass that on to other clients and work. Not sure if by selecting the local domain it actually is using the machine name or a ".\" and thus successively passing it on. However, it seems like I can only get a couple of succesfull multiple installs going before it starts to fail.

For instance - I select 9 clients, 4 get updated using local admin, then it locks up my AD account even though I entered the local admin username/password. Get someone to unlock me. Try again with just 4 clients, one goes through with local admin then the other 3 fail with:

It uses the account you enter in the GUI client upgrade window for the actual upgrade but prior to that it needs to connect to the client from the IS and this uses the account configured on the Installation Server as the IS user.

Try settng a different account as the IS user instead (make sure you get the password right it doesn't authenticate during the omniinetpasswd command it just encodes and saves it) then try another push install using the local accounts. Does this new IS account now get locked out instead of your one?

I have seen similar issues with the Windows Installation Server if you try to remotely install/upgrade clients which are part of a different domain/workgroup. With DP 10.x the Windows Installation Server in a workgroup gives me serious trouble. Can you comment on your environment.

When I selected 5 clients and did Upgrade, I got the Authentication Prompt, I used the same service account. It did 4 without issue and the first one in the list didn't throw an error but sat at Installation in Progress.

When I went to log into the server that hadn't updated with my own AD credentials, I was met with "the referenced account is locked." I got a co-worket to unlock me (their getting used to it by now) and logged into the server and killed the msiexec installation process. The process restarted and completed the disk agent upgrade.

I've been sorting my clients by their Disk Agent version and the server in question had been tried before. There's a possibility that the installlation process was leftover from earlier attempts. So lets try again.

I grabbed 11 clients that were lower in the list and that I hadn't tried to Upgrade yet. I authenticated with the AD Service Account and it started on the first 5 of the clients, then gave the message "The referenced account is locked out" for the remaining 6 clients and my own AD account was locked out again. The 5 that authenticated correctly got the install without issue.

I found out that since I have a dedicated admin account and password, I must login to windows as that account to upgrade. I had the same problem this morning after upgrading. I log in to my Installation server as the dedicated account and I can run as many upgrades as I wish. THe problem did not occur when I was upgrading *nix system, only Windows.

If you are able to successfully log into another system, the issue is likely not with your NetID. If you are unable to log into multiple systems, then there is likely an issue with your NetID. Resetting your password will correct the issue. You can also contact the OIT Support Center and a technician will be available to assist you.

All users passwords expire every 365 days. In advance of your NetID password expiring you will receive multiple emails (at two weeks before, one week before, and one day before). This email will be sent to students at their preferred email address listed in MyNevada, and employees at their preferred email address listed in Workday.