In my case, I have a Windows 2003 Server that is part of a domain controlled only by a Windows 2000 Server. On the former I was getting 1006 + 1030 from userenv. The fault was of a misconfiguration of the DNS on the w2k server: there were records in the forward lookup zone with no name (thus marked "(as parent)") pointing to a dismissed server. I deleted them and left only one pointing to my Windows 2000 controller.
I solved this problem by resetting the disconnected sessions at the server that recorded the 1006 and 1030 events. It appears that the password for the account used to open those sessions changed while the session was still active and for some reason the session was not reset.
I work for a school district with 3000+ computers. These errors showed up on ( 3 ) computers randomly (2 were older Dell machines and the other was just built from scratch and updated to WinXP SP3). After going through many steps listed here, the web, and elsewhere (Mark Minasi's support forums), a co-worker decided to change the network card to a new one, and the problem was solved. I don't really know why this would effect some logons, and not others, but it did work.
Regarding the "Stored User Names and Passwords" dialog box referred to by Sean, James and others, the user does NOT need to be an Administrator to have access to them. The Windows 2000/XP User Accounts dialog box is excruciatingly poorly designed.
It's subtle, for sure, but click "Manage your passwords" at the BOTTOM of the dialog box and ANY user can manage their stored passwords.
In Vista, Microsoft eliminated the confusing dialog box and all the extra mouse-clicks. In the User Accounts Control Panel applet, click "Manage your network passwords" in the left pane to get to the same dialog, whether an admin or a normal user.
This event and event id 1030 kept reappearing every 1.5 hours on a SQL server. Reading the given possible solutions here triggered me to use the terminal server manager MMC. I had two disconnected sessions. I logged them of and the events didnt appear anymore. So check the disconnected sessions.
We had a user that after changing her password, basic auth to the workstation would work, but no login script would run nor was \\server\ browsable. It would prompt for credentials. My problem was solved following the same steps as James described below. The user already had local admin privileges so it was just a matter of walking the line. There was an entry for saved credentials to the server doing the auth, so when they changed their password, the autologin kicked in and locked out the user account nearly immediately keeping them from touching the server again.
For me it was a problem with the network cards being teamed together using the HP Network Configuration Utility that lets you team the network ports together for redundancy. Dissolving the team fixed the issues and replication started succeeding.
There are different flavours for this event depending on the actual description of the reason why the computer was unable to bind to the domain controller:
- Invalid Credentials - This indicates that the computer was able to find and attempt to connect to the domain controller but the credentials used to authenticate itself were incorrect. In most cases this is a sign of incorrect DNS configuration.
- Local Error - This shows that the computer didn't get that far as to connect to a domain controller (there was a problem locally). For example, having TCP/IP Filtering enabled on the network card may stop the local computer from connecting to the domain controller using the TCP/389 (LDAP) protocol.
- Timeout - When this is recorded, it appears that the computer did find the domain controller but when it tried to connect to it the connection request timed out.
This event followed by an Event ID 1030 from the same source can repeatedly appear on a virtual machine. Updating the network driver on the host machine clears up the error.
We were getting this along with event every 5 minutes on two Windows 2003 Servers. In addition, winlogon.exe caused 50% CPU usage every 5 minutes. The problem was solved with reinstalling Panda FileSecure. In addition, reinstalling Panda FileSecure did not bring the problem back.
In my case, a wrong logoff caused the problem. I simply kicked off the user so the Group Policy processing could proceed.
My problem was solved following the same steps as James described below. However, instead of deleting and re-adding the computer & account, etc. from the domain as he did, I just temporarily gave the affected user administrative privileges and was able to find the stored user name info when I logged in as that user. Go to Start -> Control Panel -> User Accounts -> Advanced tab -> Manage Passwords. Note that you cannot go into this area without Admin privileges and you cannot see them when you are logged in as another user. Once I found and deleted the stored credentials, I removed admin privileges and was able to log in normally without the authentication problems.
We had a laptop that would hang for an extremely long time after login was entered. The event log showed event 1006 and event 1030. We checked the network adapter properties and noticed that "Enable IEEE 802.1x authentication for this network" box was check. After clearing the check box and rebooting, the problem disappeared.
As per Microsoft: "An Active Directory, network connectivity, or network configuration problem prevents Group Policy settings from being applied. Group Policy processing for the computer or user failed and will continue to fail until this problem is resolved". See MSW2KDB
for more details.
From a newsgroup post: "Last weekend I deployed the first GPO for desktop screen saver protection to all computers. On Monday, I found out that not all computers had this policy applied, and most of the computers had this event logged. After two days investigation, I found the reason for this error was due to the logon password expiration. Apparently, quite a few user accounts had their passwords expired over the weekend, and they did not change their passwords before expiration. Then GPO are not pushed out because of the user account cannot be validated. A bit funny, but that makes sense. Users who changed their password will not have that problem later on".
From a newsgroup post :"This may occur on a multihomed DC (2003) with two NICs, where one NIC has port filtering enabled and is blocking port 389. This can occur even if the “port blocking” NIC is lower in the binding order than a “non port blocking” NIC.
Also check to see whether there are any services running in the context ABC\Administrator.
Lastly, make sure the DNS zone for the AD Domain has dynamic updates enabled".
Someone suggested that forcing Kerberos to use TCP instead of UDP helped him to alleviate this problem. See ME244474
for details on accomplishing this.
In my case, this event was generated by an disconnected terminal server session. The user's password had been changed.
In one case, on a Windows 2003 SP1 domain controller, this event appeared after an attempted Authoritative Restore of Active Directory. The two domain controllers in the domain were restored from Ghost backups.
I had recently renamed my domain. I used netdiag and dcdiag to look for and correct DNS problems but I still kept getting this error every 5 minutes. Only after I downloaded and installed the Group Policy Management Console add-in did an invalid group policy under my domain controller jump out. I deleted it, added a new one and the problem went away.
In my case, the event appeared on a Windows 2003 server after we changed the domain admin password. All services had correctly been changed, but the console was logged on during the password change. A simple logoff-logon solved the problem.
My issues on this event were caused by cached credentials on the client. They were not showing up when I logged in as Administrator (Tristen and Sean below had issues related to this, but were able to find and delete the offending credentials). Rob's comments under EventID 14 from source Kerberos, about client credentials not appearing were very helpful in pointing me in the right direction to solve my issue. Instead of deleting and re-adding the computer & account, etc. from the domain as he did, I just temporarily gave the affected user administrative privileges and was able to find the stored user name info when I logged in as that user. Go to Start -> Control Panel -> User Accounts -> Advanced tab -> Manage Passwords. Note that you cannot go in to this area without Admin privileges and you cannot see them when you are logged in as another user. Once I found and deleted the stored credentials, I removed admin privileges and was able to log in normally without the authentication problems.
We were getting this along with event 1030, on two SQL servers; both errors started on the same day and were associated with the same user. It turned out that the database administrator had left herself logged on to both SQL servers and then changed her password. We simply logged her off and the error was gone.
I had exactly the same problem as Tristen. I went into Control Panel -> User Accounts -> Advanced tab -> Manage Passwords, and removed the user from the list. After a reboot, the problem disappeared.
I was getting EventID 1006 and EventID 1030 errors on a user’s machine. The problem turned out to be caused by the fact that both domain controllers had entries under "user accounts / manage passwords" which were blank. I removed both entries, which fixed the problem and allowed the group policy to update.
Only seen by laptop user after returning from offsite work (logging in with cached credentials on previous logon/bootup) - system will hang at blue screen before "starting windows" window appears on screen. This is NOT a boot error message (ME242518
is the only article I can find which looks similar), but a network issue: if the network cable is unplugged, the system boots fine. If "Offline Files" in Explorer is turned off, the system boots fine. Can't turn off Offline files, as user needs it for laptop to work offsite properly.