[SSSD] [sssd PR#342][comment] SELINUX: Use getseuserbyname to get IPA seuser

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

fidencio commented:
"""
Is there an equivalent API for del_seuser as there is for get_seuser? I didn't 
find anything like that when looking at 
https://github.com/SELinuxProject/selinux/blob/master/libselinux/include/selinux/selinux.h
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/342#issuecomment-324160541
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#342][comment] SELINUX: Use getseuserbyname to get IPA seuser

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

lslebodn commented:
"""
If we decided to remove `get_seuser` then is there any reason why `del_seuser` 
cannot be replaced as well?
I would prefer all or nothing.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/342#issuecomment-324142036
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#342][+Changes requested] SELINUX: Use getseuserbyname to get IPA seuser

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#342][-Accepted] SELINUX: Use getseuserbyname to get IPA seuser

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

Label: -Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

lslebodn commented:
"""
master:
* aede6a1f4412f133e4b3fd76944f764d76fc4868
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324099400
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][+Pushed] libwbclient: Fix warning statement with no effect

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][closed] libwbclient: Fix warning statement with no effect

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/354
Author: lslebodn
 Title: #354: libwbclient: Fix warning statement with no effect
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/354/head:pr354
git checkout pr354
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

fidencio commented:
"""
That's exactly the case that could be avoided by having something like 
https://github.com/SSSD/sssd/pull/50.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324060339
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#347][comment] Fixes related to negative cache and "root" user/group

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/347
Title: #347: Fixes related to negative cache and "root" user/group

fidencio commented:
"""
retest this, please
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/347#issuecomment-324096441
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][+Accepted] libwbclient: Fix warning statement with no effect

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

sumit-bose commented:
"""
ACK
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324065118
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

fidencio commented:
"""
That's exactly the case that could be avoided by having something like 
https://github.com/SSSD/sssd/pull/50.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324060339
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

lslebodn commented:
"""
I was testing such patch on el7 and I did not notice it either.
I wonder how could it fix https://pagure.io/SSSD/sssd/issue/3461 :-)
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324057600
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][comment] libwbclient: Fix warning statement with no effect

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/354
Title: #354: libwbclient: Fix warning statement with no effect

sumit-bose commented:
"""
oops, I'm sorry for not catching this, so I put a postit to my monitor 
reminding me to really run a build with even the simplest looking changes. So 
let me run a build before I ack it ...
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/354#issuecomment-324056898
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#354][opened] libwbclient: Fix warning statement with no effect

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/354
Author: lslebodn
 Title: #354: libwbclient: Fix warning statement with no effect
Action: opened

PR body:
"""
src/sss_client/libwbclient/wbc_pam_sssd.c: In function ‘wbcAuthenticateUserEx’:
src/sss_client/libwbclient/wbc_pam_sssd.c:52:5: error: statement with no effect 
[-Werror=unused-value]
 WBC_ERR_WINBIND_NOT_AVAILABLE;
 ^
src/sss_client/libwbclient/wbc_pam_sssd.c:53:1: error: control reaches end of 
non-void function [-Werror=return-type]
 }
 ^

`WBC_SSSD_NOT_IMPLEMENTED` is not an error code but also macro which can log to 
syslog
and then return `WBC_ERR_NOT_IMPLEMENTED`
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/354/head:pr354
git checkout pr354
From a0a75108c4d34c74217c06ea351d3ec3b4fe3ba9 Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Tue, 22 Aug 2017 16:50:23 +0200
Subject: [PATCH] libwbclient: Fix warning statement with no effect
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

src/sss_client/libwbclient/wbc_pam_sssd.c: In function ‘wbcAuthenticateUserEx’:
src/sss_client/libwbclient/wbc_pam_sssd.c:52:5: error: statement with no effect [-Werror=unused-value]
 WBC_ERR_WINBIND_NOT_AVAILABLE;
 ^
src/sss_client/libwbclient/wbc_pam_sssd.c:53:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
---
 src/sss_client/libwbclient/wbc_pam_sssd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sss_client/libwbclient/wbc_pam_sssd.c b/src/sss_client/libwbclient/wbc_pam_sssd.c
index fb269fd7a..77698f523 100644
--- a/src/sss_client/libwbclient/wbc_pam_sssd.c
+++ b/src/sss_client/libwbclient/wbc_pam_sssd.c
@@ -49,7 +49,7 @@ wbcErr wbcAuthenticateUserEx(const struct wbcAuthUserParams *params,
 *error = NULL;
 }
 
-WBC_ERR_WINBIND_NOT_AVAILABLE;
+return WBC_ERR_WINBIND_NOT_AVAILABLE;
 }
 
 /* Trigger a verification of the trust credentials of a specific domain */
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#347][comment] Fixes related to negative cache and "root" user/group

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/347
Title: #347: Fixes related to negative cache and "root" user/group

jhrozek commented:
"""
On Tue, Aug 22, 2017 at 12:48:50PM +, fidencio wrote:
> @jhrozek: Let me answer your questions here ...
> 
> 1. I've dropped the patches related to "0";
> 2. Thanks for the integration tests. I've gone through your patches and added 
> them on top of mines (with the Reviewed-by ...). So, if you want someone else 
> to take a look at those, feel free to ping whoever you feel the more 
> appropriate person would be. But, IMO, there's no need to open a new PR with 
> those.
> 3. As replied in the code, we descend only into active domains because I 
> wasn't sure whether would be a good idea to descend also into inactive 
> domains. I've changed that already.

As long as the global option works for subdomains, I'm fine. The
per-subdomain option can be added later, when we expose individual
options for subdomains.

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/347#issuecomment-324030952
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#353][+Pushed] libwbclient: Change return code for wbcAuthenticateUserEx

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/353
Title: #353: libwbclient: Change return code for wbcAuthenticateUserEx

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#353][comment] libwbclient: Change return code for wbcAuthenticateUserEx

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/353
Title: #353: libwbclient: Change return code for wbcAuthenticateUserEx

jhrozek commented:
"""
* master: 725d04cd21016dc6092a9f03cd363bb83d7c054c
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/353#issuecomment-324029049
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Michal Židek]

On 08/22/2017 12:31 PM, Jakub Hrozek wrote:

