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
It will be unfair to revert in his absence without a majority.
Can someone else express his opinion on the matter?
>>> 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
>> 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
> 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
> Freeipa-devel mailing list
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list