On 02/15/2013 04:03 PM, Simo Sorce wrote:
On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote:
On 02/15/2013 04:54 PM, Orion Poplawski wrote:
On 02/15/2013 02:34 PM, John Dennis wrote:
On 02/15/2013 04:16 PM, Orion Poplawski wrote:

Hmm, that is the filter in TB for me too, but:

     [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH
base="ou=people,dc=nwra,dc=com" scope=2
attrs="description notes title sn sn mozillaHomeLocalityName givenName
mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company
mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp
nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn
postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st
region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail
facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3
mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street
street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager
pagerphone ou department departmentNumber orgunit birthmonth
mozillaWorkStreet2 mozillaHomePostalCode objectClass"

is what I see in the LDAP server log

I don't know, beats me as to why there is no objectclass filter component.
Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and
ignores it when it builds the final filter.

What happens if you set the TB filter to (objectclass=person)?

Yup, then it adds it:


O.K. I presume it's obvious the consequence of this little experiment is
that if we do an an RFE that results in removing the person objectclass
from non-human users you'll have to configure a custom LDAP search
filter in every client in your enterprise if you don't want them to see
non-human users in their search results.

Not really, without the person objectclass none of the attributes
thunderbird searches by default would be part of the user object, so the
user would *not* show up.

So the RFE would perfectly solve also the requirement these 'non-person'
users do not show up in thunderbird.


posixAccount must have "cn".

Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       or...@nwra.com
Boulder, CO 80301                   http://www.nwra.com

Freeipa-users mailing list

Reply via email to