Thanks Alan; I think I understand what you mean, however each of our trees is sorted by campus, then OU, then users. Student | | |---Brisbane | |---Sydney1 | |---Sydney2 | |---Canberra | |--computers | |--Printers | |---users and the same for staff. What's the best way to format the baseDN to allow for recursive searches through each OU container. At the moment I have basedn= "ou=users,dc=student,dc=acu,dc=edu,dc=au", which is obviously wrong. Many thanks Stephen Walsh [EMAIL PROTECTED] Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++ Stephen Walsh <[EMAIL PROTECTED]> wrote: > ldap_search() failed: Operations error It's a combination of factors. What's happening is that your LDAP search isn't fully qualified, so when something isn't found in "students", AD returns a referral to "staff". OpenLDAP fails to use the authentication credentials for the referral that it was given for the original query. And lo, "operations error", which is such a useful message. It's a cross-domain referral problem. You have a "staff" domain, and a "student" domain, each of which trusts each other in AD. The solution is to fully qualify all of the queries so that AD doesn't return a referral. Usually adding "ou=people" (or something like that) will usually do the trick. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html