On 11/12/2012 10:10 AM, Simo Sorce wrote: > On Mon, 2012-11-12 at 09:05 -0500, Dmitri Pal wrote: > > I changed the subject because this is a separate discussion and not a > review of the patches. > >> It is generally a good idea to be able to get SUDO rules from two >> different domains. >> Think about a setup when SSSD is configured with two domains say AD and >> IPA. >> Both can serve SUDO via LDAP (or via GPO when we add them for AD). Users >> from AD should use rules defined in AD while users in IPA should use >> rules from IPA. > Not if AD users come via a trust.
Correct. > If you are thinking of multihomed systems that 'join' 2 domains, well, > that is a messy situation, it is debatable what is the right thing to > do. It is stop gap solution that also should work. > >> In this case we effectively have a machine that joins two different >> domains, this should be doable. > Debatable though, what domain 'owns' the security properties of the > machine ? 2 domains might have completely different and even conflicting > rules. True but in this case it is really independent in terms of sudo. Two different domains have two different sets of users so they can have two different sets of sudo policies. This might be messy if the policies contradict but might be very handy when IPA policies follow AD policies and people migrate from AD with Quest to IPA for example. I see it as an interim migration solution but there is nothing more permanent than "temporary". > >> BTW I wonder if one can actually make the system join AD and IPA domain >> at the same time and make one configuration not step on another. >> Is it possible now? I hope so. If not we should file a ticket to make it >> possible. > I am not sure, but I think it is not a desirable thing to document. It > carries way too many breaches of trust for both domains. Opposite. I think it should be documented but the implications need to be clearly explained. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