On Tue, Aug 22, 2017 at 11:40:39AM +0200, Michal Židek wrote:

On 08/22/2017 11:21 AM, Michal Židek wrote:

On 08/21/2017 02:27 PM, Jakub Hrozek wrote:

Hi Michal and sssd-devel,

one of the RFEs that keeps coming up for SSSD is to provide a sort of an
'attestation report' for SSSD. Mostly the request is about printing who
can access this client machine.

I know that we fetch all the HBAC rules for a client with the IPA
provider, but Michal, you mentioned that it's problematic do to
something similar for the AD provider. Could you elaborate why? Would it
be possible to extend the AD access provider to fetch all GPOs that
match this client?



I am not sure how that attestation should look like. Could you
point me to an design page if we have some?

The way I understood it is that we want list of ALL users
in AD with label ALLOWED or DENIED. I am not sure if this
possible to do without basically enumerating all users in AD
and do the GPO evaluation for every single one of them.

If we just want to print the access control related rules
in GPO in some nice format, then it would be possible without
the enumeration.

My point is that making the ALLOW/DENY list could take a lot of time
even if we use cached GPOs. That was my main concern.

But again, maybe I misunderstood the RFE.

Michal
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


Also there is the question if we want to include users from all
trusted domains...

I think what could be done relatively easily is to feed some tool with
SIDs/fqdns of users/groups and make the list just for them/their
members. Would that be something we want?


Where would these come from? If the GPOs that perhaps.


The SIDs or names (probably just names) would be provided by the user
of the tool. I imagine somethink like this:

$ sssctl access-check --users f...@ad.com b...@ad.com
f...@ad.comALLOWED
b...@ad.test   DENIED

$ sssctl access-check --groups linuxus...@ad.com linuxspec...@ad.com
linuxus...@ad.com:
  f...@ad.comALLOWED
  b...@ad.comDENIED
linuxspec...@ad.com:
  sp...@ad.com  ALLOWED
  sp...@ad.com  ALLOWED
  sp...@ad.com  ALLOWED
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#351][comment] NSS: Look for name attribute also in nss_cmd_getsidbyid

[pbrezina]

  URL: https://github.com/SSSD/sssd/pull/351
Title: #351: NSS: Look for name attribute also in nss_cmd_getsidbyid

pbrezina commented:
"""
Since we depend on name attribute here, we should make it part of default 
attributes that are merged to the requested attributes in 
`cache_req_data_create_attrs`.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/351#issuecomment-324026162
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#347][synchronized] Fixes related to negative cache and "root" user/group

[fidencio]

   URL: https://github.com/SSSD/sssd/pull/347
Author: fidencio
 Title: #347: Fixes related to negative cache and "root" user/group
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/347/head:pr347
git checkout pr347
From 336d887979a097213456541be51e6dbb9223b228 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Mon, 14 Aug 2017 15:28:41 +0200
Subject: [PATCH 01/11] NEGCACHE: Add some comments about each step of
 sss_ncache_prepopulate()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The comments help to understand which part of the code is dealing with
users or groups of specific or non-specific domain filters.

Related: https://pagure.io/SSSD/sssd/issue/3460

Signed-off-by: Fabiano Fidêncio 
---
 src/responder/common/negcache.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/responder/common/negcache.c b/src/responder/common/negcache.c
index 084c47aa8..376c3e656 100644
--- a/src/responder/common/negcache.c
+++ b/src/responder/common/negcache.c
@@ -786,7 +786,7 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 return ENOMEM;
 }
 
-/* Populate domain-specific negative cache entries */
+/* Populate domain-specific negative cache user entries */
 for (dom = domain_list; dom; dom = get_next_domain(dom, 0)) {
 conf_path = talloc_asprintf(tmpctx, CONFDB_DOMAIN_PATH_TMPL,
 dom->name);
@@ -844,6 +844,7 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 }
 }
 
+/* Populate non domain-specific negative cache user entries */
 ret = confdb_get_string_as_list(cdb, tmpctx, CONFDB_NSS_CONF_ENTRY,
 CONFDB_NSS_FILTER_USERS, _list);
 if (ret == ENOENT) {
@@ -920,6 +921,7 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 }
 }
 
+/* Populate domain-specific negative cache group entries */
 filter_set = false;
 for (dom = domain_list; dom; dom = get_next_domain(dom, 0)) {
 conf_path = talloc_asprintf(tmpctx, CONFDB_DOMAIN_PATH_TMPL, dom->name);
@@ -970,6 +972,7 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 }
 }
 
+/* Populate non domain-specific negative cache group entries */
 ret = confdb_get_string_as_list(cdb, tmpctx, CONFDB_NSS_CONF_ENTRY,
 CONFDB_NSS_FILTER_GROUPS, _list);
 if (ret == ENOENT) {

From 48ef721064cbb850a9f5bd55b0d224719c9f1b96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Mon, 14 Aug 2017 15:46:10 +0200
Subject: [PATCH 02/11] NEGCACHE: Always add "root" to the negative cache
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current code only adds "root" to the negative cache in case there's
any other user or group set up in to be added.

As SSSD doesn't handle "root", it should *always* be added to the
negative cache.

Related: https://pagure.io/SSSD/sssd/issue/3460

Signed-off-by: Fabiano Fidêncio 
---
 src/responder/common/negcache.c | 88 +
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/src/responder/common/negcache.c b/src/responder/common/negcache.c
index 376c3e656..fc5ae76bc 100644
--- a/src/responder/common/negcache.c
+++ b/src/responder/common/negcache.c
@@ -771,8 +771,8 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
struct resp_ctx *rctx)
 {
 errno_t ret;
-bool filter_set = false;
 char **filter_list = NULL;
+char **default_list = NULL;
 char *name = NULL;
 struct sss_domain_info *dom = NULL;
 struct sss_domain_info *domain_list = rctx->domains;
@@ -801,7 +801,6 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 _list);
 if (ret == ENOENT) continue;
 if (ret != EOK) goto done;
-filter_set = true;
 
 for (i = 0; (filter_list && filter_list[i]); i++) {
 ret = sss_parse_name_for_domains(tmpctx, domain_list,
@@ -847,22 +846,9 @@ errno_t sss_ncache_prepopulate(struct sss_nc_ctx *ncache,
 /* Populate non domain-specific negative cache user entries */
 ret = confdb_get_string_as_list(cdb, tmpctx, CONFDB_NSS_CONF_ENTRY,
 CONFDB_NSS_FILTER_USERS, _list);
-if (ret == ENOENT) {
-if (!filter_set) {
-filter_list = talloc_array(tmpctx, char *, 2);
-if (!filter_list) {
-ret = ENOMEM;
-goto done;
-}
-filter_list[0] = talloc_strdup(tmpctx, "root");
-if (!filter_list[0]) {
-ret = ENOMEM;
-goto done;
-}
-

[SSSD] [sssd PR#347][-Changes requested] Fixes related to negative cache and "root" user/group

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/347
Title: #347: Fixes related to negative cache and "root" user/group

Label: -Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#241][comment] FleetCommander Integration

[pbrezina]

  URL: https://github.com/SSSD/sssd/pull/241
Title: #241: FleetCommander Integration

pbrezina commented:
"""
On 08/22/2017 01:54 PM, fidencio wrote:
> @pbrezina : patchset has been updated.
> Thanks for your suggestions!

