[SSSD] How to deal with multihomed machines [Re: [PATCHES] sudo failing for ad trusted user in IPA environment]

Dmitri Pal dpal at redhat.com
Tue Nov 13 23:43:31 UTC 2012


On 11/13/2012 09:24 AM, Simo Sorce wrote:
> On Tue, 2012-11-13 at 13:13 +0100, Jakub Hrozek wrote:
>> On Mon, Nov 12, 2012 at 10:10:25AM -0500, 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.
>>>
>>> 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.
>>>
>>>> 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.
>>>
>>>> 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.
>>>
>>> Simo.
>> I always thought of the SSSD being able to support multiple domains as a
>> very good thing - consider a devel and production servers in a company
>> or a client that is a member of both a home IPA server and a company
>> AD server..
>>
>> Where do you see conflicts between domains?
> Yes we built it with this capability because we think having the option
> to do that is important.
> However when you actually want to deploy something like that you must be
> aware of consequences.
>
> For example, if one of the domains is compromised and now you have a
> machine that is joined to 2 domains, you have a gateway to compromise
> the other domain too. Or at the very least to get more information than
> an anonymous user would get.
>
> This is not always necessarily a problem. In some situations the 2
> domains may exist for reasons that do not have much to do with level of
> trusts, meaning the 2 domains are within the same trust boundaries,
> however if the 2 domains are separate in order to create trust
> boundaries, then joining a machine to both is technically an issue.

Dah! :-)

Common wisdom 101:

"Do not play with fire!"
"Do not talk to strangers!"
"Fasten seat belts!"
"Do not put a client into two domains that have different trust levels!"
...


>
> I guess we just want to have this mentioned in security considerations
> somewhere and move on :)
>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list