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.

John Dennis <jden...@redhat.com>

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to