Ack.


"""

See the full comment at 
https://github.com/SSSD/sssd/pull/241#issuecomment-324011406
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#128][-Changes requested] Fix group renaming issue when "id_provider = ldap" is set

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/128
Title: #128: Fix group renaming issue when "id_provider = ldap" is set

Label: -Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#128][synchronized] Fix group renaming issue when "id_provider = ldap" is set

[fidencio]

   URL: https://github.com/SSSD/sssd/pull/128
Author: fidencio
 Title: #128: Fix group renaming issue when "id_provider = ldap" is set
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/128/head:pr128
git checkout pr128
From e482e958e501feea9cbb68953dec1a60759bd05d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 18 Jan 2017 16:43:52 +0100
Subject: [PATCH 1/2] SYSDB_OPS: Avoid adding incomplete groups with duplicated
 GID
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This situation can be hit when renaming a group. Without this patch, the
renamed group would be added to the cache while the old entry would be
there as well, causing some issues like not showing the groupname when
calling `groups user`.

Now, we take the a similar approach taken by sysdb_add_group(), checking
whether the group gid already exists and then deleting the old entry
before adding the new one.

It's important to note that the new approach only happens in case the new
added group has the same sid, uuid or original dn than the group already
added to the cache. In case it doesn't happen, the previous behavior is
preserved.

Resolves:
https://pagure.io/SSSD/sssd/issue/3202

Signed-off-by: Fabiano Fidêncio 
---
 src/db/sysdb_ops.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/src/db/sysdb_ops.c b/src/db/sysdb_ops.c
index 7ca6575ce..891e9ec24 100644
--- a/src/db/sysdb_ops.c
+++ b/src/db/sysdb_ops.c
@@ -2289,12 +2289,42 @@ int sysdb_add_incomplete_group(struct sss_domain_info *domain,
 TALLOC_CTX *tmp_ctx;
 int ret;
 struct sysdb_attrs *attrs;
+struct ldb_message *msg;
+const char *previous = NULL;
+const char *group_attrs[] = { SYSDB_SID_STR, SYSDB_UUID, SYSDB_ORIG_DN, NULL };
+const char *values[] = { sid_str, uuid, original_dn, NULL };
+bool same = false;
 
 tmp_ctx = talloc_new(NULL);
 if (!tmp_ctx) {
 return ENOMEM;
 }
 
+ret = sysdb_search_group_by_gid(tmp_ctx, domain, gid, NULL, );
+if (ret != ENOENT) {
+for (int i = 0; !same && group_attrs[i] != NULL; i++) {
+previous = ldb_msg_find_attr_as_string(msg,
+   group_attrs[i],
+   NULL);
+if (previous != NULL && values[i] != NULL) {
+same = strcmp(previous, values[i]) == 0;
+} else if (previous == NULL && values[i] == NULL) {
+same = true;
+} else {
+same = false;
+}
+}
+}
+
+if (same) {
+ret = sysdb_delete_group(domain, NULL, gid);
+if (ret != EOK) {
+DEBUG(SSSDBG_MINOR_FAILURE,
+"sysdb_delete_group() failed [%d]: %s\n",
+ret, sss_strerror(ret));
+}
+}
+
 /* try to add the group */
 ret = sysdb_add_basic_group(domain, name, gid);
 if (ret) goto done;

From 38532d4fa9c336a851ef7f75516aa8b13f80d83b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Mon, 23 Jan 2017 17:49:20 +0100
Subject: [PATCH 2/2] TESTS: Add sysdb test for renaming incomplete groups
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The test added also test the negative case, when a group has been added
but it has a different sid, uuid and original dn, which results in an
EEXIST return.

Related:
https://pagure.io/SSSD/sssd/issue/3202

Signed-off-by: Fabiano Fidêncio 
---
 src/tests/sysdb-tests.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/src/tests/sysdb-tests.c b/src/tests/sysdb-tests.c
index c186ed2fb..3b30b6788 100644
--- a/src/tests/sysdb-tests.c
+++ b/src/tests/sysdb-tests.c
@@ -989,6 +989,71 @@ START_TEST (test_sysdb_add_incomplete_group)
 }
 END_TEST
 
+START_TEST (test_sysdb_rename_incomplete_group)
+{
+struct sysdb_test_ctx *test_ctx;
+struct test_data *data;
+int ret;
+struct ldb_message *msg = NULL;
+const char *old_fqdn_groupname;
+const char *stored_fqdn_groupname;
+char *new_groupname;
+
+/* Setup */
+ret = setup_sysdb_tests(_ctx);
+if (ret != EOK) {
+fail("Could not set up the test");
+return;
+}
+
+data = test_data_new_group(test_ctx, _i);
+fail_if(data == NULL);
+
+/* "Rename" the already added incomplete group by adding
+ * the very same group with a different name. */
+old_fqdn_groupname = data->groupname;
+new_groupname = talloc_asprintf(data, "foo%d", _i);
+fail_if(new_groupname == NULL, "talloc_asprintf() failed\n");
+data->groupname = sss_create_internal_fqname(test_ctx,
+ new_groupname,
+  

[SSSD] [sssd PR#241][comment] FleetCommander Integration

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/241
Title: #241: FleetCommander Integration

fidencio commented:
"""
@pbrezina: patchset has been updated. Thanks for your suggestions!
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/241#issuecomment-324003707
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#353][comment] libwbclient: Change return code for wbcAuthenticateUserEx

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/353
Title: #353: libwbclient: Change return code for wbcAuthenticateUserEx

