Ошибка при выполнении привязки ldap bind 1006

Доброго времени уважаемые форумчане.

Суть проблемы:

С недавнего времени перестали выполнятся групповые политики в домене у пользователей.

С логах системы у клиента ошибка:

Сбой обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена. Это может быть временным явлением. Как только компьютеру удастся подключиться к контроллеру домена и групповая политика будет
обработана успешно, будет создано сообщение об успехе. Если это сообщение не появляется в течение нескольких часов, обратитесь к администратору.
Не удалось успешно обновить политику пользователя. Обнаружены следующие ошибки:

Ошибка при обработке групповой политики. Не удалось пройти проверку подлинности в службе каталогов Active Directory на контроллере домена. (Ошибка при выполнении привязки LDAP Bind). На вкладке «Подробности» можно найти код и описание
ошибки.

Подробности:

Посмотрев по статье:

Event ID 1006 — Group Policy Preprocessing (Active Directory)

Как-то бред с неправильными учетными данными, даже поменял пароль. Сервер по сети доступен, сетевые папки видны:

Доступ к ним есть.

На сервере в событиях безопасности формируется аудит отказа:

Учетной записи не удалось выполнить вход в систему.

Субъект:
ИД безопасности:
NULL SID
Имя учетной записи:
—
Домен учетной записи:
—
Код входа:
0x0

Тип входа: 3

Учетная запись, которой не удалось выполнить вход:
ИД безопасности:
NULL SID
Имя учетной записи:
CAB2$
Домен учетной записи:
DOMAIN.LOCAL

Сведения об ошибке:
Причина ошибки:
Выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.
Состояние:
0xC000015B
Подсостояние:
0x0

Сведения о процессе:
Идентификатор процесса вызывающей стороны:
0x0
Имя процесса вызывающей стороны:
—

Сведения о сети:
Имя рабочей станции:
—
Сетевой адрес источника:
192.168.1.16
Порт источника:
50404

Сведения о проверке подлинности:
Процесс входа:
Kerberos
Пакет проверки подлинности:
Kerberos
Промежуточные службы:
—
Имя пакета (только NTLM):
—
Длина ключа:
0

Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.

Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.

В поле «Тип входа» указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).

В полях «Сведения о процессе» указано, какая учетная запись и процесс в системе выполнили запрос на вход.

Поля «Сведения о сети» указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.

Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного сеансового ключа. Это поле может иметь значение «0», если сеансовый ключ не запрашивался.

Group policy error (LDAP Bind fails)

Posted on 18/05/2012 Updated on 18/05/2012

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

User: USER_ACCOUNT

Computer: YOUR_SYSTEM

Logged: DATE_AND_TIME

Task Category: None

Keywords:

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_MACHINESYSTEMCurrentControlSetserviceseventlogSystemMicrosoft-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_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWINEVTPublishers{ aea1b4fa-97d1-45f2-a64c-4d69fffd92c9} (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWINEVTPublishers 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 http://technet.microsoft.com/en-us/library/cc727283(v=ws.10).aspx, 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%System32driversetc) entries, doesn’t contain incorrect lmhosts.sam file (also in %windir%System32driversetc) 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

User: USER_ACCOUNT

Computer: YOUR_SYSTEM

Logged: DATE_AND_TIME

Task Category: None

Keywords:

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.

$URL = “LDAP://DC=DOMAIN,DC=TLD”;

$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

$de.SetInfo()

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

Start-Sleep -m 200

}

else

{

Write-Host -f green (“Unchanged:`t” + $de.properties[“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 ADModify.net 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 ADModify.net 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.

Ciao!

Pedro

Links:

• http://technet.microsoft.com/en-us/library/cc727283(v=ws.10).aspx