Problem
Using LDAP authentication in the IBM Content Manager OnDemand server to search for a user ID in a Microsoft Active Directory server results in an error labeled «Operations error.»
Symptom
Attempting to log on through an OnDemand client results in the error «The server failed while attempting to logon.»
Taking an OnDemand server trace shows that the initial bind to the Active Directory server was successful, but the search failed with the error «Operations error»:
ArcLDAP_Authenticate LDAP server: example.com
ArcLDAP_Authenticate LDAP port: 389
ArcLDAP_Authenticate LDAP base DN: DC=example,DC=com
ArcLDAP_Authenticate LDAP bind DN: CN=sample-user,OU=sample,DC=example,DC=com
ArcLDAP_Authenticate LDAP bind attribute: sAMAccountName
ArcLDAP_Authenticate LDAP mapped attribute: sAMAccountName
ArcLDAP_Authenticate LDAP bind message file: (null)
ArcLDAP_Authenticate LDAP allow anonymous bind: FALSE
ArcLDAP_Authenticate Initialization successful
ArcLDAP_Authenticate Setting Protocol version to 3
ArcLDAP_Authenticate Simple bind as ‘CN=sample-user,OU=sample,DC=example,DC=com’ successful
ArcLDAP_Authenticate Searching with filter sAMAccountName=USER1
ArcLDAP_Authenticate LDAP search failed: Operations error
ArcLDAP_Authenticate User ‘USER1’ not found in LDAP
ArcLDAP_Authenticate RC=4
This error typically occurs when OnDemand is configured with a base distinguished name that searches across subordinate domains that are direct descendants of the directory server domain. In the previous example, the base distinguished name was set to
DC=example,DC=com
, which is at the root level of the Active Directory server
example.com
.
Cause
This problem is caused by referral chasing.
With referral chasing enabled, when a subtree search is performed, the Active Directory server sends back referrals that might require the LDAP API to bind (authenticate) to another Active Directory server at a different domain inside the Active Directory forest. If the bind fails due to incorrect credentials or insufficient access, the entire authentication process fails with the operations error.
On the Linux operating system, the OnDemand server uses the OpenLDAP API to communicate with the Active Directory server. The search scope is set to subtree and by default the referral option is enabled in the OpenLDAP API. With these conditions set, referral chasing might occur. See the Related information section for more information about referral chasing.
Environment
This error can occur with an OnDemand server running on Linux and UNIX operating systems, but does not occur when running an OnDemand server on Windows.
Resolving The Problem
There are three options that you can use to resolve this issue:
- Search the Active Directory Global Catalog instead. This search can be accomplished by changing the ARS_LDAP_PORT in the ars.cfg file of your OnDemand server to communicate through the Active Directory Global Catalog port, 3268. When you make the change to search the global catalog instead, you bypass referral chasing. See the Related information section for more information about the Active Directory Global Catalog.
- Disable referrals in the OpenLDAP API on the OnDemand server. To disable referrals, modify the file /etc/openldap/ldap.conf and add the following line to the end of the file:REFERRALS off
- Specify a non-root level base distinguished name in the ARS_LDAP_BASE_DN parameter of the ars.cfg file of your OnDemand server. In the example from the Symptom section, the base distinguished name is set at the root level or top level, DC=example,DC=com. Changing it to a lower, more specific, non-root level distinguished name such as OU=sample,DC=example,DC=com might resolve the problem by eliminating the possibility of a referral being issued to a subordinate domain.
Related Information
[{«Product»:{«code»:»SSEPCD»,»label»:»Content Manager OnDemand for Multiplatforms»},»Business Unit»:{«code»:»BU053″,»label»:»Cloud & Data Platform»},»Component»:»Server»,»Platform»:[{«code»:»PF016″,»label»:»Linux»},{«code»:»PF025″,»label»:»Platform Independent»}],»Version»:»8.4.1;8.4″,»Edition»:»»,»Line of Business»:{«code»:»LOB45″,»label»:»Automation»}}]
User-129623928 posted
Hi all.
I’m having the popular «Operations Error Occurred» error when trying to query AD from an ASP.NET 1 legacy app.
Code is as follows. AppSettings[«ADServer»] is set to «LDAP://DC=XXX,DC=YYY,DC=ZZZ»
DirectoryEntry searchRoot = new DirectoryEntry(ConfigurationSettings.AppSettings["ADServer"].ToString());
DirectorySearcher search = new DirectorySearcher(searchRoot);
search.Filter = String.Format("(SAMAccountName={0})", samAccount);
search.PropertiesToLoad.Add("samaccountname");
search.PropertiesToLoad.Add("givenname");
search.PropertiesToLoad.Add("sn");
search.PropertiesToLoad.Add("mail");
search.PropertiesToLoad.Add("userPrincipalName");
SearchResult result = search.FindOne();
Exception is as follows.
Type : System.Runtime.InteropServices.COMException, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Message : An operations error occurred
Source : System.DirectoryServices
Help link :
ErrorCode : -2147016672
TargetSite : Void Bind(Boolean)
Stack Trace : at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
at System.DirectoryServices.DirectorySearcher.FindOne()
This works on PREPROD but not PROD. Support has confirmed the AD permissions are identical between PREPROD and PROD using adsiedit tool.
IIS / web.config settings are the same between PREPROD and PROD. i.e
- Integrated authentication turned on.
- Basic authentication turned on.
- No anonymous access.
- Domain / realm left blank.
- Impersonation turned on and using authentication mode = windows in web.config.
I have run the same LDAP query from the command line on the PROD web server using the ldifde command as the same user that is trying to access the app and this worked OK, so it’s not a problem with the LDAP root or query syntax.
So in both environments it is trying to do the query as the logged-in user, but in PROD they don’t seem to have permission to do this programmatically. Or something else is the problem.
I was wondering if anyone could suggest anything else for me to examine as a diference between PREPROD and PROD?
Thanks in advance for any help
Lee.
Возможные причины:
1. Строка слишком большой длины.
2. Неверный тип — строка записывается в числовой атрибут.
3. Неправильное значение, например, атрибут может принимать только определённое значение, либо одно из набора значений.
Возможные причины:
1. При добавлении записи — один или несколько атрибутов в LDIF (или операции добавления/замены) для записи в точности совпадают (дублируются).
Дополнительный текст: unable to get TLS Client DN (невозможно получить DN клиента TLS).
Возможные причины:
1. Не предоставлен сертификат клиента в случае, если директива TLSVerifyClient установлена в ‘demand’.
2. Не предоставлен сертификат клиента в случае, если директива TLSVerifyClient установлена в ‘never’. В этом случае данное сообщение об ошибке не является фатальным и обслуживание клиента продолжается.
Дополнительный текст: no global superior knowledge (нет сведений о глобальном вышестоящем каталоге) — имя записи, которую собираются добавить или модифицировать, не находится ни в одном из контекстов именования и у сервера нет правильной отсылки на вышестоящий каталог.
Возможная причина: не задан атрибут olcSuffix (директива suffix в slapd.conf) для DIT, на которое идёт ссылка.
Дополнительный текст: Shadow context; no update referral (теневой контекст (реплика); отсылки для выполнения обновлений не указано) — DIT, в которое собираются вносить изменения, является репликой в режиме «только для чтения», и, из-за отсутствия директивы updateref, невозможно возвратить отсылку.
Возможные причины:
1. Была попытка произвести запись в реплику «только для чтения» (в конфигурации syncrepl потребитель всегда в режиме «только для чтения»).
2. В конфигурации syncrepl multi-master в файле slapd.conf возможно пропущена директива mirrormode true.
3. Если slapd при запуске использовал файл slapd.conf, а директория slapd.d (cn=config) также существует, то при последующих модификациях DIT могут возникать ошибки с выдачей этого сообщения. В частности, в FreeBSD требуется наличие явного указания в rc.conf (slapd_cn_config=»YES») для принудительного использования slapd.d.
Возможная причина:
Попытка удаления атрибута (особенно в cn=config), удаление которого запрещено.
Дополнительный текст: olcDbDirectory: value #0: invalid path: No such file or directory
Возможная причина: перед инициализацией новой базы данных директория для её размещения должна существовать.