sumit-bose commented:
"""
@lslebodn, thank you for taking case of this. For this PR is it a plain ACK 
from me. Imo #351 is fine as well but I would prefer the hear if @pbrezina has 
any comments. Please let me know if there is some urgency, in this case I would 
ACK #351 as well.

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/353#issuecomment-324002611
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#347][comment] Fixes related to negative cache and "root" user/group

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/347
Title: #347: Fixes related to negative cache and "root" user/group

jhrozek commented:
"""
Actually, one more question -- why do we descend into only active domains? I 
think we should set the negcache also for disabled domains.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/347#issuecomment-324001322
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#347][comment] Fixes related to negative cache and "root" user/group

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/347
Title: #347: Fixes related to negative cache and "root" user/group

jhrozek commented:
"""
The patches mostly look good and fix the issue. I have two things to ask:
1) I don't think the patches that special-case the "id 0" case are needed. If 
you run "id 0" and tail the NSS logs, you would see that the id utility tries 
to be smart and treats the numerical input as name (unlike getent passwd which 
tries to convert the input to an integer and if that succeeds, calls getpwuid 
instead of getpwnam). I'm not sure if name "0" is legal in the POSIX sense or 
if utilities like useradd would allow adding a user with the name "0", but I 
don't think we should special case this. Just the name root and the UID 0 
because those have a special meaning in UNIX.

2) I wrote integration tests for this PR. Currently they would fail because 
they test this fix, but I think we should push them atop your patches. You can 
find the tests here: https://github.com/jhrozek/sssd/tree/review

If you agree, then let's push this PR and then I'll open a new PR with the 
tests and you can review those three test patches.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/347#issuecomment-324001097
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Jakub Hrozek]

On Tue, Aug 22, 2017 at 11:40:39AM +0200, Michal Židek wrote:
> On 08/22/2017 11:21 AM, Michal Židek wrote:
> > On 08/21/2017 02:27 PM, Jakub Hrozek wrote:
> > > Hi Michal and sssd-devel,
> > > 
> > > one of the RFEs that keeps coming up for SSSD is to provide a sort of an
> > > 'attestation report' for SSSD. Mostly the request is about printing who
> > > can access this client machine.
> > > 
> > > I know that we fetch all the HBAC rules for a client with the IPA
> > > provider, but Michal, you mentioned that it's problematic do to
> > > something similar for the AD provider. Could you elaborate why? Would it
> > > be possible to extend the AD access provider to fetch all GPOs that
> > > match this client?
> > > 
> > 
> > I am not sure how that attestation should look like. Could you
> > point me to an design page if we have some?
> > 
> > The way I understood it is that we want list of ALL users
> > in AD with label ALLOWED or DENIED. I am not sure if this
> > possible to do without basically enumerating all users in AD
> > and do the GPO evaluation for every single one of them.
> > 
> > If we just want to print the access control related rules
> > in GPO in some nice format, then it would be possible without
> > the enumeration.
> > 
> > My point is that making the ALLOW/DENY list could take a lot of time
> > even if we use cached GPOs. That was my main concern.
> > 
> > But again, maybe I misunderstood the RFE.
> > 
> > Michal
> > ___
> > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
> 
> Also there is the question if we want to include users from all
> trusted domains...
> 
> I think what could be done relatively easily is to feed some tool with
> SIDs/fqdns of users/groups and make the list just for them/their
> members. Would that be something we want?

Where would these come from? If the GPOs that perhaps.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Michal Židek]

On 08/22/2017 12:43 PM, Michal Židek wrote:

On 08/22/2017 11:38 AM, Jakub Hrozek wrote:

On Tue, Aug 22, 2017 at 11:21:43AM +0200, Michal Židek wrote:

On 08/21/2017 02:27 PM, Jakub Hrozek wrote:

Hi Michal and sssd-devel,

one of the RFEs that keeps coming up for SSSD is to provide a sort 
of an

'attestation report' for SSSD. Mostly the request is about printing who
can access this client machine.

I know that we fetch all the HBAC rules for a client with the IPA
provider, but Michal, you mentioned that it's problematic do to
something similar for the AD provider. Could you elaborate why? 
Would it

be possible to extend the AD access provider to fetch all GPOs that
match this client?



I am not sure how that attestation should look like. Could you
point me to an design page if we have some?


The point of this thread is to come up with the design :-) I would
prefer to see what we can do currently, do a first draft of the design
and then pass it on to users and customers who requested the feature and
see if they are OK with this.



The way I understood it is that we want list of ALL users
in AD with label ALLOWED or DENIED.


Hmm, I was going to say just allowed, but now I remember that we also
can use GPOs to deny access, right?


Yes, we can have rules to specifically deny access and if I am not
mistaken they have higher priority (IIRC if the user is allowed in
some rule and denied in other rule then he is denied access).

With GPOs there is also the issue with security filtering. A GPO
can be filtered out for some users or groups (the GPO can be made
relevent only if specified users and groups are logging in) in
that case it does not matter what is in the GPO.


I mean, for the user who is not in the security filter of some
GPO, it does not matter what is in the GPO, because it is ignored
when this user logs in.



This can get more complicated, because that means different
users see different subset of GPOs, if we merge all GPOs and
make attestation report based on that, we may actually end up
with list that is not relevant at all.




I am not sure if this
possible to do without basically enumerating all users in AD
and do the GPO evaluation for every single one of them.


So, here is what I'm thinking for IPA and I initially thought we could
take a similar approach for AD.

For IPA, we fetch all the HBAC rules which apply for this host, either
directly or via a host group. The rules contain the user name or a
group.

Usernames are easy and the report could just print them. For groups,
unfortunately we don't have other mean that to call getgrnam.


GPOs do not contain any names, only SIDs, and those can be
both user SIDs and group SIDs.



So the report would look like this:
 for rule in cached_hbac_rules:
 for user in rule.users:
 print "$user is allowed"
 for group in rule.groups:
 print "Members of $group are allowed. That includes: "
 group_members = getgrnam($group)
 for member in $group_members:
 print "$member"


In the worst case scenario, we can really fall back to
create a tool for AD provider that gets list of names or
groups and does the GPO evaluation as if those people were
logging in. This would give the most accurate results and
could also be used as debugging tool for GPO processing.
But it would be very slow to do for all users in the AD,
but given the nature of this tool the database can be split
into parts and not everything needs to be done at once
(for example admin decides to create the ALLOW/DENY list
for just users from few groups (linux_users for example)).



I /though/ that we fetch all the GPOs and we could print a similar
report as the pseudocode above, just unrolling the SIDs in the GPOs.



If we just want to print the access control related rules
in GPO in some nice format, then it would be possible without
the enumeration.


This could be an option, too.


But as I said the security filter could make this problematic.





My point is that making the ALLOW/DENY list could take a lot of time
even if we use cached GPOs. That was my main concern.

But again, maybe I misunderstood the RFE.


See above, the RFE is a bit fuzzy, we need to see what we can do first.


Sure, thanks for explanation.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#353][comment] libwbclient: Change return code for wbcAuthenticateUserEx

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/353
Title: #353: libwbclient: Change return code for wbcAuthenticateUserEx

lslebodn commented:
"""
@sumit-bose this PR + #351 together improves situation with sssd-libwbclient 
and samba-4.6
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/353#issuecomment-323998255
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: debugging adcli info - short name not returned

