JR Aquino wrote: >> 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! > > I completely agree with you but the main opponent of the idea is on vacation now. It will be unfair to revert in his absence without a majority.
Can someone else express his opinion on the matter? >>> ~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. > > Sold! >>> ~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. > > > We will cross this bridge when time comes. We have some thoughts and considerations. > _______________________________________________ > Freeipa-devel mailing list > Freeipaemail@example.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel