https://fedorahosted.org/sssd/ticket/1616
There where three main issues.
1. sssd_sudo didn't support subdomains at all
2. sudo sends two request - for default options and for rules We match user with domain in default options request and send the domain name back to sudo. Sudo sends it back to us in the form "user@domain" in rules request.
If the username already contains domain name (subdomain case), sudo sent us "user@domain@domain". I fixed this by changing the protocol. Sudo sends user and domain separately now. The old protocol is also supported, but a debug message is printed that it will not work with subdomains.
3. subdomain users are stored in cn=subdomain,cn=sysdb, but rules are stored in cn=ipadomain,cn=sysdb. I'm using subdomain sysdb context for user lookups and ipadomain sysdb context for rules lookups.
[PATCH 1/6] fix missing parameter in two debug messages
[PATCH 2/6] use tmp_ctx in sudosrv_get_sudorules_from_cache()
[PATCH 3/6] solves 1 and 3
[PATCH 4/6] solves 2
[PATCH 5/6] bumps libsss_sudo version
[PATCH 6/6] adds useful debugging info
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
On 11/12/2012 02:33 PM, Pavel Březina wrote:
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
I'm attaching a new set of patches base on IRC discussion with Simo and Jakub.
Domain name is no longer sent to sudo. This was done without changing the protocol.
On Tue, Nov 13, 2012 at 03:53:43PM +0100, Pavel Březina wrote:
On 11/12/2012 02:33 PM, Pavel Březina wrote:
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
I'm attaching a new set of patches base on IRC discussion with Simo and Jakub.
Domain name is no longer sent to sudo. This was done without changing the protocol.
I just checked the handling of subdomain users in patch 0003 and it looks good to me. Rules for subdomain users are always searched in the parent domain.
bye, Sumit
On Wed, Nov 14, 2012 at 11:02:14AM +0100, Sumit Bose wrote:
On Tue, Nov 13, 2012 at 03:53:43PM +0100, Pavel Březina wrote:
On 11/12/2012 02:33 PM, Pavel Březina wrote:
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
I'm attaching a new set of patches base on IRC discussion with Simo and Jakub.
Domain name is no longer sent to sudo. This was done without changing the protocol.
I just checked the handling of subdomain users in patch 0003 and it looks good to me. Rules for subdomain users are always searched in the parent domain.
bye, Sumit
I tested the functionality and the patches seem to work fine. Here is a full review:
Patch 1/7: sudo: fix missing parameter in two debug messages Ack
Patch 2/7: use tmp_ctx in sudosrv_get_sudorules_from_cache() Ack
Patch 3/7: sudo: support users from subdomains Ack
Patch 4/7: sudo: do not send domain name with username Ack but please file a ticket to change the protocol
Patch 5/7: libsss_sudo: bump version to 2:1:1 (revision) I think it would be better to get rid of the version completely and just build with -module -avoid-version. The API is defined on the consumer side only anyway.
Patch 6/7: sudo: print message if old protocol is used I don't really agree with this change. Why should we allow higher protocol numbers and only disallow 0?
Patch 7/7: sudo: print how many rules we are refreshing or returning Ack
On Wed, Nov 14, 2012 at 02:37:01PM +0100, Jakub Hrozek wrote:
On Wed, Nov 14, 2012 at 11:02:14AM +0100, Sumit Bose wrote:
On Tue, Nov 13, 2012 at 03:53:43PM +0100, Pavel Březina wrote:
On 11/12/2012 02:33 PM, Pavel Březina wrote:
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com Date: Fri, 9 Nov 2012 13:31:52 +0100 Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages
src/responder/sudo/sudosrv_get_sudorules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/responder/sudo/sudosrv_get_sudorules.c b/src/responder/sudo/sudosrv_get_sudorules.c index b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 100644 --- a/src/responder/sudo/sudosrv_get_sudorules.c +++ b/src/responder/sudo/sudosrv_get_sudorules.c @@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx *cmd_ctx) NULL, &groupnames); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE,
("Unable to retrieve user info [%d]: %s\n",strerror(ret)));
("Unable to retrieve user info [%d]: %s\n", ret,strerror(ret))); goto done; }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
I'm attaching a new set of patches base on IRC discussion with Simo and Jakub.
Domain name is no longer sent to sudo. This was done without changing the protocol.
I just checked the handling of subdomain users in patch 0003 and it looks good to me. Rules for subdomain users are always searched in the parent domain.
bye, Sumit
I tested the functionality and the patches seem to work fine. Here is a full review:
Patch 1/7: sudo: fix missing parameter in two debug messages Ack
Patch 2/7: use tmp_ctx in sudosrv_get_sudorules_from_cache() Ack
Patch 3/7: sudo: support users from subdomains Ack
Patch 4/7: sudo: do not send domain name with username Ack but please file a ticket to change the protocol
Patch 5/7: libsss_sudo: bump version to 2:1:1 (revision) I think it would be better to get rid of the version completely and just build with -module -avoid-version. The API is defined on the consumer side only anyway.
Patch 6/7: sudo: print message if old protocol is used I don't really agree with this change. Why should we allow higher protocol numbers and only disallow 0?
Patch 7/7: sudo: print how many rules we are refreshing or returning Ack
I'm going to push the acked patches and Pavel will resubmit the nacked ones separately.
On Wed, Nov 14, 2012 at 05:10:27PM +0100, Jakub Hrozek wrote:
On Wed, Nov 14, 2012 at 02:37:01PM +0100, Jakub Hrozek wrote:
On Wed, Nov 14, 2012 at 11:02:14AM +0100, Sumit Bose wrote:
On Tue, Nov 13, 2012 at 03:53:43PM +0100, Pavel Březina wrote:
On 11/12/2012 02:33 PM, Pavel Březina wrote:
On 11/09/2012 03:18 PM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote: > From 724ebcafa2d4e54df048ca2a578b03281fb7fe6f Mon Sep 17 00:00:00 2001 >From: =?UTF-8?q?Pavel=20B=C5=99ezina?= pbrezina@redhat.com >Date: Fri, 9 Nov 2012 13:31:52 +0100 >Subject: [PATCH 1/6] sudo: fix missing parameter in two debug messages > >--- > src/responder/sudo/sudosrv_get_sudorules.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/src/responder/sudo/sudosrv_get_sudorules.c >b/src/responder/sudo/sudosrv_get_sudorules.c >index >b6e016c73cba6c86b9f20af63357c6fcc2b5508b..0e0437622e94a234b1597bcd272633f6944d4762 >100644 >--- a/src/responder/sudo/sudosrv_get_sudorules.c >+++ b/src/responder/sudo/sudosrv_get_sudorules.c >@@ -369,7 +369,7 @@ errno_t sudosrv_get_rules(struct sudo_cmd_ctx >*cmd_ctx) > NULL, &groupnames); > if (ret != EOK) { > DEBUG(SSSDBG_CRIT_FAILURE, >- ("Unable to retrieve user info [%d]: %s\n", >strerror(ret))); >+ ("Unable to retrieve user info [%d]: %s\n", ret, >strerror(ret))); > goto done; > }
The comment says 2 debug messages, but the patch only has one, which is wrong ?
Simo.
Hi, thank you. Looks like I forgot to modify the second message. New patches are attached.
I'm attaching a new set of patches base on IRC discussion with Simo and Jakub.
Domain name is no longer sent to sudo. This was done without changing the protocol.
I just checked the handling of subdomain users in patch 0003 and it looks good to me. Rules for subdomain users are always searched in the parent domain.
bye, Sumit
I tested the functionality and the patches seem to work fine. Here is a full review:
Patch 1/7: sudo: fix missing parameter in two debug messages Ack
Patch 2/7: use tmp_ctx in sudosrv_get_sudorules_from_cache() Ack
Patch 3/7: sudo: support users from subdomains Ack
Patch 4/7: sudo: do not send domain name with username Ack but please file a ticket to change the protocol
Patch 5/7: libsss_sudo: bump version to 2:1:1 (revision) I think it would be better to get rid of the version completely and just build with -module -avoid-version. The API is defined on the consumer side only anyway.
Patch 6/7: sudo: print message if old protocol is used I don't really agree with this change. Why should we allow higher protocol numbers and only disallow 0?
Patch 7/7: sudo: print how many rules we are refreshing or returning Ack
I'm going to push the acked patches and Pavel will resubmit the nacked ones separately.
Patches 1-4 and 7 have been pushed to master and sssd-1-9
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
[PATCH 4/6] solves 2
Sorry, but I fail to understand why the sudo client needs to know about sssd domains at all. I am guilty of not having followed the original sudo patches submission process, but without knowing if there is a valid reason it seem to me that sudo should not know about domains at all.
Also by looking at the code I see that you make wrong assumptions about the format of a fully qualified name in sudo. It seem you assume a fully qualified name is always username@domain, but that's just the 'default' setting, the fully qualified name format is an option that admins can change, and the sudo client have no way to know what that is.
I think before I allow to further change this protocol I need to understand why it is transporting the domain name at all.
Simo.
On 11/11/2012 04:29 AM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
[PATCH 4/6] solves 2
Hi,
Sorry, but I fail to understand why the sudo client needs to know about sssd domains at all. I am guilty of not having followed the original sudo patches submission process, but without knowing if there is a valid reason it seem to me that sudo should not know about domains at all.
Sudo is sending two subsequent requests to sssd: - for a specific rule named cn=defaults, which contains global options - for rules that match specific user
We need to ensure that both requests are served from the same cache.
Originally, we served cn=defaults request from the first cache containing some sudo rules and then user-rules request from cache that contains this user. This was obviously a security bug in multidomain environment so we prohibited to use this protocol (version 0) at all.
Now (since version 1) we match user to domain during cn=defaults request and send it back to sudo so we can match the user to the same domain during the second request.
https://fedorahosted.org/sssd/ticket/1239
Also by looking at the code I see that you make wrong assumptions about the format of a fully qualified name in sudo. It seem you assume a fully qualified name is always username@domain, but that's just the 'default' setting, the fully qualified name format is an option that admins can change, and the sudo client have no way to know what that is.
Yes, I realized that with this ticket and it is no longer an issue with this patch. The domain name is now sent as a separate field.
I think before I allow to further change this protocol I need to understand why it is transporting the domain name at all.
Simo.
On 11/12/2012 08:47 AM, Pavel Březina wrote:
On 11/11/2012 04:29 AM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
[PATCH 4/6] solves 2
Hi,
Sorry, but I fail to understand why the sudo client needs to know about sssd domains at all. I am guilty of not having followed the original sudo patches submission process, but without knowing if there is a valid reason it seem to me that sudo should not know about domains at all.
Sudo is sending two subsequent requests to sssd:
- for a specific rule named cn=defaults, which contains global options
- for rules that match specific user
We need to ensure that both requests are served from the same cache.
Originally, we served cn=defaults request from the first cache containing some sudo rules and then user-rules request from cache that contains this user. This was obviously a security bug in multidomain environment so we prohibited to use this protocol (version 0) at all.
Now (since version 1) we match user to domain during cn=defaults request and send it back to sudo so we can match the user to the same domain during the second request.
https://fedorahosted.org/sssd/ticket/1239
Also by looking at the code I see that you make wrong assumptions about the format of a fully qualified name in sudo. It seem you assume a fully qualified name is always username@domain, but that's just the 'default' setting, the fully qualified name format is an option that admins can change, and the sudo client have no way to know what that is.
Yes, I realized that with this ticket and it is no longer an issue with this patch. The domain name is now sent as a separate field.
I think before I allow to further change this protocol I need to understand why it is transporting the domain name at all.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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. In this case we effectively have a machine that joins two different domains, this should be doable.
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.
On 11/12/2012 03:05 PM, Dmitri Pal wrote:
On 11/12/2012 08:47 AM, Pavel Březina wrote:
On 11/11/2012 04:29 AM, Simo Sorce wrote:
On Fri, 2012-11-09 at 14:28 +0100, Pavel Březina wrote:
[PATCH 4/6] solves 2
Hi,
Sorry, but I fail to understand why the sudo client needs to know about sssd domains at all. I am guilty of not having followed the original sudo patches submission process, but without knowing if there is a valid reason it seem to me that sudo should not know about domains at all.
Sudo is sending two subsequent requests to sssd:
- for a specific rule named cn=defaults, which contains global options
- for rules that match specific user
We need to ensure that both requests are served from the same cache.
Originally, we served cn=defaults request from the first cache containing some sudo rules and then user-rules request from cache that contains this user. This was obviously a security bug in multidomain environment so we prohibited to use this protocol (version 0) at all.
Now (since version 1) we match user to domain during cn=defaults request and send it back to sudo so we can match the user to the same domain during the second request.
https://fedorahosted.org/sssd/ticket/1239
Also by looking at the code I see that you make wrong assumptions about the format of a fully qualified name in sudo. It seem you assume a fully qualified name is always username@domain, but that's just the 'default' setting, the fully qualified name format is an option that admins can change, and the sudo client have no way to know what that is.
Yes, I realized that with this ticket and it is no longer an issue with this patch. The domain name is now sent as a separate field.
I think before I allow to further change this protocol I need to understand why it is transporting the domain name at all.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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. In this case we effectively have a machine that joins two different domains, this should be doable.
Yes, this behaviour is expected and supported.
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.
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.
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.
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?
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.
I guess we just want to have this mentioned in security considerations somewhere and move on :)
Simo.
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.
On Tue, 2012-11-13 at 18:43 -0500, Dmitri Pal wrote:
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 wish it was common sense, but experience tells me these kind of security considerations need to be spelled out because a lot of people do not think about them.
Luckily we still have naive people out there that do not have their brain wired to think about how someone may exploit whatever you have rigged up, paranoia is the next step :-)
Simo.
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Pavel Březina -
Simo Sorce -
Sumit Bose