[Sumit Bose]

On Wed, Aug 02, 2017 at 09:44:41AM +0200, Jakub Hrozek wrote:
> On Tue, Aug 01, 2017 at 06:52:41PM -, smfre...@gmail.com wrote:
> > In one of our test domains, we noticed that the short name of the domain 
> > was not being returned by "adcli info" (it is visible in the output of "net 
> > rpc info" though and it is clearly configured in Windows and can be seen in 
> > the GUI and CLI of Windows).
> > 
> > Running "adcli info --verbose" we see only a few lines about contacting 
> > servers, but nothing obvious to me.
> > 
> > Any ideas about common reasons that adcli info can't return short domain 
> > name from a particular win2K8 server but ok to others (while "net" can 
> > always return it).  Note that joining the domain (via realm) does work - 
> > even though can't get short name

adcli uses an LDAP ping
(https://msdn.microsoft.com/en-us/library/cc223811.aspx) to determine
details about the domain. As can be seen in
https://msdn.microsoft.com/en-us/library/cc223813.aspx the reply might
come in various formats but adcli can currently only handles
LOGON_SAM_LOGON_RESPONSE_EX.

Feel free to send me the output of

ldapsearch -x -H ldap://your.win2K8.dc -b '' 
'(&(DnsDomain=your.domain)(NtVer=\06\00\00\00))' -s base netlogon

and I can check if adcli can handle the outout or not.

bye,
Sumit

> 
> Hi,
> I know I'm not answering your question, but I just wanted to say that
> Sumit, who currently maintains adcli is on vacation for another two
> weeks, so it might be a while until he has a chance to answer..
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#353][opened] libwbclient: Change return code for wbcAuthenticateUserEx

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/353
Author: lslebodn
 Title: #353: libwbclient: Change return code for wbcAuthenticateUserEx
Action: opened

PR body:
"""
Samba-4.6 change behaviour of few functions
New version of code make sure session info for user is stored in cache.
It is a performance optimisation to prevent contacting KDC for each
session. More details in samba bug
https://bugzilla.samba.org/show_bug.cgi?id=11259

Old return code WBC_SSSD_NOT_IMPLEMENTED was translated
to NT_STATUS_LOGON_FAILURE which caused many failures.

[2017/08/21 11:34:15.044321,  5, pid=27742, effective(0, 0), real(0, 0)]
../libcli/security/security_token.c:53(security_token_debug)
  Security token: (NULL)
[2017/08/21 11:34:15.044330,  5, pid=27742, effective(0, 0), real(0, 0)]
../source3/auth/token_util.c:640(debug_unix_user_token)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2017/08/21 11:34:15.044349,  4, pid=27742, effective(0, 0), real(0, 0)]
../source3/smbd/sec_ctx.c:439(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2017/08/21 11:34:15.044360,  1, pid=27742, effective(0, 0), real(0, 0)]
../source3/smbd/sesssetup.c:290(reply_sesssetup_and_X_spnego)
  Failed to generate session_info (user and group token) for session
setup: NT_STATUS_LOGON_FAILURE

Resolves:
https://pagure.io/SSSD/sssd/issue/3461
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/353/head:pr353
git checkout pr353
From 8588c466bb108d4fc7a54d482d872f52923d29a5 Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Tue, 22 Aug 2017 13:09:18 +0200
Subject: [PATCH] libwbclient: Change return code for wbcAuthenticateUserEx

Samba-4.6 change behaviour of few functions
New version of code make sure session info for user is stored in cache.
It is a performance optimisation to prevent contacting KDC for each
session. More details in samba bug
https://bugzilla.samba.org/show_bug.cgi?id=11259

Old return code WBC_SSSD_NOT_IMPLEMENTED was translated
to NT_STATUS_LOGON_FAILURE which caused many failures.

[2017/08/21 11:34:15.044321,  5, pid=27742, effective(0, 0), real(0, 0)]
../libcli/security/security_token.c:53(security_token_debug)
  Security token: (NULL)
[2017/08/21 11:34:15.044330,  5, pid=27742, effective(0, 0), real(0, 0)]
../source3/auth/token_util.c:640(debug_unix_user_token)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2017/08/21 11:34:15.044349,  4, pid=27742, effective(0, 0), real(0, 0)]
../source3/smbd/sec_ctx.c:439(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2017/08/21 11:34:15.044360,  1, pid=27742, effective(0, 0), real(0, 0)]
../source3/smbd/sesssetup.c:290(reply_sesssetup_and_X_spnego)
  Failed to generate session_info (user and group token) for session
setup: NT_STATUS_LOGON_FAILURE

Resolves:
https://pagure.io/SSSD/sssd/issue/3461
---
 src/sss_client/libwbclient/wbc_pam_sssd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sss_client/libwbclient/wbc_pam_sssd.c b/src/sss_client/libwbclient/wbc_pam_sssd.c
index 174cf1310..fb269fd7a 100644
--- a/src/sss_client/libwbclient/wbc_pam_sssd.c
+++ b/src/sss_client/libwbclient/wbc_pam_sssd.c
@@ -49,7 +49,7 @@ wbcErr wbcAuthenticateUserEx(const struct wbcAuthUserParams *params,
 *error = NULL;
 }
 
-WBC_SSSD_NOT_IMPLEMENTED;
+WBC_ERR_WINBIND_NOT_AVAILABLE;
 }
 
 /* Trigger a verification of the trust credentials of a specific domain */
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Michal Židek]

On 08/22/2017 11:38 AM, Jakub Hrozek wrote:

On Tue, Aug 22, 2017 at 11:21:43AM +0200, Michal Židek wrote:

On 08/21/2017 02:27 PM, Jakub Hrozek wrote:

Hi Michal and sssd-devel,

one of the RFEs that keeps coming up for SSSD is to provide a sort of an
'attestation report' for SSSD. Mostly the request is about printing who
can access this client machine.

I know that we fetch all the HBAC rules for a client with the IPA
provider, but Michal, you mentioned that it's problematic do to
something similar for the AD provider. Could you elaborate why? Would it
be possible to extend the AD access provider to fetch all GPOs that
match this client?



I am not sure how that attestation should look like. Could you
point me to an design page if we have some?


The point of this thread is to come up with the design :-) I would
prefer to see what we can do currently, do a first draft of the design
and then pass it on to users and customers who requested the feature and
see if they are OK with this.



The way I understood it is that we want list of ALL users
in AD with label ALLOWED or DENIED.


Hmm, I was going to say just allowed, but now I remember that we also
can use GPOs to deny access, right?


Yes, we can have rules to specifically deny access and if I am not
mistaken they have higher priority (IIRC if the user is allowed in
some rule and denied in other rule then he is denied access).

With GPOs there is also the issue with security filtering. A GPO
can be filtered out for some users or groups (the GPO can be made
relevent only if specified users and groups are logging in) in
that case it does not matter what is in the GPO.

This can get more complicated, because that means different
users see different subset of GPOs, if we merge all GPOs and
make attestation report based on that, we may actually end up
with list that is not relevant at all.




I am not sure if this
possible to do without basically enumerating all users in AD
and do the GPO evaluation for every single one of them.


So, here is what I'm thinking for IPA and I initially thought we could
take a similar approach for AD.

For IPA, we fetch all the HBAC rules which apply for this host, either
directly or via a host group. The rules contain the user name or a
group.

Usernames are easy and the report could just print them. For groups,
unfortunately we don't have other mean that to call getgrnam.


GPOs do not contain any names, only SIDs, and those can be
both user SIDs and group SIDs.



So the report would look like this:
 for rule in cached_hbac_rules:
 for user in rule.users:
 print "$user is allowed"
 for group in rule.groups:
 print "Members of $group are allowed. That includes: "
 group_members = getgrnam($group)
 for member in $group_members:
 print "$member"


In the worst case scenario, we can really fall back to
create a tool for AD provider that gets list of names or
groups and does the GPO evaluation as if those people were
logging in. This would give the most accurate results and
could also be used as debugging tool for GPO processing.
But it would be very slow to do for all users in the AD,
but given the nature of this tool the database can be split
into parts and not everything needs to be done at once
(for example admin decides to create the ALLOW/DENY list
for just users from few groups (linux_users for example)).



I /though/ that we fetch all the GPOs and we could print a similar
report as the pseudocode above, just unrolling the SIDs in the GPOs.



If we just want to print the access control related rules
in GPO in some nice format, then it would be possible without
the enumeration.


This could be an option, too.


But as I said the security filter could make this problematic.





My point is that making the ALLOW/DENY list could take a lot of time
even if we use cached GPOs. That was my main concern.

But again, maybe I misunderstood the RFE.


See above, the RFE is a bit fuzzy, we need to see what we can do first.


Sure, thanks for explanation.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#342][+Accepted] SELINUX: Use getseuserbyname to get IPA seuser

[mzidek-rh]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#342][comment] SELINUX: Use getseuserbyname to get IPA seuser

[mzidek-rh]

  URL: https://github.com/SSSD/sssd/pull/342
Title: #342: SELINUX: Use getseuserbyname to get IPA seuser

mzidek-rh commented:
"""
@jhrozek sry, I only parsed 'accepted' from your message and I though you did 
accept it.

So, ACK and adding accepted flag.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/342#issuecomment-323984146
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Michal Židek]

