Re: [Freeipa-users] Limiting group/user visibility
On 2011-12-08 17:36, Rob Crittenden wrote: > Lassi Pölönen wrote: >> On 7.12.2011 21:28, Dmitri Pal wrote: So I came in to conclusion I just create a role for each customer, e.g "Customer1" and assign that role to all customer's user groups and hosts (too bad it isn't possible to assign a role to a hostgroup) . This requires an aci to be created for each customer though: Actually it seems to be possible to assign roles to host groups as well. Just not from Identity -> Host groups. IPA Server -> RBAC -> Roles has the option though. > Unless you need per-object acis you can probably simplify the filter > to cover the entire DIT by dropping the target and using just the > targetfilter. > > I'd recommend verifying that data doesn't leak via schema compat if > you have that enabled. > > rob Looks like dropping the target prevents a user from logging in, so apparently there's some entries that need to be accessible other than those labeled with memberOf . One additional thing came in to my mind: user private groups probably need to be accessible as well. At least by default there doesn't seem to be a way to assign the same role for those as well. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
Lassi Pölönen wrote: On 7.12.2011 21:28, Dmitri Pal wrote: I think I found at least one solution, that probably isn't the most elegant one. On the other hand I don't think with the current limitations of FreeIPA it is even possible to do much better. Any comments/suggestions are of course welcome. My first approach was to remove the default aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";;) and add needed permissions to specified user groups. But it appeared that there are other things that rely on this aci and as a result e.g "ipa user-find foo" stopped working as well (executed from the FreeIPA server with admin session). I figured it might be a bit too painful to try to find out all the needed aci rules if the default one is removed. So I came in to conclusion I just create a role for each customer, e.g "Customer1" and assign that role to all customer's user groups and hosts (too bad it isn't possible to assign a role to a hostgroup) . This requires an aci to be created for each customer though: aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=test";)(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr = "*")(version 3.0;acl "permission:View only Customer1";deny(all) groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";;) Well, actually not just one aci, but probably one for groups and so on, but with the same idea. The actual amount of required ACIs is still unclear since I just started testing this out, but even though there were 10 ACIs per customer I find it easier to manage than the amount of FreeIPA installations it would take to run an own domain for each. With this setup, customer's users and hosts shouldn't see data outside of their role. 389-ds's aci macros seem to have a limitation that if ($dn) is used in targetfilter, there has to be ($dn) in target as well. But since the user tree is flat, it doesn't seem to be possible to take the advantage of macro ACIs even though there's a obvious pattern in the way I'd like things to work. It is easily scripted though. I think the elegant solution would require FreeIPA to support multiple domains or configurable directory structure. I've seen some discussion about the latter and I do understand why many people are not fans of it. Seems like the right direction to me. Would you mind creating a wiki page that would outline the solution when it is ready. It seems that other people would benefit from your experience. Also it would be great to understand how we can make the process of configuring ACIs simpler for someone. There is definitely a room for improvement so if you can file a trac ticket or BZ (or several) with your enhancement recommendations would be great. Sure thing, once I figure out all the bits and pieces. My use case doesn't cover e.g mounts but will try to look into all the aspects. Currently the possible caveats are still unknown as well. Unless you need per-object acis you can probably simplify the filter to cover the entire DIT by dropping the target and using just the targetfilter. I'd recommend verifying that data doesn't leak via schema compat if you have that enabled. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On 7.12.2011 21:28, Dmitri Pal wrote: I think I found at least one solution, that probably isn't the most elegant one. On the other hand I don't think with the current limitations of FreeIPA it is even possible to do much better. Any comments/suggestions are of course welcome. My first approach was to remove the default aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";;) and add needed permissions to specified user groups. But it appeared that there are other things that rely on this aci and as a result e.g "ipa user-find foo" stopped working as well (executed from the FreeIPA server with admin session). I figured it might be a bit too painful to try to find out all the needed aci rules if the default one is removed. So I came in to conclusion I just create a role for each customer, e.g "Customer1" and assign that role to all customer's user groups and hosts (too bad it isn't possible to assign a role to a hostgroup) . This requires an aci to be created for each customer though: aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=test";)(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr = "*")(version 3.0;acl "permission:View only Customer1";deny(all) groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";;) Well, actually not just one aci, but probably one for groups and so on, but with the same idea. The actual amount of required ACIs is still unclear since I just started testing this out, but even though there were 10 ACIs per customer I find it easier to manage than the amount of FreeIPA installations it would take to run an own domain for each. With this setup, customer's users and hosts shouldn't see data outside of their role. 389-ds's aci macros seem to have a limitation that if ($dn) is used in targetfilter, there has to be ($dn) in target as well. But since the user tree is flat, it doesn't seem to be possible to take the advantage of macro ACIs even though there's a obvious pattern in the way I'd like things to work. It is easily scripted though. I think the elegant solution would require FreeIPA to support multiple domains or configurable directory structure. I've seen some discussion about the latter and I do understand why many people are not fans of it. Seems like the right direction to me. Would you mind creating a wiki page that would outline the solution when it is ready. It seems that other people would benefit from your experience. Also it would be great to understand how we can make the process of configuring ACIs simpler for someone. There is definitely a room for improvement so if you can file a trac ticket or BZ (or several) with your enhancement recommendations would be great. Sure thing, once I figure out all the bits and pieces. My use case doesn't cover e.g mounts but will try to look into all the aspects. Currently the possible caveats are still unknown as well. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
> I think I found at least one solution, that probably isn't the most > elegant one. On the other hand I don't think with the current > limitations of FreeIPA it is even possible to do much better. Any > comments/suggestions are of course welcome. > > My first approach was to remove the default aci: > (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || > sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version > 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn > = "ldap:///anyone";;) > > and add needed permissions to specified user groups. But it appeared > that there are other things that rely on this aci and as a result e.g > "ipa user-find foo" stopped working as well (executed from the FreeIPA > server with admin session). I figured it might be a bit too painful to > try to find out all the needed aci rules if the default one is removed. > > So I came in to conclusion I just create a role for each customer, e.g > "Customer1" and assign that role to all customer's user groups and hosts > (too bad it isn't possible to assign a role to a hostgroup) . This > requires an aci to be created for each customer though: > > aci: (target = > "ldap:///uid=*,cn=users,cn=accounts,dc=test";)(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr > = "*")(version 3.0;acl "permission:View only Customer1";deny(all) > groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";;) > > Well, actually not just one aci, but probably one for groups and so on, > but with the same idea. The actual amount of required ACIs is still > unclear since I just started testing this out, but even though there > were 10 ACIs per customer I find it easier to manage than the amount of > FreeIPA installations it would take to run an own domain for each. > > With this setup, customer's users and hosts shouldn't see data outside > of their role. 389-ds's aci macros seem to have a limitation that if > ($dn) is used in targetfilter, there has to be ($dn) in target as well. > But since the user tree is flat, it doesn't seem to be possible to take > the advantage of macro ACIs even though there's a obvious pattern in the > way I'd like things to work. It is easily scripted though. > > I think the elegant solution would require FreeIPA to support multiple > domains or configurable directory structure. I've seen some discussion > about the latter and I do understand why many people are not fans of it. > > Seems like the right direction to me. Would you mind creating a wiki page that would outline the solution when it is ready. It seems that other people would benefit from your experience. Also it would be great to understand how we can make the process of configuring ACIs simpler for someone. There is definitely a room for improvement so if you can file a trac ticket or BZ (or several) with your enhancement recommendations would be great. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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] Limiting group/user visibility
On 2011-12-01 19:01, Lassi Pölönen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > > I think I found at least one solution, that probably isn't the most elegant one. On the other hand I don't think with the current limitations of FreeIPA it is even possible to do much better. Any comments/suggestions are of course welcome. My first approach was to remove the default aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";;) and add needed permissions to specified user groups. But it appeared that there are other things that rely on this aci and as a result e.g "ipa user-find foo" stopped working as well (executed from the FreeIPA server with admin session). I figured it might be a bit too painful to try to find out all the needed aci rules if the default one is removed. So I came in to conclusion I just create a role for each customer, e.g "Customer1" and assign that role to all customer's user groups and hosts (too bad it isn't possible to assign a role to a hostgroup) . This requires an aci to be created for each customer though: aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=test";)(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr = "*")(version 3.0;acl "permission:View only Customer1";deny(all) groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";;) Well, actually not just one aci, but probably one for groups and so on, but with the same idea. The actual amount of required ACIs is still unclear since I just started testing this out, but even though there were 10 ACIs per customer I find it easier to manage than the amount of FreeIPA installations it would take to run an own domain for each. With this setup, customer's users and hosts shouldn't see data outside of their role. 389-ds's aci macros seem to have a limitation that if ($dn) is used in targetfilter, there has to be ($dn) in target as well. But since the user tree is flat, it doesn't seem to be possible to take the advantage of macro ACIs even though there's a obvious pattern in the way I'd like things to work. It is easily scripted though. I think the elegant solution would require FreeIPA to support multiple domains or configurable directory structure. I've seen some discussion about the latter and I do understand why many people are not fans of it. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On 2.12.2011 17:41, Simo Sorce wrote: On Fri, 2011-12-02 at 08:01 -0600, david t. klein wrote: I think, rather than replicating your admin accounts, have a separate admin realm, and then have all customer realms trust your admin realm, and use those credentials. In future this will be an easier way. But right now trust relationships won't allow you to use a single admin account to actually manage multiple freeipa realms. Simo. From my point of view the fact that a single instance is only able to run a single realm is even a bigger issue. But I think we can accomplish what we need with pretty simple ACIs since the need for limiting the visibility isn't too complex and follows the same pattern with every customer. -Lassi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On Fri, 2011-12-02 at 08:01 -0600, david t. klein wrote: > I think, rather than replicating your admin accounts, have a separate admin > realm, and then have all customer realms trust your admin realm, and use > those credentials. In future this will be an easier way. But right now trust relationships won't allow you to use a single admin account to actually manage multiple freeipa realms. 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] Limiting group/user visibility
I think, rather than replicating your admin accounts, have a separate admin realm, and then have all customer realms trust your admin realm, and use those credentials. -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Lassi Pölönen Sent: Friday, December 02, 2011 12:49 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Limiting group/user visibility On 2011-12-01 19:01, Lassi Pölönen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: >>>> Hi, >>>> >>>> I'm looking for implementing FreeIPA in an environment where there are >>>> multiple customers in multiple organizations and a single organization >>>> that manages the users, sets the access rights etc. >>>> >>>> We don't have a centralized system currently so I will be starting >>>> from >>>> the scratch in that sense. The first concern I've had so far is >>>> that we >>>> don't want different customers to be able to find information about >>>> each >>>> other. Currently in my test setup any user can find out every user >>>> in a >>>> group if they know the group name and all the groups for each user if >>>> they know the username. In some cases this might reveal information >>>> the >>>> customer is not willing to share. >>>> >>>> So are there ways to limit that e.g certain hosts/hostgroups or >>>> users/usergroups see some defined subset of the directory? Or are >>>> there >>>> some other suggested approaches? As the current setup relies on local >>>> authentication, users naturally are able to find users/groups only on >>>> servers they are able to log in and that is the level of >>>> confidentiality >>>> we are looking for if possible >>>> >>>> >>>> -Lassi Pölönen >>>> >>>> >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > Replying to myself.. Actually I would think my goal would be pretty typical setup for managed hosting companies like us as we are the ones who manage all the accounts and servers for our customer organizations. We grant customer access to servers we host and we should have our own accounts on every server as well. Running multiple domains in this case means we would need to replicate our admin accounts to every domain (not sure if there's even a feasible solution to do that) and also manage customer accounts on multiple FreeIPA installations. Running a single domain would make it easier to provide a single account for customers for services that are common to every customer, e.g ticketing system, wikis and so on. It's just that they shouldn't be able to know about each other. Anyway, looking at macro ACIs, it at least looks like it's possible to accomplish with a few pretty simple rules. ___ 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] Limiting group/user visibility
On 2011-12-01 19:01, Lassi Pölönen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > Replying to myself.. Actually I would think my goal would be pretty typical setup for managed hosting companies like us as we are the ones who manage all the accounts and servers for our customer organizations. We grant customer access to servers we host and we should have our own accounts on every server as well. Running multiple domains in this case means we would need to replicate our admin accounts to every domain (not sure if there's even a feasible solution to do that) and also manage customer accounts on multiple FreeIPA installations. Running a single domain would make it easier to provide a single account for customers for services that are common to every customer, e.g ticketing system, wikis and so on. It's just that they shouldn't be able to know about each other. Anyway, looking at macro ACIs, it at least looks like it's possible to accomplish with a few pretty simple rules. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On 1.12.2011 15:12, Stephen Gallagher wrote: On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. Please note that the *search_filter options aren't fully functional yet. We're improving them substantially for the 1.7.0 release of SSSD. But Jakub is right: if you manipulate the ACIs of your user entries, then you can restrict which client machines can see those entries. Ok, thanks for the replies. ACIs sound like pretty much the only feasible solution and still less things to maintain than completely dedicated setups. Will look in to 389's documentation for more. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: > On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: > > Hi, > > > > I'm looking for implementing FreeIPA in an environment where there are > > multiple customers in multiple organizations and a single organization > > that manages the users, sets the access rights etc. > > > > We don't have a centralized system currently so I will be starting from > > the scratch in that sense. The first concern I've had so far is that we > > don't want different customers to be able to find information about each > > other. Currently in my test setup any user can find out every user in a > > group if they know the group name and all the groups for each user if > > they know the username. In some cases this might reveal information the > > customer is not willing to share. > > > > So are there ways to limit that e.g certain hosts/hostgroups or > > users/usergroups see some defined subset of the directory? Or are there > > some other suggested approaches? As the current setup relies on local > > authentication, users naturally are able to find users/groups only on > > servers they are able to log in and that is the level of confidentiality > > we are looking for if possible > > > > > > -Lassi Pölönen > > > > > > If you insist on a single instance for multiple organizations, then I > agree with Stephen Ingram that the correct way would be to setup ACIs. > > You could also abuse the ldap_user_search_filter and ldap_group_search_filter > parameters to limit NSS lookups performed by SSSD. However, nothing > would prevent clients from looking at the directory structure with > ldapsearch or using the IPA UI. Please note that the *search_filter options aren't fully functional yet. We're improving them substantially for the 1.7.0 release of SSSD. But Jakub is right: if you manipulate the ACIs of your user entries, then you can restrict which client machines can see those entries. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: > Hi, > > I'm looking for implementing FreeIPA in an environment where there are > multiple customers in multiple organizations and a single organization > that manages the users, sets the access rights etc. > > We don't have a centralized system currently so I will be starting from > the scratch in that sense. The first concern I've had so far is that we > don't want different customers to be able to find information about each > other. Currently in my test setup any user can find out every user in a > group if they know the group name and all the groups for each user if > they know the username. In some cases this might reveal information the > customer is not willing to share. > > So are there ways to limit that e.g certain hosts/hostgroups or > users/usergroups see some defined subset of the directory? Or are there > some other suggested approaches? As the current setup relies on local > authentication, users naturally are able to find users/groups only on > servers they are able to log in and that is the level of confidentiality > we are looking for if possible > > > -Lassi Pölönen > > If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
Hi, that could be one option as well, not completely ruled out. But in some cases it is a bit too much overhead though. If there are multiple small organizations with only a handful of account and servers, setting up a dedicated HA instance for each one doesn't feel very cost effective as it would mean tens of those. Currently a single installation can't handle multiple realms, am I right? -Lassi Pölönen On 30.11.2011 21:01, Steven Jones wrote: Hi, I would have thought this was a case/design of separate realm's. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Lassi Pölönen [lassi.polo...@iki.fi] Sent: Thursday, 1 December 2011 12:18 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Limiting group/user visibility Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen ___ 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
Re: [Freeipa-users] Limiting group/user visibility
Lassi On Wed, Nov 30, 2011 at 3:18 AM, Lassi Pölönen wrote: > I'm looking for implementing FreeIPA in an environment where there are > multiple customers in multiple organizations and a single organization > that manages the users, sets the access rights etc. > > We don't have a centralized system currently so I will be starting from > the scratch in that sense. The first concern I've had so far is that we > don't want different customers to be able to find information about each > other. Currently in my test setup any user can find out every user in a > group if they know the group name and all the groups for each user if > they know the username. In some cases this might reveal information the > customer is not willing to share. > > So are there ways to limit that e.g certain hosts/hostgroups or > users/usergroups see some defined subset of the directory? Or are there > some other suggested approaches? As the current setup relies on local > authentication, users naturally are able to find users/groups only on > servers they are able to log in and that is the level of confidentiality > we are looking for if possible I asked a similar question earlier (https://www.redhat.com/archives/freeipa-users/2011-September/msg00197.html). As Adam says, since the directory allows visibility of all users, it is a logical step to allow a similar view in the UI. I suspect that you would have to adjust the ACIs in your directory such that users could only see users in their own group. However, this might cause issues with other processes which expect to see users without any restrictions. I haven't had the chance to prove or disprove this yet. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
Hi, I would have thought this was a case/design of separate realm's. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Lassi Pölönen [lassi.polo...@iki.fi] Sent: Thursday, 1 December 2011 12:18 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Limiting group/user visibility Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen ___ 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
