On 02/15/2013 04:16 PM, Orion Poplawski wrote:
On 02/15/2013 02:02 PM, John Dennis wrote:
On 02/15/2013 03:57 PM, Orion Poplawski wrote:
On 02/15/2013 01:56 PM, John Dennis wrote:
On 02/15/2013 03:46 PM, Simo Sorce wrote:
This is an interesting use case, it would probably be appropriate to
have a RFE filed to allow to create ipa users marked as 'non-person' so
that they are not assigned the person objectclass.

Yes, that addresses one large component of the problem. But the part of the
requirement is not to have non-humans show up in every client (e.g. mail
clients) that support LDAP directory lookups. That means they have to modify
the filter on every client. That's a tall order :-(


Actually, this would cover it.  The LDAP address book searches look for
attributes that the *person objectclasses provide.  Without them, they are
excluded.

Interesting, before I replied I checked the filter in my Thunderbird client
and it's set to (objectclass=*). I don't know if I modified it as some point
or if it's the default, I assumed it's the default. I suspect it's the default
filter for many clients.



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)?

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

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to