On Mon, 25 Jun 2012, W.Siebert@t-systems.com wrote:
Hello, thank you,
but my application CUCM can use only one directory to authenticate users. I can configure only one dc
Exactly; this was written with a client that only accepts a single baseDN in mind. Configure to ldap://newopenldap.example.com/ with baseDN "" if you use the config example I wrote. (Play around with OpenLDAP clients such as ldapsearch(1) to get the feel of things first, or if posting to the list.)
Regards Waldemar
-----Urspr?ngliche Nachricht----- Von: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Gesendet: Montag, 25. Juni 2012 16:28 An: Siebert, Waldemar Cc: openldap-technical@openldap.org Betreff: Re: Controlled LDAP Proxy/Relay
On Fri, 22 Jun 2012, W.Siebert@t-systems.com wrote:
Hello, thanks for your answer. But I don?t have any local users. All users are in two targets: domain01.com and domain99.net (AD). Where I should place userPassword attribute?
So you have dc=microsoft1 running on ad1.example.com and dc=microsoft2 running on ad2.example.net, with no need for additional data?
Have you considered:
database meta subordinate suffix "dc=microsoft1" uri ldap://ad1.example.com/dc=microsoft1
database meta subordinate suffix "dc=microsoft2" uri ldap://ad2.example.net/dc=microsoft2
database null suffix ""
and then have your "single baseDN only" client configured to the back-null? Only place this gets slightly weird is if you have conflicting namespace across the two back-meta's (i.e. if "cn=example,dc=microsoft1" and "cn=example,dc=microsoft2" both exist -- check your application behavior carefully in such a case).
My problem: We have a VoIP realized by Cisco Unified Call Manager (CUCM). There are several thousand users in the customers directory (domain01.com) using CUCM for Voice and ca 100 adminusers in the supplier directory (domain99.net). No trusting, different companies. Because CUCM can use only one directory to authenticate users I've implemented a OpenLDAP Metadirectory that proxying this 2 Microsft AD targets. But meta backend tries to authenticate by the first target, if the user was not found, by the second. Result: Intrusion detection register a lot of unsuccessfully login attempts. Therefore my question: Is it possible to implement the controlled proxy with OpenLDAP ? E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_ go to the target1, and when username is _xxx@domain99.net_ go to the target2. Can you help me please Kind regards Waldemar ################################################################ On 08/02/2012 09:58, W.Siebert@t-systems.com wrote:
Is it possible to implement the controlled proxy with OpenLDAP ? E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_ mailto:xxx@domain01.com go to the target1, and when username is _xxx@domain99.net_mailto:xxx@domain99.net go to the target2.
Yes, a combination of meta database config in slapd.conf and appropriate SASL config. In your schema, use the following in userPassword: userPassword: {SASL}xxx@DOMAIN where DOMAIN is whichever domain the user needs to be authenticated against. In slapd.conf: database meta suffix dc=local rootdn cn=administrator,dc=local rootpw secret # domain01 uri ldaps://domain01.com:3269/ou=domain01.com,dc=local lastmod off suffixmassage "ou=domain01.com=local" "dc=domain01,dc=com" idassert-bind bindmethod=simple binddn="cn=binder,dc=domain01,dc=com" credentials="password" flags=non-prescriptive idassert-authzFrom "dn.exact:cn=administrator,dc=local" # domain02 uri ldaps://domain02.com:3269/ou=domain02.com,dc=local lastmod off suffixmassage "ou=domain02.com=local" "dc=domain02,dc=com" idassert-bind bindmethod=simple binddn="cn=binder,dc=domain02,dc=com" credentials="password" flags=non-prescriptive idassert-authzFrom "dn.exact:cn=administrator,dc=local" In saslauthd.conf you need to create the appropriate search base for authentication based on the domain in the userPassword field: ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta ldap_search_base: ou=%d,dc=local ldap_filter: (sAMAccountName=%U) ldap_auth_method: bind ldap_bind_dn: cn=administrator,dc=local ldap_password: secret ldap_deref: never ldap_use_sasl: no Hopefully this is enough info to get you going. -- Liam Gretton liam.gretton@le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom