Re: (ITS#6668) MemberOf Overlay
by wf＠bitplan.com
on
http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-m...
one can see how the issue hit us. We have a Suse 11.2 machine where
the standard openldap configuration is slapd.conf based.
On another ubuntu 10.04 machine it's cn=config based.
The memberOf function simply didn't work and there were not proper error
messages and googling the issue was a pain in the ****
When we finally found out that we need an overlay no rpm was available.
So we went and tried everything on the ubuntu machine.
But then there was this change of how everything is configured.
Basically we could start googling all over again. Many hours and
problems later we got the memberOf function working. What we know now is
that OpenLdap has joined the list of projects that have abandondend
simple configuration with a more complicated one. We've seen this with
grub2, gnome and other projects. In all cases in our opinion this is not
helping the majority of people using these projects. Many years of
Documentation on the internet is invalidated and worse there are now two
ways to do things that are incompatible and if you try to go back (as we
did on ubuntu trying to get a slapd.conf based version running) it does
not get any easier.
Please use the contact form on BITPlan's webpage if you'd like to get
our configuration script for memberOf - we won't publish it at this time
since it contains user data.
--
BITPlan - smart solutions
Wolfgang Fahl
Web: http://www.bitplan.de
12 years, 11 months
(ITS#6668) MemberOf Overlay
by wf＠bitplan.com
Full_Name: Wolfgang Fahl
Version: 2.4
OS: many
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (93.193.149.46)
We have been struggling a full day with the memberOf issue and have now given
up. In our humble opinon the complexity is well out of range for such a
seemingly trival functionality.
12 years, 11 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it
> The configuration and test operations below should show exactly what's
> going on, but first, allow me to describe the
> process in a nutshell:
>
> 1. The client binds to the slave and issues a modification request
>
> 2. The slave creates the referral and tries to chase it automatically on
> the client's behalf to the upstream master
> using slapo-chain
>
> 3. The automatic referral chasing fails because the DN is not passed
> through and the slave erroneously rebinds to the
> master as anonymous (an empty DN) instead of the identity it's configured
> to assert, as set by the olcDbIDAssertBind
> attribute.
>
> 4. Because the automatic referral chasing fails, the slave kicks back the
> referral to the client, stating that the
> client "is not logged in" to the master and that "modifications require
> authentication".
>
> 5. When the client provides credentials for the referral (manual referral
> chasing), the rest of the operation works as
> expected (updates made on master, which then cascades to the slaves).
What the case description and the logs suggest is that the referral is
chased anonymously because the protocol/host/port portion of the URI in
the referral does not match the one configured in the chain-uri directive.
In this case, slapo-chain defaults to anonymous.
What slapo-chain does is take the referral string, pass it to URL parsing
routines, isolate protocol, host and port, pass it back to URL unparsing,
and compare the resulting string with the one configured in chain-uri
(which had to go through the same "normalization" when configured).
Perhaps if you try with a more detailed log level you'll be able to see
the two strings and figure out if and how they differ. Hope this helps.
p.
>
> The following LDIFs and sample operations exemplify the problem; please
> let me know if this example suffices, or if you
> need a more complete reference or further clarification:
>
> #################################################
> # CONFIGURATION #
> #################################################
>
> ### back-config base entry on slave (abbreviated)
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcConfigDir: /etc/ldap/slapd.d
> olcReadOnly: FALSE
> olcReverseLookup: FALSE
> olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem
> olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem
> olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem
> olcAuthzPolicy: none
> olcLogLevel: stats sync
> olcPasswordHash: {SSHA}SUPERSECRET
> olcServerID: 1 ldap://master1.example.com
> olcServerID: 2 ldap://slave1.example.com
>
> ### back-config modules entry
> dn: cn=module{0},cn=config
> objectClass: olcModuleList
> cn: module{0}
> olcModulePath: /usr/lib/ldap
> olcModuleLoad: {0}back_hdb.la
> olcModuleLoad: {1}autogroup.la
> olcModuleLoad: {2}syncprov.la
> olcModuleLoad: {3}back_ldap.la
>
> ### back-config chain overlay entry
> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcChainConfig
> olcOverlay: {0}chain
>
> ### back-config chain database
> dn:
> olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
> objectClass: olcLDAPConfig
> objectClass: olcChainDatabase
> olcDatabase: {0}ldap
> olcDbURI: ldap://master1.example.com
> olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com"
> credentials=SECRET mode=self
>
>
> #################################################
> # SIMPLE OPERATIONAL EXAMPLE #
> #################################################
>
> ### NOTE: This example uses ldapvi, but results are identical to
> ldapmodify, etc.
> ### NOTE: The client binds initially to the slave as the admin here, but
> results are identical to scenarios in which the
> client binds as a regular user
>
> ### Attempting to modify 'displayColor' attribute belonging to entry
> 'uid=ryans,ou=Users,dc=example,dc=com'
> root@slave1:~# ldapvi -h localhost --bind=simple -D
> cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover
> 159 entries read
>
> add: 0, rename: 0, modify: 1, delete: 0
> Action? [yYqQvVebB*rsf+?] y
> Received referral to
> ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com.
> You are not logged in to ldap://master1.example.com:389 yet.
> Type '!' or 'y' to do so.
> Rebind? [y!nB*qQ?] y
>
> --- Login
> Type M-h for help on key bindings.
>
> Filter or DN: cn=admin,dc=example,dc=com
> Password: ***********
> Bound as cn=admin,dc=example,dc=com.
> Done.
>
> #################################################
> # LOGS FOR OPERATIONAL EXAMPLE #
> #################################################
>
> ### Logs on slave showing referral was correctly generated (err=10)
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from
> IP=127.0.0.1:34118 (IP=0.0.0.0:389)
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text=
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established
> tls_ssf=128 ssf=128
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND
> dn="cn=admin,dc=example,dc=com" method=128
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND
> dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0
> text=
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0
> deref=0 filter="(objectClass=*)"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ *
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn=""
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH
> base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="cn=admin,dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="ou=users,dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="ou=groups,dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="uid=ryans,ou=users,dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY
> dn="cn=ryans,ou=groups,dc=example,dc=com"
> Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101
> err=0 nentries=159 text=
> Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD
> dn="uid=ryans,ou=Users,dc=example,dc=com"
> Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor
> Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10
> text=
>
>
> ### Logs on master showing that when the slave tried to chase the
> referral, it erroneously bound as anonymous
> ### NOTE: slave1.example.com = 10.0.1.196
> Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from
> IP=10.0.1.196:43376 (IP=0.0.0.0:389)
> Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn=""
> method=128
> Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0
> text=
> Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD
> dn="uid=ryans,ou=Users,dc=example,dc=com"
> Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD
> attr=displayColor
> Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8
> text=modifications require authentication
> Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND
> Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed
> Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from
> IP=10.0.1.196:43377 (IP=0.0.0.0:389)
>
>
> If there are any details not shown that you'd like, or any clarification
> you require, or if there's anything at all you
> need to help facilitate the investigation, please let me know and I'll do
> my best to accommodate. Thanks!
>
> -Ryan
>
>
>
12 years, 11 months
Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it
> Note that the SSSVLV overlay can handle paged results locally too, thus
> negating any need for back-ldap/back-meta to forward it to a remote
> server.
> Obviously for greatest generality, there needs to be a way to configure
> which
> set of controls to pass through, and which to process locally. (Much like
> back-ldap's option to process the WhoAmI exop...)
Right. With proxies the problem is twofold:
a) clients request pr because they think they're talking to AD
b) the proxy may need to use pr even if the client does not request it,
because it knows it's talking to AD
In (a), the issue could be handled the way sssvlv does, relieving the
proxy from having to deal with server-side pr; this would be extremely
beneficial, for example, for back-meta
In (b), the proxy could be configured to use pr the way I mentioned above;
in principle, the proxy could be so clever to avoid using pr, and simply
accept to handle unrequested pr responses, but only if instructed to do
so.
Filtering what controls are passed thru should be easy, since both proxy
backends always call ldap_back_controls_add()/meta_back_controls_add() to
muck with request controls (usually to add proxied authorization and so);
this function could easily strip or add pr if instructed to do so.
p.
12 years, 11 months
Re: (ITS#6665) back_ldap and back_meta chasing referrals authentication
by masarati＠aero.polimi.it
> Full_Name: Javier Sanz
> Version: 2.4.17
> OS: Debian Linux 5.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.38.203.12)
>
>
> back_ldap and back_meta should be able to do a non-anonymous bind to the
> referrals returned by the external LDAP servers.
>
> This is a regression since 2.3, because the old directives "pseudorootdn"
> and
> "pseudorootpw" allowed specifying the binddn and password that would be
> used to
> chase the referrals, but their 2.4 replacements "idassert-bind" and
> "idassert-authzFrom" do not allow that, so these binds are always done
> anonymously.
Back-ldap seems to work as expected if you set
chase-referrals yes
rebind-as-user yes
idassert-bind bindmethod=simple
binddn=<dn>
credentials=<cred>
mode=self
and binddn <dn> with credentials <cred> exists on both the remote server
and the one pointed to by the referral.
With back-meta, it should work with the same parameters; however, I've
checked and the specific code used to bind during searches does not set
the rebind procedure correctly. I've fixed this in HEAD, please test.
Thanks, p.
12 years, 11 months
Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
>> Full_Name: Javier Sanz
>> Version: 2.4.17
>> OS: Debian Linux 5.0
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (80.38.203.12)
>>
>>
>> back_meta and back_ldap should forward server controls that clients use in
>> their
>> queries to the corresponding external LDAP servers.
>
> Both back-ldap and back-meta forward controls to the remote servers.
>
>> For example, the inhability to send controls to external servers currently
>> causes that RFC2696 paged results control cannot be used, so it is
>> impossible to
>> retrieve more results for a query than the page size configured in the
>> external
>> server, which often is not a big number.
>
> As far as I can tell, back-ldap supports paged results correctly (just
> tested with HEAD and 2.4.23 code). Back-meta does not, and likely will
> never do. Please note that while all back-ldap needs to do is blindly
> forward control request/response, back-meta would need to separately
> handle requests server-side (i.e. when the client requests the control)
> and client-side (i.e. when non LDAP-compliant remote servers return the
> control while the client did not request it). In between, it would need
> to return the page size requested by the client and store the (possibly
> paged) response of each remote server. Not worth the effort. The
> solution consists in increasing the page size returned by default by
> non-LDAP compliant remote servers.
>
> Perhaps the problem could be split in two:
>
> 1) allow to configure per-target mandatory use of paged results, with a
> specified page size; this means that search requests hitting a specific
> target would always add the paged results control to the request, and
> handle control responses accordingly.
>
> 2) handle server-side control response in an overlay that takes care of
> storing search results and returning them as appropriate. This would
> (maybe inefficiently) handle paged results regardless of the backend that
> is actually handling a request.
>
> Even if only (1) is implemented, clients would no longer need to use pr
> when talking to slapd, since back-meta would handle non-LDAP compliant
> remote servers that return pr response when the control is not requested.
>
> I think this ITS should be closed (back-ldap and back-meta do forward
> controls); maybe another ITS with a back-meta feature request to handle
> non-LDAP compliant remote servers could be filed.
Note that the SSSVLV overlay can handle paged results locally too, thus
negating any need for back-ldap/back-meta to forward it to a remote server.
Obviously for greatest generality, there needs to be a way to configure which
set of controls to pass through, and which to process locally. (Much like
back-ldap's option to process the WhoAmI exop...)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 11 months
Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it
> Full_Name: Javier Sanz
> Version: 2.4.17
> OS: Debian Linux 5.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.38.203.12)
>
>
> back_meta and back_ldap should forward server controls that clients use in
> their
> queries to the corresponding external LDAP servers.
Both back-ldap and back-meta forward controls to the remote servers.
> For example, the inhability to send controls to external servers currently
> causes that RFC2696 paged results control cannot be used, so it is
> impossible to
> retrieve more results for a query than the page size configured in the
> external
> server, which often is not a big number.
As far as I can tell, back-ldap supports paged results correctly (just
tested with HEAD and 2.4.23 code). Back-meta does not, and likely will
never do. Please note that while all back-ldap needs to do is blindly
forward control request/response, back-meta would need to separately
handle requests server-side (i.e. when the client requests the control)
and client-side (i.e. when non LDAP-compliant remote servers return the
control while the client did not request it). In between, it would need
to return the page size requested by the client and store the (possibly
paged) response of each remote server. Not worth the effort. The
solution consists in increasing the page size returned by default by
non-LDAP compliant remote servers.
Perhaps the problem could be split in two:
1) allow to configure per-target mandatory use of paged results, with a
specified page size; this means that search requests hitting a specific
target would always add the paged results control to the request, and
handle control responses accordingly.
2) handle server-side control response in an overlay that takes care of
storing search results and returning them as appropriate. This would
(maybe inefficiently) handle paged results regardless of the backend that
is actually handling a request.
Even if only (1) is implemented, clients would no longer need to use pr
when talking to slapd, since back-meta would handle non-LDAP compliant
remote servers that return pr response when the control is not requested.
I think this ITS should be closed (back-ldap and back-meta do forward
controls); maybe another ITS with a back-meta feature request to handle
non-LDAP compliant remote servers could be filed.
p.
12 years, 11 months
Re: (ITS#6667) memberof infinite recursion on node rename
by masarati＠aero.polimi.it
Can you provide a minimal example that triggers the problem? You should
boil it down to:
- the slapd.conf or the contents of the cn=config database
- the LDIF needed to populate the database
- the operation that causes the problem (I presume it's a modify or a
write operation, so you should be able to provide it in form of LDIF and
main parameters, e.g. the identity that is performing the operation).
Thanks, p.
12 years, 11 months
Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it
Valgrind shows more issues possibly related to this ITS when
SLAP_NO_SL_MALLOC is defined. When running test047, whoami results in
conn=1013 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3
conn=1013 op=1 WHOAMI
==11941== Thread 5:
==11941== Conditional jump or move depends on uninitialised value(s)
==11941== at 0x820B122: rwm_op_rollback (rwm.c:62)
==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165)
==11941== by 0x809EC0F: slap_cleanup_play (result.c:436)
==11941== by 0x809F34B: send_ldap_response (result.c:621)
==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802)
==11941== by 0x80C90BD: fe_extended (extended.c:237)
==11941== by 0x810E8FD: overlay_op_walk (backover.c:669)
==11941== by 0x810EAB2: over_op_func (backover.c:721)
==11941== by 0x810EC71: over_op_extended (backover.c:796)
==11941== by 0x80C8D95: do_extended (extended.c:177)
==11941== by 0x808AD29: connection_operation (connection.c:1109)
==11941== by 0x808B269: connection_read_thread (connection.c:1245)
==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685)
==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so)
==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so)
==11941==
==11941== Conditional jump or move depends on uninitialised value(s)
==11941== at 0x820B13A: rwm_op_rollback (rwm.c:65)
==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165)
==11941== by 0x809EC0F: slap_cleanup_play (result.c:436)
==11941== by 0x809F34B: send_ldap_response (result.c:621)
==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802)
==11941== by 0x80C90BD: fe_extended (extended.c:237)
==11941== by 0x810E8FD: overlay_op_walk (backover.c:669)
==11941== by 0x810EAB2: over_op_func (backover.c:721)
==11941== by 0x810EC71: over_op_extended (backover.c:796)
==11941== by 0x80C8D95: do_extended (extended.c:177)
==11941== by 0x808AD29: connection_operation (connection.c:1109)
==11941== by 0x808B269: connection_read_thread (connection.c:1245)
==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685)
==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so)
==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so)
conn=1013 op=1 RESULT oid= err=0 text=
Possibly, although not directly, related leaks:
==11941==
==11941== 244 bytes in 4 blocks are definitely lost in loss record 10 of 11
==11941== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==11941== by 0x826BB67: ber_memalloc_x (memory.c:226)
==11941== by 0x80F5229: slap_sl_malloc (sl_malloc.c:285)
==11941== by 0x826BB82: ber_memalloc_x (memory.c:229)
==11941== by 0x824C16E: ldap_dn2bv_x (getdn.c:3015)
==11941== by 0x80A53E2: dnPrettyNormal (dn.c:745)
==11941== by 0x820D4DC: rwm_exop_passwd (rwm.c:1048)
==11941== by 0x820D7C5: rwm_extended (rwm.c:1116)
==11941== by 0x810E87D: overlay_op_walk (backover.c:659)
==11941== by 0x810EAB2: over_op_func (backover.c:721)
==11941== by 0x810EC71: over_op_extended (backover.c:796)
==11941== by 0x80C8D95: do_extended (extended.c:177)
==11941== by 0x808AD29: connection_operation (connection.c:1109)
==11941== by 0x808B269: connection_read_thread (connection.c:1245)
==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685)
==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so)
==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so)
Will look at this ASAP.
p.
12 years, 11 months
