Group policy error (LDAP Bind fails)

Posted on Updated on

On some systems (in my cases Remote Desktop Session Hosts (RDSHs)) the following error appears in the System event log:

Event ID: 1006

Description: The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

Source: GroupPolicy

Level: Error




Task Category: None


OpCode: (1)

The event source is GroupPolicy, which means the group policy client. The description tells us the processing of group policies failed, because Windows couldn’t authenticate to the Active Directory (AD) service server side (so on a domain controller (DC)), a conclusion from the fact the LDAP Bind function call has failed. The Details tab shows us the exact error code (see the field ErrorCode) is 49.

Figure 1

Figure 2

Figure 3

Side note: the event source GroupPolicy is technically registered with the name “Microsoft-Windows-GroupPolicy” (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\System\Microsoft-Windows-GroupPolicy). The DLL (gpsvc.dll) is configured here, but there is also a referral to a GUID ({aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}) for more information through the REG_EXPAND_SZ named value providerGuid. A provider with this GUID is registered in the registry at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{ aea1b4fa-97d1-45f2-a64c-4d69fffd92c9} (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers is the place where event providers are registered), which contains the provider’s name (Microsoft-Windows-GroupPolicy) and new referrals to the DLL that is used for the event logging (gpsvc.dll).

Side note: LDAP stands for Lightweight Directory Access Protocol and is a protocol used to communicate to directory servers (like Active Directory (AD) servers, called domain controllers). When setting up an LDAP connection there could be some initialization phase to set it up. This is called the Bind (hence LDAP Bind) and the action is called binding. This includes (but is not limited to) authentication.

What is error code 49? The error and its error codes are described on, where we can read 49 means “Invalid credentials”. This means a logged on user has invalid credentials, so he/she can’t authenticate to AD to get his/her user group policies. It’s impossible to log on with invalid credentials, so this means the user had valid credentials at the time of logon, but the credentials became invalid while he/she was logged on (so during the session) in a way where the Kerberos tickets for that user are expired too (those tickets are used for authentication to Kerberos aware services (the story about Kerberos can be quite complex, so I’m making it simple here)). This is not always the case though. For example, somebody can be logged on and received Kerberos tickets and then an administrator changes your password. The tickets of the logged on user are still valid though (that is, for the rest of the ticket lifetime). Anyway, the thing is there could be another reason for this error… As I always say: don’t take those error messages too literally.

Another known cause for this error seems to be a name resolution problem. Check if your server has been registered correctly in DNS, doesn’t contain incorrect hosts file (in %windir%\System32\drivers\etc) entries, doesn’t contain incorrect lmhosts.sam file (also in %windir%\System32\drivers\etc) entries. Especially when your system has been built up based on a “specific” image (which is not sysprepped), these things should be checked for. By the way, it’s a best practice to use “generic” images (sysprepped) to deploy new systems. As a good IT administrator I have checked all those things, but no luck… Well, I mean everything was fine, so I hadn’t found the cause of the logged error yet :-s

I started to look and look and look at those errors… Over and over again… The weird thing is this error is logged for multiple users, but only for a few of them. And there is no DC being mentioned in the event (see figure 2: EventData – DCName)… Also, the error is always logged every night between 0 and 5 AM (local time). After that I see successful group policy events being logged, even for the same users! To be more precise I get the following successful System events (the time moments clearly differ from those from the previous screenshots, but that doesn’t really matter):

Event ID: 1503

Description: The Group Policy settings for the user were processed successfully. New settings from 10 Group Policy objects were detected and applied.

Source: GroupPolicy

Level: Information




Task Category: None


OpCode: (1)

Figure 4

Figure 5

Figure 6

Then a colleague of mine, Jo Jacobs, told me some users once had time restrictions to logon! Hey how! I checked the account settings in AD for the users having such a GP error being logged in the System event and oh yes, indeed, those users were time restricted between 0 and 5 AM every day! Users who don’t have this error being logged obviously had no time restriction at all. You can change those time restrictions in the AD management console (on WS03 that’s Active Directory Users and Computers (dsa.msc)): select the user object, right-click it, select Properties, go to the tab “Account” and click the button “Logon Hours…”. The dialog box “Logon Hours for USER” appears and you can clearly see the white pieces, representing the time frames where the user is denied to logon (the blue time frames show us when the user is allowed to logon).

Figure 7

The solution is simple: if you need those time restrictions, then ignore the error events. If you don’t need those time restrictions, remove them and the errors will disappear too. In our case time restrictions were once necessary for some users, but not anymore. So it seems some users still have old settings! We are planning to remove the time restrictions! You see, sometimes hunting error events can help you keep your environment clean and compliant! J

For those who want to automate all this you can execute the following PowerShell (PS) script. It looks for every user in your domain and checks for his/her Logon Hours. If there are time restrictions, those are removed. Note you should replace the first line with your own LDAP path.


$root = New-Object DirectoryServices.DirectoryEntry $URL

$ds = New-Object DirectoryServices.DirectorySearcher

$ds.SearchRoot = $root

$ds.filter = “objectCategory=Person”

$src = $ds.FindAll()

Write-Host $src.Count ” user objects found.`n”

$src | %{

$de = $_.GetDirectoryEntry()

$LH = New-Object ‘Byte[]’ 21

For ($k = 0; $k -le 20; $k = $k + 1)


    $LH[$k] = [byte]255


if (diff $de.logonHours.Value $LH)


$de.logonHours.Value = $LH


Write-Host -f yellow (“Changed:`t” + $[“sAMAccountName”])

Start-Sleep -m 200




Write-Host -f green (“Unchanged:`t” + $[“sAMAccountName”])



The number of user objects is calculated first. Then every user’s Logon Hours is compared to the variable LH, which is an byte array of 21 “full bytes” (1111 1111), representing allowed logon all the time (so no restrictions). If Logon Hours is the same (so there are no restrictions), nothing further happens. Otherwise Logon Hours is set to this variable, effectively meaning all restrictions are removed.

One last set of “last things” J

  • In the case described here (and that I have experienced) there were no invalid credentials, so again, don’t take those errors and error code descriptions always too literally. Of course it has something to do with credentials the user cannot really use anymore (i.e. during the time restrictions), so it is close.
  • My case explains why there is no DC mentioned in the error details: because of the time restrictions it has nothing to do with a specific DC.
  • You can use the great tool to change user attributes in bulk, but Logon Hours isn’t available… L It’s not even possible through the Custom tab where you can specify “custom” attributes. That’s because doesn’t support byte arrays and that’s what Logon Hours actually is (or otherwise called: an octet string). So you should use the script instead.





6 thoughts on “Group policy error (LDAP Bind fails)

    Jim van der Harst said:
    28/03/2013 at 13:05

    Awesome analytics for this problem. Turns out..the first solution was in my case the answer. The password expired during their session and net user /domain showed that they did changed their passwords the very next morning. Thank you very much for this!!!!

    Todd H. said:
    20/06/2013 at 16:38

    Nice deductive systems administration. Logon hours were the culprit for me. Thanks for posting.

    Grant said:
    05/09/2013 at 08:29

    Had this problem drove me nuts
    My fix was to delete all credentials

    rundll32.exe keymgr.dll, KRShowKeyMgr

    zmedgyesi said:
    01/10/2013 at 13:41

    Nice article. I could not find the reason on some systems. Finally found some remote desktop connections with idle time of 126 days. This is over the password age limit.

    Dheeru said:
    03/01/2014 at 09:16

    Really useful and Thanks giving..!!

    chemi said:
    02/09/2014 at 10:40

    great and helpfully post!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s