#26 Usertab - Error in ldap search
I'm using sarg 2.3.1 and I'm trying to generate reports with common names (CNs) looked up from a MS AD server. My base DN is DC=myDomain,DC=go,DC=gov,DC=br. I have several OUs (Department1, Department2...) beneath it and several users under each OU (there are not one OU with all users under it). When I use the follow parameters on sarg.conf I get a LDAP error (Operations error):
usertab ldap
LDAPHost myAD-Server.ipasgo.go.gov.br
LDAPPort 389
LDAPBindDN CN=BindUser,OU=Department1,DC=myDomain,DC=go,DC=gov,DC=br
LDAPBindPW myPassword
LDAPBaseSearch DC=myDomain,DC=go,DC=gov,DC=br
LDAPFilterSearch (sAMAccountName=%s)
LDAPTargetAttr cn
Curiously, ldapsearch tool works perfectly with similar parameters:
ldapsearch -x -h myAD-Server.myDomain.go.gov.br -p 389 -s sub -D "CN=BindUser,OU=Department1,DC=myDomain,DC=go,DC=gov,DC=br" -w "myPassword" -b "DC=myDomain,DC=go,DC=gov,DC=br" "(sAMAccountName=someTestUserLogin)" cn
I can't move my users to just one OU on my AD server. Sarg generates "correctly" the reports when I change the LDAPBaseSearch parameter to a specific OU, but only users under that OU have the logins exchanged by the CNs on the reports. Other users appears with blank names. Am I doing something wrong? Is there some workaround? Thanks in advance.
What is the error reported by sarg ? Can you show the actual output with the error message ?
Do you have some log on your server reporting the actual error as seen from the server's side ?
Frederic
Hi. Of course I can:
SARG: Records in file: 171879, reading: 0.00%
SARG: LDAP search failed: Operations error
... (Error repeated for each user in access.log)
SARG: LDAP search failed: Operations error
SARG: LDAP search failed: Operations error
SARG: LDAP search failed: Operations error
SARG: Successful report generated on /web/html/acessoweb/Diario/25Jan2011-25Jan2011
SARG: Records in file: 161937, reading: 100.00%
I've analyzed /var/log/messages and /var/log/secure on my "sarg server" and Windows events (Event Viewer ) on my AD server and I didn't find any entries about errors in ldap search. :(
That terse error message isn't going to help us... Unfortunately, it is from the LDAP library and sarg cannot get more information than that.
Let me summarize what you wrote to be sure I do understand correctly. A query with a OU in the base DN works with both ldapsearch and sarg. But a query *without* any OU produces an error in sarg while ldapsearch returns the expected result. Is that right ?
I ask this because the ldapsearch query you reported as working does include a OU in the base DN. Is this a copy and paste error ? Did you try ldapsearch without any OU ?
Both sarg and ldapsearch uses the same LDAP library as far as I know (I didn't write the LDAP code) except that sarg escapes a lot of characters to be on the safe side. They should both produce the same result.
I don't have a LDAP server to test sarg. If I provide you with a modified usetab.c file, can you recompile sarg and give it a try ?
Frederic
> Let me summarize what you wrote to be sure I do understand correctly. A
> query with a OU in the base DN works with both ldapsearch and sarg. But a
> query *without* any OU produces an error in sarg while ldapsearch returns
> the expected result. Is that right ?
Perfect! You've understood right!
> I ask this because the ldapsearch query you reported as working does
> include a OU in the base DN. Is this a copy and paste error ? Did you try
> ldapsearch without any OU ?
No, the query I've pasted hasn't an OU in the base DN (-b "DC=myDomain,DC=go,DC=gov,DC=br"). It has an OU in the bind user (-D "CN=BindUser,OU=Department1,DC=myDomain,DC=go,DC=gov,DC=br"). Ldaptool works with and without an OU in the base dn.
> I don't have a LDAP server to test sarg. If I provide you with a modified
> usetab.c file, can you recompile sarg and give it a try ?
Sure. It would be a pleasure.
The call to ldap_search_s looks correct. The search should extend to the subtree as well.
Can you add the one line in usertab.c as shown here:
http://sarg.svn.sourceforge.net/viewvc/sarg/branches/v2.3/usertab.c?r1=492&r2=491&pathrev=492
Hint: Search for ldap_search_s in usertab.c and add the debuga call after the error message. Then compile and run sarg and watch the output. In addition to the error message, it should show the actual filter and the base DN. Let's see if they are what you expect.
Hint2: If the processing of the whole log file takes too much time, you can stop sarg after the first error. To do that, simply add exit(1) after the debuga you just added.
I've followed your hints and the sarg output was:
SARG: Records in file: 960214, reading: 0.00
SARG: LDAP search failed: Operations error
SARG: looking for "(sAMAccountName=UserLogin1)" at or below "DC=myDomain,DC=go,DC=gov,DC=br"
SARG: Records in file: 960214, reading: 100.00%
I've updated ldap libraries on my "sarg server" and the error persists. The packages currently installed are:
nss_ldap.i386 0:253-25.el5
openldap.i386 0:2.3.43-12.el5_5.3
openldap-clients.i386 0:2.3.43-12.el5_5.3
openldap-devel.i386 0:2.3.43-12.el5_5.3
In usertab.c, around line 143, there is this line:
int ldap_protocol_version = LDAPProtocolVersion;
Can you replace LDAPProtocolVersion with 3.
According to http://drupal.org/node/55735, there may a bug that can be solved with two lines. First try if this single change solves your problem. If it doesn't, try to add the following code after the previous ldap_set_option:
ldap_referrals=0;
if (ldap_set_option(ldap_handle, LDAP_OPT_REFERRALS, &ldap_referrals) != LDAP_SUCCESS) {
debuga(_("Could not set LDAP referrals %d\n"), ldap_referrals);
exit(EXIT_FAILURE);
}
Don't forget to declare int ldap_referrals at the beginning of the function.
I cannot commit this code to svn as it is highly experimental and would be a workaround for a bug in your LDAP server.
Frederic
Hello Frederic.
I'm sorry for the delay. Only today I had the chance to test your code. I've changed usertab.c as you suggested and the problem persists:
SARG: Records in file: 2315, reading: 0.00
SARG: LDAP search failed: Operations error
SARG: looking for "(sAMAccountName=UserLogin1)" at or below
"DC=myDomain,DC=go,DC=gov,DC=br"
SARG: Records in file: 2315, reading: 100.00%
The changes you suggested didn't solve the problems of the this guy too:
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg58754.html
Then I guess I'll have to dive into the source code of ldapsearch and see how it works.
It's going to take some time but as google didn't return anything useful, it's the only solution left.
According to libldap's source code, the error message you are seeing is related to the LDAP Referrals. I don't know yet what it is and how it affects sarg as I have no knowledge of LDAP. I have found an explanation at http://technet.microsoft.com/en-us/library/cc978014.aspx but haven't read it all yet. Do you see how it could be related to your server ?
I made some changes to sarg. Can you test the latest version in svn at https://sarg.svn.sourceforge.net/svnroot/sarg/branches/v2.3 ?
ldap_search doesn't do anything fancy. Sarg calls several deprecated functions but the underlying code is nearly identical to the supported API in libldap. The only significant difference I could spot is that the new API used by ldap_search sets a default schema. Therefore, I have changed sarg to call the new API. Let's see if it improve anything.
I also made a small optimization to only ask for the requested attribute (cn in your case) instead of asking for all the available attributes and only keep the requested one.
Should I use only usertab.c from this repository (https://sarg.svn.sourceforge.net/svnroot/sarg/branches/v2.3) or compile all the files?
- I've used only usertab.c (considering only it was changed by you) from the repository above and recompiled sarg with other files from stable version. Then I've tried to generate the report. Sarg produces some lines (SARG: Records in file: 546942, reading: 0.00%...reading: 99.64%), but finishes showing a segmentation fault error and the report is not generated. This when ldap option is used in usertab parameter. When this option is not used, the report is generated normally.
- Considering that I have to compile all the files of the repository you've indicated, I couldn't find the configure script and I was not able to do that. How can I generate this file in order to make the binary? Or maybe you could supply a repository or a tarball with configure script in it.
Thanks for your time.
The configure script is created with [code]autoreconf -fi[/code].
If you experience any problem, I can send a tar.gz to your sourceforge e-mail address but make sure your sourceforge account is configured to accept external e-mails (it isn't by default).
Only upgrading usertab.c should have worked but you must first run [code]make clean[/code] before running [code]make[/code] or compile with [code]make -B sarg[/code] to rebuild all the .o files.
Ok, send me a tar.gz, please. I couldn't generate de configure script because CentOS does not have gettext 0.16 or above.
The mail is gone and didn't bounce back yet.
I've compiled the file you sent me and sarg produced the same error that before:
/etc/cron.d/relatoriosSarg/sarg-reports: line 208: 25966 Segmentation fault $SARG -f $CONFIG_FILE -d $TODAY -o $PATH_SAIDA > $ERRORS 2>&1
If I disable ldap option in usertab parameter, the error above doesn't occur.
I sent an e-mail to your sourceforge address with a new version of usertab.c. It should fix the problem.
The fix is in svn too.
New version of usertab.c file solved the problem with seg fault, but now the operations error in ldap search returned. See output below:
SARG: Records in file: 1038504, reading: 0.00
SARG: Records in file: 1038504, reading: 100.00%
SARG: Period covered by log files: 03/02/2011-03/02/2011
SARG: LDAP search failed: Operations error
SARG: looking for "(sAMAccountName=UserLogin1)" at or below "DC=myDomain,DC=go,DC=gov,DC=br"
...
SARG: LDAP search failed: Operations error
SARG: looking for "(sAMAccountName=UserLoginN)" at or below "DC=myDomain,DC=go,DC=gov,DC=br"
SARG: Successful report generated on /web/html/acessoweb/Diario/03Feb2011-03Feb2011
SARG: Records in file: 1038504, reading: 100.00%
Then it isn't due to the old API and setting a default schema doesn't help either.
I'll look more closely at the source code of ldapsearch.
query global catalog of AD, and this will work. SARG does not yet support AD refferals
to do that, first you need to finout what is GC on your AD. Serach ms KB for that.
And LDAP port should be 3268
Do you know what must be done to support AD referrals in sarg ?
I have spent hours reviewing the source code of ldapsearch without being able to find out what it does that sarg does not do. I know it is a referral problem but I haven't found anything related to that in ldapsearch.
Frederic