[Freeipa-users] Non-human users

John Dennis jdennis at redhat.com
Fri Feb 15 21:34:31 UTC 2013


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 <jdennis at redhat.com>

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




More information about the Freeipa-users mailing list