[SSSD-users] Re: case sensitive email

[Sumit Bose]

On Fri, Nov 10, 2017 at 02:53:55PM +, Galen Johnson wrote:
> ?Hey,
> 
> 
> We've recently noticed that users logging in using emails are having issues 
> when they use camel case but it works fine when all lower case.  We haven't 
> changed the configs so
> 
> 
> case_sensitive = preserving?
> 
> 
> has not changed.  Could the behavior have changed with a recent update.  We 
> are running version 1.15.2 (sssd-1.15.2-50.el7_4.6.x86_64?).  This did not 
> used to be the behavior.  Is there some other config that we now need to 
> enable to allow the previous behavior?

Would it be possible to send sssd_pam.log and sssd_DOMAIN.log with
debug_level=10 for a login attempt with camel case?

bye,
Sumit

> 
> 
> thanks
> 
> 
> =G=

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

[SSSD-users] Re: case sensitive email

[Galen Johnson]

It's possible that whatever is causing this is in the nss module since it 
appears that the lowercase address is found where mixed case is not. Previous 
comment pertained to domain logs.  Just browsed the nss log.  Still stymied...


=G=



From: Galen Johnson
Sent: Monday, November 13, 2017 7:36 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: case sensitive email


Ignore the comment about the query missing.  I started fresh and see the same 
query where the only difference is the case...however, where the mixed case 
fails, the lowcase continues.  Even at debug level 10 I'm not seeing anything 
obvious as to why it moves on for the lowcase example.  Up to that point the 
logs are essentially identical.


I'm stymied.


=G=



From: Galen Johnson
Sent: Monday, November 13, 2017 6:52 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: case sensitive email


I've done a bit more digging and sssd handles the request differently when it's 
mixed case versus all lowercase...when it's mixed case, I see this search 
string in the logs


