Hi All, Following everyone's help our eduroam system is up and running by the target date - Many thanks, particularly to Alan and Ivan. I'm now trying to configure it *properly* I have, in the ldap module configuration: chase_referrals = yes rebind = yes I'm running version 2.1.6 on Solaris doing lookups against Active Directory. I get, in the debug: rlm_ldap: Bind was successful rlm_ldap: performing search in dc=ad, dc=hud, dc=ac, dc=uk, with filter (sAMAccountName=mytestusername) rlm_ldap: ldap_search() failed: Operations error rlm_ldap::ldap_groupcmp: search failed Has anyone got latest information on what causes this or how to fix it. I have a workaround but it's not ideal. I assume trying to get more helpful information out of Microsoft AD is pretty futile but has anyone any clues as to what "operations error" realy means? The workaround is to specify a container in the search but as the number of possible containers for a search increases things rapidly begin to get out of hand ..... Regards, Leighton --- This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.
Leighton Man wrote:
I have, in the ldap module configuration:
chase_referrals = yes rebind = yes
That's good...
I'm running version 2.1.6 on Solaris doing lookups against Active Directory.
I get, in the debug:
rlm_ldap: Bind was successful rlm_ldap: performing search in dc=ad, dc=hud, dc=ac, dc=uk, with filter (sAMAccountName=mytestusername) rlm_ldap: ldap_search() failed: Operations error rlm_ldap::ldap_groupcmp: search failed
That's bad.
Has anyone got latest information on what causes this or how to fix it. I have a workaround but it's not ideal. I assume trying to get more helpful information out of Microsoft AD is pretty futile but has anyone any clues as to what "operations error" realy means? The workaround is to specify a container in the search but as the number of possible containers for a search increases things rapidly begin to get out of hand .....
Microsoft says "it means error in operation". Nice. How many AD servers do you have? Is the FreeRADIUS server (i.e. admin account) allowed to do the queries?[ Alan DeKok.
Leighton, Try using ldapsearch in verbose mode (and debug mode) to get more info from AD. ldapsearch -v -h <AD Server> -D "cn=<account to bind> dc=ad, dc=hud, dc=ac, dc=uk" -w <password> -x -b "dc=ad, dc=hud, dc=ac, dc=uk" "(sAMAccountName=mytestusername)"
From a Windows machine, you can also use tools from joeware.com, try adfind (http://www.joeware.net/freetools/tools/adfind/index.htm).
Once you are able to successfully query AD from a Windows machine and/or ldapsearch, update your FR configuration and try again. Tim
-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Leighton Man Sent: Tuesday, October 06, 2009 8:50 AM To: 'FreeRadius users mailing list' Subject: Ldap search and AD operations error
Hi All,
Following everyone's help our eduroam system is up and running by the target date - Many thanks, particularly to Alan and Ivan.
I'm now trying to configure it *properly*
I have, in the ldap module configuration:
chase_referrals = yes rebind = yes
I'm running version 2.1.6 on Solaris doing lookups against Active Directory.
I get, in the debug:
rlm_ldap: Bind was successful rlm_ldap: performing search in dc=ad, dc=hud, dc=ac, dc=uk, with filter (sAMAccountName=mytestusername) rlm_ldap: ldap_search() failed: Operations error rlm_ldap::ldap_groupcmp: search failed
Has anyone got latest information on what causes this or how to fix it. I have a workaround but it's not ideal. I assume trying to get more helpful information out of Microsoft AD is pretty futile but has anyone any clues as to what "operations error" realy means? The workaround is to specify a container in the search but as the number of possible containers for a search increases things rapidly begin to get out of hand .....
Regards,
Leighton
--- This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Subject: RE: Ldap search and AD operations error
Leighton,
Try using ldapsearch in verbose mode (and debug mode) to get more info from AD.
ldapsearch -v -h <AD Server> -D "cn=<account to bind> dc=ad, dc=hud, dc=ac, dc=uk" -w <password> -x -b "dc=ad, dc=hud, dc=ac, dc=uk" "(sAMAccountName=mytestusername)"
From a Windows machine, you can also use tools from joeware.com, try adfind (http://www.joeware.net/freetools/tools/adfind/index.htm).
Once you are able to successfully query AD from a Windows machine and/or ldapsearch, update your FR configuration and try again.
Tim
Many thanks for the reply Tim and apologies for the long delay before trying this. Ldapsearch from the command line as you suggest above works fine yet the debug from FR shows this: rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=ad, dc=hud, dc=ac, dc=uk, with filter (sAMAccountName=mytestusername) rlm_ldap: ldap_search() failed: Operations error rlm_ldap::ldap_groupcmp: search failed rlm_ldap: ldap_release_conn: Release Id: 0 The basedn and filter are identical on the command line and in the config. If I specify an AD container in the config, the search succeeds (providing it's the right container, of course ) Any more ideas - I'm really stuck on this one! Leighton --- This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.
participants (3)
-
Alan DeKok -
Leighton Man -
Tim Sylvester