On 08/22/2017 11:21 AM, Michal Židek wrote:

On 08/21/2017 02:27 PM, Jakub Hrozek wrote:

Hi Michal and sssd-devel,

one of the RFEs that keeps coming up for SSSD is to provide a sort of an
'attestation report' for SSSD. Mostly the request is about printing who
can access this client machine.

I know that we fetch all the HBAC rules for a client with the IPA
provider, but Michal, you mentioned that it's problematic do to
something similar for the AD provider. Could you elaborate why? Would it
be possible to extend the AD access provider to fetch all GPOs that
match this client?



I am not sure how that attestation should look like. Could you
point me to an design page if we have some?

The way I understood it is that we want list of ALL users
in AD with label ALLOWED or DENIED. I am not sure if this
possible to do without basically enumerating all users in AD
and do the GPO evaluation for every single one of them.

If we just want to print the access control related rules
in GPO in some nice format, then it would be possible without
the enumeration.

My point is that making the ALLOW/DENY list could take a lot of time
even if we use cached GPOs. That was my main concern.

But again, maybe I misunderstood the RFE.

Michal
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


Also there is the question if we want to include users from all
trusted domains...

I think what could be done relatively easily is to feed some tool with
SIDs/fqdns of users/groups and make the list just for them/their
members. Would that be something we want?

Michal
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Jakub Hrozek]

