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:
>
> 1) Disable referral chasing in the client:
>
> ldap_set_option( ld , LDAP_OPT_REFERRALS , LDAP_OPT_OFF );
>
>
> 2) Bind to the top level server using master credentials.
> 3) Search for the specified user; if the user doesn't exist at that server, one or more referrals will be returned.
> 4) 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 to accommodate 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>
> <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 that contained 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> <http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com>
> >
> >
> > The intent is to redirect any requests received by serverA that refer 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 of uk.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)' -b dc=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>
> <http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub>
> >
> > ... and I can chase that referral using the -C option to retrieve the entry from serverB:
> >
> > [root@Mike21 ~]# ldapsearch -x '(uid=mike)' -b dc=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 in serverB, I get an authentication failure:
> >
> > [root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -D uid=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 DN doesn't exist at serverA.
> > But I read that every request apart from unbind and abandon can result 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 serverB based on the referral in serverA.
> >
> > Is this sort of set up possible?
>
> You will need to configure chaining or some other proxy mechanism instead.
> >
> > 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/