Re: [Freeipa-users] Non-human users
On Sat, 2013-02-16 at 13:31 +, Charlie Derwent wrote: Bit late to the conversation here, but if you want another example of a quasi-system account within IPA, there is the need for a user to handle automated enrollment/re-enrollment of servers. Charlie For this we should be able to use a service principal, not a full account. Unless for some reason you need this principal to show up as a user in the system (full posixAccount). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/17/2013 02:37 PM, Simo Sorce wrote: On Sat, 2013-02-16 at 13:31 +, Charlie Derwent wrote: Bit late to the conversation here, but if you want another example of a quasi-system account within IPA, there is the need for a user to handle automated enrollment/re-enrollment of servers. Charlie For this we should be able to use a service principal, not a full account. Unless for some reason you need this principal to show up as a user in the system (full posixAccount). Simo. I do not think we have any permission setup in IPA for a service account to perform any modification operations. It can be host account though and we have permission mechanisms built into IdM to allow a host (provisioning system or hypervisor) manage other hosts and services running on them. It should be in the docs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- 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
Re: [Freeipa-users] Non-human users
Bit late to the conversation here, but if you want another example of a quasi-system account within IPA, there is the need for a user to handle automated enrollment/re-enrollment of servers. Charlie On Fri, Feb 15, 2013 at 11:32 PM, Brian Cook bc...@redhat.com wrote: On Feb 15, 2013, at 3:11 PM, Simo Sorce s...@redhat.com wrote: On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: On 02/15/2013 05:12 PM, 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. Can it be managed via Puppet? Unlikely, thunderbird preferences are per user and stored in user preference files, which cannot be arbitrarily overridden. Following URL details a deployment method that configures thunderbird for address book in AD with a custom search string. Maybe you can use it or it will inspire you as to how to accomplish your deployment. http://wpkg.org/Thunderbird#System-wide Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Non-human users
Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 12:32 PM, Orion Poplawski wrote: On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. -- 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
Re: [Freeipa-users] Non-human users
There are lots of use cases where it makes sense to have a share 'application' user: -agentless monitoring -penetration testing -code deployment -clustering The system user is not always the user an application is running as. Sometimes it is just a user that is used to gain access to a remote system. Brian --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Feb 15, 2013, at 9:52 AM, John Dennis jden...@redhat.com wrote: On 02/15/2013 12:32 PM, Orion Poplawski wrote: On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. -- 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
John Dennis wrote: On 02/15/2013 12:32 PM, Orion Poplawski wrote: On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. The mock user is sort of a system account but it would be definitely nice to be able to manage its group membership from IPA, for example. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. -- 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
Re: [Freeipa-users] Non-human users
John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... -- 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
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:38 AM, John Dennis wrote: On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
Orion Poplawski wrote: On 02/15/2013 11:38 AM, John Dennis wrote: On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. In any case, it is probably reasonable to discuss these two cases separately. As John said, for pure system daemons it is probably best to leave those as local accounts. For quasi local accounts like mock or backup accounts things get a little fuzzy. I think I would avoid storing the user in /etc/passwd and the group in IPA, if possible. I imagine that sssd would be able to handle the case ok but I don't know that this is something they actively test. Why do you want/need to distinguish them from real people? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:39 PM, Orion Poplawski wrote: On 02/15/2013 11:38 AM, John Dennis wrote: On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. O.K. but I want to make sure you understand the difference. If you give login or other permissions to a network facing system daemon you're opening a huge security hole. Adding the apache user to the set of users managed by IPA is quite dangerous unless you are extraordinarily careful to remove privileges normally granted by IPA, it could lead to the complete compromise of your network. -- 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
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:50 AM, John Dennis wrote: O.K. but I want to make sure you understand the difference. If you give login or other permissions to a network facing system daemon you're opening a huge security hole. Adding the apache user to the set of users managed by IPA is quite dangerous unless you are extraordinarily careful to remove privileges normally granted by IPA, it could lead to the complete compromise of your network. Understood. This is actually all before we have moved to IPA, but are exploring things. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:49 AM, Rob Crittenden wrote: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. In any case, it is probably reasonable to discuss these two cases separately. As John said, for pure system daemons it is probably best to leave those as local accounts. For quasi local accounts like mock or backup accounts things get a little fuzzy. I think I would avoid storing the user in /etc/passwd and the group in IPA, if possible. I imagine that sssd would be able to handle the case ok but I don't know that this is something they actively test. Why do you want/need to distinguish them from real people? rob What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted real human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no *person attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 02:23 PM, Orion Poplawski wrote: On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. If your goal is not to have system users returned in a ldap search you'll have to filter them (e.g. adding (uid = 1024) to the search filter because system users are usually less than some magic number, it used to be 512, now it's 1024 I believe). Adding that (or some other filter criteria) to every LDAP client in your enterprise is probably not viable. I don't think setting ACL's to prevent specific users from being returned in searches is viable either because they need to visible during the operations they're involved in. The problem as I see it is that IPA by design stores users in a flat namespace. That means you cannot partition users by putting them in different LDAP containers (trees). During the design of IPA the issue of whether we would use a flat namespace or permit different namespaces (via LDAP containers, conventionally called organizational units, i.e. OU's) came up. There was a sentiment that OU's had historically been problematic, hence we have a flat namespace and partitioning would be done via filtering. Thus only thing I can suggest at the moment is filtering, perhaps others have a better idea. Your other alternative is not put these system users in LDAP and instead use local users groups managed via some other mechanism (puppet?). I'm not sure this issue has come up before, it does present some interesting issues. John -- 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
Re: [Freeipa-users] Non-human users
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 :-( -- 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
Re: [Freeipa-users] Non-human users
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. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:42 PM, John Dennis wrote: On 02/15/2013 02:23 PM, Orion Poplawski wrote: On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. Your other alternative is not put these system users in LDAP and instead use local users groups managed via some other mechanism (puppet?). I've been testing with puppet, but that doesn't work. It detects the groups presence in ldap, so doesn't add them to /etc/group, then when it goes to add apache to the various groups, that fails. Possibly could missing functionality in puppet, but not a solution at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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. -- 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
Re: [Freeipa-users] Non-human users
On Feb 15, 2013, at 1:02 PM, John Dennis jden...@redhat.com 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. I think maybe he means that he is putting a custom search string in the address books that filters out objects that don't have attributes that *person object classes provide, but that doesn't work unless you can keep those attributes from being assigned to non-person accounts in freeipa. -Brian -- 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 03:46 PM, Simo Sorce wrote: On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: On 02/15/2013 11:49 AM, Rob Crittenden wrote: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. In any case, it is probably reasonable to discuss these two cases separately. As John said, for pure system daemons it is probably best to leave those as local accounts. For quasi local accounts like mock or backup accounts things get a little fuzzy. I think I would avoid storing the user in /etc/passwd and the group in IPA, if possible. I imagine that sssd would be able to handle the case ok but I don't know that this is something they actively test. Why do you want/need to distinguish them from real people? rob What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted real human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no *person attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. 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. Simo. https://fedorahosted.org/freeipa/ticket/3430 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- 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
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:01 PM, Orion Poplawski wrote: On 02/15/2013 01:42 PM, John Dennis wrote: On 02/15/2013 02:23 PM, Orion Poplawski wrote: On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. Your other alternative is not put these system users in LDAP and instead use local users groups managed via some other mechanism (puppet?). I've been testing with puppet, but that doesn't work. It detects the groups presence in ldap, so doesn't add them to /etc/group, then when it goes to add apache to the various groups, that fails. Possibly could missing functionality in puppet, but not a solution at the moment. sssd.conf has some filter directives that will prevent sssd from looking up the specified users/groups. That should prevent puppet from detecting the LDAP group. -- - *question everything*learn something*answer nothing* Lucas Yamanishi -- Systems Administrator, ADNET Systems, Inc. 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:46 PM, Simo Sorce wrote: On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted real human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no *person attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. 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. Simo. Filed https://fedorahosted.org/freeipa/ticket/3431 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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
Re: [Freeipa-users] Non-human users
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*))) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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. -- 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
Re: [Freeipa-users] Non-human users
On 02/15/2013 05:12 PM, 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. Can it be managed via Puppet? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- 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
Re: [Freeipa-users] Non-human users
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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:06 PM, 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: 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. That said, there are still other (and arguably more important) reasons for this RFE. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
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
Re: [Freeipa-users] Non-human users
On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: On 02/15/2013 05:12 PM, 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. Can it be managed via Puppet? Unlikely, thunderbird preferences are per user and stored in user preference files, which cannot be arbitrarily overridden. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On Feb 15, 2013, at 3:11 PM, Simo Sorce s...@redhat.com wrote: On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: On 02/15/2013 05:12 PM, 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. Can it be managed via Puppet? Unlikely, thunderbird preferences are per user and stored in user preference files, which cannot be arbitrarily overridden. Following URL details a deployment method that configures thunderbird for address book in AD with a custom search string. Maybe you can use it or it will inspire you as to how to accomplish your deployment. http://wpkg.org/Thunderbird#System-wide Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
