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.


>>> ~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

> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel@redhat.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?

Freeipa-devel mailing list

Reply via email to