Patch for Adding in ldap_server, ldb the notion of request made through LDAPS

simo idra at
Mon Mar 21 06:29:45 MDT 2011

On Sun, 2011-03-20 at 15:53 +0300, Matthieu Patou wrote:
> Hello All,
> After noticing that we didn't return correctly referrals when doing it 
> through ldaps (referrals are returned like ldap:// when they should be 
> ldaps://), I started to look in the code and didn't find any trace of 
> flags that indicate whether or not the request comes from ldaps.
> This commit 3fbbbedd47be60f2b1deb04140d73dcc049b00e5, flags the 
> information in the ldapsrv* structures.
> This commit 24874162efdf78065eebf54f194e13ec8465e753, use the flags in 
> the ldapsrv* structure and call the ldb_set_mark function to set the 
> flag in the ldb_request
> This commit 2bec148cb4cb130e23016509c922bb1bfc22ef2e, use the ldb flags 
> to format the referral accordingly.
> They are present at 
> Note: I'm pretty sure that this kind of information will be needed more 
> than once as I also faced case when windows refuse to do things over 
> plain ldap (ie. setting password through ldap).

Sorry Matthieu but I think this information is ldap server/samba
specific and should be put in some opaque structure that ldb knows
nothing about. Ldb itself has no listener so having functions in ldb to
set this information sounds awkward.

Finally, although your immediate problem was referrals I thin this
approach is reductive. You probably want to make it a bit more generic
and put in this opaque internal samba structure also information like
the ssf level so that modules can decide whther to trust exposing some
information based on that number (like other ldap servers do). The ssf
is a number that described the "security" of the connection and is set
by ldaps and also by gssapi protected connection. Also both openldap and
389ds set ssf to 72 if ldapi:// is used as that is considered a secure
connection as nobody except root can evesdrop it anyway.



Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list