> That was the original design, however I was told that this is not > something people will be interested in. Thanks for you data point but to > change it we probably need couple more data points and comments.
I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! >> ~hostMask~ >> >> I feel inclined to agree with Dmitri regarding a deferral on the hostMask >> attribute for resource sake. I tend to see the data center design to stick >> closer to hostname utilization, rather than subnets... I.E. people tend to >> put a mixed bag of servers in the same subnet, but they tend to make sure >> that like servers have similar hostnames or sane hostnames that can have a >> floating IP address in the case of clusering, or high-availability, etc, >> etc. That is just my observation. Feel free to correct me if I am grossly >> out of spec for the rest of the industry. >> > > This will really be a relieve not to support it for now. Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. > >> ~Using memberUser as slight of hand over netgroups~ >> >> It's my understanding that the sudo source does a "getent netgroup" style of >> lookup to search ldap for the netgroup... if that is correct, it may indeed >> be necessary to utilize the compat function to share the hostgroups with >> sudo... >> >> The overall goal, again, being to eliminate duplication of info: >> prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup >> contains the same manually duplicated servers as prod-servers netgroup... >> > > The problem is that it is reverse. > Since for IPA the host groups are primary concepts and the netgroup is > something we want to phase out the logic is the following: > * Hosts are grouped into the host groups. > * A netgroup is a shallow container around the host group. > In our model host group can be a member of the netgroup not vice versa. > But this is not related to the question at hand. > > The question regarding memberUser is that the sudo spec allows using a > netgroup to refer to a set of users. This is really a atavism to use > netgroups to reference a set of users instead of a direct user group. > The question is: can we assume it to be an atavism and not support it. > I updated the page so this point is more clear. Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
