Hello, One thing that stopped working since I introduced the new directives which fixed the authentication problem is being able to peruse the directories using Apache Directory Studio. I can still see the AD branches but when I try to look at them I get an error which in the server logs is reported as
res_errno: 1, res_error: <000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1>, res_matched: <> ldap_free_request (origid 2, msgid 2)
So I must still be missing something in my configuration. Thanx Gaby
On 09/11/11 19:34 +0000, Gabriella Turek wrote:
Hi Dan,
The way I got it to work (by pure chance mind you , I just happened on a blog entry somewhere) was to add this entry to the slapd.config file:
# Configure slapd-ldap back end to connect to AD database ldap suffix "ou=user accounts,dc=niwa,dc=local" subordinate rebind-as-user uri "ldap://aucwdfp01.niwa.local:389" chase-referrals yes
Nowhere in any documentation did I see this mentioned, and yet it worked immediately, So I don't know what to think. Gaby
On 10/11/11 6:37 AM, "Dan White" dwhite@olp.net wrote:
On 07/11/11 21:57 +0000, Gabriella Turek wrote:
Hello, I've set up an openLDAP server (2.4.23) which chains to an Active Directory (2008). I can successfully search for users, it will find them in Active Directory if they are not in openLDAP, but I cannot authenticate the Active Directory users. The error is "Invalid credentials (49)" Everything is currently configured with clear text ldapSearch works fine when pointed directly to the Active Directory.
The chaining configuration in the slapd.conf is:
overlay chain chain-uri ldap://aucwdfp01.niwa.local:389 chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=SDT Tester,ou=NIWA Staff Accounts,ou=User Accounts, dc=niwa,dc=local" credentials=xxxxxxx mode="self" flags=non-prescriptive chain-return-error TRUE
Does mode="none" work? If my reading of slapd-ldap(5) is correct, with any config other than 'none', slapd will attempt to assert the proxyAuthz control.
I checked our local AD server (2003) and it does not appear to support that control:
ldapsearch -LLL -x -H ldap://<AD.ip> -s "base" -b "" supportedControl dn: supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.801 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.528 supportedControl: 1.2.840.113556.1.4.417 supportedControl: 1.2.840.113556.1.4.619 supportedControl: 1.2.840.113556.1.4.841 supportedControl: 1.2.840.113556.1.4.529 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.521 supportedControl: 1.2.840.113556.1.4.970 supportedControl: 1.2.840.113556.1.4.1338 supportedControl: 1.2.840.113556.1.4.474 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.10 supportedControl: 1.2.840.113556.1.4.1504 supportedControl: 1.2.840.113556.1.4.1852 supportedControl: 1.2.840.113556.1.4.802 supportedControl: 1.2.840.113556.1.4.1907 supportedControl: 1.2.840.113556.1.4.1948
proxyAuthz control == 2.16.840.1.113730.3.4.18 (RFC 4370)
-- Dan White
-- Dan White BTC Broadband Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite@olp.net http://www.btcbroadband.com