On Tue, Aug 22, 2017 at 11:21:43AM +0200, Michal Židek wrote:
> On 08/21/2017 02:27 PM, Jakub Hrozek wrote:
> > Hi Michal and sssd-devel,
> > 
> > one of the RFEs that keeps coming up for SSSD is to provide a sort of an
> > 'attestation report' for SSSD. Mostly the request is about printing who
> > can access this client machine.
> > 
> > I know that we fetch all the HBAC rules for a client with the IPA
> > provider, but Michal, you mentioned that it's problematic do to
> > something similar for the AD provider. Could you elaborate why? Would it
> > be possible to extend the AD access provider to fetch all GPOs that
> > match this client?
> > 
> 
> I am not sure how that attestation should look like. Could you
> point me to an design page if we have some?

The point of this thread is to come up with the design :-) I would
prefer to see what we can do currently, do a first draft of the design
and then pass it on to users and customers who requested the feature and
see if they are OK with this.

> 
> The way I understood it is that we want list of ALL users
> in AD with label ALLOWED or DENIED. 

Hmm, I was going to say just allowed, but now I remember that we also
can use GPOs to deny access, right?

> I am not sure if this
> possible to do without basically enumerating all users in AD
> and do the GPO evaluation for every single one of them.

So, here is what I'm thinking for IPA and I initially thought we could
take a similar approach for AD.

For IPA, we fetch all the HBAC rules which apply for this host, either
directly or via a host group. The rules contain the user name or a
group.

Usernames are easy and the report could just print them. For groups,
unfortunately we don't have other mean that to call getgrnam.

So the report would look like this:
for rule in cached_hbac_rules:
for user in rule.users:
print "$user is allowed"
for group in rule.groups:
print "Members of $group are allowed. That includes: "
group_members = getgrnam($group)
for member in $group_members:
print "$member"

I /though/ that we fetch all the GPOs and we could print a similar
report as the pseudocode above, just unrolling the SIDs in the GPOs.

> 
> If we just want to print the access control related rules
> in GPO in some nice format, then it would be possible without
> the enumeration.

This could be an option, too.

> 
> My point is that making the ALLOW/DENY list could take a lot of time
> even if we use cached GPOs. That was my main concern.
> 
> But again, maybe I misunderstood the RFE.

See above, the RFE is a bit fuzzy, we need to see what we can do first.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: about access control reporting with id_provider=ad

[Michal Židek]

On 08/21/2017 02:27 PM, Jakub Hrozek wrote:

Hi Michal and sssd-devel,

one of the RFEs that keeps coming up for SSSD is to provide a sort of an
'attestation report' for SSSD. Mostly the request is about printing who
can access this client machine.

I know that we fetch all the HBAC rules for a client with the IPA
provider, but Michal, you mentioned that it's problematic do to
something similar for the AD provider. Could you elaborate why? Would it
be possible to extend the AD access provider to fetch all GPOs that
match this client?



I am not sure how that attestation should look like. Could you
point me to an design page if we have some?

The way I understood it is that we want list of ALL users
in AD with label ALLOWED or DENIED. I am not sure if this
possible to do without basically enumerating all users in AD
and do the GPO evaluation for every single one of them.

If we just want to print the access control related rules
in GPO in some nice format, then it would be possible without
the enumeration.

My point is that making the ALLOW/DENY list could take a lot of time
even if we use cached GPOs. That was my main concern.

But again, maybe I misunderstood the RFE.

Michal
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#332][comment] sydb: index improvements

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/332
Title: #332: sydb: index improvements

