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
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
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?
Freeipa-users mailing list