(Mon Nov 13 22:50:11:092700 2017) [sssd[be[exnet]]] [sdap_get_generic_ext_step] 
(0x0400): calling ldap_search_ext with 
[(&(|(krbPrincipalName=us...@example.com)(mail=us...@my.domain.com)(krbPrincipalName=User1\\@example@my.domain.com))(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0][ou=users,ou=production,ou=Customers,dc=my,dc=domain,dc=com].


but when it's all lowcase it seems to go down a completely different path as I 
never see that sdap_get_generic_ext_step? for it...


Why would changing the login case cause this behavior?


Note: auth_provider, id_provider, and access_provider are all set to ldap.  Not 
sure why krbPrincipalName is even showing in the ldap search...however, if I 
remove the krb properties from sssd.conf, then email doesn't work at all.  This 
used to work.  The only thing that has changed that I am aware of is the 
version of SSSD on the system.


=G=



From: Galen Johnson
Sent: Friday, November 10, 2017 9:53 AM
To: End-user discussions about the System Security Services Daemon
Subject: case sensitive email


?Hey,


We've recently noticed that users logging in using emails are having issues 
when they use camel case but it works fine when all lower case.  We haven't 
changed the configs so


case_sensitive = preserving?


has not changed.  Could the behavior have changed with a recent update.  We are 
running version 1.15.2 (sssd-1.15.2-50.el7_4.6.x86_64?).  This did not used to 
be the behavior.  Is there some other config that we now need to enable to 
allow the previous behavior?


thanks


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

[SSSD-users] Re: case sensitive email

[Galen Johnson]

Ignore the comment about the query missing.  I started fresh and see the same 
query where the only difference is the case...however, where the mixed case 
fails, the lowcase continues.  Even at debug level 10 I'm not seeing anything 
obvious as to why it moves on for the lowcase example.  Up to that point the 
logs are essentially identical.


I'm stymied.


=G=



From: Galen Johnson
Sent: Monday, November 13, 2017 6:52 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: case sensitive email


I've done a bit more digging and sssd handles the request differently when it's 
mixed case versus all lowercase...when it's mixed case, I see this search 
string in the logs


(Mon Nov 13 22:50:11:092700 2017) [sssd[be[exnet]]] [sdap_get_generic_ext_step] 
(0x0400): calling ldap_search_ext with 
[(&(|(krbPrincipalName=us...@example.com)(mail=us...@my.domain.com)(krbPrincipalName=User1\\@example@my.domain.com))(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0][ou=users,ou=production,ou=Customers,dc=my,dc=domain,dc=com].


but when it's all lowcase it seems to go down a completely different path as I 
never see that sdap_get_generic_ext_step? for it...


Why would changing the login case cause this behavior?


Note: auth_provider, id_provider, and access_provider are all set to ldap.  Not 
sure why krbPrincipalName is even showing in the ldap search...however, if I 
remove the krb properties from sssd.conf, then email doesn't work at all.  This 
used to work.  The only thing that has changed that I am aware of is the 
version of SSSD on the system.


=G=



From: Galen Johnson
Sent: Friday, November 10, 2017 9:53 AM
To: End-user discussions about the System Security Services Daemon
Subject: case sensitive email


?Hey,


We've recently noticed that users logging in using emails are having issues 
when they use camel case but it works fine when all lower case.  We haven't 
changed the configs so


case_sensitive = preserving?


has not changed.  Could the behavior have changed with a recent update.  We are 
running version 1.15.2 (sssd-1.15.2-50.el7_4.6.x86_64?).  This did not used to 
be the behavior.  Is there some other config that we now need to enable to 
allow the previous behavior?


thanks


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

[SSSD-users] Re: case sensitive email

[Galen Johnson]

I've done a bit more digging and sssd handles the request differently when it's 
mixed case versus all lowercase...when it's mixed case, I see this search 
string in the logs


(Mon Nov 13 22:50:11:092700 2017) [sssd[be[exnet]]] [sdap_get_generic_ext_step] 
(0x0400): calling ldap_search_ext with 
[(&(|(krbPrincipalName=us...@example.com)(mail=us...@my.domain.com)(krbPrincipalName=User1\\@example@my.domain.com))(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0][ou=users,ou=production,ou=Customers,dc=my,dc=domain,dc=com].


but when it's all lowcase it seems to go down a completely different path as I 
never see that sdap_get_generic_ext_step? for it...


Why would changing the login case cause this behavior?


Note: auth_provider, id_provider, and access_provider are all set to ldap.  Not 
sure why krbPrincipalName is even showing in the ldap search...however, if I 
remove the krb properties from sssd.conf, then email doesn't work at all.  This 
used to work.  The only thing that has changed that I am aware of is the 
version of SSSD on the system.


=G=



From: Galen Johnson
Sent: Friday, November 10, 2017 9:53 AM
To: End-user discussions about the System Security Services Daemon
Subject: case sensitive email


?Hey,


We've recently noticed that users logging in using emails are having issues 
when they use camel case but it works fine when all lower case.  We haven't 
changed the configs so


case_sensitive = preserving?


has not changed.  Could the behavior have changed with a recent update.  We are 
running version 1.15.2 (sssd-1.15.2-50.el7_4.6.x86_64?).  This did not used to 
be the behavior.  Is there some other config that we now need to enable to 
allow the previous behavior?


thanks


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

[SSSD-users] Re: net groups with IPA

[Alexander Bokovoy]

On ma, 13 marras 2017, Charles Hedrick wrote:

While we’re on this subject, it would be useful for IPA to support
netgroup.byhost. That would give signifiant advantages with Netapp. If
that is supported, Netapp will look up the netgroups for a host every
time a mount is done. Without it, they consider that reloading the
whole net group file is too inefficient, so they depend upon a cache
whose normal TTL is a day.

I'm confused here.

We have:
- LDAP: native netgroups in IPA, used by SSSD IPA provider directly
- LDAP: compatibility tree that exposes native IPA netgroups as RFC2307bis
  objects with no way to set blank nisDomainName right now
- NIS protocol: NIS triplets generated based on the compat tree
  netgroups.

The latter provides three netgroup maps:
- netgroup
- netgroup.byhost
- netgroup.byuser

The are already exist but both netgroup.byhost and netgroup.byuser are
not utilized by glibc, so they may have regressed (I see them defined in
the code).

Which of the implementation do you use? Did you configure your Netapp
filer to look up LDAP in cn=ng,cn=compat,$SUFFIX or is it using NIS
protocol?





On Nov 13, 2017, at 4:25 AM, Pavel Březina  wrote:

On 11/08/2017 11:47 PM, Charles Hedrick wrote:

In my opinion the whole rfc3704bis implementation of net groups is wonky.

This isn’t the only problem. Why is there a distinction between internal and 
external hosts? Suppose I add an external host to a net group, and later do ipa 
host-add for it. If the distinction actually matters I’d expect the system to 
turn the external host entry into an internal host entry. But it doesn’t.

In principle there’s a difference between blank and -, but the ipa 
implementation always produces - for missing user and host and blank for 
missing domain name.

I’d really rather see the system just store the triples rather than doing a 
complex mapping going in and out.



On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:

Pavel, does this sound like the bug you were looking at wrt sudo lately?

On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:

Netapp wants the domain field to be blank. That leaves us a problem that’s hard 
to solve.

On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
> wrote:

OK, I see what’s going on, but it looks like a bug.

We mostly use net groups for hosts. In NIS our entries like like (hostname,,)  
You can put that into IPA by specifying NISdomain=, i.e. blank domain name. 
However if you do that, getent shows no entries. That is, entries with blank 
hostname are ignored. I claim this is a bug, since for a host entry there’s no 
reason to specify a domain.

I also found that specifying

ipa_netgroup_domain=cs.rutgers.edu

causes no net groups to display, even ones whose domain is 
cs.rutgers.edu.
 This also looks like a bug.

On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
> wrote:

We want to move our net groups from NIS to IPA. I’ve loaded the groups. They’re 
visible on a system that uses nslcd pointed at the IPA server. But the systems 
that use SSSD for authentication don’t show anything. The net groups all show 
as undefined.

I’ve turned on debugging and looked at the LDAP logs. It does the right quotes 
and the log says it extracts the members. But they don’t show up.

Any idea where to look?


Can you send us some example of what you are trying to achieve and what does 
not work? I'm also ccing Alexander Bokovoy to see why IPA adds somewhere dash 
and somewhere blanks.





--
/ Alexander Bokovoy
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: net groups with IPA

[Alexander Bokovoy]

On ma, 13 marras 2017, Charles Hedrick wrote:

Sure. We use netgroups for /etc/exports. The most natural format for triples is

(host,,)

That’s the format Netapp documents. By default, ipa netgroup-add-member uses

(host,-,domain)

where domain seems to come from our Kerberos domain. Netapp
documentation requests leaving that field blank, though some
documentation suggests that if it’s filled in, they will ignore triples
where the domain doesn’t match the Netapp’s domain. We are no longer
using NIS, so as far as we know, the Netapp doesn’t have a NIS domain.
I think it’s safest to leave the field blank.

IPA sets NIS domain by default to its primary domain (equal to IPA
realm in lower case). This is just a default value.


I can do this in IPA. —nisdomain= will leave it blank. That results in

(host,-,)

That works with the Netapp. (I haven’t actually tried putting a domain in.)

Unfortunately it won’t work with sssd, because sssd won’t show any
triples if the nisdomain isn’t set for that net group.

So, the real issue is SSSD's inability to support empty netgroup domain
part, right?

This is the code in ipa_netgr_process_all():
...
   ret = sysdb_attrs_get_string(state->netgroups[i], SYSDB_NETGROUP_DOMAIN,
);
   if (ret != EOK) {
   goto done;
   }
...

   DEBUG(SSSDBG_TRACE_INTERNAL, "Putting together triples of "
 "netgroup %d\n", i);
   for (j = 0; j < uids_count; j++) {
   for (k = 0; k < hosts_count; k++) {
   triple = talloc_asprintf(state, "(%s,%s,%s)",
hosts[k], uids[j],
domain);
   if (triple == NULL) {
   ret = ENOMEM;
   goto done;
   }

   ret = sysdb_attrs_add_string(state->netgroups[i],
SYSDB_NETGROUP_TRIPLE,
triple);
   if (ret != EOK) {
   goto done;
   }
   }
   }


So, if no domain is retrieved, no netgroup triple is generated by SSSD
IPA provider. Note that this does not utilize compatibility netgroups
subtree as generated by schema compatibility plugin (in
cn=ng,cn=compat,$SUFFIX) but instead works directly with IPA netgroups.

So our discussion about RFC2307bis is not really applicable here. If we
consider the use case with a blank nisDomainName a valid one (and I
think we can consider it), the code above needs to be fixed to allow
such use. It is a fairly simple fix.


In general I don’t understand why IPA and sssd are using a nonstandard
representation of net groups. Why not just a collection of triples and
subgroups? As far as I can see RFC 2307bis has the same schema for net
groups as RFC 2307.
https://tools.ietf.org/html/draft-howard-rfc2307bis-02. Is there a
later version of RFC 2307bis that I haven’t been able to find? Draft 2
is the latest at tools.ietf.org.

  ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
DESC 'Abstraction of a netgroup. May refer to other
  netgroups'
MUST cn
MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )

The representation used by IPA seems to be non-standard. I’d expect IPA
and sssd to allow me to add any triple I want that’s valid in a normal
net group file.

You can read (old) explanation on why IPA has schema as it has:
https://www.freeipa.org/page/FreeIPAv2:DS_Design_Summary#Netgroups



One problem with the IPA representation is that there are no actual
triples. There’s a list of hosts, a list of users, and a domain. Not
all triples can be represented that way. Something like (host1, user1,)
(host2, user2,)
has to be represented by a user list of user1, user2 and a host list of
host1, host2. But the pairing isn’t always well defined. E.g. I added
to that group an external host3 and an internal user3. I ended up with

(host3, user1,)
(host1, user2,)
(host2, user3,)

I don’t know whether there are applications that use the pairing of
hosts and users, but the original design was intended to support that.
With IPA it’s dangerous, because I have to know just how IPA generates
the triples from the entires.

Frankly speaking, original RFC2307bis design had very little explanation
on the actual semantics. It just listed attributes and demonstrated
their use in examples. Actual semantical meaning wasn't defined.

In addition, NIS and NIS+ never had any RFC defined for them.


Is there a way to get the RFC-defined behavior from IPA and SSSD?

Can you point me to what you call RFC-defined behavior? Because I don't
see RFC defining a behavior but rather a storage format (which is
suboptimal but that's another story).



We don’t actually have a user case for pairing. We just need a host
list. So for 

[SSSD-users] Re: net groups with IPA

[Alexander Bokovoy]

On ma, 13 marras 2017, Charles Hedrick wrote:

So, the real issue is SSSD's inability to support empty netgroup domain
part, right?


Yes, that’s the real bug. It doesn’t appear that the other issues are
serious, as I can’t find any real appiication that uses the NIS entries
as triples.

The sssd problem is moderately serious for me. I don’t want to put in
an arbitrary NIS domain name for a system that doesn’t use NIS, because
even if it works on the Netapp now, I’d be depending upon undocumented
behavior or I’d have to give it a dummy NIS domain. I’m reluctant to
tell the Netapp that it’s in a NIS domain that doesn’t exist. Who knows
what it would do?

It could also be an issue for transition. Consider a situation like
ours where we’re combining a number of NIS domains into a single IPA
domain. While we could work around it, it would be cleanest for our
netgroup entries not to have a domain name, so it’s clear that they
apply to all NIS domains. (In fact our transition has gone far enough
that this isn’t a real problem. We’re decommissioning NIS pretty
rapidly.)

Sure. Could you please file a bug about it (if not yet filed)?




Can you point me to what you call RFC-defined behavior? Because I don't
see RFC defining a behavior but rather a storage format (which is
suboptimal but that's another story).


I guess it depends upon how you understand the RFC. Clearly it doesn’t
matter how you store data as long as you present it to the application
the way the RFC specifies. But in fact an LDAP query simply presents it
as stored. So you have to use the compat tree to get the defined
results. Even there, there are triples that would be valid under the
RFC that you can’t generate. I agree that there may be no actual
applications that would do it, but that doesn’t seem like something you
want your directory services dictating.

In principle according to the documentation we could write an
application that checks access using both user and host from a triple.
E.g.

(host1, user1, domain1)

would authorize applications running in domain1 to accept login from
user1@host1. You can’t reliably generate triples like that, because the
association between user and host isn’t stored. You can fake it, but
the first time a host is removed, or for mixes of internal and external
hosts, you’ll get unexpected behavior.

Not sure why you keep saying that.

# ipa netgroup-add netgroup-foo  --nisdomain=xs.ipa.cool
-
Added netgroup "netgroup-foo"
-
 Netgroup name: netgroup-foo
 NIS domain name: xs.ipa.cool
 IPA unique ID: dafcbb66-c89a-11e7-b3e5-001a4a62eb77
# ipa netgroup-add-member netgroup-foo --users=ab --hosts=raup
 Netgroup name: netgroup-foo
 NIS domain name: xs.ipa.cool
 Member User: ab
 Member Host: raup.xs.ipa.cool
-
Number of members added 2
-


# ldapsearch -x -b cn=ng,cn=compat,dc=xs,dc=ipa,dc=cool  cn=netgroup-foo
dn: cn=netgroup-foo,cn=ng,cn=compat,dc=xs,dc=ipa,dc=cool
objectClass: nisNetgroup
objectClass: top
nisNetgroupTriple: (raup.xs.ipa.cool,ab,xs.ipa.cool)
cn: netgroup-foo

As you can see, there is a pretty standard for IPA way of creating an
object and adding members to it. Many other types of objects follow the
same approach. More to that, compat tree in LDAP has exactly what you
want.

Was it unclear to you that 'ipa netgroup-add-member' is the command to
use? See 'ipa help netgroup' for details on all commands we have about
netgroups.


Since no known applications uses this, it’s probably not a serious bug,
but I wouldn’t have created a design that disallows it.


On Nov 13, 2017, at 11:44 AM, Alexander Bokovoy  wrote:

On ma, 13 marras 2017, Charles Hedrick wrote:

Sure. We use netgroups for /etc/exports. The most natural format for triples is

(host,,)

That’s the format Netapp documents. By default, ipa netgroup-add-member uses

(host,-,domain)

where domain seems to come from our Kerberos domain. Netapp
documentation requests leaving that field blank, though some
documentation suggests that if it’s filled in, they will ignore triples
where the domain doesn’t match the Netapp’s domain. We are no longer
using NIS, so as far as we know, the Netapp doesn’t have a NIS domain.
I think it’s safest to leave the field blank.

IPA sets NIS domain by default to its primary domain (equal to IPA
realm in lower case). This is just a default value.


I can do this in IPA. —nisdomain= will leave it blank. That results in

(host,-,)

That works with the Netapp. (I haven’t actually tried putting a domain in.)

Unfortunately it won’t work with sssd, because sssd won’t show any
triples if the nisdomain isn’t set for that net group.

So, the real issue is SSSD's inability to support empty netgroup domain
part, right?

This is the code in ipa_netgr_process_all():
...
  ret = sysdb_attrs_get_string(state->netgroups[i], SYSDB_NETGROUP_DOMAIN,
   );
  if (ret != 

[SSSD-users] Re: [SSSD] SSSD Virtual Test Suite

[Fabiano Fidêncio]

On Mon, Nov 13, 2017 at 11:16 AM, Pavel Březina  wrote:
> Hello,
>
> It took me a lot longer than I expected but here it is at last. This is my
> set of scripts that use vagrant and Ansible to automatically provision
> virtual environment that I use to develop and test SSSD.
>
> To create this environment you only need to run one command:
> $ ./setup.sh
>
> and after a while you have several machines provisioned and ready. This
> machines include LDAP, IPA and AD servers with one machine dedicated to
> SSSD. This machine is already enrolled to those servers.
>
> To start building and/or testing SSSD with all available providers, you can
> just run:
> $ vagrant ssh client
>
> Additionally, it allows you to automatically source your set of scripts on
> each login and access IPA web-ui from your browser.
>
> I tried to make the provisioning as fast as possible but it still takes
> approximately one hour on my machine. So be patient.
>
> Any ideas and patches for improvements are welcomed.
>
>
> The source is available at:
> https://github.com/pbrezina/sssd-test-suite


Okay, I've found some small issues related to the readme and some few
annoyances while trying to run the scripts.

For the former, I'll open some PRs. For the latter, it's worth to
discuss what's your preference/understand better the requirements:

1) Why do have to run the script as root? AFAIU there's some way to
escalate privileges when running an Ansible script (example, running
sudo whenever it's needed). Is that something desired?

2) Restarting NetworkManager is quite intrusive, mainly without any
kind of warning.

3) Why do we need Vagrant 2.0 as the minimum version?

4) The guide was written for Fedora systems ... what's the reason to
choose Fedora over CentOS?

It will take a long time to download all the vagrant images, but I'll
get back here with the feedback as soon as this process is over.

Amazing initiative! Thanks a lot, Pavel!


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

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

> On Nov 13, 2017, at 12:51 PM, Alexander Bokovoy  wrote:
> 
> Not sure why you keep saying that.


Your example showed only one entry. Suppose I want to generate 

(host1, user1,)
(host2, user2,)

I can use 

ipa netgroup-add-member —hosts=host1 —users=user1
ipa netgroup-add-member —hosts=host2 —users=user2

But the results aren’t always as expected


Failure mode 1: deleting a host

ipa netgroup-add-member testng --hosts=www.rutgers.edu --users=hedrick
ipa netgroup-add-member testng --hosts=c217.cs.rutgers.edu --users=clh

nisNetgroupTriple: (www.rutgers.edu,hedrick,cs.rutgers.edu)
nisNetgroupTriple: (c217.cs.rutgers.edu,clh,cs.rutgers.edu)

ipa host-del www.rutgers.edu

nisNetgroupTriple: (c217.cs.rutgers.edu,hedrick,cs.rutgers.edu)
nisNetgroupTriple: (-,clh,cs.rutgers.edu)

Note that hedrick is now paired with c217, not www.


Failure mode 2: external host mixed with internal

ipa netgroup-add-member testng --users=dsmith --hosts=rci.rutgers.edu

nisNetgroupTriple: (rci.rutgers.edu,hedrick,cs.rutgers.edu)
nisNetgroupTriple: (c217.cs.rutgers.edu,clh,cs.rutgers.edu)
nisNetgroupTriple: (-,dsmith,cs.rutgers.edu)

Probably not what I intended. The problem is that external hosts are shown 
first, while the user is added last.

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

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

The netapp is using LDAP with RFC2307 for all name service. That include users, 
groups, and netgroups.

What they are asking for is for LDAP to implement netgroup.byhost. It appears 
that AD does this. As far as I can tell, they are looking for 
nisMapName=netgroup.byhost accessed via LDAP.

I hadn’t thought about asking IPA to emulate NIS. If that would efficiently 
implement the netgroup.byhost NIS map, maybe it’s the way to go. We don’t 
currently have NIS enabled for the netapp. We’re using RFC2307 for users and 
groups. Netapp supports ns-switch, so it sounds like we could use NIS for just 
netgroups. Is that what you’d suggest?

> On Nov 13, 2017, at 12:15 PM, Alexander Bokovoy  wrote:
> 
> On ma, 13 marras 2017, Charles Hedrick wrote:
>> While we’re on this subject, it would be useful for IPA to support
>> netgroup.byhost. That would give signifiant advantages with Netapp. If
>> that is supported, Netapp will look up the netgroups for a host every
>> time a mount is done. Without it, they consider that reloading the
>> whole net group file is too inefficient, so they depend upon a cache
>> whose normal TTL is a day.
> I'm confused here.
> 
> We have:
> - LDAP: native netgroups in IPA, used by SSSD IPA provider directly
> - LDAP: compatibility tree that exposes native IPA netgroups as RFC2307bis
>  objects with no way to set blank nisDomainName right now
> - NIS protocol: NIS triplets generated based on the compat tree
>  netgroups.
> 
> The latter provides three netgroup maps:
> - netgroup
> - netgroup.byhost
> - netgroup.byuser
> 
> The are already exist but both netgroup.byhost and netgroup.byuser are
> not utilized by glibc, so they may have regressed (I see them defined in
> the code).
> 
> Which of the implementation do you use? Did you configure your Netapp
> filer to look up LDAP in cn=ng,cn=compat,$SUFFIX or is it using NIS
> protocol?
> 
>> 
>> 
>>> On Nov 13, 2017, at 4:25 AM, Pavel Březina  wrote:
>>> 
>>> On 11/08/2017 11:47 PM, Charles Hedrick wrote:
 In my opinion the whole rfc3704bis implementation of net groups is wonky.
 
 This isn’t the only problem. Why is there a distinction between internal 
 and external hosts? Suppose I add an external host to a net group, and 
 later do ipa host-add for it. If the distinction actually matters I’d 
 expect the system to turn the external host entry into an internal host 
 entry. But it doesn’t.
 
 In principle there’s a difference between blank and -, but the ipa 
 implementation always produces - for missing user and host and blank for 
 missing domain name.
 
 I’d really rather see the system just store the triples rather than doing 
 a complex mapping going in and out.
 
 
> On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:
> 
> Pavel, does this sound like the bug you were looking at wrt sudo lately?
> 
> On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:
>> Netapp wants the domain field to be blank. That leaves us a problem 
>> that’s hard to solve.
>> 
>> On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
>> > wrote:
>> 
>> OK, I see what’s going on, but it looks like a bug.
>> 
>> We mostly use net groups for hosts. In NIS our entries like like 
>> (hostname,,)  You can put that into IPA by specifying NISdomain=, i.e. 
>> blank domain name. However if you do that, getent shows no entries. That 
>> is, entries with blank hostname are ignored. I claim this is a bug, 
>> since for a host entry there’s no reason to specify a domain.
>> 
>> I also found that specifying
>> 
>> ipa_netgroup_domain=cs.rutgers.edu
>> 
>> causes no net groups to display, even ones whose domain is 
>> cs.rutgers.edu.
>>  This also looks like a bug.
>> 
>> On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
>> > wrote:
>> 
>> We want to move our net groups from NIS to IPA. I’ve loaded the groups. 
>> They’re visible on a system that uses nslcd pointed at the IPA server. 
>> But the systems that use SSSD for authentication don’t show anything. 
>> The net groups all show as undefined.
>> 
>> I’ve turned on debugging and looked at the LDAP logs. It does the right 
>> quotes and the 

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

> So, the real issue is SSSD's inability to support empty netgroup domain
> part, right?

Yes, that’s the real bug. It doesn’t appear that the other issues are serious, 
as I can’t find any real appiication that uses the NIS entries as triples.

The sssd problem is moderately serious for me. I don’t want to put in an 
arbitrary NIS domain name for a system that doesn’t use NIS, because even if it 
works on the Netapp now, I’d be depending upon undocumented behavior or I’d 
have to give it a dummy NIS domain. I’m reluctant to tell the Netapp that it’s 
in a NIS domain that doesn’t exist. Who knows what it would do?

It could also be an issue for transition. Consider a situation like ours where 
we’re combining a number of NIS domains into a single IPA domain. While we 
could work around it, it would be cleanest for our netgroup entries not to have 
a domain name, so it’s clear that they apply to all NIS domains. (In fact our 
transition has gone far enough that this isn’t a real problem. We’re 
decommissioning NIS pretty rapidly.)

> Can you point me to what you call RFC-defined behavior? Because I don't
> see RFC defining a behavior but rather a storage format (which is
> suboptimal but that's another story).

I guess it depends upon how you understand the RFC. Clearly it doesn’t matter 
how you store data as long as you present it to the application the way the RFC 
specifies. But in fact an LDAP query simply presents it as stored. So you have 
to use the compat tree to get the defined results. Even there, there are 
triples that would be valid under the RFC that you can’t generate. I agree that 
there may be no actual applications that would do it, but that doesn’t seem 
like something you want your directory services dictating.

In principle according to the documentation we could write an application that 
checks access using both user and host from a triple. E.g. 

(host1, user1, domain1)

would authorize applications running in domain1 to accept login from 
user1@host1. You can’t reliably generate triples like that, because the 
association between user and host isn’t stored. You can fake it, but the first 
time a host is removed, or for mixes of internal and external hosts, you’ll get 
unexpected behavior.

Since no known applications uses this, it’s probably not a serious bug, but I 
wouldn’t have created a design that disallows it.

> On Nov 13, 2017, at 11:44 AM, Alexander Bokovoy  wrote:
> 
> On ma, 13 marras 2017, Charles Hedrick wrote:
>> Sure. We use netgroups for /etc/exports. The most natural format for triples 
>> is
>> 
>> (host,,)
>> 
>> That’s the format Netapp documents. By default, ipa netgroup-add-member uses
>> 
>> (host,-,domain)
>> 
>> where domain seems to come from our Kerberos domain. Netapp
>> documentation requests leaving that field blank, though some
>> documentation suggests that if it’s filled in, they will ignore triples
>> where the domain doesn’t match the Netapp’s domain. We are no longer
>> using NIS, so as far as we know, the Netapp doesn’t have a NIS domain.
>> I think it’s safest to leave the field blank.
> IPA sets NIS domain by default to its primary domain (equal to IPA
> realm in lower case). This is just a default value.
> 
>> I can do this in IPA. —nisdomain= will leave it blank. That results in
>> 
>> (host,-,)
>> 
>> That works with the Netapp. (I haven’t actually tried putting a domain in.)
>> 
>> Unfortunately it won’t work with sssd, because sssd won’t show any
>> triples if the nisdomain isn’t set for that net group.
> So, the real issue is SSSD's inability to support empty netgroup domain
> part, right?
> 
> This is the code in ipa_netgr_process_all():
> ...
>   ret = sysdb_attrs_get_string(state->netgroups[i], SYSDB_NETGROUP_DOMAIN,
>);
>   if (ret != EOK) {
>   goto done;
>   }
> ...
> 
>   DEBUG(SSSDBG_TRACE_INTERNAL, "Putting together triples of "
> "netgroup %d\n", i);
>   for (j = 0; j < uids_count; j++) {
>   for (k = 0; k < hosts_count; k++) {
>   triple = talloc_asprintf(state, "(%s,%s,%s)",
>hosts[k], uids[j],
>domain);
>   if (triple == NULL) {
>   ret = ENOMEM;
>   goto done;
>   }
> 
>   ret = sysdb_attrs_add_string(state->netgroups[i],
>SYSDB_NETGROUP_TRIPLE,
>triple);
>   if (ret != EOK) {
>   goto done;
>   }
>   }
>   }
> 
> 
> So, if no domain is retrieved, no netgroup triple is generated by SSSD
> IPA provider. Note that this does not utilize compatibility netgroups
> subtree as generated by schema compatibility plugin (in
> 

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

I just looked at documentation and source code. All the documentation I can 
find for netgroups leaves the semantics up to the application. The net group 
documentation does, however, imply that we’re dealing with a set of triples, 
not separate host and user lists. I checked the source for both openssh and bsd 
rlogin. For them it appears that they ignore the pairing and treat the net 
group as a list of hosts and users. 

I don’t see how you could prove that there are no applications that use all the 
documented capabilities of netgroups, but the most likely two possibilities 
don’t. 

rlogin ignores triples that aren’t in the current NIS domain (or blank, 
presumably). sshd ignores the domain component.

> On Nov 13, 2017, at 4:25 AM, Pavel Březina  wrote:
> 
> On 11/08/2017 11:47 PM, Charles Hedrick wrote:
>> In my opinion the whole rfc3704bis implementation of net groups is wonky.
>> 
>> This isn’t the only problem. Why is there a distinction between internal and 
>> external hosts? Suppose I add an external host to a net group, and later do 
>> ipa host-add for it. If the distinction actually matters I’d expect the 
>> system to turn the external host entry into an internal host entry. But it 
>> doesn’t.
>> 
>> In principle there’s a difference between blank and -, but the ipa 
>> implementation always produces - for missing user and host and blank for 
>> missing domain name.
>> 
>> I’d really rather see the system just store the triples rather than doing a 
>> complex mapping going in and out.
>> 
>> 
>>> On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:
>>> 
>>> Pavel, does this sound like the bug you were looking at wrt sudo lately?
>>> 
>>> On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:
 Netapp wants the domain field to be blank. That leaves us a problem that’s 
 hard to solve.
 
 On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
 > wrote:
 
 OK, I see what’s going on, but it looks like a bug.
 
 We mostly use net groups for hosts. In NIS our entries like like 
 (hostname,,)  You can put that into IPA by specifying NISdomain=, i.e. 
 blank domain name. However if you do that, getent shows no entries. That 
 is, entries with blank hostname are ignored. I claim this is a bug, since 
 for a host entry there’s no reason to specify a domain.
 
 I also found that specifying
 
 ipa_netgroup_domain=cs.rutgers.edu
 
 causes no net groups to display, even ones whose domain is 
 cs.rutgers.edu.
  This also looks like a bug.
 
 On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
 > wrote:
 
 We want to move our net groups from NIS to IPA. I’ve loaded the groups. 
 They’re visible on a system that uses nslcd pointed at the IPA server. But 
 the systems that use SSSD for authentication don’t show anything. The net 
 groups all show as undefined.
 
 I’ve turned on debugging and looked at the LDAP logs. It does the right 
 quotes and the log says it extracts the members. But they don’t show up.
 
 Any idea where to look?
> 
> Can you send us some example of what you are trying to achieve and what does 
> not work? I'm also ccing Alexander Bokovoy to see why IPA adds somewhere dash 
> and somewhere blanks.
> 

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

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

While we’re on this subject, it would be useful for IPA to support 
netgroup.byhost. That would give signifiant advantages with Netapp. If that is 
supported, Netapp will look up the netgroups for a host every time a mount is 
done. Without it, they consider that reloading the whole net group file is too 
inefficient, so they depend upon a cache whose normal TTL is a day.


> On Nov 13, 2017, at 4:25 AM, Pavel Březina  wrote:
> 
> On 11/08/2017 11:47 PM, Charles Hedrick wrote:
>> In my opinion the whole rfc3704bis implementation of net groups is wonky.
>> 
>> This isn’t the only problem. Why is there a distinction between internal and 
>> external hosts? Suppose I add an external host to a net group, and later do 
>> ipa host-add for it. If the distinction actually matters I’d expect the 
>> system to turn the external host entry into an internal host entry. But it 
>> doesn’t.
>> 
>> In principle there’s a difference between blank and -, but the ipa 
>> implementation always produces - for missing user and host and blank for 
>> missing domain name.
>> 
>> I’d really rather see the system just store the triples rather than doing a 
>> complex mapping going in and out.
>> 
>> 
>>> On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:
>>> 
>>> Pavel, does this sound like the bug you were looking at wrt sudo lately?
>>> 
>>> On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:
 Netapp wants the domain field to be blank. That leaves us a problem that’s 
 hard to solve.
 
 On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
 > wrote:
 
 OK, I see what’s going on, but it looks like a bug.
 
 We mostly use net groups for hosts. In NIS our entries like like 
 (hostname,,)  You can put that into IPA by specifying NISdomain=, i.e. 
 blank domain name. However if you do that, getent shows no entries. That 
 is, entries with blank hostname are ignored. I claim this is a bug, since 
 for a host entry there’s no reason to specify a domain.
 
 I also found that specifying
 
 ipa_netgroup_domain=cs.rutgers.edu
 
 causes no net groups to display, even ones whose domain is 
 cs.rutgers.edu.
  This also looks like a bug.
 
 On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
 > wrote:
 
 We want to move our net groups from NIS to IPA. I’ve loaded the groups. 
 They’re visible on a system that uses nslcd pointed at the IPA server. But 
 the systems that use SSSD for authentication don’t show anything. The net 
 groups all show as undefined.
 
 I’ve turned on debugging and looked at the LDAP logs. It does the right 
 quotes and the log says it extracts the members. But they don’t show up.
 
 Any idea where to look?
> 
> Can you send us some example of what you are trying to achieve and what does 
> not work? I'm also ccing Alexander Bokovoy to see why IPA adds somewhere dash 
> and somewhere blanks.
> 

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

[SSSD-users] Re: net groups with IPA

[Charles Hedrick]

Sure. We use netgroups for /etc/exports. The most natural format for triples is

(host,,)

That’s the format Netapp documents. By default, ipa netgroup-add-member uses

(host,-,domain)

where domain seems to come from our Kerberos domain. Netapp documentation 
requests leaving that field blank, though some documentation suggests that if 
it’s filled in, they will ignore triples where the domain doesn’t match the 
Netapp’s domain. We are no longer using NIS, so as far as we know, the Netapp 
doesn’t have a NIS domain. I think it’s safest to leave the field blank.

I can do this in IPA. —nisdomain= will leave it blank. That results in

(host,-,)

That works with the Netapp. (I haven’t actually tried putting a domain in.)

Unfortunately it won’t work with sssd, because sssd won’t show any triples if 
the nisdomain isn’t set for that net group.

In general I don’t understand why IPA and sssd are using a nonstandard 
representation of net groups. Why not just a collection of triples and 
subgroups? As far as I can see RFC 2307bis has the same schema for net groups 
as RFC 2307. https://tools.ietf.org/html/draft-howard-rfc2307bis-02. Is there a 
later version of RFC 2307bis that I haven’t been able to find? Draft 2 is the 
latest at tools.ietf.org.

   ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
 DESC 'Abstraction of a netgroup. May refer to other
   netgroups'
 MUST cn
 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )

The representation used by IPA seems to be non-standard. I’d expect IPA and 
sssd to allow me to add any triple I want that’s valid in a normal net group 
file.

One problem with the IPA representation is that there are no actual triples. 
There’s a list of hosts, a list of users, and a domain. Not all triples can be 
represented that way. Something like
(host1, user1,)
(host2, user2,)
has to be represented by a user list of user1, user2 and a host list of host1, 
host2. But the pairing isn’t always well defined. E.g. I added to that group an 
external host3 and an internal user3. I ended up with

(host3, user1,)
(host1, user2,)
(host2, user3,)

I don’t know whether there are applications that use the pairing of hosts and 
users, but the original design was intended to support that. With IPA it’s 
dangerous, because I have to know just how IPA generates the triples from the 
entires.

Is there a way to get the RFC-defined behavior from IPA and SSSD?

We don’t actually have a user case for pairing. We just need a host list. So 
for the moment the plan is to add hosts with nisdomain=, and use nslcd in 
nsswitch.conf for net groups on the Linux systems that are NFS servers.

I don’t have any specific use case for distinguishing between space and -. But 
the spec says they mean something different. I don’t know why you would adopt a 
representation that doesn’t allow for every valid triple.


On Nov 13, 2017, at 4:25 AM, Pavel Březina 
> wrote:

Can you send us some example of what you are trying to achieve and what does 
not work? I'm also ccing Alexander Bokovoy to see why IPA adds somewhere dash 
and somewhere blanks.

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

[SSSD-users] Re: SSSD and SUDO not working

[Lukas Slebodnik]

On (13/11/17 11:20), Andrea Passuello wrote:
>Thanks all for the answers.
>
>This is the debug with level=10.
>
>
>(Mon Nov 13 10:35:40 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_dispatch]
>(0x4000): dbus conn: 0xe76180
>(Mon Nov 13 10:35:40 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_dispatch]
>(0x4000): Dispatching.
>(Mon Nov 13 10:35:40 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_message_handler]
>(0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path
>/org/freedesktop/sssd/service
>(Mon Nov 13 10:35:40 2017) [sssd[be[MYDOMAIN.COM]]]
>[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>
>==> sssd_sudo.log <==
>(Mon Nov 13 10:35:47 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle
>timer re-set for client [0x1f4b430][19]
>(Mon Nov 13 10:35:47 2017) [sssd[sudo]] [client_recv] (0x0200): Client
>disconnected!
>(Mon Nov 13 10:35:47 2017) [sssd[sudo]] [client_destructor] (0x2000):
>Terminated client [0x1f4b430][19]
>
>==> sssd_MYDOMAIN.COM.log <==
>(Mon Nov 13 10:35:50 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_dispatch]
>(0x4000): dbus conn: 0xe76180
>(Mon Nov 13 10:35:50 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_dispatch]
>(0x4000): Dispatching.
>(Mon Nov 13 10:35:50 2017) [sssd[be[MYDOMAIN.COM]]] [sbus_message_handler]
>(0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path
>/org/freedesktop/sssd/service
>(Mon Nov 13 10:35:50 2017) [sssd[be[MYDOMAIN.COM]]]
>[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>
>==> sssd_sudo.log <==
>(Mon Nov 13 10:35:50 2017) [sssd[sudo]] [sbus_dispatch] (0x4000): dbus
>conn: 0x1f3d6d0
>(Mon Nov 13 10:35:50 2017) [sssd[sudo]] [sbus_dispatch] (0x4000):
>Dispatching.
>(Mon Nov 13 10:35:50 2017) [sssd[sudo]] [sbus_message_handler] (0x2000):
>Received SBUS method org.freedesktop.sssd.service.ping on path
>/org/freedesktop/sssd/service
>(Mon Nov 13 10:35:50 2017) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000):
>Not a sysbus message, quit
>

You didn't provided sudo logs only sssd logs.

>
>This is the output of "sudo -l"
>
>$ sudo -l
>Matching Defaults entries for MYUSER on andrea-X550LA:
>env_reset, mail_badpass, secure_path=/usr/local/sbin\:/
>usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
>
>User MYUSER may run the following commands on andrea-X550LA:
>(root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
>(ALL : ALL)
>
OK,
sudo says that you are allowed to run some commands.
I cannot see any problem.

>
>
>My sudo version is 1.8.16, I think it should be quite up-to-date. Isn't it?
>
>
>If i check the MYUSER's groups I can see the SystemAdmin group that is the
>group I set in LDAP and it's referred by LDAP's sudoers.
>
>$ groups
>MYUSER adm cdrom dip plugdev lpadmin sambashare wireshark SystemAdmin
>
>
>
>This is the ldapsearch's output
>
>$ ldapsearch -H ldap://LDAPSERVER -b ou=sudoers,dc=MYDOMAIN,dc=COM -ZZ
>'(&(objectClass=sudoRole))' -x
># extended LDIF
>#
># LDAPv3
># base 

[SSSD-users] Re: net groups with IPA

[Alexander Bokovoy]

On ma, 13 marras 2017, Pavel Březina wrote:

On 11/08/2017 11:47 PM, Charles Hedrick wrote:

In my opinion the whole rfc3704bis implementation of net groups is
wonky.

RFC 3704bis does not exist. RFC3704 is about ingress filtering in
multihome networks. Are you talking about RFC 2307bis?


This isn’t the only problem. Why is there a distinction between
internal and external hosts? Suppose I add an external host to a net
group, and later do ipa host-add for it. If the distinction actually
matters I’d expect the system to turn the external host entry into an
internal host entry. But it doesn’t.

In principle there’s a difference between blank and -, but the ipa
implementation always produces - for missing user and host and blank
for missing domain name.

For hosts and users, if you specify hostCategory=all or
userCategory=all, there will be blanks in the generated
nisNetgroupTriple. 


For NIS domain name there is always either explicitly defined
nisDomainName or a '-'. Where did you see blanks for the nisDomainName?

Actual mapping rule looks like this:

schema-compat-entry-attribute: nisNetgroupTriple=(%link("%ifeq(\"hostCategory\
",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\"memberHo
st\\\",\\\"fqdn\\\")\\\",\\\"%deref_r(\\\"member\\\",
\\\"fqdn\\\")\\\",\\\"%deref_r(\\\"memberHost\\\",\\\"member\
\\",\\\"fqdn\\\")\\\")\")","%ifeq(\"hostCategory\",\"all\",\"\",\
"-\")",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\
"memberUser\\\",\\\"uid\\\")\\\",\\\"%deref_r(\\\"member\
\\",\\\"uid\\\")\\\",\\\"%deref_r(\\\"memberUser\\\",\\\"
member\\\",\\\"uid\\\")\\\")\")","%ifeq(\"userCategory\",\"all\",
\"\",\"-\")"),%{nisDomainName:-})

As you can see in the last part it includes %{nisDomainName:-}, e.g. if
attribute nisDomainName is not defined in the original IPA net group
object, it will be replaced by '-'.

So one way to solve this problem is by replacing the
"%{nisDomainName:-}" by a more complex expression, something that would
use some predefined nisDomainName to be a trigger to add a blank there.

Something like

%ifeq("nisDomainName","any","","%{nisDomainName:-}"

instead of %{nisDomainName:-}

In my case it looks like this:
# ipa netgroup-show my-new-netgroup
 Netgroup name: my-new-netgroup
 NIS domain name: any
 User category: all
 Host category: all

# ldapsearch -x -b cn=ng,cn=compat,$SUFFIX cn=my-new-netgroup
dn: cn=my-new-netgroup,cn=ng,cn=compat,$SUFFIX
objectClass: nisNetgroup
objectClass: top
nisNetgroupTriple: (,,)
cn: my-new-netgroup


I’d really rather see the system just store the triples rather than
doing a complex mapping going in and out.

IPA uses a different LDAP schema for net groups than what RFC2307bis expects.
Thus, a need to dynamically redefine LDAP objects (for whole RFC2307,
not just net groups).






On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:

Pavel, does this sound like the bug you were looking at wrt sudo lately?

On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:

Netapp wants the domain field to be blank. That leaves us a problem that’s hard 
to solve.

On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
> wrote:

OK, I see what’s going on, but it looks like a bug.

We mostly use net groups for hosts. In NIS our entries like like
(hostname,,)  You can put that into IPA by specifying NISdomain=,
i.e. blank domain name. However if you do that, getent shows no
entries. That is, entries with blank hostname are ignored. I claim
this is a bug, since for a host entry there’s no reason to specify a
domain.

I also found that specifying

ipa_netgroup_domain=cs.rutgers.edu

causes no net groups to display, even ones whose domain is
cs.rutgers.edu.
This also looks like a bug.

On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
> wrote:

We want to move our net groups from NIS to IPA. I’ve loaded the
groups. They’re visible on a system that uses nslcd pointed at the
IPA server. But the systems that use SSSD for authentication don’t
show anything. The net groups all show as undefined.

I’ve turned on debugging and looked at the LDAP logs. It does the
right quotes and the log says it extracts the members. But they
don’t show up.

Any idea where to look?


Can you send us some example of what you 

[SSSD-users] SSSD Virtual Test Suite

[Pavel Březina]

Hello,

It took me a lot longer than I expected but here it is at last. This is 
my set of scripts that use vagrant and Ansible to automatically 
provision virtual environment that I use to develop and test SSSD.


To create this environment you only need to run one command:
$ ./setup.sh

and after a while you have several machines provisioned and ready. This 
machines include LDAP, IPA and AD servers with one machine dedicated to

SSSD. This machine is already enrolled to those servers.

To start building and/or testing SSSD with all available providers, you 
can just run:

$ vagrant ssh client

Additionally, it allows you to automatically source your set of scripts 
on each login and access IPA web-ui from your browser.


I tried to make the provisioning as fast as possible but it still takes 
approximately one hour on my machine. So be patient.


Any ideas and patches for improvements are welcomed.

The source is available at:
https://github.com/pbrezina/sssd-test-suite
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org