Thanks again for your advice, Howard.
I am only implementing an LDAP client that needs to operate in a customer environment that may exploit referrals; i.e. I don't have any influence over how the servers are configured at a customer site.
But would you be able to suggest a better approach for my client code?
1) UserA signs in with PasswordA 2) My code binds with the LDAP server with which it's been configured. 3) The code constructs a filter consisting of "cn=UserA". 4) It then performs a search specifying the filter and a base, (also pre-configured). 5) Referral chasing allows this search to succeed even if the matching entry exists on a different LDAP server. 6) My client code then extracts the DN of the returned entry. 7) It then attempts to authenticate that user using that DN and the entered PasswordA. 8) This is where my design falls short; the bind doesn't chase referrals and instead the authentication fails because the associated entry exists in a different server.
So bearing in mind that: a) I have no control over how a customer configures their LDAP servers, b) The customer configures my client program with the name of one LDAP server along with a filter, base and master bind credentials, c) My client program only knows the CN of the user and not their DN, d) Ultimately, I just need to authenticate that user,
... is there a better approach that would accommodate environments that use referrals?
Thanks again, Mike
On Thu, 12 May 2022 at 03:23, Howard Chu hyc@symas.com wrote:
Mike Stevens wrote:
Many thanks for your prompt response and for pointing me at the
appropriate spec, Howard.
I don't believe that chaining and proxies are an option as I have no
control over the configuration of the LDAP server and must instead adapt the client to
accommodate servers that utilise referrals.
One alternative I've considered is:
Disable referral chasing in the client:
ldap_set_option( ld , LDAP_OPT_REFERRALS , LDAP_OPT_OFF );
Bind to the top level server using master credentials.
Search for the specified user; if the user doesn't exist at that
server, one or more referrals will be returned.
- Iterate over each referral attempting to bind to each one using the
user's credentials until either the bind succeeds or I run out of referral candidates.
If you have time to comment on that proposal, I'd be very grateful.
That's a lot of work. I would just set up my own slapd configured with two back-ldap instances.
first instance pointed at server B, marked subordinate.
second instance pointed at server A.
Point all clients at this slapd, all done, move on.
Kind regards, Mike
On Wed, 11 May 2022 at 22:57, Howard Chu <hyc@symas.com <mailto:
hyc@symas.com>> wrote:
Mike Stevens wrote: > Good day. > > > > I’m an LDAP novice and am attempting to modify an LDAP client toaccommodate an LDAP server environment that makes use of referrals.
> > > > I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers. > > > The initial entries in the tree on serverA contains : > > > # xxx.com <http://xxx.com> <http://xxx.com> > dn: dc=xxx,dc=com > description: xxx.com <http://xxx.com> <http://xxx.com> > dc: xxx > o: xxx.com <http://xxx.com> <http://xxx.com> > objectClass: top > objectClass: dcObject > objectClass: organization > > # Users, xxx.com <http://xxx.com> <http://xxx.com> > dn: ou=Users,dc=xxx,dc=com > ou: Users > description: xxx Users > objectClass: organizationalUnit > > # search reference > *ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub <http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub%3E
<http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub>* > > # mike, Users, xxx.com <http://xxx.com> <http://xxx.com> > dn: uid=mike,ou=Users,dc=xxx,dc=com > cn: mike > ou: Users > uid: mike > givenName: Mike > mail: mike@uk.xxx.com <mailto:mike@uk.xxx.com> <mailto:mike@uk.xxx.com mailto:mike@uk.xxx.com>
> objectClass: Person > objectClass: organizationalPerson > objectClass: inetOrgPerson > > > > I believe the "ref" entry is known as a subordinate referral; > > it was created by populating the tree from an LDIF file thatcontained the following:
> > > dn: dc=uk,dc=xxx,dc=com > objectClass: referral > objectClass: extensibleObject > dc: uk > ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com <http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com%3E < http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com%3E
> > > The intent is to redirect any requests received by serverA thatrefer to the subtree uk.xxx.com http://uk.xxx.com http://uk.xxx.com to serverB.
> > > The tree on serverB contains: > > > # xxx.com <http://xxx.com> <http://xxx.com> > dn: dc=xxx,dc=com > description: xxx.com <http://xxx.com> <http://xxx.com> > dc: xxx > o: xxx.com <http://xxx.com> <http://xxx.com> > objectClass: top > objectClass: dcObject > objectClass: organization > > # uk.xxx.com <http://uk.xxx.com> <http://uk.xxx.com> > dn: dc=uk,dc=xxx,dc=com > dc: uk > o: uk.xxx.com <http://uk.xxx.com> <http://uk.xxx.com> > description: xxx Users in the UK > objectClass: dcObject > objectClass: organization > > # mike, uk.xxx.com <http://uk.xxx.com> <http://uk.xxx.com> > dn: uid=mike,dc=uk,dc=xxx,dc=com > cn: mike > uid: mike > givenName: Mike > mail: mike@uk.xxx.com <mailto:mike@uk.xxx.com> <mailto:mike@uk.xxx.com mailto:mike@uk.xxx.com>
> objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > > > Now, if I perform a search on serverA specifying a base ofuk.xxx.com http://uk.xxx.com http://uk.xxx.com, I get an RC=10 Referral result as expected:
> > [root@serverA ~]# ldapsearch -x '(uid=mike)' -bdc=uk,dc=xxx,dc=com -LL
> version: 1 > > Referral (10) > Matched DN: dc=uk,dc=xxx,dc=com > Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub <http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub%3E
<http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub> > > ... and I can chase that referral using the -C option to retrievethe entry from serverB:
> > [root@Mike21 ~]# ldapsearch -x '(uid=mike)' -bdc=uk,dc=ibm,dc=com -LL -C
> version: 1 > > dn: uid=mike,dc=uk,dc=xxx,dc=com > cn: mike > uid: mike > givenName: Mike > mail: mike@uk.xxx.com <mailto:mike@uk.xxx.com> <mailto:mike@uk.xxx.com mailto:mike@uk.xxx.com>
> objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > > But, if I attempt a bind to serverA using the user that exists inserverB, I get an authentication failure:
> > [root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -Duid=mike,dc=uk,dc=xxx,dc=com -w passw0rD
> ldap_bind: Invalid credentials (49) > > Now, I realise that the failure would be expected as the bind DNdoesn't exist at serverA.
> But I read that every request apart from unbind and abandon canresult in a referral.
> So why doesn't the bind follow the "ref" to serverB? > Is that possible and have I not configured my server correctly? No. See RFC3296 section 5.6.1. > > Ultimately, what I'd like to do in my client is something like: > > ld_user = ldap_init( "ldap://serverA:389/dc=uk,dc=xxx,dc=com", 0 );
> > ... followed by : > > err = ldap_simple_bind_s( ld_user,"uid=mike,dc=uk,dc=xxx,dc=com" , password);
> > ... and have LDAP authenticate the given user against serverBbased on the referral in serverA.
> > Is this sort of set up possible? You will need to configure chaining or some other proxy mechanisminstead.
> > Many thanks for your advice, > Mike > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/