jhrozek commented:
"""
I think the patches are great and we've seen already reports by users who run 
the patches and reported that performance improved substantially.

There are some objects that are not user or group but still use OBJECTCLASS and 
not CATEGORY. At least `sysdb_save_autofsmap` still uses `SYSDB_OBJECTCLASS`, 
then `sysdb_svc_add` (or rather the sysdb_services module), the sysdb_ssh 
module, sysdb_netgroups module and the sudo module.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/332#issuecomment-323966202
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#352][synchronized] logging: Removing duplicate log message

[amitkumar50]

   URL: https://github.com/SSSD/sssd/pull/352
Author: amitkumar50
 Title: #352: logging: Removing duplicate log message
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/352/head:pr352
git checkout pr352
From 1e7afe84a9871a26986cb1170fb13da5a4dbca73 Mon Sep 17 00:00:00 2001
From: AmitKumar 
Date: Mon, 21 Aug 2017 19:59:59 +0530
Subject: [PATCH] logging: Removing duplicate log message

Duplicate log messages were getting logged if trust relationship
breaks for some reason from AD. That causes lot spam in syslog.
This PR removes duplicate log entry and keeps extended log entry.

Resolves: https://pagure.io/SSSD/sssd/issue/3450
---
 src/providers/ldap/ldap_child.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/src/providers/ldap/ldap_child.c b/src/providers/ldap/ldap_child.c
index cfbfc5b76..b796e5cae 100644
--- a/src/providers/ldap/ldap_child.c
+++ b/src/providers/ldap/ldap_child.c
@@ -61,13 +61,6 @@ static void sig_term_handler(int sig)
 static krb5_context krb5_error_ctx;
 #define LDAP_CHILD_DEBUG(level, error) KRB5_DEBUG(level, krb5_error_ctx, error)
 
-static const char *__ldap_child_krb5_error_msg;
-#define KRB5_SYSLOG(krb5_error) do { \
-__ldap_child_krb5_error_msg = sss_krb5_get_error_message(krb5_error_ctx, krb5_error); \
-sss_log(SSS_LOG_ERR, "%s", __ldap_child_krb5_error_msg); \
-sss_krb5_free_error_message(krb5_error_ctx, __ldap_child_krb5_error_msg); \
-} while(0)
-
 struct input_buffer {
 const char *realm_str;
 const char *princ_str;
@@ -450,11 +443,6 @@ static krb5_error_code ldap_child_get_tgt_sync(TALLOC_CTX *memctx,
 DEBUG(SSSDBG_FATAL_FAILURE,
   "Failed to init credentials: %s\n",
sss_krb5_get_error_message(context, krberr));
-sss_log(SSS_LOG_ERR,
-"Failed to initialize credentials using keytab [%s]: %s. "
-"Unable to create GSSAPI-encrypted LDAP connection.",
-KEYTAB_CLEAN_NAME,
-sss_krb5_get_error_message(context, krberr));
 goto done;
 }
 DEBUG(SSSDBG_TRACE_INTERNAL, "credentials initialized\n");
@@ -527,7 +515,11 @@ static krb5_error_code ldap_child_get_tgt_sync(TALLOC_CTX *memctx,
 if (krberr != 0) {
 const char *krb5_msg;
 
-KRB5_SYSLOG(krberr);
+sss_log(SSS_LOG_ERR,
+"Failed to initialize credentials using keytab [%s]: %s. "
+"Unable to create GSSAPI-encrypted LDAP connection.",
+KEYTAB_CLEAN_NAME,
+sss_krb5_get_error_message(context, krberr));
 krb5_msg = sss_krb5_get_error_message(context, krberr);
 *_krb5_msg = talloc_strdup(memctx, krb5_msg);
 sss_krb5_free_error_message(context, krb5_msg);
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: RFC: 1.15.4 cleanup

[Jakub Hrozek]

On Tue, Aug 22, 2017 at 09:19:54AM +0200, Lukas Slebodnik wrote:
> On (21/08/17 21:04), Jakub Hrozek wrote:
> >Hi,
> >
> >1.15.4 will be released by the end of this months in a time-based
> >fashion. But obviously, the milestone is too big, so we need to decide
> >where do we push the tickets to.
> >
> >I added tags to the tickets with my proposed cleanup:
> >- move to 1.16:
> >  
> > https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-one-sixteen_stones=
> >- move to 'future releases' 
> > https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-future_stones=
> >- move to 'patches welcome'
> >  
> > https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-patches-welcome_stones=
> >
> 
> What is a difference between 'future releases' and 'patches welcome' ?

future releses = this is what we look at when we plan a next version

patches welcome = unless someone submits a PR, we won't look at this
ticket. We're just leaving it around in case someone else is interested
in providing a patch.

> 
> Why is https://pagure.io/SSSD/sssd/issue/3399 proposed to move into
> future releases if it already have PR?

Because I missed it has a PR :)

> 
> 
> >It would be nice to hear some feedback from others before I move the
> >tickets.
> >
> >About the tickets that are proposed to stay in 1.15 -- most of them have
> >PRs available, but those that we won't finish should IMO be rolled to
> >1.15.5, because who knows when will 1.16.0 be released and especially
> >the KCM related fixes are important to be included in Fedora around
> >Sep-5, so I think we might want to do another release a week after .4..
> >
> >And finally, about the 1.16 milestone -- I suggest we start chopping on
> >that one as developers shake off 1.15.x tasks. We should do a time-based
> >release by the end of September, then one by the end of October and see
> >how many tickets are left..
> >
> 
> We could afford to do time-based releases if we have full code coverage
> in upstream. We are not there yet.

Yes, but time-based here means 'we won't continue developing sssd in
this milestone until all the tickets are fixed', but instead 'we release
sssd by some date and move the tickets into other releases'.

Of couse we would fix regressions and run tests.

btw since sssd releases were historically driven by RHEL a lot, quite a
few releases were time-based anyway based on RHEL schedule. I hope
maintainers from other distributions would chime in with their schedule
(and Timo did in a way with 1.15 lately on IRC..)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#325][-Changes requested] MAN: Improve description of 'trusted domain section' in sssd.conf's man page

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/325
Title: #325: MAN: Improve description of 'trusted domain section' in 
sssd.conf's man page

Label: -Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#128][+Changes requested] Fix group renaming issue when "id_provider = ldap" is set

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/128
Title: #128: Fix group renaming issue when "id_provider = ldap" is set

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#241][comment] FleetCommander Integration

[pbrezina]

  URL: https://github.com/SSSD/sssd/pull/241
Title: #241: FleetCommander Integration

pbrezina commented:
"""
Typo in "related":
```xml
+
+Default: id_provider is used if it
+is set and can perform session reltted tasks.
+

```


This works and it looks good in provider logs but in pam log is a system error 
which may be confusing. Please add the diff I provided so we can avoid it.

```
275 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending 
request with the following data:
276 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
SSS_PAM_OPEN_SESSION
277 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: 
LDAP.PB
278 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
use...@ldap.pb
279 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): service: 
su
280 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: pts/7
281 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
pbrezina
282 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 
not set
283 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 
type: 0
284 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): 
newauthtok type: 0
285 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
286 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 
10586
287 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_print_data] (0x0100): logon 
name: user-1
288 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0xe9e330
289 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): 
pam_dp_send_req returned 0
290 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 
0xe9e330
291 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_dp_process_reply] (0x0010): 
Reply error.
292 (Tue Aug 22 09:59:23 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply 
called with result [4]: System error.
```
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/241#issuecomment-323951221
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: RFC: 1.15.4 cleanup

[Lukas Slebodnik]

On (21/08/17 21:04), Jakub Hrozek wrote:
>Hi,
>
>1.15.4 will be released by the end of this months in a time-based
>fashion. But obviously, the milestone is too big, so we need to decide
>where do we push the tickets to.
>
>I added tags to the tickets with my proposed cleanup:
>- move to 1.16:
>  
> https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-one-sixteen_stones=
>- move to 'future releases' 
> https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-future_stones=
>- move to 'patches welcome'
>  
> https://pagure.io/SSSD/sssd/roadmap?status=Open=cleanup-patches-welcome_stones=
>

What is a difference between 'future releases' and 'patches welcome' ?

Why is https://pagure.io/SSSD/sssd/issue/3399 proposed to move into
future releases if it already have PR?


>It would be nice to hear some feedback from others before I move the
>tickets.
>
>About the tickets that are proposed to stay in 1.15 -- most of them have
>PRs available, but those that we won't finish should IMO be rolled to
>1.15.5, because who knows when will 1.16.0 be released and especially
>the KCM related fixes are important to be included in Fedora around
>Sep-5, so I think we might want to do another release a week after .4..
>
>And finally, about the 1.16 milestone -- I suggest we start chopping on
>that one as developers shake off 1.15.x tasks. We should do a time-based
>release by the end of September, then one by the end of October and see
>how many tickets are left..
>

We could afford to do time-based releases if we have full code coverage
in upstream. We are not there yet.

LS
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org