RE: (ITS#7673)
by Russell.Mosemann＠cune.edu
Pierangelo Masarati wrote:
> Try rwm-drop-unrequested-attrs no (slapo-rwm(5)).
That had my hopes up. I didn't think any of those settings applied, because nothing about the query or the results is being rewritten or mapped. In effect, rwm should not be doing anything at all. Everything should pass through the overlay.
I set rwm-drop-unrequested-attrs to no, and it made things worse. If I include the filter attributes in the query, nothing is returned, now. If no attributes are specified, all of the allowed attributes are returned, as before.
--
Russell Mosemann, Ph.D.
Professor of Computer Science
10 years, 2 months
Re: (ITS#7673)
by pierangelo.masarati＠polimi.it
On 09/04/2013 10:22 PM, Russell.Mosemann(a)cune.edu wrote:
> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> The lookup succeeds, and the returned entry is run through the searchEntryD=
> N context. It appears that somewhere in or around there all of the attribut=
> es are removed except for the requested attributes. That means the ACL filt=
> er will fail, if the filter attributes are not requested in the query. If t=
> he requested attributes include the filter attributes, the query succeeds, =
> but the result only returns the dn without any other attributes.
>
> If no attributes are requested, all allowed attributes are returned.
>
> The man page indicates that searchEntryDN should not be applied, because it=
> is not defined, and there is no default.
Try rwm-drop-unrequested-attrs no (slapo-rwm(5)).
p.
>
>
> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
> //www.w3.org/TR/REC-html40">
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>>
> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
> <style><!--
> /* Font Definitions */
> @font-face
> {font-family:"Cambria Math";
> panose-1:2 4 5 3 5 4 6 3 2 4;}
> @font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:11.0pt;
> font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {mso-style-priority:99;
> color:purple;
> text-decoration:underline;}
> span.EmailStyle17
> {mso-style-type:personal-compose;
> font-family:"Times New Roman","serif";
> color:windowtext;}
> .MsoChpDefault
> {mso-style-type:export-only;
> font-family:"Calibri","sans-serif";}
> @page WordSection1
> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> {page:WordSection1;}
> --></style><!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
> <div class=3D"WordSection1">
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif"">The lookup succeeds, and the returne=
> d entry is run through the searchEntryDN context. It appears that somewhere=
> in or around there all of the attributes are removed except
> for the requested attributes. That means the ACL filter will fail, if the =
> filter attributes are not requested in the query. If the requested attribut=
> es include the filter attributes, the query succeeds, but the result only r=
> eturns the dn without any other
> attributes.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif""><o:p> </o:p></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif"">If no attributes are requested, all =
> allowed attributes are returned.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif""><o:p> </o:p></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif"">The man page indicates that searchEn=
> tryDN should not be applied, because it is not defined, and there is no def=
> ault.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
> mes New Roman","serif""><o:p> </o:p></span></p>
> </div>
> </body>
> </html>
>
> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--
>
>
>
>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years, 2 months
(ITS#7673)
by Russell.Mosemann＠cune.edu
--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The lookup succeeds, and the returned entry is run through the searchEntryD=
N context. It appears that somewhere in or around there all of the attribut=
es are removed except for the requested attributes. That means the ACL filt=
er will fail, if the filter attributes are not requested in the query. If t=
he requested attributes include the filter attributes, the query succeeds, =
but the result only returns the dn without any other attributes.
If no attributes are requested, all allowed attributes are returned.
The man page indicates that searchEntryDN should not be applied, because it=
is not defined, and there is no default.
--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Times New Roman","serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif"">The lookup succeeds, and the returne=
d entry is run through the searchEntryDN context. It appears that somewhere=
in or around there all of the attributes are removed except
for the requested attributes. That means the ACL filter will fail, if the =
filter attributes are not requested in the query. If the requested attribut=
es include the filter attributes, the query succeeds, but the result only r=
eturns the dn without any other
attributes.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif"">If no attributes are requested, all =
allowed attributes are returned.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif""><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif"">The man page indicates that searchEn=
tryDN should not be applied, because it is not defined, and there is no def=
ault.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti=
mes New Roman","serif""><o:p> </o:p></span></p>
</div>
</body>
</html>
--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--
10 years, 2 months
Re: (ITS#7679) Problem with overlay dynlist
by pierangelo.masarati＠polimi.it
On 09/02/2013 04:52 PM, a.rossini(a)cineca.it wrote:
> Full_Name: Angelo Rossini
> Version: slapd 2.4.23 (Dec 16 2012 11:48:44)
> OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (130.186.20.62)
>
>
> I've tried to use the overlay dynlist to manage dynamic group; i've added these
> rows to slapd.conf:
>
> # required schema for dynamic groups
> include /etc/ldap/schema/dyngroup.schema
>
> # permanent load of the dynlist overlay
>
> moduleload dynlist
>
> overlay dynlist
> dynlist-attrset groupOfURLs memberURL seeAlso
>
> And created a group using this LDIF:
>
> dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it
>
> objectClass: groupOfURLs
>
> cn: GROUP_DYN
>
> memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE)
>
> When i try ldap searches like ldapsearch --baseDN
> cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like
> ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it
> 'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to
> retrieve the list of distinguished names of the results but only a list of some
> other attributes of the result.
>
> The configuration is exactly the one described in the
> http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page.
>
> What is wrong?
So far, there is no evidence of a software bug. Does your build pass
test044 ? If so, then it must be something in the way you're using the
overlay.
You should direct the discussion to the openldap-technical mailing list,
and provide a simple, self-contained test case that reproduces the problem.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years, 2 months
Re: Re : Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com
"POISSON Frédéric" wrote:
> Hello all,
>
> Thanks first for the patch, i have applied it on my own build of 2.4.36 but i
> have now a strange behavior, the slapd do not crash but it refused operations.
>
> First here is the diff after applying the patch :
> $ diff ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c
> ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c.orig
> 3795d3794
> < slap_tls_ctx = NULL;
> 3804,3808d3802
> < } else {
> < if ( rc == LDAP_NOT_SUPPORTED )
> < rc = LDAP_UNWILLING_TO_PERFORM;
> < else
> < rc = LDAP_OTHER;
>
> Now when i only add or replace only attribute olcTLSRandFile on cn=config i have :
>
> ldap_modify: Server is unwilling to perform (53)
>
>
> When i replace following values in this order with 4 actions/operations or
> with a single action/operation it works :
>
> dn: cn=config
> changetype: modify
> replace: olcTLSCACertificateFile
> olcTLSCACertificateFile: /usr/products/openldap/etc/openldap-single/tls/cacert.pem
> -
> replace: olcTLSCertificateFile
> olcTLSCertificateFile: /usr/products/openldap/etc/openldap-single/tls/cert.pem
> -
> replace: olcTLSCertificateKeyFile
> olcTLSCertificateKeyFile: /usr/products/openldap/etc/openldap-single/tls/key.pem
> -
> replace: olcTLSRandFile
> olcTLSRandFile: /dev/random
>
> But it don't works with only olcTLSRandfile if i do an add or replace first, why ?
>
> What do you need for investigation ?
There's nothing to investigate, this works as designed. The config engine
requires your TLS configuration to be valid when you configure it. That means
at a minimum you must configure a server cert and key. If you only configure
the randfile and nothing else, the config is rejected.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
Re: (ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk
On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote:
> matth(a)netsight.co.uk wrote:
>> Full_Name: Matt Hamilton
>> Version: 2.4.36
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (213.133.64.253)
>>
>>
>> I am using the meta backend to query multiple LDAP (AD) backends. This is to
>> consolidate several directories in different departments into one. We attempt
>> both simple binds with username/password and also anon binds to look up user
>> information.
>
> That doesn't make much sense, since AD disallows anonymous Binds.
Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client.
>> At the moment, trying to do an authenticated simple bind to slapd caused an
>> Operational Error to be propagated to the client regardless of the setting of
>> 'onerr'. Even when a result is successfully found. This is due to one server in
>> the backend succeeding and the other returning an operational error due to an
>> invalid bind (as would be expected as the credentials supplied from the client
>> will only work with one of the backends).
>>
>> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that
>> the code is not checking for 'Operational Error' as a specific case above and so
>> uses the default case (line 1665). Hence sres is set to 'Operational Error' too
>> at line 1934.
>
> back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there.
I'm not talking about binds there. I'm talking about errors being propagated.
-Matt
>>
>> The server should be changing this to LDAP_SUCCESS somewhere in that logic
>> unless META_BACK_ONERR_REPORT.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
