Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-13 Thread Lachlan Musicman 
I am still having problems with FreeIPA/HBAC, SSSD and logging into hosts.
Could this be the reason that SSSD isn't picking up the full list of groups
a user belongs to?

In particular, ipa hbac test says true. "id domain\\username" or "id
username@domain" returns the correct groups. But the
sssd_domain.com.log- shows hbac_eval_user_element returning a list of
groups that doesn't include the IPA groups in the HBAC rule? (it does
return the AD group that is the external group that the IPA group would
register as being HBAC true, but not the matching IPA group)

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 9 March 2017 at 20:39, Jakub Hrozek  wrote:

> On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> > On to, 09 maalis 2017, Jakub Hrozek wrote:
> > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > > Hola,
> > > >
> > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and
> sssd
> > > > (via COPR) 1.15.1, which has a one way trust to an AD domain.
> unix.name.org
> > > > -> name.org
> > > >
> > > > I've seen some interesting behaviour.
> > > >
> > > > Being part of a large organisation with a smaller nix environment
> and a
> > > > larger Windows environment we see all the best of odd AD management
> > > > behaviour (eg spaces in usernames...).
> > > >
> > > > Turns out some of the groups in AD have an @ symbol in them.
> > > >
> > > > The behavioural difference we see is: given userA in group "name @ of
> > > > group" that on the FreeIPA server:
> > > >
> > > > [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> > > >
> > > > works as expected.
> > > >
> > > > But on a client
> > > >
> > > > [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> > > >
> > > > returns nothing.
> > >
> > > Yes, it is a know issue:
> > >https://pagure.io/SSSD/sssd/issue/3219
> > >
> > > There were some users who reported this works better with a modified
> > > re_expression:
> > >re_expression = ((?P.+)@(?P[^@]+$))
> > > but I agree we should fix this by default. However, the fix must be
> done
> > > at both the SSSD level and the IPA extdom plugin, which also searches
> > > for the @-sign in the user and group names.
> > Luckily, a change for extdom plugin seem to be straightforward -- search
> > for the *last* occurence of the domain separator, not the first one. We
> > had a similar issue with nfs idmapd code too.
>
> Yes, the most tricky part would be testing, to make sure the new regular
> expression doesn't break anything. I used the one I showed to unblock
> some RHEL customers that were complaining and were a bit stuck, but I
> didn't have enough time to run all our available tests with it, that's
> why we didn't switch by default..
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-09 Thread Jakub Hrozek 
On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> On to, 09 maalis 2017, Jakub Hrozek wrote:
> > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > Hola,
> > > 
> > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
> > > (via COPR) 1.15.1, which has a one way trust to an AD domain. 
> > > unix.name.org
> > > -> name.org
> > > 
> > > I've seen some interesting behaviour.
> > > 
> > > Being part of a large organisation with a smaller nix environment and a
> > > larger Windows environment we see all the best of odd AD management
> > > behaviour (eg spaces in usernames...).
> > > 
> > > Turns out some of the groups in AD have an @ symbol in them.
> > > 
> > > The behavioural difference we see is: given userA in group "name @ of
> > > group" that on the FreeIPA server:
> > > 
> > > [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> > > 
> > > works as expected.
> > > 
> > > But on a client
> > > 
> > > [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> > > 
> > > returns nothing.
> > 
> > Yes, it is a know issue:
> >https://pagure.io/SSSD/sssd/issue/3219
> > 
> > There were some users who reported this works better with a modified
> > re_expression:
> >re_expression = ((?P.+)@(?P[^@]+$))
> > but I agree we should fix this by default. However, the fix must be done
> > at both the SSSD level and the IPA extdom plugin, which also searches
> > for the @-sign in the user and group names.
> Luckily, a change for extdom plugin seem to be straightforward -- search
> for the *last* occurence of the domain separator, not the first one. We
> had a similar issue with nfs idmapd code too.

Yes, the most tricky part would be testing, to make sure the new regular
expression doesn't break anything. I used the one I showed to unblock
some RHEL customers that were complaining and were a bit stuck, but I
didn't have enough time to run all our available tests with it, that's
why we didn't switch by default..

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-09 Thread Alexander Bokovoy 

On to, 09 maalis 2017, Jakub Hrozek wrote:

On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:

Hola,

On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
(via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
-> name.org

I've seen some interesting behaviour.

Being part of a large organisation with a smaller nix environment and a
larger Windows environment we see all the best of odd AD management
behaviour (eg spaces in usernames...).

Turns out some of the groups in AD have an @ symbol in them.

The behavioural difference we see is: given userA in group "name @ of
group" that on the FreeIPA server:

[r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org

works as expected.

But on a client

[r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org

returns nothing.


Yes, it is a know issue:
   https://pagure.io/SSSD/sssd/issue/3219

There were some users who reported this works better with a modified
re_expression:
   re_expression = ((?P.+)@(?P[^@]+$))
but I agree we should fix this by default. However, the fix must be done
at both the SSSD level and the IPA extdom plugin, which also searches
for the @-sign in the user and group names.

Luckily, a change for extdom plugin seem to be straightforward -- search
for the *last* occurence of the domain separator, not the first one. We
had a similar issue with nfs idmapd code too.

--
/ Alexander Bokovoy
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..7c67fb7 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
 char *short_user_name = NULL;
 
 short_user_name = strdup(user_name);
-if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
 char *short_group_name = NULL;
 
 short_group_name = strdup(group_name);
-if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx 
*ctx,
 goto done;
 }
 
-sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
 if (sep == NULL) {
 set_err_msg(req, "Failed to split fully qualified name");
 ret = LDAP_OPERATIONS_ERROR;
@@ -1023,7 +1023,7 @@ static int handle_name_request(struct ipa_extdom_ctx *ctx,
 char *buf = NULL;
 struct sss_nss_kv *kv_list = NULL;
 
-if (strchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) {
+if (strrchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) {
 ret = asprintf(_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR,
domain_name);
 } else {
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-09 Thread Jakub Hrozek 
On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> Hola,
> 
> On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
> (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
> -> name.org
> 
> I've seen some interesting behaviour.
> 
> Being part of a large organisation with a smaller nix environment and a
> larger Windows environment we see all the best of odd AD management
> behaviour (eg spaces in usernames...).
> 
> Turns out some of the groups in AD have an @ symbol in them.
> 
> The behavioural difference we see is: given userA in group "name @ of
> group" that on the FreeIPA server:
> 
> [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> 
> works as expected.
> 
> But on a client
> 
> [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> 
> returns nothing.

Yes, it is a know issue:
https://pagure.io/SSSD/sssd/issue/3219

There were some users who reported this works better with a modified
re_expression:
re_expression = ((?P.+)@(?P[^@]+$))
but I agree we should fix this by default. However, the fix must be done
at both the SSSD level and the IPA extdom plugin, which also searches
for the @-sign in the user and group names.
> 
> We believe it is because of the group with the @ in the name.
> 
> The AD management team agreed to change the name of one group with an @ in
> it's name, and that has solved the problem - id us...@name.org now works on
> the sssd client.
> 
> Putting aside the critiques of having an @ in a group name, I believe that
> if there isn't a bug, there is at least an inconsistency, between how
> FreeIPA and sssd handle this situation.
> 
> This was a guess based on seeing this in the logs:
> 
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust
> View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry]
> (0x1000): OriginalDN:
> [ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default
> Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
> errmsg set
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send]
> (0x0400): Executing extended operation
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done]
> (0x0400): ldap_extended_operation result: Success(0), (null).
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> ...
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data]
> (0x0040): find_domain_by_name failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [s2n_response_to_attrs] (0x0040): add_v1_user_data failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.
> 
> 
> The last three lines tipped off a colleague who was debugging why this
> userA couldn't login to anything.
> 
> Since then we have created IPA over rides for the groups with @ symbols in
> them. This also works as a solution. It's not our preferred solution, but
> we are users, not managers, of the AD system.
> 
> Cheers
> 
> L.
> 
> 
> 
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-08 Thread Lachlan Musicman 
Hola,

On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
(via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
-> name.org

I've seen some interesting behaviour.

Being part of a large organisation with a smaller nix environment and a
larger Windows environment we see all the best of odd AD management
behaviour (eg spaces in usernames...).

Turns out some of the groups in AD have an @ symbol in them.

The behavioural difference we see is: given userA in group "name @ of
group" that on the FreeIPA server:

[r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org

works as expected.

But on a client

[r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org

returns nothing.

We believe it is because of the group with the @ in the name.

The AD management team agreed to change the name of one group with an @ in
it's name, and that has solved the problem - id us...@name.org now works on
the sssd client.

Putting aside the critiques of having an @ in a group name, I believe that
if there isn't a bug, there is at least an inconsistency, between how
FreeIPA and sssd handle this situation.

This was a guess based on seeing this in the logs:

(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust
View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry]
(0x1000): OriginalDN:
[ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default
Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send]
(0x0400): Executing extended operation
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done]
(0x0400): ldap_extended_operation result: Success(0), (null).
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
...
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data]
(0x0040): find_domain_by_name failed.
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[s2n_response_to_attrs] (0x0040): add_v1_user_data failed.
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.


The last three lines tipped off a colleague who was debugging why this
userA couldn't login to anything.

Since then we have created IPA over rides for the groups with @ symbols in
them. This also works as a solution. It's not our preferred solution, but
we are users, not managers, of the AD system.

Cheers

L.





--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project