On Fri, 2013-02-15 at 16:06 -0700, Orion Poplawski wrote: > 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 > >>>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > >>>>> 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: > >>> > >>> > >>> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > >>> > >> > >> 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. > > > > Simo. > > > > posixAccount must have "cn".
Argh, you are right :-/ I forgot about that silly requirement (given it already requires 'uid') Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users