[SSSD-users] Re: Announcing SSSD 1.16.2

[Jakub Hrozek]

On Tue, Jun 12, 2018 at 07:46:55PM +0200, Sumit Bose wrote:
> > > Hi,
> > > 
> > > please try to add the following patch and then to build SSSD again:
> > > 
> > > diff --git a/Makefile.am b/Makefile.am
> > > index 9539b3c..8e76a03 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -975,6 +975,7 @@ libsss_cert_la_LIBADD = \
> > >  $(TALLOC_LIBS) \
> > >  $(TEVENT_LIBS) \
> > >  libsss_crypt.la \
> > > +libsss_child.la \
> > >  libsss_debug.la \
> > >  libsss_certmap.la \
> > >  $(NULL)
> > > 
> > 
> > Builds for me.
> 
> Thanks for testing and the feedback.
> 
> > Will there be a new release now? if not, can you mail a "proper" patch ?
> 
> I will send a pull request to github with the patch. 

Can you also file a ticket, please?

> Since I originally
> had issues reproducing the error I just wanted to know if it really works
> in other environments as well.

Releasing a new tarball with minimal changes is not a lot of work, but
also does not come totally for free..maybe a couple of hours. 

But I would like to ask if the compilationa and linker options that break
the build for you are the default for your distribution?

Because if sssd doesn't build with the default flags some distributions
use (especially a major ones like suse..) then maybe we should do a
release. Otherwise I hope all packaging systems allow for some way of
adding a patch.

btw the Jenkins CI instance that we run internally at Red Hat tests
every commit on Fedora, RHEL and Debian. The github PRs also run CI on
CentOS...so we /do/ test builds on multiple distributions, but not all
of them..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/X7WOOKBCPXIYFUWFKMBEMODL63PJ6SYN/

[SSSD-users] Re: Files provider - does not start properly ?

[Jakub Hrozek]

I’m sorry, but I don’t see any attachment..

> On 12 Jun 2018, at 11:15, JOHE (John Hearns)  wrote:
> 
> Thankyou. Logs are attached.
> 
> 
> From: Jakub Hrozek 
> Sent: 12 June 2018 10:28:39
> To: End-user discussions about the System Security Services Daemon
> Subject: [SSSD-users] Re: Files provider - does not start properly ?
>  
> Yes, just please make sure they don’t contain some confidential data (host 
> names etc..)
> 
> > On 12 Jun 2018, at 10:09, JOHE (John Hearns)  wrote:
> > 
> > Hi Jakub. I have the logs available. What is the best way to upload?
> > I guess just attach them here as a reply!
> > From: Jakub Hrozek 
> > Sent: 11 June 2018 20:30:59
> > To: End-user discussions about the System Security Services Daemon
> > Subject: [SSSD-users] Re: Files provider - does not start properly ?
> >  
> > 
> > 
> > > On 11 Jun 2018, at 16:01, JOHE (John Hearns)  wrote:
> > > 
> > > I am trying out the files providerwith sssd version 16.1 on Ubuntu Xenial.
> > > 
> > > In the configuration file I set enable_files_domain = True
> > > 
> > > sssd_implicit_files.log then says :
> > > [sssd[be[implicit_files]]] [id_callback] (0x0010): The Monitor returned 
> > > an error [org.freedesktop.DBus.Error.NoReply]
> > 
> > Can you set the full set of logs, from both the domain log file and the 
> > sssd.log file? There was one user who reported issues with the files 
> > provider on fedora but we could never pin the issue down.
> > 
> > > 
> > > Any ideas please?
> > > 
> > > Also rather confusingly /etc/nsswitch.conf still has to be set with:  
> > >   passwd  files sss
> > 
> > Fedora switched the default to “sss files” in F-26. I wouldn’t recommend 
> > just “sss” because sssd doesn’t handle root by design (if sssd is 
> > misbehaving you really want to be able to log in as root to fix things..)
> > 
> > > The simpl eminded amongst us (me) thought that from the description of 
> > > the sssd files provider, the passwd and group file would be read at 
> > > startup, therefore all you would need is sss in the nsswitch.conf
> > > Clearly there is a huge hole of comprehension. Between my ears.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > > Fedora Code of Conduct: 
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetfedora.org%2Fcode-of-conduct.html=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285684196bb001%7C0=3sXxHlG6d%2F0qcJBmGBvuLABxprGJJbTqXeOLaT5HubM%3D=0
> > > List Guidelines: 
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285684196bb001%7C0=IORN3ztfDoKQx%2BSnGODR2Pm54UZNe6m1Y%2FcwI1w64iU%3D=0
> > > List Archives: 
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org%2Fmessage%2FZ45SFIFRWFRVXUBWV2OMMITLC4ODR6W4%2F=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285684196bb001%7C0=SZU9mFU7b8cEv%2BjhHz4RRQyqCsoHWUIrWiY0DYImnLc%3D=0
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct: 
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetfedora.org%2Fcode-of-conduct.html=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285684196bb001%7C0=3sXxHlG6d%2F0qcJBmGBvuLABxprGJJbTqXeOLaT5HubM%3D=0
> > List Guidelines: 
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285684196bb001%7C0=IORN3ztfDoKQx%2BSnGODR2Pm54UZNe6m1Y%2FcwI1w64iU%3D=0
> > List Archives: 
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org%2Fmessage%2FNG2XM5WHSK2EP3K5TLOLWYKHJF7IY6QV%2F=01%7C01%7Cjohe%40novozymes.com%7Cdccd8e054da24e7a72ac08d5cfc9829f%7C43d5f49ee03a4d22a2285

[SSSD-users] Re: Files provider - does not start properly ?

[Jakub Hrozek]

> On 11 Jun 2018, at 16:01, JOHE (John Hearns)  wrote:
> 
> I am trying out the files providerwith sssd version 16.1 on Ubuntu Xenial.
> 
> In the configuration file I set enable_files_domain = True
> 
> sssd_implicit_files.log then says :
> [sssd[be[implicit_files]]] [id_callback] (0x0010): The Monitor returned an 
> error [org.freedesktop.DBus.Error.NoReply]

Can you set the full set of logs, from both the domain log file and the 
sssd.log file? There was one user who reported issues with the files provider 
on fedora but we could never pin the issue down.

> 
> Any ideas please?
> 
> Also rather confusingly /etc/nsswitch.conf still has to be set with:  
>   passwd  files sss

Fedora switched the default to “sss files” in F-26. I wouldn’t recommend just 
“sss” because sssd doesn’t handle root by design (if sssd is misbehaving you 
really want to be able to log in as root to fix things..)

> The simpl eminded amongst us (me) thought that from the description of the 
> sssd files provider, the passwd and group file would be read at startup, 
> therefore all you would need is sss in the nsswitch.conf
> Clearly there is a huge hole of comprehension. Between my ears.
> 
> 
> 
> 
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/Z45SFIFRWFRVXUBWV2OMMITLC4ODR6W4/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/NG2XM5WHSK2EP3K5TLOLWYKHJF7IY6QV/

[SSSD-users] Re: sssd failing to lookup user/group names by ID

[Jakub Hrozek]

> On 1 Jun 2018, at 22:10, David Potterveld  wrote:
> 
> I'm not sure that we do need it…

Then removing the local domain is also a valid workaround for this issue.

> I think it was put in the config as a placeholder for old accounts on legacy 
> systems when deciding on how UID ranges should be mapped when we ultimately 
> migrate to a FreeIPA domain that trusts our AD forest. We're having some 
> issues getting permission from the AD managers to set up the required trust, 
> but that's another story. Until that's ironed out, we are joining systems to 
> the domain with "realm" using the  SID<->UID mapping that FreeIPA will use.
> 
> I've found a workaround for the bug for us. If I just comment out the 
> "max_id" line in domain/local, then everything goes back to normal. With only 
> a small number of IDs in local, and anything imported from legacy systems 
> well below the start of the SID mapping, I don't think we need to try and 
> enforce the upper limit.
> 
> Thanks,
> David
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/OITRMKTZYHHMUSO3O547HNKCM2GBXWAL/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/AE3VBXJM6JRF5R634WKVZMG5XTESTHMP/

[SSSD-users] Re: Nested LDAP groups and filtering

[Jakub Hrozek]

> On 2 Jun 2018, at 10:24, Christian Svensson  wrote:
> 
> Hi Jakub,
> 
> On Fri, Jun 1, 2018 at 6:52 PM, Jakub Hrozek  wrote:
> First, I’m sorry that I missed the e-mail in the moderation queue. We get a 
> fair amount of spam and things sometimes slip through.
> 
> No worries, I thought it would take some time when I got the manual 
> moderation message - I would have subscribed and re-sent if it would have 
> take much longer, no hard feelings :-).
>  
> 
> > On 20 May 2018, at 14:23, Christian Svensson  wrote:
> > 
> > Hi sssd-users,
> > 
> > My LDAP setup contains two bases:
> > dc=office1,dc=company,dc=tld
> > dc=office2,dc=company,dc=tld
> > 
> > Groups can cross-reference other groups in the two bases, like this:
> > cn=printer-access,ou=groups,dc=office1,dc=company,dc=tld
> > - member: cn=everybody,ou=groups,dc=office1,dc=company,dc=tld
> > - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld 
> > cn=printer-access,ou=groups,dc=office2,dc=company,dc=tld
> > - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld 
> > 
> > What I'm trying achieve is to have a server belonging to office1 being able 
> > to expand all groups, even if the references are across office boundary, 
> > but only see the leaf groups that are in its own base.
> > 
> > What I've tried is something like this:
> > [domain/office1]
> > debug_level = 9
> > enumerate = true
> > cache_credentials = true
> > entry_cache_timeout = 600
> > id_provider = ldap
> > auth_provider = ldap
> > chpass_provider = ldap
> > ldap_search_base = dc=company,dc=tld
> > ldap_group_search_base = dc=office1,dc=company,dc=tld
> > # Also tried with:
> > # ldap_group_search_base = dc=company,dc=tld?subtree?(dc:dn:=office1)
> > ldap_schema = rfc2307bis
> > ldap_group_member = member
> > ldap_group_nesting_level = 5
> > ldap_uri = ldaps://xxx
> > ldap_tls_reqcert = hard
> > ldap_tls_cacert = /etc/ssl/ldap-ca.crt
> > 
> > Sadly this does not work, which I'm not that surprised over. The lookup 
> > logic reports:
> > (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_save_grpmem] 
> > (0x0400): Adding member users to group [printer-access@office1]
> > (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_find_entry_by_origDN] 
> > (0x4000): Searching cache for 
> > [cn=everybody,ou=groups,dc=office2,dc=company,dc=tld].
> > (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_fill_memberships] 
> > (0x0080): Member [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld] was 
> > not found in cache. Is it out of scope?
> > 
> 
> > Looking at the way things are executed in code and logs it seems like there 
> > is no "post processing" to drop groups based on LDAP attributes, nor is 
> > there any way for me to add attributes to the full name of the resource to 
> > disambiguate them. Those are the two ways I've been attacking this, and 
> > both seems to not be supported.
> > 
> > Are my observations correct? Is there a workaround other than making sure 
> > groups have unique names across the whole company?
> > 
> > When groups are not colliding in name everything works just fine if I put " 
> > ldap_group_search_base =  dc=company,dc=tld", but I'd prefer if I could 
> > avoid having to resort to globally unique group names.
> > 
> > Thanks,
> > 
> > P.S. My groups are named differently and have been renamed in the log 
> > messages. Let me know if something doesn't make sense and I might have 
> > typo'd a replacement.
> 
> Yes, I must admit I got a bit confused. Is the issue related to both members 
> in your example having the same name? IOW, if you have “everybody” and 
> “nobody” in different subtrees, are those resolved correctly?
> 
> If I understand your question, yes - it's related to having the same name of 
> sorts, but only indirectly.
> The naive search base would be the common ancestor DN, which would be in this 
> example dc=company,dc=tld. Given that sssd-ldap says:
> "Note: It is unsupported to have multiple search bases which reference 
> identically-named objects (for example, groups with the same name in two 
> different search bases). This will lead to unpredictable behavior on client 
> machines.”

This is indeed not supported in SSSD because internally the users are all put 
into a flattened database where the DN of the object (the sssd database is 
LDAP-like) is something like cn=username,dc=groups,dc=$domain,dc=sysdb. So two 
objects with the same name would be stored with the same DN..

> that scares me a 

[SSSD-users] Re: Strange behaviour with groups

[Jakub Hrozek]

On Fri, Jun 01, 2018 at 11:31:55AM +, JOHE (John Hearns) wrote:
> I am seeing some very strange behaviour.
> 
> Very often when I issue the command 'groups   username' then only the local 
> groups in /etc/group are returned.
> 
> Issue the command again then the list with the local groups plus the AD 
> groups is returned.
> 
> In /etc/nsswitch.conf group:  files sss
> 
> I am altering the parameter ad_enable_gc to  False but this happened with is 
> set to True also.
> 
> 
> Any ideas please?

Not without logs that capture the issue, sorry.

See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XSOSASZDGEELE7EXD5Z3BYU24GTP7CEG/

[SSSD-users] Re: Strange behaviour with groups

[Jakub Hrozek]

> On 1 Jun 2018, at 15:10, John Hearns  wrote:
> 
> Jakub, a genuine thankyou for the response.
> 
> I have logs of course, at a high debug level. I find that they are very 
> verbose.
> Do you have a suggestion please as to 
> (a)  which of the logs to look at for this problem?  I guess sssd_nss.log

Yes, I normally try to note the time when an issue happens and look first into 
the sssd_nss log and then at the matching entries in the domain log.

> (b) any particular patterns I should look out for?

The “id” command translates into calling “initgroups”, so I would look into 
calls matching “initgr” in the logs.

By the way, you mentioned the user is a member of local groups. Is the user 
also present in passwd or only in LDAP?

> 
> 
> 
> On 1 June 2018 at 14:37, Jakub Hrozek  wrote:
> On Fri, Jun 01, 2018 at 11:31:55AM +, JOHE (John Hearns) wrote:
> > I am seeing some very strange behaviour.
> > 
> > Very often when I issue the command 'groups   username' then only the local 
> > groups in /etc/group are returned.
> > 
> > Issue the command again then the list with the local groups plus the AD 
> > groups is returned.
> > 
> > In /etc/nsswitch.conf group:  files sss
> > 
> > I am altering the parameter ad_enable_gc to  False but this happened with 
> > is set to True also.
> > 
> > 
> > Any ideas please?
> 
> Not without logs that capture the issue, sorry.
> 
> See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XSOSASZDGEELE7EXD5Z3BYU24GTP7CEG/
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/JQZZRTKAYJFUHL7DZQFC4LUBANUIPSNI/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/KA22UPQEZX2UA234FNG5DABE5TYL25DT/

[SSSD-users] Re: sssd failing to lookup user/group names by ID

[Jakub Hrozek]

This is a bug that was fixed recently upstrea, but not in RHEL/centos yet.

Do you actually use the local domain? 

> On 1 Jun 2018, at 18:47, David Potterveld  wrote:
> 
> I'm having an issue with sssd failing to look up user or group names from an 
> AD provider. The error occurs on both modern Fedora and Centos 7 systems 
> joined to AD via realm commands. On Centos 7, the version of SSSD is 1.16.0, 
> and that is the version on which I am reporting.
> 
> The systems will work perfectly for a long time (up to months) and then 
> suddenly start failing. The most noticeable failure is that "ls -l" of files 
> will give UID/GID numbers, not names, and also ssh into the system will 
> report the error "/usr/bin/id: cannot find name for group ID".
> 
> The failure can be temporarily cured with commands such as:
> 
> getent passwd username
> getent group "domain users"
> 
> but after a short period of time the failure resumes. Clearing the cache via 
> "sss_cache -E" also causes the problem to immediately manifest.
> 
> I ran some tests with logging enabled. NSS debug level set to 6. The test is 
> to issue the command:
> 
> ls -ld dpotterv
> 
> When things are working, I see:
> 
> drwx--. 19 dpotterv domain users 29 Jun  1 10:08 dpotterv
> 
> When things are failing, I see:
> 
> drwx--. 19 900209170 900200513 29 Jun  1 10:08 dpotterv
> 
> Here are the entries from the nss log for FAILURE:
> 
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client 
> connected!
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Received client version [1].
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Offered version [1].
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 
> 900209170
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #21: New 
> request 'User by ID'
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): 
> CR #21: Performing a multi-domain search
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): 
> CR #21: Search will check the cache and check the data provider
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR 
> #21: Using domain [local]
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR 
> #21: Looking up UID:900209170@local
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR 
> #21: Checking negative cache for [UID:900209170@local]
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR 
> #21: [UID:900209170@local] is not present in negative cache
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR 
> #21: Looking up [UID:900209170@local] in cache
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): 
> id exceeds min/max boundaries
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR 
> #21: ID [UID:900209170@local] was filtered out
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_locate_dom_cache_done] 
> (0x0040): cache_req_search_recv returned [1432158300]: ID is outside the 
> allowed range
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_process_result] (0x0400): 
> CR #21: Finished: Error 1432158300: ID is outside the allowed range
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [client_recv] (0x0200): Client 
> disconnected!
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client 
> connected!
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Received client version [1].
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Offered version [1].
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 
> 900200513
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #22: New 
> request 'Group by ID'
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): 
> CR #22: Performing a multi-domain search
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): 
> CR #22: Search will check the cache and check the data provider
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR 
> #22: Using domain [local]
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR 
> #22: Looking up GID:900200513@local
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR 
> #22: Checking negative cache for [GID:900200513@local]
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR 
> #22: [GID:900200513@local] is not present in negative cache
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR 
> #22: Looking up [GID:900200513@local] in cache
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): 
> id exceeds min/max boundaries
> (Fri Jun  1 11:17:59 2018) [sssd[nss]] 

[SSSD-users] Re: Nested LDAP groups and filtering

[Jakub Hrozek]

First, I’m sorry that I missed the e-mail in the moderation queue. We get a 
fair amount of spam and things sometimes slip through.

> On 20 May 2018, at 14:23, Christian Svensson  wrote:
> 
> Hi sssd-users,
> 
> My LDAP setup contains two bases:
> dc=office1,dc=company,dc=tld
> dc=office2,dc=company,dc=tld
> 
> Groups can cross-reference other groups in the two bases, like this:
> cn=printer-access,ou=groups,dc=office1,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office1,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld 
> cn=printer-access,ou=groups,dc=office2,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld 
> 
> What I'm trying achieve is to have a server belonging to office1 being able 
> to expand all groups, even if the references are across office boundary, but 
> only see the leaf groups that are in its own base.
> 
> What I've tried is something like this:
> [domain/office1]
> debug_level = 9
> enumerate = true
> cache_credentials = true
> entry_cache_timeout = 600
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> ldap_search_base = dc=company,dc=tld
> ldap_group_search_base = dc=office1,dc=company,dc=tld
> # Also tried with:
> # ldap_group_search_base = dc=company,dc=tld?subtree?(dc:dn:=office1)
> ldap_schema = rfc2307bis
> ldap_group_member = member
> ldap_group_nesting_level = 5
> ldap_uri = ldaps://xxx
> ldap_tls_reqcert = hard
> ldap_tls_cacert = /etc/ssl/ldap-ca.crt
> 
> Sadly this does not work, which I'm not that surprised over. The lookup logic 
> reports:
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_save_grpmem] (0x0400): 
> Adding member users to group [printer-access@office1]
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_find_entry_by_origDN] 
> (0x4000): Searching cache for 
> [cn=everybody,ou=groups,dc=office2,dc=company,dc=tld].
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_fill_memberships] 
> (0x0080): Member [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld] was 
> not found in cache. Is it out of scope?
> 

> Looking at the way things are executed in code and logs it seems like there 
> is no "post processing" to drop groups based on LDAP attributes, nor is there 
> any way for me to add attributes to the full name of the resource to 
> disambiguate them. Those are the two ways I've been attacking this, and both 
> seems to not be supported.
> 
> Are my observations correct? Is there a workaround other than making sure 
> groups have unique names across the whole company?
> 
> When groups are not colliding in name everything works just fine if I put " 
> ldap_group_search_base =  dc=company,dc=tld", but I'd prefer if I could avoid 
> having to resort to globally unique group names.
> 
> Thanks,
> 
> P.S. My groups are named differently and have been renamed in the log 
> messages. Let me know if something doesn't make sense and I might have typo'd 
> a replacement.

Yes, I must admit I got a bit confused. Is the issue related to both members in 
your example having the same name? IOW, if you have “everybody” and “nobody” in 
different subtrees, are those resolved correctly?

> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/TBUDKSJXU43XL4X3FMVGKCPJQOMVFNPZ/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/CF4RXQXBRLKRIKRL2FBLO3KBEUMC7N3W/

[SSSD-users] CVE-2018-10852: information leak from the sssd-sudo responder

[Jakub Hrozek]

=== A security bug in SSSD 1.8 and later =

Subject: information leak from the sssd-sudo responder

CVE ID: CVE-2018-10852

Summary: The UNIX socket that is used for communication between the sudo
utility and the sssd-sudo responder had its permissions set to world-readable
and writable, which means that anyone who can send a message using the same
raw protocol that sudo and SSSD use can read the sudo rules available for
any user.

Impact: low

Affects default configuration: When configured with tools like
ipa-client-install

Introduced with: SSSD 1.8

== Description ==
SSSD uses a UNIX pipe, typically located at /var/lib/sss/pipes/sudo for
communication between sudo and the sssd-sudo responder. When SSSD created
this pipe, the umask() call was set to be too permissive, which resulted
in the pipe being readable and writable. Then, if an attacker used the
same communication protocol that sudo uses to talk to SSSD, they could
obtain the list of sudo rules for any user who stores their sudo rules in
a remote directory.

While the sudo responder is not started by default by SSSD itself, utilities
like ipa-client-install configure the sudo responder to be started.

One way of mitigating the issue would be, for systems that run a recent SSSD
version and use the systemd service manager to remove sudo from the list
of services started by SSSD, then augment the sssd-sudo.socket service file
with the “SocketMode=0600” directive and finally configure the sssd-sudo
socket to be activated by systemd (systemctl enable sssd-sudo.socket).

== Patch avaliability ===
* master: https://pagure.io/SSSD/sssd/c/ed90a20a0f0e936eb00d268080716c0384ffb01d
* sssd-1-14: 
https://pagure.io/SSSD/sssd/c/3a0397b4c2b2d9c47e8bd0da808f5a1797244439
* sssd-1-13: 
https://pagure.io/SSSD/sssd/c/b0614512bee0b07ab1ab9c314220402c7c4680ac
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XUCDLKDVH7HZKPSJ7GEJAVNZS5CW35EK/

[SSSD-users] Re: credentials cache cleared at sssd restart pam_sss + krb5

[Jakub Hrozek]

On Tue, May 01, 2018 at 01:53:48PM +0200, cedric hottier wrote:
> Dear sssd users,
> 
> I observe that at each sssd start, the credentials cache is cleared. Is it
> an expected behavior ?
> If yes, is there a parameter to make this caching permanent (or at least
> not erased at each sssd restart ).
> My issue is that If I reboot my laptop without connection to my KDC, I am
> not able to log due to [sysdb_cache_auth] cached credentials not available.
> 
> here is my config : Debian testing / SSD version : 1.16.1
> 
> /etc/sssd/sssd.conf :
> [sssd]
> services = nss, pam, ifp
> domains = ECCM.LAN
> 
> [pam]
> pam_verbosity = 2
> offline_credentials_expiration = 0
> 
> /etc/sssd/conf.d/01_ECCM_LAN.conf
> [domain/ECCM.LAN]
> debug_level = 10
> id_provider = files

I'm afraid this is a known bug with id_provider=files. I was looking
into fixing this last week, but I don't have a patch yet.

In the meantime, you can use:
id_provider=proxy
proxy_lib_name=files

I think that should work in the meantime..

> auth_provider = krb5
> krb5_server = DebianCubox.eccm.lan
> krb5_realm = ECCM.LAN
> krb5_validate = true
> krb5_ccachedir = /var/tmp
> krb5_keytab = /etc/krb5.keytab
> krb5_store_password_if_offline = true
> 
> cache_credentials = true
> 
> After a fresh reboot, I am able to log in only if the krb5_server is
> available.
> As long as I do not restart the sssd daemon, I am able to log in.
> 
> The credentials caching seems to work properly as I see
> " Authenticated with cache credentials " at each TTY console just before
> the usual loggin message.
> 
> But If restart the sssd daemon while disconnected from the network, I am
> not able to log in anymore. The credentials cache seems to have been
> cleared.
> 
> Here is the /var/log/sssd/krb5_child.log
> 
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [main] (0x0400):
> krb5_child started.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [unpack_buffer]
> (0x1000): total buffer size: [128]
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [unpack_buffer]
> (0x0100): cmd [241] uid [1000] gid [1000] validate [true] enterprise
> principal [false] offline [true] UPN [ced...@eccm.lan]
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [unpack_buffer]
> (0x2000): No old ccache
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [unpack_buffer]
> (0x0100): ccname: [FILE:/var/tmp/krb5cc_1000_XX] old_ccname: [not set]
> keytab: [/etc/krb5.keytab]
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [check_use_fast]
> (0x0100): Not using FAST.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942
> [k5c_precreate_ccache] (0x4000): Recreating ccache
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942
> [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [become_user]
> (0x0200): Trying to become user [1000][1000].
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [main] (0x2000):
> Running as [1000][1000].
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [become_user]
> (0x0200): Trying to become user [1000][1000].
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [become_user]
> (0x0200): Already user [1000].
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [k5c_setup] (0x2000):
> Running as [1000][1000].
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942
> [set_lifetime_options] (0x0100): No specific renewable lifetime requested.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942
> [set_lifetime_options] (0x0100): No specific lifetime requested.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [main] (0x0400): Will
> perform offline auth
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [create_empty_ccache]
> (0x1000): Creating empty ccache
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [create_empty_cred]
> (0x2000): Created empty krb5_creds.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [create_ccache]
> (0x4000): Initializing ccache of type [FILE]
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [create_ccache]
> (0x4000): returning: 0
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [k5c_send_data]
> (0x0200): Received error code 0
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942
> [pack_response_packet] (0x2000): response packet size: [56]
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [k5c_send_data]
> (0x4000): Response sent.
> (Tue May  1 12:35:44 2018) [[sssd[krb5_child[8942 [main] (0x0400):
> krb5_child completed successfully
> 
> On /var/log/sssd/sssd_ECCM_LAN.log :
> 
> (Tue May  1 12:35:44 2018) [sssd[be[ECCM.LAN]]] [sbus_dispatch] (0x4000):
> dbus conn: 0x560ea04b4be0
> (Tue May  1 12:35:44 2018) [sssd[be[ECCM.LAN]]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Tue May  1 12:35:44 2018) [sssd[be[ECCM.LAN]]] [sbus_message_handler]
> (0x2000): Received SBUS method
> 

[SSSD-users] Re: sssd-users@lists.fedorahosted.org post from ced...@hottier.com requires approval

[Jakub Hrozek]

> On 1 May 2018, at 23:30, ad...@fedoraproject.org wrote:
> 
> As list administrator, your authorization is requested for the
> following mailing list posting:
> 
>List:sssd-users@lists.fedorahosted.org
>From:ced...@hottier.com
>Subject: Re: [SSSD-users] Re: credentials cache cleared at sssd restart 
> pam_sss + krb5
> 
> The message is being held because:
> 
>The message is not from a list member
> 
> At your convenience, visit your dashboard to approve or deny the
> request.
> 
> From: cedric hottier 
> Subject: Re: [SSSD-users] Re: credentials cache cleared at sssd restart 
> pam_sss + krb5
> Date: 1 May 2018 at 23:30:53 CEST
> To: sssd-users@lists.fedorahosted.org
> 
> 
> Dear Jakub,
> Thanks a lot for your workaround. It works perfectly now.
> 
> I guess that fixing this issue is not a priority as the proxy_lib_names=files 
> works fine.
> I did not find any bug report regarding this issue, and I think it would be 
> worth to create one with your workaround .

Well, it’s causing issues, so it’s a priority :) the bug link is 
https://pagure.io/SSSD/sssd/issue/3591

> Regards
> Cedric
> - 
> 
> 
> 
> From: sssd-users-requ...@lists.fedorahosted.org
> Subject: confirm 87d041498495ab1b6d4a693f3d23ef672262cce9
> Date: 1 May 2018 at 23:30:59 CEST
> 
> 
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for posting
> to the list.  The Approved: header can also appear in the first line
> of the body of the reply.
> 
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Server not found in Kerberos database and debug level 11

[Jakub Hrozek]

> On 2 May 2018, at 17:54, JOHE (John Hearns)  wrote:
> 
> I would appreciate some pointers.
> I have a sandbox setup running on VMs.  There is an AD controller using the 
> VM image which Microsoft has available for testing.
> I have created a domain called ad.test
> 
> On my client machine I am continually getting this error:
> [sssd[be[adtest.private]]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: 
> Unspecified GSS failure.  Minor code may provide more information (Server not 
> found in Kerberos database)
> 

I find it easier to debug this kind of an issue with:
KRB5_TRACE=/dev/stderr ldapsearch -Y GSSAPI -H ldap://your.ad.dc -s base -b “”

Also, what version and on what OS are you running?

> 
> On the client   klist-k | uniq returns
> 
> KVNO Principal
>  
> --
>3 CLIENT1$@ADTEST.PRIVATE
>3 host/CLIENT1@ADTEST.PRIVATE
>3 host/client1@ADTEST.PRIVATE
>3 RestrictedKrbHost/CLIENT1@ADTEST.PRIVATE
>3 RestrictedKrbHost/client1@ADTEST.PRIVATE
> 
> The funny thing is ONLY   kinit -k CLIENT1$\@ADTEST.PRIVATE   will work.

This is expected, only the client$@realm principal is a user/computer 
principal, the rest are service principals.

> I do get a tgt:
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: CLIENT1$@ADTEST.PRIVATE
> 
> Just in the sandbox I am also setting:
> ldap_auth_disable_tls_never_use_in_production = true

Please don’t use this, not only it is very insecure, but also it doesn’t make 
any sense, this option is only useful if you use auth_provider=ldap. With 
id_provider/auth_provider=ad, TLS is not used, but GSSAPI is.

> 
> Any pointers please?  I have cranked debug up to 8 and this error message 
> seems to be the crucial one.
> 
> By the way, why does the debug level not go up to 11?

Because 9 is the highest?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: System Error (4) for passwd users

[Jakub Hrozek]

On Wed, Jan 24, 2018 at 06:06:38PM +0100, Franky Van Liedekerke wrote:
> Op Woensdag, 24-01-2018 om 17:44 schreef Jakub Hrozek:
> > On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote:
> > > Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek:
> > > > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote:
> > > > > Sorry about the line breaks.  Adding "enable_files_domain = false" to 
> > > > > the [sssd] section fixed the issue.  Just out of curiosity, could I 
> > > > > ask what that does?  Its not in the man page.  
> > > > 
> > > > SSSD has a feature which mirrors the local /etc/passwd and /etc/group
> > > > files for faster lookups of local users without having to enable nscd
> > > > which is tricky to operate together with sssd, especially if you run
> > > > sssd for a remote domain, too:
> > > > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
> > > > But I'm surprised that Debian would enable this feature without changing
> > > > the nsswitch.conf order like Fedora did. They probably should disable
> > > > the files domain by default..
> > > > 
> > > > The files domain is currently identity-only and no authentication is
> > > > performed. That, together with the duplicate users and the files domain
> > > > running by default has been causing the failures for you..
> > > 
> > > On a side-note: I just tested this enable_files_domain and it seems using 
> > > it results in the next domain still being queried for local users 
> > > (verified by sifting through the ldap server logs). Using an explicit 
> > > domain with id_provider=files apparently works differently (that domain 
> > > answers and the next one is not queried), which is not very transparent.
> > > Is this expected?
> > 
> > What was the order of the explicit domains? Note the implicit domain is
> > always prepended before any other domain..
> 
> The order in case of an explicit domain is first the files-based one, then 
> ldap. So the order is (or should be) identical in both cases.
> 

Then I don't know without logs, sorry.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: max_id no longer working

[Jakub Hrozek]

On Wed, Jan 24, 2018 at 03:06:58PM +0100, Franky Van Liedekerke wrote:
> ​Hi,
> 
> 
> 
>  
> 
> 
> 
> we saw a lot of queries for uidnumber=4294967295  in our ldap backend
> logs (from sssd), so we did as suggested by 
> 
> 
> 
> https://access.redhat.com/solutions/2963401
> 
> 
> 
>  
> 
> 
> 
> and added max_id=4294967294 in our sssd domain config.
> 
> 
> 
> But this seems to be ignored (at least in version
> 1.15.2-50.el7_4.8.x86_64), as the queries continue to arrive in ldap.
> 
> 
> 
> Adding ldap_max_id with the same value resulted in an "numerical out
> of range" error and sssd refuses to start then (seems to be 16-bit
> ...).
> 
> 
> 
>  
> 
> 
> 
> And of course I read the nfsnobody discussions where the uid=65534 :-)
> 
> 
> 
> As a workaround, I added an entry in /etc/passwd for uid
> 4294967295 so the problem went away, but this still leaves the max_id
> and ldap_max_id issues that should be working fine ...
> 
> 
> 
> Any hints?

Sounds like https://pagure.io/SSSD/sssd/issue/3569 which was fixed upstream
in the upcoming (once we fix known regressions...) release. The fix was
also backported to RHEL-7.5 and the next RHEL-7.4.z release..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: System Error (4) for passwd users

[Jakub Hrozek]

add_iface] (0x0400): Registering 
> interface org.freedesktop.sssd.DataProvider.Failover with path 
> /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:44 2018)
> [sssd[be[place.edu]]] [sbus_message_handler] (0x2000): Received SBUS method 
> org.freedesktop.sssd.DataProvider.Client.Register on path 
> /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:44 2018)
> [sssd[be[place.edu]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus 
> message, quit(Wed Jan 24 08:53:44 2018) [sssd[be[place.edu]]] 
> [dp_client_register] (0x0100): Cancel DP ID timeout
> [0x55a3326e7070](Wed Jan 24 08:53:44 2018) [sssd[be[place.edu]]] 
> [dp_client_register] (0x0100): Added Frontend client [SUDO](Wed Jan 24 
> 08:53:44 2018) [sssd[be[place.edu]]] [sbus_message_handler]
> (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getDomains 
> on path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:44 2018) 
> [sssd[be[place.edu]]] [sbus_get_sender_id_send]
> (0x2000): Not a sysbus message, quit(Wed Jan 24 08:53:44 2018) 
> [sssd[be[place.edu]]] [dp_attach_req] (0x0400): DP Request [Subdomains #2]: 
> New request. Flags [].(Wed Jan 24 08:53:44 2018)
> [sssd[be[place.edu]]] [dp_attach_req] (0x0400): Number of active DP request: 
> 1(Wed Jan 24 08:53:44 2018) [sssd[be[place.edu]]] 
> [ad_subdomains_handler_send] (0x0400): Subdomains were recently
> refreshed, nothing to do(Wed Jan 24 08:53:44 2018) [sssd[be[place.edu]]] 
> [dp_req_done] (0x0400): DP Request [Subdomains #2]: Request handler finished 
> [0]: Success(Wed Jan 24 08:53:44 2018)
> [sssd[be[place.edu]]] [_dp_req_recv] (0x0400): DP Request [Subdomains #2]: 
> Receiving request data.(Wed Jan 24 08:53:44 2018) [sssd[be[place.edu]]] 
> [dp_req_reply_list_success] (0x0400): DP Request
> [Subdomains #2]: Finished. Success.(Wed Jan 24 08:53:44 2018) 
> [sssd[be[place.edu]]] [dp_req_reply_std] (0x1000): DP Request [Subdomains 
> #2]: Returning [Success]: 0,0,Success(Wed Jan 24 08:53:44 2018)
> [sssd[be[place.edu]]] [dp_table_value_destructor] (0x0400): Removing 
> [8:8::] from reply table(Wed Jan 24 08:53:44 2018) 
> [sssd[be[place.edu]]] [dp_req_destructor] (0x0400): DP Request
> [Subdomains #2]: Request removed.(Wed Jan 24 08:53:44 2018) 
> [sssd[be[place.edu]]] [dp_req_destructor] (0x0400): Number of active DP 
> request: 0
> 
> On Wed, 2018-01-24 at 14:37 +0100, Jakub Hrozek wrote:
> > On Tue, Jan 23, 2018 at 07:44:04PM -0500, goe...@gmail.com wrote:
> > > Hi,
> > > 
> > > The troubleshooting guide in the docs said to email the list if the System
> > > Error (4) shows up, so I figured I bring this issue up.  I'm running sssd
> > > version 1.16.0 on Debian testing and recently encountered a new behavior.
> > > We set up sssd with active directory based authentication on an already
> > > established system.  For various reasons there are still local passwd
> > > users, some of whom also have ad accounts.  What used to happen is that 
> > > the
> > > pam/nsswitch stack was set up so that those users would end up with their
> > > passwd id.  If they had an ad account they could log in with either their
> > > shadow password or their ad password.  Right after we upgraded from
> > > 1.16.0-1 to 1.16.0-2 any local user generated a System Error (4) in the
> > > logs and and local users with ad accounts could no longer use their ad
> > > passwords (although they could still use their local passwords).  There
> > > isn't a lot of information in the logs.
> > 
> > Can you also paste your full configuration and the sssd domain log(s) ?
> > 
> > Does sssd on Debian use the implicit files provider (ps would show a
> > sssd_be process running with --name implicit_files)
> > ___
> > 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 mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: System Error (4) for passwd users

[Jakub Hrozek]

On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote:
> Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek:
> > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote:
> > > Sorry about the line breaks.  Adding "enable_files_domain = false" to the 
> > > [sssd] section fixed the issue.  Just out of curiosity, could I ask what 
> > > that does?  Its not in the man page.  
> > 
> > SSSD has a feature which mirrors the local /etc/passwd and /etc/group
> > files for faster lookups of local users without having to enable nscd
> > which is tricky to operate together with sssd, especially if you run
> > sssd for a remote domain, too:
> > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
> > But I'm surprised that Debian would enable this feature without changing
> > the nsswitch.conf order like Fedora did. They probably should disable
> > the files domain by default..
> > 
> > The files domain is currently identity-only and no authentication is
> > performed. That, together with the duplicate users and the files domain
> > running by default has been causing the failures for you..
> 
> On a side-note: I just tested this enable_files_domain and it seems using it 
> results in the next domain still being queried for local users (verified by 
> sifting through the ldap server logs). Using an explicit domain with 
> id_provider=files apparently works differently (that domain answers and the 
> next one is not queried), which is not very transparent.
> Is this expected?

What was the order of the explicit domains? Note the implicit domain is
always prepended before any other domain..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: [Freeipa-users] Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[Jakub Hrozek]

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:
> On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
> My bad, did not include sssd-users earlier.  :(
> 
> > Hey All,
> > 
> > I'm wondering if anyone came across this error below.  We have two RHEL
> > 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02
> > 
> > Both connect to the same AD DC host below: addc-srv03.addom.com.
> > Verified krb5.conf and sssd.conf both are identical.  We can login on
> > the http-srv01 and can list all groups for an AD account.
> > 
> > On http-srv02 we cannot login and any group listing from the CLI result
> > only in the user's local groups.  No AD groups.
> > 
> > Logs give us the output below.  Short of adding in the entire log which
> > I might not be able to do till the end of the week, what could we look
> > at to resolve this?
> > 
> > There's very little available online on this error.  The RH solution
> > doesn't make sense since the first host connects and authenticates users
> > just fine so it's definitely GC enabled.
> > 
> 
> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> 
> 
> 
> samba-libs-4.6.2-12.el7_4.x86_64
> samba-client-libs-4.6.2-12.el7_4.x86_64
> sssd-1.15.2-50.el7_4.6.x86_64
> openldap-2.4.44-5.el7.x86_64
> sssd-ldap-1.15.2-50.el7_4.6.x86_64
> sssd-common-pac-1.15.2-50.el7_4.6.x86_64
> samba-winbind-clients-4.6.2-12.el7_4.x86_64
> samba-common-4.6.2-12.el7_4.noarch
> sssd-client-1.15.2-50.el7_4.6.x86_64
> sssd-proxy-1.15.2-50.el7_4.6.x86_64
> samba-winbind-modules-4.6.2-12.el7_4.x86_64
> python-sssdconfig-1.15.2-50.el7_4.6.noarch
> sssd-ipa-1.15.2-50.el7_4.6.x86_64
> samba-common-libs-4.6.2-12.el7_4.x86_64
> sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
> samba-winbind-4.6.2-12.el7_4.x86_64
> sssd-krb5-1.15.2-50.el7_4.6.x86_64
> sssd-ad-1.15.2-50.el7_4.6.x86_64
> sssd-common-1.15.2-50.el7_4.6.x86_64
> samba-common-tools-4.6.2-12.el7_4.x86_64
> 
> 
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus
> conn: 0x55b2e22e8700
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
> (0x2000): Received SBUS method
> org.freedesktop.sssd.dataprovider.getAccountInfo on path
> /org/freedesktop/sssd/dataprovider
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
> (0x2000): Not a sysbus message, quit
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler]
> (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP
> Request [Account #4]: New request. Flags [0x0001].
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
> Number of active DP request: 1
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> (0x1000): Domain ADDOM is Active
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> (0x1000): Domain ADDOM is Active
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
> (0x4000): beginning to connect
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
> (0x0100): Trying to resolve service 'AD_GC'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000):
> Status of server 'addc-srv03.addom.com' is 'working'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
> Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'

What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?

> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080):
> SSSD is unable to complete the full connection request, this internal status
> does not necessarily indicate network port issues.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
> (0x0020): No available servers for service 'AD_GC'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done]
> (0x1000): Server resolution failed: [5]: Input/output error
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
> (0x0400): Failed to connect to server, but ignore mark offline is enabled.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
> (0x4000): notify error to op #1: 5 [Input/output error]
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP
> Request [Account #4]: Request handler finished [0]: Success
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP
> Request [Account #4]: Receiving request data.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success]
> (0x0400): DP Request [Account #4]: Finished. Success.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP
> Request 

[SSSD-users] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7

[Jakub Hrozek]

The preffered place is https://pagure.io/SSSD/sssd/new_issue

On Fri, Feb 02, 2018 at 05:59:18PM +, Simon Engelbert wrote:
> Sure, where is the proper place to file tickets?
> 
> - Simon
> On 2018-02-02, 10:20 AM, "Jakub Hrozek" <jhro...@redhat.com> wrote:
> 
> If you can reproduce this with a recent build, please file a ticket..
> 
> On Fri, Feb 02, 2018 at 05:01:25PM +, Simon Engelbert wrote:
> > We updated to the latest copr repo and it does not seem to make a 
> difference, we are seeing the exact same issues.
> > 
> > We have noticed a weird pattern that is, honestly, not always 
> consistent but looks like this…
> > 
> > ## Login attempt 1 ##
> > *local*
> > u...@domain.ad@local: ~$ ssh server
> > Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> > 
> > *on server*
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> > 
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> > 
> > root@server: ~$ sss_cache -E
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> > 
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> > 
> > root@server: ~$ exit
> > 
> > ## Login attempt 2 ##
> > *local*
> > u...@domain.ad@local: ~$ ssh server
> > Last login: Fri Feb  2 16:31:23 2018 from local
> > 
> > user@server: ~$
> > 
> > *on server*
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> > 
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> > 
> > 
> > ## Login attempt 3 ##
> > *local*
> > u...@domain.ad@local: ~$ ssh server
> > Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> > 
> > *on server*
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> > 
> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> > 
> > 
> > It appears as though clearing the cache clears or resets the cache 
> correctly and then a successful login clears or resets the cache incorrectly.
> > 
> > Also here are our configs…
> > 
> > [sssd]
> > config_file_version = 2
> > #wmb - added ssh to the following line
> > services = ssh, nss, pam
> > domains = DOMAIN.AD
> > #wmb added next line
> > default_domain_suffix = DOMAIN.AD
> > debug_level = 0x3ff0
> > 
> > #wmb added the following line
> > [ssh]
> > 
> > [nss]
> > override_homedir = /users/%u
> > default_shell = /bin/bash
> > use_fully_qualified_names = True
> > fallback_homedir = /users/%u@%d
> > reconnection_retries = 3
> > 
> > [pam]
> > reconnection_retries = 3
> > #wmb added the following line - Keep user credentials in cache for 7 
> days
> > offline_credentials_expiration = 7
> > 
> > [domain/DOMAIN.AD]
> > #wmb - added next line
> > ad_domain = DOMAIN.AD
> > debug_level = 0x3ff0
> > enumerate = false
> > #wmb - Do not return group members for group lookups. Default false
> > #ignore_group_members = true
> > id_provider = ad
> > chpass_provider = ad
> > auth_provider = ad
> > access_provider = simple
> > #simple_allow_groups = hadoop_admins, hadoop_users
> > ad_server =  ADSERVER1.DOMAIN.AD
> > #wmb activated next line
> > ad_backup_server =  ADSERVER2.DOMAIN.AD
> > ldap_schema = ad
> > ldap_user_principal = sAMAccountName
> > #wmb added the next 2 lines for SSH keys
> > ldap_user_extra_attrs = User-sshPublicKey:User-sshPublicKey
> > ldap_user_ssh_public_key = User-sshPublicKey
> > ldap_id_mapping = true
> > ldap_force_upper_case_realm = true
> > case_sensitive = false
> > krb5_realm = DOMAIN.AD
> > #wmb  tags stored by the realmd configuration service for this domain
> > realmd_tags = manages-system joined-with-samba
> > #wmb Save user passwd if they log in offline. Do kinit when they com 
> online
> > #krb5_store_password_if_offline = true
> > ldap_access_order = filter,expire
> > ldap_account_expire_policy = ad
> > cache_credentials = true
> > account_cache_expiration = 15
> > enum_cache_timeout = 120
> > entry_cache_nowait_percentage = 50
> 

[SSSD-users] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7

[Jakub Hrozek]

If you can reproduce this with a recent build, please file a ticket..

On Fri, Feb 02, 2018 at 05:01:25PM +, Simon Engelbert wrote:
> We updated to the latest copr repo and it does not seem to make a difference, 
> we are seeing the exact same issues.
> 
> We have noticed a weird pattern that is, honestly, not always consistent but 
> looks like this…
> 
> ## Login attempt 1 ##
> *local*
> u...@domain.ad@local: ~$ ssh server
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> 
> *on server*
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> 
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> 
> root@server: ~$ sss_cache -E
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> 
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> 
> root@server: ~$ exit
> 
> ## Login attempt 2 ##
> *local*
> u...@domain.ad@local: ~$ ssh server
> Last login: Fri Feb  2 16:31:23 2018 from local
> 
> user@server: ~$
> 
> *on server*
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> 
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> 
> 
> ## Login attempt 3 ##
> *local*
> u...@domain.ad@local: ~$ ssh server
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> 
> *on server*
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
> 
> root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad
> 
> 
> It appears as though clearing the cache clears or resets the cache correctly 
> and then a successful login clears or resets the cache incorrectly.
> 
> Also here are our configs…
> 
> [sssd]
> config_file_version = 2
> #wmb - added ssh to the following line
> services = ssh, nss, pam
> domains = DOMAIN.AD
> #wmb added next line
> default_domain_suffix = DOMAIN.AD
> debug_level = 0x3ff0
> 
> #wmb added the following line
> [ssh]
> 
> [nss]
> override_homedir = /users/%u
> default_shell = /bin/bash
> use_fully_qualified_names = True
> fallback_homedir = /users/%u@%d
> reconnection_retries = 3
> 
> [pam]
> reconnection_retries = 3
> #wmb added the following line - Keep user credentials in cache for 7 days
> offline_credentials_expiration = 7
> 
> [domain/DOMAIN.AD]
> #wmb - added next line
> ad_domain = DOMAIN.AD
> debug_level = 0x3ff0
> enumerate = false
> #wmb - Do not return group members for group lookups. Default false
> #ignore_group_members = true
> id_provider = ad
> chpass_provider = ad
> auth_provider = ad
> access_provider = simple
> #simple_allow_groups = hadoop_admins, hadoop_users
> ad_server =  ADSERVER1.DOMAIN.AD
> #wmb activated next line
> ad_backup_server =  ADSERVER2.DOMAIN.AD
> ldap_schema = ad
> ldap_user_principal = sAMAccountName
> #wmb added the next 2 lines for SSH keys
> ldap_user_extra_attrs = User-sshPublicKey:User-sshPublicKey
> ldap_user_ssh_public_key = User-sshPublicKey
> ldap_id_mapping = true
> ldap_force_upper_case_realm = true
> case_sensitive = false
> krb5_realm = DOMAIN.AD
> #wmb  tags stored by the realmd configuration service for this domain
> realmd_tags = manages-system joined-with-samba
> #wmb Save user passwd if they log in offline. Do kinit when they com online
> #krb5_store_password_if_offline = true
> ldap_access_order = filter,expire
> ldap_account_expire_policy = ad
> cache_credentials = true
> account_cache_expiration = 15
> enum_cache_timeout = 120
> entry_cache_nowait_percentage = 50
> entry_cache_nowait_timeout = 28800
> #wmb add if you want to restrict access to a certain group
> ldap_group_search_base = DC=DOMAIN,DC=AD
> ldap_sasl_authid = host/ser...@domain.ad
> #wmb - enable AD client to update its DNS record
> dyndns_update = True
> dyndns_update_ptr = True
> dyndns_refresh_interval = 43200
> dyndns_ttl = 3600
> 
> - Simon
> On 2018-02-02, 4:07 AM, "Lukas Slebodnik" <lsleb...@redhat.com> wrote:
> 
> On (02/02/18 11:54), Jakub Hrozek wrote:
> >In the non-working cases, I see the name qualified where it shouldn't be
> >e.g:
> 
> >[(&(sAMAccountName=u...@domain.ad)(objectclass=user)(sAMAccountName=*)(objectSID=*))][DC=DOMAIN,DC=AD].
>  
> >while in the working case, the name in the filter is just 
> 'samaccoutnname=user'.
> >
> >This is a bug, but at the same time, there's been a number of commits in
> >that area that might fix the bug..
> >
> >Since you are running CentOS, I guess you are not worried about losing a
> >support contract :-) so I'm wondering if you could test the 1.16.x 
> release
> >from our test repos?
> >
> >That said, I don't see ou

[SSSD-users] Re: FreeIPA/SSSD sssd_nss error: The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]

[Jakub Hrozek]

On Wed, Jan 31, 2018 at 12:32:28PM -0600, Anthony Joseph Messina wrote:
> In a Fedora 27 FreeIPA-4.6 domain with the following sssd.conf, I regularly
> get the followin error:
> 
> sssd_nss[2603]: The Data Provider returned an error 
> [org.freedesktop.sssd.Error.DataProvider.Fatal]
> 
> Increasing the sssd debug level reveals that the fatal error seems to be 
> raised
> by the lookup in the implicit_files domain which doesn't contain this GID.
> 
> While this happens on all my FreeIPA clients, this particular host is a 
> mailserver
> postfix and cyrus-imap with saslsuthd/pam authentication so the number of user
> lookups is far higher and the error occurs with considerable frequency.
> 
> Do I have a misconfiguration here or is there a problem with implicit_domain
> and GID lookups?  It doesn't seem like this should be a fatal error when the
> GID exists in the example.com FreeIPA/SSSD domain.
> 
> # /etc/nsswitch.conf (snippet)
> passwd: sss files mymachines systemd
> shadow: files sss
> group:  sss files mymachines systemd
> 
> # /etc/sssd/sssd.conf
> [domain/example.com]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = host.example.com
> chpass_provider = ipa
> ipa_server = _srv_, ipa-master.ipa.example.com
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, sudo, pam, ssh, ifp
> 
> domains = example.com
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> allowed_uids = apache, root
> 
> [secrets]
> 
> # Relevant sssd_nss debug logs
> Jan 30 18:22:48 sssd_nss[2603]: Input ID: 11
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: New request 'Group by ID'
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Performing a multi-domain search
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Search will check the cache and 
> check the data provider
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Using domain [implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Looking up 
> GID:11@implicit_files
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Checking negative cache for 
> [GID:11@implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: [GID:11@implicit_files] 
> is not present in negative cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Looking up 
> [GID:11@implicit_files] in cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Object 
> [GID:11@implicit_files] was not found in cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Looking up 
> [GID:11@implicit_files] in data provider
> Jan 30 18:22:48 sssd_nss[2603]: Issuing request for 
> [0x56200cc04250:2:11@implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: Creating request for 
> [implicit_files][0x2][BE_REQ_GROUP][idnumber=11:-]
> Jan 30 18:22:48 sssd_nss[2603]: Entering request 
> [0x56200cc04250:2:11@implicit_files]

I think it's probably https://pagure.io/SSSD/sssd/issue/3520. In general
the files provider shouldn't be calling the Data Provider at all,
because all users should be always cached.

Could you open a bug against Fedora so we can link it with the upstream
ticket and you can test the fix when it's ready?

btw the implicit files domain can be disabled, I think that would be the
best workaround in the meantime.

> Jan 30 18:22:48 sssd_nss[2603]: Input ID: 11
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: New request 'Group by ID'
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Performing a multi-domain search
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Search will check the cache and 
> check the data provider
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Using domain [implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Looking up 
> GID:11@implicit_files
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Checking negative cache for 
> [GID:11@implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: [GID:11@implicit_files] 
> is not present in negative cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Looking up 
> [GID:11@implicit_files] in cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Object 
> [GID:11@implicit_files] was not found in cache
> Jan 30 18:22:48 sssd_nss[2603]: CR #134774: Looking up 
> [GID:11@implicit_files] in data provider
> Jan 30 18:22:48 sssd_nss[2603]: Issuing request for 
> [0x56200cc04250:2:11@implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: Identical request in progress: 
> [0x56200cc04250:2:11@implicit_files]
> Jan 30 18:22:48 sssd_nss[2603]: The Data Provider returned an error 
> [org.freedesktop.sssd.Error.DataProvider.Fatal]
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Data Provider Error: 3, 5, Failed 
> to get reply from Data Provider
> Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Due to an error we will return 
> cached data
> Jan 30 

[SSSD-users] Re: FreeIPA/SSSD sssd_nss error: The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]

[Jakub Hrozek]

On Wed, Jan 31, 2018 at 01:56:56PM -0600, Anthony Joseph Messina wrote:
> On Wednesday, January 31, 2018 1:45:27 PM CST Jakub Hrozek wrote:
> > On Wed, Jan 31, 2018 at 12:32:28PM -0600, Anthony Joseph Messina wrote:
> > > In a Fedora 27 FreeIPA-4.6 domain with the following sssd.conf, I
> > > regularly
> > > get the followin error:
> > > 
> > > sssd_nss[2603]: The Data Provider returned an error
> > > [org.freedesktop.sssd.Error.DataProvider.Fatal]
> > > 
> > > Increasing the sssd debug level reveals that the fatal error seems to be
> > > raised by the lookup in the implicit_files domain which doesn't contain
> > > this GID.
> > > 
> > > While this happens on all my FreeIPA clients, this particular host is a
> > > mailserver postfix and cyrus-imap with saslsuthd/pam authentication so
> > > the number of user lookups is far higher and the error occurs with
> > > considerable frequency.
> > > 
> > > Do I have a misconfiguration here or is there a problem with
> > > implicit_domain and GID lookups?  It doesn't seem like this should be a
> > > fatal error when the GID exists in the example.com FreeIPA/SSSD domain.
> > > 
> > > # /etc/nsswitch.conf (snippet)
> > > passwd: sss files mymachines systemd
> > > shadow: files sss
> > > group:  sss files mymachines systemd
> > > 
> > > # /etc/sssd/sssd.conf
> > > [domain/example.com]
> > > cache_credentials = True
> > > krb5_store_password_if_offline = True
> > > ipa_domain = example.com
> > > id_provider = ipa
> > > auth_provider = ipa
> > > access_provider = ipa
> > > ipa_hostname = host.example.com
> > > chpass_provider = ipa
> > > ipa_server = _srv_, ipa-master.ipa.example.com
> > > ldap_tls_cacert = /etc/ipa/ca.crt
> > > [sssd]
> > > services = nss, sudo, pam, ssh, ifp
> > > 
> > > domains = example.com
> > > [nss]
> > > homedir_substring = /home
> > > 
> > > [pam]
> > > 
> > > [sudo]
> > > 
> > > [autofs]
> > > 
> > > [ssh]
> > > 
> > > [pac]
> > > 
> > > [ifp]
> > > allowed_uids = apache, root
> > > 
> > > [secrets]
> > > 
> > > # Relevant sssd_nss debug logs
> > > Jan 30 18:22:48 sssd_nss[2603]: Input ID: 11
> > > Jan 30 18:22:48 sssd_nss[2603]: CR #134773: New request 'Group by ID'
> > > Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Performing a multi-domain
> > > search Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Search will check the
> > > cache and check the data provider Jan 30 18:22:48 sssd_nss[2603]: CR
> > > #134773: Using domain [implicit_files] Jan 30 18:22:48 sssd_nss[2603]: CR
> > > #134773: Looking up GID:11@implicit_files Jan 30 18:22:48
> > > sssd_nss[2603]: CR #134773: Checking negative cache for
> > > [GID:11@implicit_files] Jan 30 18:22:48 sssd_nss[2603]: CR
> > > #134773: [GID:11@implicit_files] is not present in negative cache
> > > Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Looking up
> > > [GID:11@implicit_files] in cache Jan 30 18:22:48 sssd_nss[2603]:
> > > CR #134773: Object [GID:11@implicit_files] was not found in cache
> > > Jan 30 18:22:48 sssd_nss[2603]: CR #134773: Looking up
> > > [GID:11@implicit_files] in data provider Jan 30 18:22:48
> > > sssd_nss[2603]: Issuing request for
> > > [0x56200cc04250:2:11@implicit_files] Jan 30 18:22:48
> > > sssd_nss[2603]: Creating request for
> > > [implicit_files][0x2][BE_REQ_GROUP][idnumber=11:-] Jan 30
> > > 18:22:48 sssd_nss[2603]: Entering request
> > > [0x56200cc04250:2:11@implicit_files]
> > I think it's probably https://pagure.io/SSSD/sssd/issue/3520. In general
> > the files provider shouldn't be calling the Data Provider at all,
> > because all users should be always cached.
> > 
> > Could you open a bug against Fedora so we can link it with the upstream
> > ticket and you can test the fix when it's ready?
> 
> Fedora Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1540703

Thanks, linked to the upstream bug.

> 
> > btw the implicit files domain can be disabled, I think that would be the
> > best workaround in the meantime.
> 
> Thanks Jakub.  If I disable the implicit_files domain, I need to revert the 
> nsswitch configuration to list files before sss, correct?

You don't need to, but you should, because without the files domain,
every program falls back from libnss_sss to libsss_files at least once
per runtime and without the files domain there is no benefit anymore in
having the sss module precede the files module.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: System error with free-ipa on login

[Jakub Hrozek]

The selinux_child failed:
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [seuser_needs_update] 
(0x2000): getseuserbyname: ret: 0 seuser: unconfined_u mls: unknown 
 
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [libsemanage] 
(0x0020): could not cache policy database   

 
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [libsemanage] 
(0x0020): could not cache join database 

 
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [libsemanage] 
(0x0020): could not enter read-only section 

 
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [libsemanage] 
(0x0020): Error while reading kernel policy from 
/var/lib/selinux/targeted/active/policy.linked. 

(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [set_seuser] 
(0x0020): Cannot commit SELinux transaction 

  
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [main] (0x0020): 
Cannot set SELinux login context.   

  
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961 [main] (0x0020): 
selinux_child failed! 

What is 'sestatus' telling you? If you don't use the SELInux login mapping, you 
can set selinux_provider=none to work around tihs.

On Thu, Feb 15, 2018 at 09:45:43AM -, Iaroslav  wrote:
> it happened again with one of our server after power lost.
> 
> full logs of all sections with debug_level=10
> https://drive.google.com/open?id=1Yq2EQ0W9kSz7NhbrB-sv9EkQ2WD4mdXL
> 
> sssctl user-checks test1
> user: test1
> action: acct
> service: system-auth
> 
> SSSD nss user lookup result:
>  - user name: test1
>  - user id: 140070
>  - group id: 140070
>  - gecos: test1 test
>  - home directory: /home/test1
>  - shell: /bin/bash
> 
> SSSD InfoPipe user lookup result:
>  - name: test1
>  - uidNumber: 140070
>  - gidNumber: 140070
>  - gecos: test1 test
>  - homeDirectory: /home/test1
>  - loginShell: /bin/bash
> 
> testing pam_acct_mgmt
> 
> pam_acct_mgmt: Permission denied
> 
> PAM Environment:
>  - no env -
> 
>  
> sssctl user-checks pontostroy
> user: pontostroy
> action: acct
> service: system-auth
> 
> SSSD nss user lookup result:
>  - user name: pontostroy
>  - user id: 140014
>  - group id: 140014
>  - gecos: Iaroslav Andrusyak
>  - home directory: /home/pontostroy
>  - shell: /bin/bash
> 
> SSSD InfoPipe user lookup result:
>  - name: pontostroy
>  - uidNumber: 140014
>  - gidNumber: 140014
>  - gecos: Iaroslav Andrusyak
>  - homeDirectory: /home/pontostroy
>  - loginShell: /bin/bash
> 
> testing pam_acct_mgmt
> 
> pam_acct_mgmt: System error
> 
> PAM Environment:
>  - no env -
> ___
> 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: ETA release ?

[Jakub Hrozek]

On Mon, Feb 19, 2018 at 09:09:09AM +, Joakim Tjernlund wrote:
> Seem to recall a new release of sssd was planned some time ago but I
> don't see one. Change of plans? To what?

No change of plans, we've 'just' been finding more and more regressions.
Currently there is only one open -
https://pagure.io/SSSD/sssd/issue/3550

So the release should happen Quite Soon Now.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: sudo for Active Directory group

[Jakub Hrozek]

If you follow https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html 
and generate the sssd logs, does that shed some more light?

> On 22 Dec 2017, at 14:48, Viktor Ekl  wrote:
> 
> Hello. 
> 
> Sssd 1.15.2-50 on Centos 7. I'm trying to grant sudo access to members of 
> known AD group (say, "linux_admin"), but with no success:
> " is not allowed to run sudo on .  This incident will be reported"
> Can't understand why, according to sssd_domain.log group and members found ?
> 
> My configuration, /etc/sudoers:
> %wheel  ALL=(ALL)   ALL
> %linux_adminALL=(ALL)ALL
> 
> part of /etc/sssd/sssd.conf:
> sudo_provider = ldap
> 
> Part of sudo_debug log:
> sudo[1069] sudo_getgrnam: group linux_admin [] -> gid 10001 [] (cached)
> ...
> sudo[1069] sudo_get_gidlist: looking up group IDs for testadmin
> ...
> sudo[1069] user_in_group: user testadmin NOT in group linux_admin
> 
> Part of sssd_testdomain.com.log:
> [sssd[be[testdomain.com]]] [dp_get_account_info_handler] (0x0200): Got 
> request for [0x2][BE_REQ_GROUP][name=linux_ad...@testdomain.com]
> [sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): DP Request [Account 
> #11]: New request. Flags [0x0001].
> [sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): Number of active DP 
> request: 1
> [sssd[be[testdomain.com]]] [sss_domain_get_state] (0x1000): Domain 
> testdomain.com is Active
> [sssd[be[testdomain.com]]] [sdap_get_groups_next_base] (0x0400): Searching 
> for groups with base [cn=users,dc=testdomain,dc=com]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling 
> ldap_search_ext with 
> [(&(cn=linux_admin)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=users,dc=testdomain,dc=com].
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [objectClass]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [cn]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [userPassword]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [gidNumber]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [memberUid]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [modifyTimestamp]
> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
> attrs: [uSNChanged]
> [sssd[be[testdomain.com]]] [sdap_parse_entry] (0x1000): OriginalDN: 
> [CN=linux_admin,CN=Users,DC=testdomain,DC=com].
> [sssd[be[testdomain.com]]] [sdap_get_generic_op_finished] (0x0400): Search 
> result: Success(0), no errmsg set
> [sssd[be[testdomain.com]]] [sdap_get_groups_process] (0x0400): Search for 
> groups, returned 1 results.
> [sssd[be[testdomain.com]]] [sdap_has_deref_support] (0x0400): The server 
> supports deref method ASQ
> [sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 0 users found 
> in the hash table
> [sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 1 groups found 
> in the hash table
> [sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] 
> attribute. [0][Success]
> [sssd[be[testdomain.com]]] [sdap_get_primary_name] (0x0400): Processing 
> object linux_admin
> [sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Processing group 
> linux_ad...@testdomain.com
> [sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): The group 
> has 1 members
> [sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): Group has 1 
> members
> [sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Storing info for group 
> linux_ad...@testdomain.com
> [sssd[be[testdomain.com]]] [sysdb_store_group] (0x1000): The group record of 
> linux_ad...@testdomain.com did not change, only updated the timestamp cache
> [sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] 
> attribute. [0][Success]
> [sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Failed to get group 
> sid
> [sssd[be[testdomain.com]]] [sdap_get_primary_name] (0x0400): Processing 
> object linux_admin
> [sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Processing group 
> linux_ad...@testdomain.com
> [sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Adding member users 
> to group [linux_ad...@testdomain.com]
> [sssd[be[testdomain.com]]] [sdap_fill_memberships] (0x0080): Member 
> [testadmin] is it out of domain scope?
> [sssd[be[testdomain.com]]] [sdap_fill_memberships] (0x0080): Member 
> [testadmin] was not found in cache. Is it out of scope?
> [sssd[be[testdomain.com]]] [sysdb_set_entry_attr] (0x0200): Entry 
> [name=linux_ad...@testdomain.com,cn=groups,cn=testdomain.com,cn=sysdb] has 
> set [ts_cache] attrs.
> [sssd[be[testdomain.com]]] [dp_req_done] (0x0400): DP Request [Account #11]: 
> Request handler finished [0]: Success
> [sssd[be[testdomain.com]]] [_dp_req_recv] (0x0400): DP Request [Account #11]: 
> 

[SSSD-users] Re: sudo for Active Directory group

[Jakub Hrozek]

Ah, since you’re using local sudo rules and not stored in AD, I think only the 
sudo log would be most interesting. Plus, is the user either a member of wheel 
or linux_admin? (iow, do either of these group show up if you run ‘id’ as the 
user?)

> On 22 Dec 2017, at 15:09, Jakub Hrozek <jhro...@redhat.com> wrote:
> 
> If you follow 
> https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html and 
> generate the sssd logs, does that shed some more light?
> 
>> On 22 Dec 2017, at 14:48, Viktor Ekl <viktorekl...@gmail.com> wrote:
>> 
>> Hello. 
>> 
>> Sssd 1.15.2-50 on Centos 7. I'm trying to grant sudo access to members of 
>> known AD group (say, "linux_admin"), but with no success:
>> " is not allowed to run sudo on .  This incident will be 
>> reported"
>> Can't understand why, according to sssd_domain.log group and members found ?
>> 
>> My configuration, /etc/sudoers:
>> %wheel  ALL=(ALL)   ALL
>> %linux_adminALL=(ALL)ALL
>> 
>> part of /etc/sssd/sssd.conf:
>> sudo_provider = ldap
>> 
>> Part of sudo_debug log:
>> sudo[1069] sudo_getgrnam: group linux_admin [] -> gid 10001 [] (cached)
>> ...
>> sudo[1069] sudo_get_gidlist: looking up group IDs for testadmin
>> ...
>> sudo[1069] user_in_group: user testadmin NOT in group linux_admin
>> 
>> Part of sssd_testdomain.com.log:
>> [sssd[be[testdomain.com]]] [dp_get_account_info_handler] (0x0200): Got 
>> request for [0x2][BE_REQ_GROUP][name=linux_ad...@testdomain.com]
>> [sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): DP Request [Account 
>> #11]: New request. Flags [0x0001].
>> [sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): Number of active DP 
>> request: 1
>> [sssd[be[testdomain.com]]] [sss_domain_get_state] (0x1000): Domain 
>> testdomain.com is Active
>> [sssd[be[testdomain.com]]] [sdap_get_groups_next_base] (0x0400): Searching 
>> for groups with base [cn=users,dc=testdomain,dc=com]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling 
>> ldap_search_ext with 
>> [(&(cn=linux_admin)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=users,dc=testdomain,dc=com].
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [objectClass]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [cn]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [userPassword]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [gidNumber]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [memberUid]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [modifyTimestamp]
>> [sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting 
>> attrs: [uSNChanged]
>> [sssd[be[testdomain.com]]] [sdap_parse_entry] (0x1000): OriginalDN: 
>> [CN=linux_admin,CN=Users,DC=testdomain,DC=com].
>> [sssd[be[testdomain.com]]] [sdap_get_generic_op_finished] (0x0400): Search 
>> result: Success(0), no errmsg set
>> [sssd[be[testdomain.com]]] [sdap_get_groups_process] (0x0400): Search for 
>> groups, returned 1 results.
>> [sssd[be[testdomain.com]]] [sdap_has_deref_support] (0x0400): The server 
>> supports deref method ASQ
>> [sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 0 users found 
>> in the hash table
>> [sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 1 groups found 
>> in the hash table
>> [sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] 
>> attribute. [0][Success]
>> [sssd[be[testdomain.com]]] [sdap_get_primary_name] (0x0400): Processing 
>> object linux_admin
>> [sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Processing group 
>> linux_ad...@testdomain.com
>> [sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): The group 
>> has 1 members
>> [sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): Group has 
>> 1 members
>> [sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Storing info for 
>> group linux_ad...@testdomain.com
>> [sssd[be[testdomain.com]]] [sysdb_store_group] (0x1000): The group record of 
>> linux_ad...@testdomain.com did not change, only updated the timestamp cache
>> [sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] 
>> attribute. [0][Success]
>> [sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Failed

[SSSD-users] Re: SSD / chown on initial automated installation

[Jakub Hrozek]

On Fri, Dec 22, 2017 at 06:45:04PM +0100, Vadim Bulst wrote:
> Hi sssd-users,
> 
> i'm using SSSD for the auth on our compute clusters - about 130 nodes in
> total. The installation is done by Foreman and Puppet. Most of our clusters
> are on CentOS 7.3 and we are planning to upgrade to 7.4 by reinstall all
> nodes.
> 
> Here is my question:
> 
> In my puppet scripts i'm not able to change the group of a specific folder
> from local group to a netgroup. Even if i successfully call "getent group
> g_netgroup" before - my puppet module is trowing an error.

Does this command return anything?

When you run the puppet script (sorry if this is not the right
nomenclature, I know nothing about puppet), and watch the sssd logs with
tail or something similar, do you see any errors (or even any activity)
?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: id: cannot find name for group ID

[Jakub Hrozek]

> On 24 Jul 2018, at 22:33, Mario Rossi  wrote:
> 
> Should I sanitize the logs and send them over ?
> Thank you

yes
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/N7BPA5VZE5XZRNJ7YPD6T2LC44ZC7CXS/

[SSSD-users] Re: AD user account get Permission denied when trying to login

[Jakub Hrozek]

> On 24 Jul 2018, at 05:39, Farshid Mahdavipour  wrote:
> 
> (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [get_and_save_tgt] 
> (0x0020): 1544: [-1765328366][Client's credentials have been revoked]
> (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [map_krb5_error] 
> (0x0020): 1657: [-1765328366][Client's credentials have been revoked]

The account was locked out.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/NVWMXT7EWHTIDWRFZ4DTQSPVEGN3WFGG/

[SSSD-users] Re: SSSD attempts Dyndns updates for loopback address [SEC=UNOFFICIAL]

[Jakub Hrozek]

This sounds like a bug. We should never update DNS with loopback addresses and 
I’m sure we at least had checks in place to prevent this. Can you file a 
ticket, please?

> On 3 Aug 2018, at 08:06, Kosseck, Adam MR  wrote:
> 
> UNOFFICIAL
> 
> A number of DHCP linux workstation hosts in our environment were not updating 
> DNS.
> Logs in SSSD showed that the Dynamic DNS child was failing with status 256.
> Further investigation into the logs (with debug turned up past 5) showed that 
> the issue seems to be that SSSD is attempting to update both host and PTR DNS 
> records on the Windows DNS servers for the loopback address (127.0.0.1).
>  
> Dyndns Config in /etc/sssd/conf.d/.conf is:
>  
> [domain/example.com]
> Ad_hostname = host.fqdn
> Dyndns_update = true
> Dyndns_update_ptr = true
> Dyndns_ttl = 3600
> Dyndns_iface = 
>  
>  
> have the following in their hosts file:
>  
> # /etc/hosts
> 127.0.0.1  localhost
> 127.0.0.1  host.fqdn  host
> 198.168.x.x host.fqdn  host
>  
> Tested workstations are running SSSD 1.16.1 on Ubuntu 18.04.1 LTS.
>  
> Removing the second 127.0.0.1 line and reloading SSSD resolved the issue.
> I understand that having 127.0.0.1 against the FQDN is unusual, but this 
> “feature” is unfortunately required by a vendor product we are using.
> Is it possible for SSSD dyndns logic to be updated so that it ignores 
> loopback IPs?
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/GHM4IWSWDJCG65PI6ICVWU6XGRSVYFCD/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/TPAY2DPFCOOP2TRDFNWILRUGUBL7TWGF/

[SSSD-users] Re: login attributes not being updated

[Jakub Hrozek]

SSSD does not update any attributes on its own. Are you sure the users are not 
logging in with e.g. ssh public key which would bypass AD DCs during 
authentication completely?

> On 3 Aug 2018, at 17:15, Galen Johnson  wrote:
> 
> Hey,
> 
> I'm wondering if SSSD might not be updating some of the logon attributes in 
> AD.  We recently were directed to use updated DCs and some attributes no 
> longer seem to be getting updated; for example, logonCount and lastLogon.  In 
> some cases, the attribute is non-existant.  I'm leaning towards it being a DC 
> issue since it was gettting updated with the previous controllers but wanted 
> to see if anyone was aware of any reason SSSD could be at issue.
> 
> thanks
> 
> =G=
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/J5WOQKQDJRAHTYISIYXNTBROKXVTRKGO/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/WJ7DFXQVKNZSQJWQGUVMLRF5BGLQA5S4/

[SSSD-users] Re: sssd connecting to two AD domains

[Jakub Hrozek]

Are mydomain and mydomain2 coming from a different forest?

with id_provider=ad sssd should work fine with domains from the same forest and 
it should pick the right principal. If it doesn’t and setting ldap_sasl_authid 
to shortname$@realm, then there must be a bug in the principal selection logic.

> On 30 Jul 2018, at 11:25, Ondrej Valousek  wrote:
> 
> Ok, I see that it’s probably not supported:
> https://pagure.io/SSSD/sssd/issue/2078
> right?
> Ondrej
>  
> From: Ondrej Valousek [mailto:ondrej.valou...@s3group.com] 
> Sent: Monday, July 30, 2018 10:45 AM
> To: End-user discussions about the System Security Services Daemon 
> 
> Subject: [SSSD-users] sssd connecting to two AD domains
>  
> Hi all,
>  
> I have a machine joined to AD domain “mydomain.com” and there is also domain 
> “mydomain2.com”. The two are connected with full two way trust.
>  
> SSSD can happily recognize users from “mydomain.com”, but fails with users 
> from “mydomain2.com” - sssd complains that:
>  
> (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): 
> Port status of port 389 for server 'server.mydomain2.com' is 'not working'
> (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): 
> SSSD is unable to complete the full connection request, this internal status 
> does not necessarily indicate network port issues.
>  
> But I can connect to that server with ldapsearch just fine (using a TGT 
> obtained with kinit –k hostname$).
>  
> Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong 
> principal “host/hostname@REALM” instead of “hostname$@REALM”:
>  
>  
> (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): 
> Child responded: 14 [Client 'host/hostn...@mydomain.com' not found in 
> Kerberos database], expired on [0]
> (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): 
> Could not get TGT: 14 [Bad address]
> (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): 
> Cannot get a TGT: ret [1432158226](Authentication Failed)
>  
>  
> I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using 
> wrong principal?
> Using RHEL-7.
> Thanks,
>  
> Ondrej
> -
>  
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: communicati...@s3group.com. Thank You. 
> Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 
> 378073. Registered Office: South County Business Park, Leopardstown, Dublin 
> 18.
>  
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: 
> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
> (S3 Group). Registered in Ireland no. 378073. Registered Office: South County 
> Business Park, Leopardstown, Dublin 18.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/Z6H27YNJRSOZE6735CWXMKAHAH4STNNG/

[SSSD-users] Re: SSSD setup for authentication against AD using LDAP provider

[Jakub Hrozek]

> On 10 Aug 2018, at 02:29, Andre Piwoni  wrote:
> 
> Hi Jakub,
> 
> Here's my use case:
> I'm running Pgpool-II mainly for load balancing requests to PostgreSQL
> servers. While PgPool-II supports LDAP(AD) or GSSAPI/Kerberos, which I
> have working, I need PgPool authentication which supports LDAP(AD) via
> PAM module. PostgreSQL authorization does not utilize LDAP(AD) but
> database permissions so LDAP(AD) memberships etc. are not needed.
> 
> cat vi /etc/pam.d/pgpool
> #%PAM-1.0
> authrequiredpam_sss.so
> account requiredpam_sss.so
> 
> In addition to auth_provider now I have configured id_provider to be
> LDAP and I managed to get things to work after setting ldap_id_mapping
> = true. I'm trying to avoid to join domain which is why I'm using LDAP
> for AD.
> One thing that I had to do was to configure ldap_default_bind_dn and
> ldap_default_authtok, which sucks because I don't want to expose
> password for some admin account in file. I should be able to get basic
> info about user using provided credentials using simple non-anonymous
> bind as I've done in other projects.
> 

I’m not sure this is permitted by AD by default. I think AD requires you to 
authenticate in one way or another.

> What is odd is that search queries are performed first and than PAM
> Authentication with simple bind is done last.
> In addition, amount of LDAP queries for my simple case is excessive.
> 5 LDAP queries on objectClass=group for memberships even though I set
> ldap_group_nesting_level = 0. I have my memberships in memberOf
> attribute.

This might be https://pagure.io/SSSD/sssd/issue/3425 ?

> 1 LDAP query on objectClass=group for ObjectSID
> 1 LDAP query for my user info
> 2 LDAP queries for other stuff on objectClass=*
> 
> Is there a way to avoid using ldap_default_bind_dn and
> ldap_default_authtok for LDAP?

For generic LDAP yes, as a matter of fact, this is the default, but the client 
can only do what the server allows it to do.

> If so, does it mean that user to be
> authenticated has to have enough permissions to do searches in AD via
> LDAP?
> 
> Thank you,
> Andre
> On Thu, Aug 9, 2018 at 1:19 PM Jakub Hrozek  wrote:
>> 
>> On Thu, Aug 09, 2018 at 10:06:52AM -0700, Andre Piwoni wrote:
>>> There does not seem to be much documentation how to make
>>> authentication work without any extras. All I need is a simple
>>> non-anonymous bind using provided credentials without any searches. My
>>> understanding is that I don't need NSS for this only PAM with
>>> auth_provider set to ldap. However, without id_provider set in
>>> sssd.conf SSSD does not start at all. This has been reported as a bug
>>> and supposedly have been fixed before SSSD 1.16.0 version that I'm
>>> using. I have tried to set id_provider to none but I'm getting some
>>> indications in logs that id provider is needed. Is it possible to do
>>> simple non-anonymous bind without anything extra, not even chpass?
>> 
>> I'm not sure this is possible. One of the core design decisions of SSSD
>> was that a domain ties authentication and identity source -- so you do
>> need an id_provider to fetch the identity from somewhere.
>> 
>> That somewhere might not be the same server or not a remote server at
>> all, there is also the proxy id_provider that is able to wrap any nss
>> module, but there needs to be some ID provider.
>> 
>> What is the use-case you are trying to solve?
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BKVIAMB6KYGJTXNECDM5BPHWP3XE4JTG/
> 
> 
> 
> -- 
> 
> Andre Piwoni
> 
> Sr. Software Developer, BI/Database
> 
> WebMD Health Services
> 
> Mobile: 801.541.4722
> 
> www.webmdhealthservices.com
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/765EVHKNCV576BM5T72OVQJMVSKJKBLK/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/MNPV5NUPIIHRGL3PVBM5NEXRUEQMP7CF/

[SSSD-users] Announcing SSSD 1.16.3

[Jakub Hrozek]

gure.io/SSSD/sssd/issue/3777>`_ - If access check for a 
privileged pipe fails, the responder loops indefinitely
* `3776 <https://pagure.io/SSSD/sssd/issue/3776>`_ - Spurious check in the sssd 
nss memcache can cause the memory cache to be skipped
* `3774 <https://pagure.io/SSSD/sssd/issue/3774>`_ - Desktop Profile: The 10th 
policy is producing a wrong file name
* `3773 <https://pagure.io/SSSD/sssd/issue/3773>`_ - SSSD bails out saving 
desktop profiles in case an invalid profile is found
* `3767 <https://pagure.io/SSSD/sssd/issue/3767>`_ - Groups go missing with PAC 
enabled in sssd
* `3766 <https://pagure.io/SSSD/sssd/issue/3766>`_ - CVE-2018-10852: 
information leak from the sssd-sudo responder
* `3758 <https://pagure.io/SSSD/sssd/issue/3758>`_ - override_homedir should 
not apply to the files provider
* `3755 <https://pagure.io/SSSD/sssd/issue/3755>`_ - The search filter for 
detecting POSIX attributes in global catalog is too broad and can cause a high 
load on the servers
* `3754 <https://pagure.io/SSSD/sssd/issue/3754>`_ - SSSD AD uses LDAP filter 
to detect POSIX attributes stored in AD GC also for regular AD DC queries
* `3747 <https://pagure.io/SSSD/sssd/issue/3747>`_ - sss_ssh_authorizedkeys 
exits abruptly if SSHD closes its end of the pipe before reading all the SSH 
keys
* `3652 <https://pagure.io/SSSD/sssd/issue/3652>`_ - kdcinfo doesn't get 
populated for other domains
* `3607 <https://pagure.io/SSSD/sssd/issue/3607>`_ - Handle conflicting e-mail 
addresses more gracefully
* `3597 <https://pagure.io/SSSD/sssd/issue/3597>`_ - sssd doesn't allow user 
with expired password to login when PasswordgraceLimit set
* `3596 <https://pagure.io/SSSD/sssd/issue/3596>`_ - A combination of the same 
qualified and unqualified sudoUser causes Error: 17: File exists
* `3542 <https://pagure.io/SSSD/sssd/issue/3542>`_ - Get host key without 
proxying connection
* `3475 <https://pagure.io/SSSD/sssd/issue/3475>`_ - Full information regarding 
priority of lookup of principal  in keytab not in man page
* `3291 <https://pagure.io/SSSD/sssd/issue/3291>`_ - RFE: sssd in cross realm 
trust configuration should be use AD KDC from a list or site defined in the 
config file

Detailed Changelog
--


* Alexander Bokovoy (2): 

 * ipa provider: always use a special keytab to talk to a trusted DC 
 * ipa provider: expand search base to cover trusted domain objects 

* Alexey Sheplyakov (1): 

 * nss: skip incomplete groups instead of bailing out 

* Amit Kumar (1): 

 * Responder: simplify if-else structure in sss_dp_get_account_msg() 

* Fabiano Fidêncio (18): 

 * intg: Do not hardcode nsslibdir 
 * files: do not apply override_homedir to files provider 
 * tests: add override_homedir tests for files provider 
 * files: do not apply override_shell to files provider 
 * tests: add override_shell tests for files provider 
 * util: add is_files_provider() helper 
 * files: make use of is_files_provider() helper 
 * cache_req: keep the files provider as the first domain to be searched 
 * tests: add basic tests for 
cache_req_domain_new_list_from_domain_resolution_order() 
 * tests: add a test to ensure the output_fqnames is false for files 
provider 
 * deskprofile: don't bail if we fail to save one profile 
 * sdap: respect passwordGracelimit 
 * deskprofile: fix a typo in _get_filename_path() 
 * tests: add tests for ipa_deskprofile_get_filename_path() 
 * util: introduce sss_ssh_print_pubkey() 
 * ssh: make use of sss_ssh_print_pubkey() 
 * sss_ssh_knownhostsproxy: add option to only print the pubkey 
 * nss: remove unused label 

* Jakub Hrozek (38): 

 * Bumping the version to track the 1.16.3 development 
 * TESTS: Extend the schema with sshPublicKey attribute 
 * TESTS: Allow adding sshPublicKey for users 
 * TESTS: Add a basic SSH responder test 
 * SSH: Do not exit abruptly if SSHD closes its end of the pipe before 
reading all the SSH keys 
 * TESTS: Add a helper binary that can trigger the SIGPIPE to 
authorizedkeys 
 * TESTS: Add a regression test for SIGHUP handling in 
sss_ssh_authorizedkeys 
 * Revert "LDAP/IPA: add local email address to aliases" 
 * util: Remove the unused function is_email_from_domain 
 * TESTS: Allow storing e-mail address for users 
 * TESTS: Add regression test for looking up users with conflicting e-mail 
addresses 
 * AD/LDAP: Do not misuse the ignore_mark_offline to check if a connection 
needs to be checked for POSIX attribute presence 
 * MAN: Remove outdated notes from the re_expression description 
 * MAN: Document the re_expression needed to suport @-signs in the 
groupnames 
 * SUDO: Create the socket with stricter permissions 
 * AD: expose the helper function to format the site DNS query 
 * RESOL

[SSSD-users] Announcing SSSD 2.0

[Jakub Hrozek]

 relies
   on "python" which might not be available on all distributions

* There is a script that autogenerates code for the internal SSSD IPC.
  The script happens to call "python" which is not available on all
  distributions. Patching the ``sbus_generate.sh`` file to call e.g.
  python3 explicitly works around the issue

Tickets Fixed
-
 * `3717 <https://pagure.io/SSSD/sssd/issue/3717>`_ - Don't package 
sssd-secrets by default
 * `3685 <https://pagure.io/SSSD/sssd/issue/3685>`_ - KCM: Default to a new 
back end that would write to the secrets database directly
 * `3530 <https://pagure.io/SSSD/sssd/issue/3530>`_ - Remove 
CONFDB_DOMAIN_LEGACY_PASS
 * `3515 <https://pagure.io/SSSD/sssd/issue/3515>`_ - Disable host wildcards in 
sudoHost attribute (ldap_sudo_include_regexp=false)
 * `3494 <https://pagure.io/SSSD/sssd/issue/3494>`_ - Remove the special-case 
for RFC2307bis with zero nesting level
 * `3493 <https://pagure.io/SSSD/sssd/issue/3493>`_ - Remove the pysss.local 
interface
 * `3492 <https://pagure.io/SSSD/sssd/issue/3492>`_ - Remove support for 
ldap_groups_use_matching_rule_in_chain and 
ldap_initgroups_use_matching_rule_in_chain
 * `3304 <https://pagure.io/SSSD/sssd/issue/3304>`_ - Only build the local 
provider conditionally
 * `2926 <https://pagure.io/SSSD/sssd/issue/2926>`_ - Make list of local PAM 
services allowed for Smartcard authentication configurable

Detailed Changelog
--

* Amit Kumar (1): 

  * providers: disable ldap_sudo_include_regexp by default 

* Fabiano Fidêncio (19): 

  * man/sss_ssh_knownhostsproxy: fix typo pubkeys -> pubkey 
  * providers: drop ldap_{init,}groups_use_matching_rule_in_chain support 
  * ldap: remove parallel requests from rfc2307bis 
  * tests: adapt common_dom to files_provider 
  * tests: adapt test_sysdb_views to files provider 
  * tests: adapt sysdb-tests to files_provider 
  * tests: adapt sysdb_ssh tests to files provider 
  * tests: adapt auth-tests to files provider 
  * tests: adapt tests_fqnames to files provider 
  * sysdb: sanitize the dn on cleanup_dn_filter 
  * sysdb: pass subfilter and ts_subfilter to sysdb_search_*_by_timestamp() 
  * tests: adapt test_ldap_id_cleanup to files provider 
  * tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_certmap 
  * tests: remove LOCAL_SYSDB_FILE reference from 
test_sysdb_domain_resolution_order_ 
  * tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_subdomains 
  * tests: remove LOCAL_SYSDB_FILE reference from common_dom 
  * local: build local provider conditionally 
      * pysss: fix typo in comment 
  * pysss: remove pysss.local 

* Jakub Hrozek (55): 

  * Updating the version to track 1.16.4 development 
  * src/tests/python-test.py is GPLv3+ 
  * src/tests/intg/util.py is licensed under GPLv3+ 
  * src/tests/intg/test_ts_cache.py is licensed under GPLv3+ 
  * src/tests/intg/test_sudo.py is licensed under GPLv3+ 
  * src/tests/intg/test_sssctl.py is licensed under GPLv3+ 
  * src/tests/intg/test_ssh_pubkey.py is licensed under GPLv3+ 
  * src/tests/intg/test_session_recording.py is licensed under GPLv3+ 
  * src/tests/intg/test_secrets.py is licensed under GPLv3+ 
  * src/tests/intg/test_pysss_nss_idmap.py is licensed under GPLv3+ 
  * src/tests/intg/test_pam_responder.py is licensed under GPLv3+ 
  * src/tests/intg/test_pac_responder.py is licensed under GPLv3+ 
  * src/tests/intg/test_netgroup.py is licensed under GPLv3+ 
  * src/tests/intg/test_memory_cache.py is licensed under GPLv3+ 
  * src/tests/intg/test_local_domain.py is licensed under GPLv3+ 
  * src/tests/intg/test_ldap.py is licensed under GPLv3+ 
  * src/tests/intg/test_kcm.py is licensed under GPLv3+ 
  * src/tests/intg/test_infopipe.py is licensed under GPLv3+ 
  * src/tests/intg/test_files_provider.py is licensed under GPLv3+ 
  * src/tests/intg/test_files_ops.py is licensed under GPLv3+ 
  * src/tests/intg/test_enumeration.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_passwd.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_nss.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_netgroup.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_ldb.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_id.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_group.py is licensed under GPLv3+ 
  * src/tests/intg/secrets.py is licensed under GPLv3+ 
  * src/tests/intg/ldap_local_override_test.py is licensed under GPLv3+ 
  * src/tests/intg/ldap_ent.py is licensed under GPLv3+ 
  * src/tests/intg/krb5utils.py is licensed under GPLv3+ 
  * src/tests/intg/kdc.py is licensed under GPLv3+ 
  * src/tests/intg/files_ops.py is licensed under GPLv3+ 
  * src/tests/intg/ent_test.py is

[SSSD-users] Re: SSSD setup for authentication against AD using LDAP provider

[Jakub Hrozek]

On Thu, Aug 09, 2018 at 10:06:52AM -0700, Andre Piwoni wrote:
> There does not seem to be much documentation how to make
> authentication work without any extras. All I need is a simple
> non-anonymous bind using provided credentials without any searches. My
> understanding is that I don't need NSS for this only PAM with
> auth_provider set to ldap. However, without id_provider set in
> sssd.conf SSSD does not start at all. This has been reported as a bug
> and supposedly have been fixed before SSSD 1.16.0 version that I'm
> using. I have tried to set id_provider to none but I'm getting some
> indications in logs that id provider is needed. Is it possible to do
> simple non-anonymous bind without anything extra, not even chpass?

I'm not sure this is possible. One of the core design decisions of SSSD
was that a domain ties authentication and identity source -- so you do
need an id_provider to fetch the identity from somewhere.

That somewhere might not be the same server or not a remote server at
all, there is also the proxy id_provider that is able to wrap any nss
module, but there needs to be some ID provider.

What is the use-case you are trying to solve?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BKVIAMB6KYGJTXNECDM5BPHWP3XE4JTG/

[SSSD-users] Re: HowTo Handle an AD User rename?

[Jakub Hrozek]

I think this was fixed in a later version. With these old versions, just 
removing the cache should help.

> On 15 Aug 2018, at 17:12, Pete Klukowski  wrote:
> 
> Hello,
> 
> We have SSSD running on CentOS 7.3 communicating with Active Directory 
> (Server 2008 R2).
> 
> An AD account (e.g., msmith1) that had been synch'd with the SSSD service and 
> was working fine (both "id msmi...@domain.com" and "getent passwd msmith1" 
> succeeded) has been renamed to msmith.
> 
> Now on the CentOS/SSSD server if we, as root, su - to the newly renamed 
> msmith account we get messages such as, cannot find name for user ID 
> 151X17 and I have no name! (see below):
> /usr/bin/id: cannot find name for user ID 151X17
> /usr/bin/id: cannot find name for user ID 151X17
> [I have no name!@server ~]
> 
> Similarly, running id msmith results in:
> id: msmith: no such user
> 
> Lastly, unlike all the other sync'd /home/userid@DOMAIN .COM directories, the 
> owner of the /home/msmith directory on the CentOS/SSSD server shows 
> 151X17 as the owner rather than msm...@domain.com.
> 
> Can anyone please provide specific steps on how to re-create a working 
> /home/msm...@domain.com on the CentOS/SSSD server?  FWIW, there is nothing of 
> value in the current directory.
> 
> Thanks
> 
> 
>  
> 
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/5QCYLBXUHZZ5DIAVAVIJLANXK4SMR3XL/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/TZBBM7XL7PKWGTS6E4AZGDVXGFPY62YH/

[SSSD-users] Re: SSSD setup for authentication against AD using LDAP provider

[Jakub Hrozek]

On Wed, Aug 22, 2018 at 09:42:55AM -0700, Andre Piwoni wrote:
> AD allows simple authentication via simple non-anonymous bind with
> user credentials
> (https://msdn.microsoft.com/en-us/library/cc223499.aspx) and this is
> enough to get at least user account information, which includes basic
> group memberships. Most ADs that I worked with, in addition to
> authenticated user info, allow other browsing after this step. This
> includes extended group membership, like nested groups and info.

Ah, sorry, yes, I misread your earlier e-mail. You wrote:

> One thing that I had to do was to configure ldap_default_bind_dn and
> ldap_default_authtok, which sucks because I don't want to expose
> password for some admin account in file. 

And I skipped the 'admin' word and thought you dislike having a password
in the config file at all and were looking for using an anonymous bind.

> I should be able to get basic
> info about user using provided credentials using simple non-anonymous
> bind as I've done in other projects.

And this should be possible using ldap_default_bind_dn and
ldap_default_authtok
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/GEGFJMF5MJ7A3EI6I6CIUF57IMQFE5CR/

[SSSD-users] Re: "groups: cannot find name for group ID #####"

[Jakub Hrozek]

On Mon, Jul 23, 2018 at 11:08:54AM -0400, sssdusers.20.retin...@spamgourmet.com 
wrote:
> Unfortunately it seems to not be so easy:
> rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf
> ...
> #passwd: compat systemd sss
> #group:  compat systemd sss
> passwd: files sss
> group:  files sss
> shadow: files sss
> gshadow:files
> ...
> rtadmin@ubt18-test:~$ getent passwd user1
> user1:*:30335:33111:User One:/users/user1:/bin/bash
> rtadmin@ubt18-test:~$ groups user1
> user1 : unix_users groups: cannot find name for group ID 33118
> 33118
> 
> Curiously, when I did `getent passwd user1` it seems to have resolved and
> cached the primary group, but not any secondary groups.
> 
> Discussing `sss_cache -E`,
> rtadmin@ubt18-test:~$ sudo  sss_cache -E
> rtadmin@ubt18-test:~$ groups user1
> user1 : groups: cannot find name for group ID 33111
> 33111 groups: cannot find name for group ID 33118
> 33118
> rtadmin@ubt18-test:~$ groups user2
> user2 : groups: cannot find name for group ID 33111
> 33111
> rtadmin@ubt18-test:~$ getent passwd user2
> user2:*:30255:33111:User Two:/users/user2:/bin/bash
> rtadmin@ubt18-test:~$ groups user2
> user2 : groups: cannot find name for group ID 33111
> 33111
> # (note that user2 is not in group 33118.)

There are two issues. One is that initgroups does not find the
supplementary groups and the other that the group ID cannot be resolved.
For both it would be nice to see the logs, but since you were modifying
nsswitch.conf -- is there an initgroups: line there at all? If not, it's
fine because libc falls back to the groups: line, but if initgroups: is
specified, it must contain sss as well.

> 
> -- and that also shoots down my assumption regarding `getent passwd `
> causing the primary group to be cached.
> 
> 
> 
> On Fri, Jul 20, 2018 at 5:55 PM, Joakim Tjernlund -
> joakim.tjernl...@infinera.com <
> sssdusers.retinkab.d133d58ee0.Joakim.Tjernlund#sssd-users@lists.fedorahosted.org>
> wrote:
> 
> > Start with replacing compat with files in nsswitch.conf
> >
> >

> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/WNJZ6NRRSSN5UBVXSP34OUPVNMYDGVX2/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XYYPS4JKVNRLJKOBUNI46A7SDMSA2RCF/

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Jakub Hrozek]

On Mon, Jul 23, 2018 at 12:05:49PM -0400, Mario Rossi wrote:
> 
> I am seeing similar issues on CentOS 7, where groups, including primary
> group, cannot be looked up. This is really bad when other services depend on
> group lookups, for example sshd match group statements for enabling
> tcpforwarding which otherwise is disable globally, iptables group lookups (
> yes, I use both ).
> 
> [root@snoopy ~]$ rpm -q sssd
> sssd-1.16.0-19.el7_5.5.x86_64
> 
> root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service
> sssd start
> Redirecting to /bin/systemctl stop sssd.service
> Redirecting to /bin/systemctl start sssd.service
> 
> root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
> uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102
> 
> 
> root@snoopy[/etc/sssd]# *getent -s sss group
> development-wholes...@hostopia.com*
> development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
> 
> root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
> uid=11158(ezaporozhets)*gid=1004(development-wholesale)
> **groups=1004(development-wholesale),1102*
> 
> I tried setting ldap_use_tokengroups = false at domain level, however still
> seeing the issue. I use ldap provider.

Then tokengroups are not relevant at all, it's an AD provider option
primarily.

I would suggest to gather the logs (and even better, start a separate
thread so the two don't mixed up..)

> 
> Thank you
> 
> On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
> > 
> > > On 22 Jul 2018, at 20:49, Spike White  wrote:
> > > 
> > > I can't replicate that "duplicate domains" situation any more.  (I 
> > > thought I'd saved that sssd.conf file, but it doesn't exhibit the same 
> > > behaviour).
> > > 
> > > Here are the logs for a specific account failing to look up all groups 
> > > with ldap_use_tokengroups = True.
> > > 
> > > Logs are at this URL:
> > > 
> > > https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0
> > > 
> > > I have included the realmd.conf, sssd.conf and krb5.conf as well.
> > > 
> > > Here's (incorrect) result back from sssd with ldap_use_tokengroups = True
> > > 
> > > [root@spikerealmd02 sssd]# id admpatrick_wheeler
> > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> > > groups=2604370(admpatrick_wheeler),1010(amerunixusers)
> > > 
> > Thank you, now the logs are more helpful. What I see is repetition of “cant 
> > find domain for $SID”. And I believe this is because the subdomains 
> > provider is disabled, because (quite confusingly) the subdomains provider 
> > is also responsible for fetching information about the joined domain, like 
> > its SID or the NetBIOS name.
> > 
> > So I think there are three options:
> > 1) add ad_enabled_domains=$self to each of the domains, e.g. add 
> > ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should 
> > make sssd fetch info about that domain only. I know you wrote earlier that 
> > this gave you some other headaches, but if it does, then there’s another 
> > bug..
> > 2) try to help sssd by setting the domain SID manually with the 
> > ldap_idmap_default_domain_sid option
> > 3) just use tokengroups=false as a workaround.
> > 
> > > Here is correct result back when ldap_use_tokengropus = False:
> > > 
> > > [root@spikerealmd02 sssd]# id admpatrick_wheeler
> > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> > > groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)
> > > 
> > > this is sssd version 1.16.0
> > > 
> > > Spike
> > > 
> > > 
> > > 
> > Thanks, this is more helpful
> > > On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek  wrote:
> > > 
> > > 
> > > > On 13 Jul 2018, at 17:40, Spike White  wrote:
> > > > 
> > > > Jakub,
> > > > 
> > > > Thank you to answering so promptly.
> > > > 
> > > > We are currently testing this in a lab before full deployment, so I 
> > > > have some degree of time before we deploy sssd in a bigger context.  If 
> > > > you would prefer for me to work with you directly off-line, plea

[SSSD-users] Re: problem login in with AD account after joined to the AD domain

[Jakub Hrozek]

0x0100): ruser:
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): rhost: 172.17.253.11
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): authtok type: 0
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): newauthtok type: 0
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): priv: 1
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): cli_pid: 70882
> 
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): logon name: not set
> 
> 
> 
> ==> /var/log/sssd/sssd.log <==
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [sbus_conn_register_path] (0x0400):
> Registering object path /org/freedesktop/sssd/monitor with D-Bus connection
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400):
> Registering interface org.freedesktop.DBus.Properties with path
> /org/freedesktop/sssd/monitor
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400):
> Registering interface org.freedesktop.DBus.Introspectable with path
> /org/freedesktop/sssd/monitor
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [client_registration] (0x0100): Received
> ID registration: (pam,1)
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [mark_service_as_started] (0x0200):
> Marking pam as started.
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [client_registration] (0x0100): Received
> ID registration: (nss,1)
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [mark_service_as_started] (0x0200):
> Marking nss as started.
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [mark_service_as_started] (0x0400): All
> services have successfully started, creating pid file
> 
> (Mon Jul 23 14:24:48 2018) [sssd] [notify_startup] (0x0400): Sending
> startup notification to systemd
> 
> (Mon Jul 23 14:24:53 2018) [sssd] [services_startup_timeout] (0x0400):
> Handling timeout
> 
> 
> 
> ==> /var/log/sssd/sssd_nss.log <==
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
> CR #4: Checking negative cache for [grp-linux-adm...@corp.example.com]
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
> CR #4: [grp-linux-adm...@corp.example.com] is not present in negative cache
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> CR #4: Looking up [grp-linux-adm...@corp.example.com] in cache
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [sysdb_get_user_members_recursively]
> (0x0400): No such entry
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
> #4: Returning [grp-linux-adm...@corp.example.com] from cache
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_search_ncache_filter]
> (0x0400): CR #4: This request type does not support filtering result by
> negative cache
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_create_and_add_result]
> (0x0400): CR #4: Found 1 entries in domain corp.example.com
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [cache_req_done] (0x0400): CR #4:
> Finished: Success
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [client_recv] (0x0200): Client
> disconnected!
> 
> (Mon Jul 23 14:25:37 2018) [sssd[nss]] [client_recv] (0x0200): Client
> disconnected!
> 
> 
> 
> ==> /var/log/sssd/sssd_pam.log <==
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_print_data] (0x0100):
> newauthtok type: 0
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> 70882
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_print_data] (0x0100): logon
> name: mahdavif
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_dom_forwarder] (0x0100):
> pam_dp_send_req returned 0
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200):
> received: [0 (Success)][corp.example.com]
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [0]: Success.
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [filter_responses] (0x0100):
> [pam_response_filter] not available, not fatal.
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 32
> 
> (Mon Jul 23 14:25:37 2018) [sssd[pam]] [client_recv] (0x0200): Client
> disconnected!
> 
> 
> On Mon, Jul 23, 2018 at 1:15 AM, Jakub Hrozek  wrote:
> 
> >
> >
> > > On 22 Jul 2018, at 22:47, Farshid Mahdavipour 
> > wrote:
> > >
> > > Hi,
> > >
> > > I have configured sssd.service to authenticate to AD on RHE

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Jakub Hrozek]

> On 22 Jul 2018, at 20:49, Spike White  wrote:
> 
> I can't replicate that "duplicate domains" situation any more.  (I thought 
> I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour).
> 
> Here are the logs for a specific account failing to look up all groups with 
> ldap_use_tokengroups = True.
> 
> Logs are at this URL:
>https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0
> 
> I have included the realmd.conf, sssd.conf and krb5.conf as well.
> 
> Here's (incorrect) result back from sssd with ldap_use_tokengroups = True
> 
> [root@spikerealmd02 sssd]# id admpatrick_wheeler
> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> groups=2604370(admpatrick_wheeler),1010(amerunixusers)
> 

Thank you, now the logs are more helpful. What I see is repetition of “cant 
find domain for $SID”. And I believe this is because the subdomains provider is 
disabled, because (quite confusingly) the subdomains provider is also 
responsible for fetching information about the joined domain, like its SID or 
the NetBIOS name.

So I think there are three options:
1) add ad_enabled_domains=$self to each of the domains, e.g. add 
ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make 
sssd fetch info about that domain only. I know you wrote earlier that this gave 
you some other headaches, but if it does, then there’s another bug..
2) try to help sssd by setting the domain SID manually with the 
ldap_idmap_default_domain_sid option
3) just use tokengroups=false as a workaround.

> Here is correct result back when ldap_use_tokengropus = False:
> 
> [root@spikerealmd02 sssd]# id admpatrick_wheeler
> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)
> 
> this is sssd version 1.16.0
> 
> Spike
> 
> 
> 

Thanks, this is more helpful
> 
> On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek  wrote:
> 
> 
> > On 13 Jul 2018, at 17:40, Spike White  wrote:
> > 
> > Jakub,
> > 
> > Thank you to answering so promptly.  
> > 
> > We are currently testing this in a lab before full deployment, so I have 
> > some degree of time before we deploy sssd in a bigger context.  If you 
> > would prefer for me to work with you directly off-line, please advise.  As 
> > an example, the attached sssd_amer.dell.com.log file was originally 40 MB.  
> > (I presume because of debugging level).  Out of respect for others on the 
> > mailing list, I severely trimmed the log file to only the lines of interest 
> > (I hope).  But it's entirely possible I may have over-trimmed.
> > 
> 
> I’m afraid so, because the logs say:
> 
> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] 
> (0x2000): No sub-attributes for [tokenGroups]
> ….
> 
> and I’m really interested in this part :-)
> 
> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] 
> [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for 
> [admpatrick_whee...@amer.dell.com]
> ...
> (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] 
> [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN 
> [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use 
> associated map
> 
> 
> > You asked:
> > Can you send logs for a single lookup of "id username" with tokengroups 
> > enabled? 
> > 
> > Attached are the logs.  sssd_amer.dell.com.log and sssd_nss.log, for this 
> > lookup:
> > 
> >[root@spikerealmd02 sssd]# id admpatrick_wheeler
> >uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> > groups=2604370(admpatrick_wheeler),1010(amerunixusers)
> > 
> > This is with ldap_use_tokengroups = True, so the above lookup is incorrect.
> > 
> > What it should show is:
> >  id admpatrick_wheeler 
> > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> > groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
> > 
> > You asked:
> >Why do you disable the subdomains provider? Isn't it easier to just list
> >the domains you want to enable using the ad_enabled_domains option?
> > 
> >btw this can actually cause issues because the subdomains provider is
> >needed to fet

[SSSD-users] Re: 1.16.2 test failure: sss_nss_idmap-tests

[Jakub Hrozek]

Unfortunately these tests don’t have an option to raise the debug level so 
stepping throught them with gdb is the only option I’m afraid..

> On 20 Jul 2018, at 20:56, Andreas Hasenack  wrote:
> 
> What I figured out so far is that this is a test that is enabled if
> you have cmocka installed, and this is the first time I had that.
> On Fri, Jul 20, 2018 at 2:22 PM Andreas Hasenack  
> wrote:
>> 
>> Hi,
>> 
>> I'm building 1.16.2 with just
>> https://pagure.io/SSSD/sssd/c/a2cc554f438c220b3cc73eb93879dd87795a86cd?branch=master
>> applied (without it, it doesn't build in Ubuntu currently) and I'm
>> seeing this test failure:
>> 
>> [==] Running 2 test(s).
>> [ RUN  ] test_getsidbyname
>> [  ERROR   ] --- 0x2 != 0
>> [   LINE   ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:121: error: 
>> Failure!
>> [  FAILED  ] test_getsidbyname
>> [ RUN  ] test_getorigbyname
>> [  ERROR   ] --- 0x2 != 0
>> [   LINE   ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:140: error: 
>> Failure!
>> [  FAILED  ] test_getorigbyname
>> [==] 2 test(s) run.
>> [  PASSED  ] 0 test(s).
>> [  FAILED  ] 2 test(s), listed below:
>> [  FAILED  ] test_getsidbyname
>> [  FAILED  ] test_getorigbyname
>> 
>> 2 FAILED TEST(S)
>> FAIL sss_nss_idmap-tests (exit status: 2)
>> 
>> I tried with samba 4.7.6 and 4.8.2 installed, and also with
>> --with-smb-idmap-interface-version 5 and 6, same result. Debian is at
>> 1.16.2 and the tests pass there just fine, so I think I'm looking at
>> some dependency problem.
>> ldb is 1.3.1
>> tdb is 1.3.15
>> 
>> Any pointers? Maybe a way to run just that test, so I can add
>> debugging statements?
>> 
>> Thanks!
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/UB32RZUSGRALDIPPDUSJIT6CSTCSM3F6/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/J2ZV2J3CFB64BH7SGYR5TB432CIZVF3K/

[SSSD-users] Re: Am I blocked on sssd-users mailing list?

[Jakub Hrozek]

> On 19 Jul 2018, at 15:37, Spike White  wrote:
> 
> All,
> 
> I fear I may be blocked.  I responded to an email thread, with an email that 
> had two small attachments.
> 
> That was wrong.  I read the mailing list by-laws and I realize that was 
> wrong.  I will not repeat that offense.  As the guidelines suggest, if I need 
> to send logs I'll post somewhere publicly and reference those URLs.
> 
> But I fear my transgression seems to have blocked my email address on 
> sssd-users mailing list.  Sending this short email to confirm.

You’re not blocked from the list (and I don’t remember anyone being blocked, 
ever..). What might have happened is that the mail might have gotten stuck in 
the moderation queue because the attachment was too large..

> 
> Spike
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/5EMICYRTWWL47SN2RZIMSGIFLSFTUYLB/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BK576KQ4BM65EOMZP2UI5XW6TU43LI7B/

[SSSD-users] Re: problem login in with AD account after joined to the AD domain

[Jakub Hrozek]

> On 22 Jul 2018, at 22:47, Farshid Mahdavipour  wrote:
> 
> Hi,
> 
> I have configured sssd.service to authenticate to AD on RHEL 7.5 and i have 
> successfully joined the rhel machine to AD.
> but i cannot login to the machine with the AD account.
> 
> here is the error when i try to login with the AD credential:
> mahdavif@172.17.248.71's password:
> Last login: Sun Jul 22 18:59:23 2018 from 172.17.253.11
> This account is currently not available.

I honestly don’t know without logs, see e.g. 
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

> Connection to 172.17.248.71 closed.
> 
> here is the sssd.conf:
> # cat /etc/sssd/sssd.conf
> ad_server = srv_addcp001, srv_addcp002
> [sssd]
> domains = corp.example.com
> config_file_version = 2
> services = nss, pam
> [domain/corp.example.com]
> ad_domain = corp.example.com
> krb5_realm = CORP.example.com
> krb5_auth_timeout = 60
> realmd_tags = manages-system joined-with-adcli
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> override_shell = /bin/bash
> ldap_id_mapping = False
> use_fully_qualified_names = False
> fallback_homedir = /home/%u@%d
> access_provider = ad
> ad_server = srv_addcp001, srv_addcp002
> 
> here is the output of the realm list:
> # realm list
> corp.example.com
>   type: kerberos
>   realm-name: CORP.example.com
>   domain-name: corp.example.com
>   configured: kerberos-member
>   server-software: active-directory
>   client-software: sssd
>   required-package: oddjob
>   required-package: oddjob-mkhomedir
>   required-package: sssd
>   required-package: adcli
>   required-package: samba-common-tools
>   login-formats: %U
>   login-policy: allow-realm-logins
> 
> This is the /var/log/secure when trying to login :
> Jul 22 17:13:05 azrlvm003 sshd[7202]: pam_sss(sshd:auth): authentication 
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 
> user=mahdavif
> Jul 22 17:13:05 azrlvm003 sshd[7202]: Accepted password for mahdavif from 
> 172.17.253.11 port 41628 ssh2
> Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session opened 
> for user mahdavif by (uid=0)
> Jul 22 17:13:06 azrlvm003 sshd[7209]: Received disconnect from 172.17.253.11 
> port 41628:11: disconnected by user
> Jul 22 17:13:06 azrlvm003 sshd[7209]: Disconnected from 172.17.253.11 port 
> 41628
> Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session closed 
> for user mahdavif

And here pam_sss is not even called, but the user seems to be found by 
pam_unix. This might indicate that the user is also present in the passwd/group 
files which is not recommended.

> 
> sssd --version
> 1.16.0
> 
> I really appreciate if you can help me.
> Thanks
> Farshid
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DFHOAB3FDTP5YTUZAZPUUNHOUN3YNVCM/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ISBQ3ZJWQOPEKQJNYPZDPFB5AAKDVUNN/

[SSSD-users] Re: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP

[Jakub Hrozek]

> On 23 Jul 2018, at 04:05, Mark Johnson  wrote:
> 
> I've been going around in circles with this for days and I'm stuck.  I'm 
> trying to run up a new AD environment with only Samba 4.8.3 servers that 
> we'll authenticate user server access against via SSSD/LDAP using a simple 
> bind.  All of our servers are either CentOS 6 or 7.
> 
> I've created a test environment with a single Samba AD 4.8.3 server as the AD 
> server, a Windows 7 client to run RSAT and a CentOS 6 and CentOS 7 server to 
> test user authentication.  The Samba server is up and running and I can 
> manage the directory via RSAT.  I've set up the CentOS 6 server and can 
> successfully authenticate user logins on this via using SSSD/LDAP to the AD.  
> However, the issue I have is with the CentOS 7 server.  I've basically copied 
> the SSSD config from the CentOS 6 server so everything is the same.  However, 
> when I start SSSD on the CentOS 7 server, it binds successfully and does an 
> initial searchRequest which it gets a result from but after doing the 
> subsequent searchRequests on Configuration, ForestDnsZones and DomainDnsZones 
> I just see a RST from the server and the whole process starts over again.  
> Over the third failure, SSSD fails to start and stops trying.
> 
> Comparing packet captures on the AD server when starting SSSD on both 
> servers, the initial ROOT search request and response are identical as is the 
> bind request and response.  However, the first wholeSubtree search request is 
> where things start looking different.  On the CentOS 6 server, it shows a 
> filter in the request of:
> Filter: (&(&(cn=smtp)(ipServiceProtocol=dccp))(objectclass=ipService))
> and there are 4 attributes in the request - objectClass, cn, ipServicePort, 
> ipServiceProtocol
> 
> Whereas on the CentOS 7 server, the filter looks like this:
> Filter: 
> (&(objectClass=sudoRole)(|(|(|(|(|(|(|(|(|(!(sudoHost=*))(sudoHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost=ldaptest7))(sudoHost=192.168.193.62))(sudoHost=192.168.192.0/23))(sudoHost=fe80::5054:ff:fef2:26ed))(sudoHost=fe80::/6
> with 13 attributes - objectClass, cn, and a bunch of sudo attributes.
> 
> The response from the Samba server to each of these is nearly identical.  
> Both servers then send searchRequests for Configuration, ForestDnsZones and 
> DomainDnsZones but with the same filter differences above.  This is the point 
> of failure for the CentOS 7 server.  The other server gets a successful 
> response from the Samba server, but the CentOS 7 server just gets an ACK.  
> When I up the debug level on SSSD on the CentOS 7 server, I see a few 
> different errors but I'm not sure which of these show cause or effect.  
> Examples...
> 
> (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] 
> [common_parse_search_base] (0x0100): Search base added: 
> [SUDO][dc=ad,dc=company,dc=com][SUBTREE][]
> (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] 
> [common_parse_search_base] (0x0100): Search base added: 
> [AUTOFS][dc=ad,dc=company,dc=com][SUBTREE][]
> (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_client_register] 
> (0x0100): Cancel DP ID timeout [0x55941e9a6860]
> (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_find_method] 
> (0x0100): Target [subdomains] is not initialized
> (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] 
> [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. 
> Target is not supported with this configuration.
> 
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] 
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] 
> [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 
> 'resolving name'
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] 
> [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 'name 
> resolved'
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] 
> [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level 
> to [4]
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_cli_auth_step] 
> (0x0100): expire timeout is 900
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [simple_bind_send] 
> (0x0100): Executing simple bind as: s...@ad.company.com
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [fo_set_port_status] 
> (0x0100): Marking port 389 of server '192.168.192.50' as 'working'
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] 
> [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 
> 'working'
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_run_online_cb] 
> (0x0080): Going online. Running callbacks.
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_ptask_enable] 
> (0x0080): Task [SUDO Smart Refresh]: already enabled
> (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_process_result] 
> (0x0040): ldap_result error: [Can't contact LDAP server]

hmm, 

[SSSD-users] Re: problems with sssd-1.9

[Jakub Hrozek]

> On 18 Jul 2018, at 21:13, Laack, Andrea P  wrote:
> 
> I have been tasked with joining a number of redhat/centos 5 servers to a 
> domain.  I found sssd-1.9 that would allow id_provider ad.  This is Centos 
> 5.11.

Well, the upstream 1.9 had the ad_provider bits, but they are not built by 
default IIRC, because the samba libraries on RHEL-5 were too old. You can check 
by running rpm -ql sssd and checking if there is libsss_ad.so..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HOYRVOP42MLPSXEM2OM46LRKYVFY7DGP/

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Jakub Hrozek]

> On 13 Jul 2018, at 17:40, Spike White  wrote:
> 
> Jakub,
> 
> Thank you to answering so promptly.  
> 
> We are currently testing this in a lab before full deployment, so I have some 
> degree of time before we deploy sssd in a bigger context.  If you would 
> prefer for me to work with you directly off-line, please advise.  As an 
> example, the attached sssd_amer.dell.com.log file was originally 40 MB.  (I 
> presume because of debugging level).  Out of respect for others on the 
> mailing list, I severely trimmed the log file to only the lines of interest 
> (I hope).  But it's entirely possible I may have over-trimmed.
> 

I’m afraid so, because the logs say:

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] 
(0x2000): No sub-attributes for [tokenGroups]
….

and I’m really interested in this part :-)

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] 
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for 
[admpatrick_whee...@amer.dell.com]
...
(Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] 
[sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN 
[CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use 
associated map


> You asked:
> Can you send logs for a single lookup of "id username" with tokengroups 
> enabled? 
> 
> Attached are the logs.  sssd_amer.dell.com.log and sssd_nss.log, for this 
> lookup:
> 
>[root@spikerealmd02 sssd]# id admpatrick_wheeler
>uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> groups=2604370(admpatrick_wheeler),1010(amerunixusers)
> 
> This is with ldap_use_tokengroups = True, so the above lookup is incorrect.
> 
> What it should show is:
>  id admpatrick_wheeler 
> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
> groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
> 
> You asked:
>Why do you disable the subdomains provider? Isn't it easier to just list
>the domains you want to enable using the ad_enabled_domains option?
> 
>btw this can actually cause issues because the subdomains provider is
>needed to fetch the joined domain SID at least, among other things. 
> 
> When I ran with:
>   ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, 
> japn.dell.com, dell.com
> 
> it broke cross-subdomain authentication.  that is, I could resolve accounts 
> from the local domain (AMER), but not from any other domain (like apac).  
> When I reviewed the logs, I saw the sssd_nss.log would do a dispatch to the 
> apac.dell.com child, but the dispatch would always fail.
> 
> In sssd_apac.dell.com.log -- the dispatch was never picked up.

Interesting, do you still have the logs around?

> 
> I also noticed that sssctl domain-list gave me this:
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> dell.com
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com

Including the duplicate domains? That sounds like a bug..

> 
> I suspect that sssd_nss was attempting to dispatch into this apac.dell.com 
> "ghost" domain and failing.  When I removed ad_enabled_domains (& commented 
> out dell.com as a domain), I noticed sssctl domain-list gave me the expected:
> 
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> 
> And cross-subdomain authentication worked (modulo this tokengroups problem 
> where not all groups show up when tokengroups == True).
> 
> You stated:
> > ldap_schema = rfc2307bis
> 
> Please don't set ldap_schema to anything else than 'ad' (the default) with 
> id_provider=ad. 
> 
> Unfortunately, our erstwhile AD administrators when they extended our AD 
> schema years ago did not use an rfc2307 schema extension.  They used a 
> rfc2307bis schema extension instead.  
> 
> I had fits with even basic sssd AD integration until I realized this.  (I 
> thought I was going to have to manually set up ldap_filters for the few 
> quirky LDAP attributes associated with an account, but then I realized this 
> conformed 100% to rfc2307bis.) When I set ldap_schema to rfc2307bis, the 
> basic (same domain) authentication worked (without tokengroups).
> 

I meant something else. Internally in SSSD, ldap_schema=ad is a superset of 
rfc2307bis with some defaults tuned to be AD-specific. And the AD provider 
really does not expect the schema to be set to anything else, moreover there 
are some branches in the underlying LDAP provider (the AD provider is a wrapper 
around the LDAP provider more or less) that check if the schema is set to “ad” 
to follow some AD specific branch.

> Spike
> 
> On Tue, Jul 10, 2018 at 9:59 AM Jakub Hrozek  wrote:
&

[SSSD-users] Re: sss_override and ssh keys

[Jakub Hrozek]

> On 11 Jul 2018, at 15:28, John Hearns  wrote:
> 
> I have set up an sss_override for my user account
> 
> johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash
> 
> I also have an entry in the locla /etc/passwd file.
> When I ssh to a server running sssd my ssh key is accepted.
> 
> When I have no local /etc/passwd 
> When I ssh to a server running sssd my ssh key is not used and I am prompted 
> for a password

Is that a local SSH key stored in the user’s home or in LDAP? If a local one, 
then I think the only important thing is to tell SSH where to look at, so the 
homedir must be correct and of course the user must have the correct UID and 
GID to be allowed to enter that homedir.

> 
> Can anyone explain please?
> 
> The answer will be along the lines of at what stage in the ssh login the 
> override is being 'honoured'
> However this is a bit of a major problem. I guess also I will be told that I 
> have done something wrong.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ARZQMHUEUBXR53P7XG5QSFMDU6KHBK3O/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DL67YE2ZEIQ5LY2UCIVRRW5U7DLM7LMZ/

[SSSD-users] Re: one user can't be looked up

[Jakub Hrozek]

> On 13 Jul 2018, at 00:16, Peter Moody  wrote:
> 
> On Wed, Jul 11, 2018 at 12:39 AM Jakub Hrozek  wrote:
>> 
>> On Tue, Jul 10, 2018 at 08:14:15PM -0700, Peter Moody wrote:
>>> line breaks are in the original logs:
>> 
>> Right, I saw this, but can I see more context earlier in the logs? See
>> inline..
> 
> attached.
> 
> this is everything from sss_cache -E, to after 'id peter' returns info
> for user pmoody
> 
>> Could it be the user itself? I don't know exactly, that's why I asked
>> for more context..
> 
> it could be. I posted the current ldif's for both users in the first
> message. is there something else I should be looking?

Thank you for the logs, they show now clearly where the issue is happening, it 
looks like when setting the attributes for the user the user is not cached yet, 
which sounds bizzare because the user is looked up in the function before.

But I’m afraid that without stepping through the code with a debugger I won’t 
be able to find the reason..I guess I could add a patch with more debug data if 
you can apply it yourself (sorry, I have no idea how to patch a debian package) 
but currently the logs are not as helpful as I thought.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DN6UKB5NX4CWZIZGMFVU4DDRT6C3M2LP/

[SSSD-users] Re: Problem with kinit

[Jakub Hrozek]

> On 16 Jul 2018, at 11:48, John Hearns  wrote:
> 
> I have had my head inside the ldap_child.c source code all morning.
> I am getting these errors logged:
> 
> [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/
> i...@nzww.nzcorp.net' not found in Kerberos database

This is expected, in AD the host/fqdn principal cannot be used to get a TGT. As 
you can see below, you are using the netbiosname$@realm principal to kinit 
which works fine.

If your configuration is using id_provider=ad I would have expected sssd to 
prefer the netbiosname$ principal, but if the selection fails or you are using 
the ldap provider, you can help sssd with the ldap_sasl_authid parameter.

> 
> However the dialy ksktutil cron job I have running completes OK, and msktutil 
> --auto-update tells me the machine password was renewed two days ago.
> 
> Here is what happens when I run kinit from the command line.
> My workstation is called ibis.  Please someone hit me with a clue stick.
> 
> # kinit -k
> kinit: Client 'host/i...@nzww.nzcorp.net' not found in Kerberos database 
> while getting initial credentials
> 
> # kinit -V -k ibis$
> Using default cache: /tmp/krb5cc_0
> Using principal: ibis$@NZWW.NZCORP.NET
> Authenticated to Kerberos v5
> 
> # kinit -V -k IBIS\$@NZWW.NZCORP.NET
> Using default cache: /tmp/krb5cc_0
> Using principal: IBIS$@NZWW.NZCORP.NET
> Authenticated to Kerberos v5
> 
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/4DY3TSRSJBV5AU2P3CQH2UHH7GHXLOLV/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BPEL355LXLAJ4ZI7UVSFHJ5ZG6CUJIWI/

[SSSD-users] Re: Signature for recent downloads

[Jakub Hrozek]

Done, the key is now on pgp.mit.edu

The full story is that my usual computer died temporarily just as I was about 
to release the tarballs and my backup didn’t include ~/.gnupg. Oops. So the 
release was done from another machine where I also created the new keys.

> On 8 Sep 2018, at 15:31, Jan Engelhardt  wrote:
> 
> 
> sssd-1.16.3 and sssd-2.0.0 were signed with a new key that has not been
> published on the standard keyservers. Can you do that?
> 
> 15:30 a4:../ldap/sssd > gpg --verify sssd-2.0.0.tar.gz.asc
> gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in 
> dirmngr.conf
> gpg: keyserver option 'no-try-dns-srv' is unknown
> gpg: assuming signed data in 'sssd-2.0.0.tar.gz'
> gpg: Signature made 2018-08-13T21:37:45 CEST
> gpg:using RSA key 0x70C146062250BDFA
> gpg: Can't check signature: No public key
> 15:30 a4:../ldap/sssd > gpg --recv-keys 0x70C146062250BDFA
> gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in 
> dirmngr.conf
> gpg: keyserver option 'no-try-dns-srv' is unknown
> gpg: keyserver receive failed: No data
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd id getent and secondary groups in active directory

[Jakub Hrozek]

On Mon, Jul 09, 2018 at 01:45:57PM +0200, John Hearns wrote:
> One stupid question - is there an easy(ish) way to tell how deep a group
> heirarachy exists on a particular site?

I don't think so, without trying. However, looking at the code now, the
default nesting limit is only two levels deep by default and should
apply also to get-user-groups (previously I thought it applies to
get-group-members only)
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DBRREXN36IKMPLIGBIZLQGXLFPWJQ2XQ/

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Jakub Hrozek]

On Mon, Jul 09, 2018 at 03:11:38PM -0500, Spike White wrote:
> All,
> 
> Below is a writeup of missing AD groups for accounts when using
> tokengroups.  When not using tokengroups, sssd is rock solid.
> 
> Yes, most of the missing AD groups are universal or global groups -- but
> not all!  For some accounts, even domain-local AD groups are missed from
> their group memberships.  (when using tokengroups).

[...]

> tokengroups-disabled SSSD:
> 
> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1010(amerunixusers),1003(amerlinuxsup),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport)
> 
> 
> 
> vas:
> 
> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> groups=2604370(admpatrick_wheeler),
> 1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
> 
> 
> 
> diff is:
> 
> 1033(amer_server_mgmt)
> 
> 1003(amerlinuxsup)
> 
> 
> 
> amer_server_mgmt is an AMER global group with GID 1033.  <--- why is sssd
> not reporting this?!?

Can you send logs for a single lookup of "id username" with tokengroups
enabled?

> 
> amerlinuxsup is an AMER universal group with GID 1003.
> 
> 
> 
> 
> 
> 
> 
> Here is my /etc/sssd/sssd.conf file:
> 
> [nss]
> debug_level = 9
> filter_groups = root
> filter_users = root
> #entry_cache_timeout = 300
> entry_cache_nowait_percentage = 75
> 
> [sssd]
> debug_level = 6
> #domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com,dell.com
> domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
> # Unnecessary.  If missing, will search in order specified in "domains"
> lines above.
> #domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com,
> japn.dell.com, dell.com
> config_file_version = 2
> services = nss,pam
> reconnection_retries = 3
> #ldap_user_member_of = member
> 
> [pam]
> pam_verbosity = 3
> debug_level = 9
> 
> [domain/amer.dell.com]
> debug_level = 9
> id_provider = ad
> access_provider = simple
> #access_provider = ad
> auth_provider = ad
> ad_domain = amer.dell.com
> krb5_realm = AMER.DELL.COM
> default_shell = /bin/bash
> #use_fully_qualified_names = False
> ldap_id_mapping = False
> subdomains_provider = none

Why do you disable the subdomains provider? Isn't it easier to just list
the domains you want to enable using the ad_enabled_domains option?

btw this can actually cause issues because the subdomains provider is
needed to fetch the joined domain SID at least, among other things.

I would change this to:
ad_enabled_domains = amer.dell.com

> 
> auto_private_groups = True
> realmd_tags = joined-with-adcli
> cache_credentials = True
> krb5_store_password_if_offline = True
> fallback_homedir = /home/%u
> ldap_schema = rfc2307bis

Please don't set ldap_schema to anything else than 'ad' (the default)
with id_provider=ad. We should probably just disallow changing the
schema in the code completely.

> ldap_sasl_authid = host/spikerealmd02.us.dell@amer.dell.com
> #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> #ldap_sasl_authid = spikerealm...@amer.dell.com
> #TEST REMOVAL. July 4 2018. SW
> #ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,
> japn.dell.com,dell.com
> dyndns_update = False
> # TEST -- commented out July 4 to not use tokengroups.
> ldap_use_tokengroups = False
> simple_allow_groups = amerlinux...@amer.dell.com, amerlinux...@amer.dell.com,
> emealinux...@emea.dell.com, AMER.DELL.COM, emealinux...@emea.dell.com,
> apaclinux...@emea.dell.com, apaclinux...@emea.dell.com
> 
> # also look at
> https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.html
> 
> [domain/apac.dell.com]
> debug_level = 9
> auto_private_groups = True
> #use_fully_qualified_names = False
> ad_domain = apac.dell.com
> krb5_realm = APAC.DELL.COM
> cache_credentials = True
> id_provider = ad
> auth_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = False
> fallback_homedir = /home/%u
> access_provider = simple
> ldap_schema = rfc2307bis
> ldap_sasl_authid = host/spikerealmd02.us.dell@amer.dell.com
> #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> #ldap_sasl_authid = spikerealm...@amer.dell.com
> #TEST REMOVAL. July 4 2018. SW
> #ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com,
> japn.dell.com, dell.com
> dyndns_update = False
> subdomains_provider = none
> # TEST -- commented out July 4 to not use tokengroups.
> ldap_use_tokengroups = False
> simple_allow_groups = apaclinux...@apac.dell.com, apaclinux...@apac.dell.com
> 
> [domain/emea.dell.com]
> debug_level = 9
> auto_private_groups = True
> #use_fully_qualified_names = False
> ad_domain = emea.dell.com
> krb5_realm = EMEA.DELL.COM
> cache_credentials = 

[SSSD-users] Re: one user can't be looked up

[Jakub Hrozek]

On Fri, Jul 06, 2018 at 09:02:25AM -0700, Peter Moody wrote:
> On Tue, Jul 3, 2018 at 11:45 PM Sumit Bose  wrote:
> >
> > On Thu, Jun 28, 2018 at 07:46:29PM -0700, Peter Moody wrote:
> > > are there any logs I can provide to help anyone figure out why this is
> > > happening? I've (re-)confirmed that this behavior is present in 1.16.1
> >
> > Can you send your sssd.conf for a start.
> 
> Thanks!
> 
> pjm@deb:~$ sudo cat /etc/sssd/sssd.conf
> [nss]
> debug_level = 0x06f0
> filter_groups = root
> filter_users  = root
> 
> reconnection_retries = 3
> use_fully_qualified_names = true
> 
> [pam]
> debug_level = 0x46f0
> reconnection_retries = 3
> 
> [sssd]
> debug_level = 0x06f0
> config_file_version  = 2
> reconnection_retries = 3
> services = nss, pam
> domains = X.COM
> 
> [domain/x.com]
> debug_level= 0x46f0
> override_shell = /bin/bash
> ignore_group_members = true
> ldap_referrals = false
> enumerate  = false
> cache_credentials = true
> 
> id_provider = ldap
> access_provider = ldap
> auth_provider   = ldap
> 
> ldap_uri = ldaps://ldap.x.com
> ldap_search_base = dc=x,dc=com
> ldap_tls_cacert  = /etc/ldap/ca.pem
> 
> ldap_tls_reqcert  = demand
> ldap_id_use_start_tls = true
> 
> dns_discovery_domain   = x.com
> 
> ldap_schema = rfc2307
> ldap_access_order = expire
> ldap_account_expire_policy = ad
> ldap_force_upper_case_realm = true
> 
> ldap_user_search_base= ou=people,dc=x,dc=com
> ldap_group_search_base   = ou=groups,dc=x,dc=com
> ldap_user_object_class   = inetOrgPerson
> ldap_user_home_directory = homeDirectory
> ldap_group_object_class  = posixGroup
> # ldap_group_name = cn
> 
> #Bind credentials
> ldap_default_bind_dn = <...>
> ldap_default_authtok = <...>
> 
> pjm@deb:~$

Can you post more context from the logs before the message that says the
ldb transaction is being cancelled?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/EDJ6P2KRPHEVM3KTAMFMASAK3ZWMZAED/

[SSSD-users] Re: sssd id getent and secondary groups in active directory

[Jakub Hrozek]

On Fri, Jul 06, 2018 at 01:41:38PM +, Ratliff, John wrote:
> 
> 
> On Fri, 2018-07-06 at 10:55 +0200, Sumit Bose wrote:
> > On Thu, Jul 05, 2018 at 08:09:55PM +, Ratliff, John wrote:
> > > 
> > 
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_print_server]
> > (0x2000): Searching 134.68.239.131:389
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> > [no filter][CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =
> > 15
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_add]
> > (0x2000): New operation 15 timeout 6
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_result] (0x2000): Trace: sh[0x564b5d62f090],
> > connected[1], ops[(nil)], ldap[0x564b5d62d1e0]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_result] (0x2000): Trace: end of ldap_result list
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
> > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_message] (0x4000): Message type:
> > [LDAP_RES_SEARCH_ENTRY]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
> > (0x1000): OriginalDN: [CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
> > (0x1000): Entry has no attributes [0(Success)]!?
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
> > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_process_message] (0x4000): Message type:
> > [LDAP_RES_SEARCH_RESULT]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0),
> > no errmsg set
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_op_destructor] (0x2000): Operation 15 finished
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
> > [sdap_get_ad_tokengroups_done] (0x1000): No tokenGroups entries for [
> > jdrat...@ads.iu.edu]
> > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [ldb] (0x4000):
> > start ldb transaction (nesting: 0)
> > 
> > this makes SSSD assume that the user is not a member of any group.
> > 
> > Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
> > details) and check if the group memberships are reported more
> > reliable.
> > 
> > Afaik the issue with the tokenGroups might indicate that the used AD
> > DC
> > has issues reaching a Global Catalog server.
> 
> Thank you for the information. I don't know what to do about it at the
> moment. Adding that parameter makes id freeze when I run it. It seems
> to be unable to handle it when this parameter exists.

If the group membership is very deep and complex, running id might take
a very long time because without using tokenGroups, the group hierarchy
must be traversed from the user "up".

Looking at the debug logs might give a clue about what the sssd is
doing.

> 
> I'm unclear what you mean by AD DC has issues reaching the global
> catalog server. Do you mean my sever is having trouble, or the DC
> itself?
> 
> One more thing I found interesting. I made another RHEL7 box and used
> winbind instead of sssd and group membership works fine there.
> 
> I made another virtual machine and tried realmd/sssd again. I took it
> off the virtual machine NAT and gave it a public IP and disabled the
> firewall to make sure that wasn't causing any issues, but there was no
> change.
> 
> This still feel like an sssd configuration problem to me, though I'm
> not sure what to do about it at the moment.
> 
> Thanks for your assitance.
> 
> -- 
> John Ratliff
> Research Storage / UITS / Pervasive Technology Institute
> Indiana University | https://pti.iu.edu



> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/2FPUT7PHHJAYYKS57PUXPOG57OIJMGGW/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: 

[SSSD-users] Re: User accounts from AD domain, sudo rules from LDAP domain

[Jakub Hrozek]

> On 19 Jan 2018, at 15:03, Johannes-Ulrich Menzebach 
>  wrote:
> 
> We're currently evaluating moving our CentOS6 Linux workstations and servers 
> from OpenLDAP to AD, but would like to avoid the AD schema customization 
> needed to put sudo rules and autofs mappings there.
> 
> So we thought about keeping sudo and autofs info on the OpenLDAP 
> infrastructure, while authenticating against AD.
> 
> The latter works very nicely using  "id_provider=ad".
> 
> Regarding sudo and autofs info, in sssd.conf I have set up a 2nd domain with 
> id_provider=ldap and auth_provider=none, referring to the old OpenLDAP server.
> 
> Indeed I've got autofs working this way (mapping NFS home directories).
> 
> sudo however does not work. It seems sssd_sudo only searches in the cache 
> file containing info of the AD domain (which has no sudo info).
> The OpenLDAP domain ( it's ldb cache file actually carries the sudo rules as 
> per ldbsearch output) is apparently ignored - seems like the function 
> sudosrv_get_sudorules_from_cache() just looks into the AD domain's cache ( 
> where the account info of the current user stems from)
> 
> Is my "split" approach totally flawed?  Is there a way to make it work 
> without patching the sssd_sudo sources to iterate over all domain caches ?
> 

I’m afraid it is expected that this setup doesn’t work, because one of the 
design decisions about the SSSD domains was that data should not overflow from 
one domain to another. So a user can only leverage sudo rules from their own 
domain.

I haven’t tried this at all, but as long as the id_provider and auth_provider 
are using ad, could you just add sudo_provider=ldap and then your sudo OpenLDAP 
server with as value of ldap_uri? Since two providers of two different types 
also don’t share data, it might work.

An alternative is always to use the built-in sudo LDAP support..

> I can provide sssd.conf and log files. Just wanted to hear first about 
> whether the approach should work at all and possible alternatives ...
> 
> Many thanks for comments/hints/proposals,
> 
> 
> Uli
> 
> ___
> 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: System Error (4) for passwd users

[Jakub Hrozek]

On Tue, Jan 23, 2018 at 07:44:04PM -0500, goe...@gmail.com wrote:
> Hi,
> 
> The troubleshooting guide in the docs said to email the list if the System
> Error (4) shows up, so I figured I bring this issue up.  I'm running sssd
> version 1.16.0 on Debian testing and recently encountered a new behavior.
> We set up sssd with active directory based authentication on an already
> established system.  For various reasons there are still local passwd
> users, some of whom also have ad accounts.  What used to happen is that the
> pam/nsswitch stack was set up so that those users would end up with their
> passwd id.  If they had an ad account they could log in with either their
> shadow password or their ad password.  Right after we upgraded from
> 1.16.0-1 to 1.16.0-2 any local user generated a System Error (4) in the
> logs and and local users with ad accounts could no longer use their ad
> passwords (although they could still use their local passwords).  There
> isn't a lot of information in the logs.

Can you also paste your full configuration and the sssd domain log(s) ?

Does sssd on Debian use the implicit files provider (ps would show a
sssd_be process running with --name implicit_files)
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: System Error (4) for passwd users

[Jakub Hrozek]

On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote:
> Sorry about the line breaks.  Adding "enable_files_domain = false" to the 
> [sssd] section fixed the issue.  Just out of curiosity, could I ask what that 
> does?  Its not in the man page.  

SSSD has a feature which mirrors the local /etc/passwd and /etc/group
files for faster lookups of local users without having to enable nscd
which is tricky to operate together with sssd, especially if you run
sssd for a remote domain, too:
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
But I'm surprised that Debian would enable this feature without changing
the nsswitch.conf order like Fedora did. They probably should disable
the files domain by default..

The files domain is currently identity-only and no authentication is
performed. That, together with the duplicate users and the files domain
running by default has been causing the failures for you..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Apache/php integration

[Jakub Hrozek]

The new API is a C one, currently it’s used by slapi-nis only, I think.

I wonder if using the already existing D-Bus API would be an option? I don’t 
know how good or bad are PHP D-Bus bindigs, but looking up the e-mail address 
works for sure, check out e.g.:
https://github.com/jhrozek/fosdem2018/blob/master/dbus-api/dbus_example_simple.py

> On 9 Mar 2018, at 15:43, Ondrej Valousek  wrote:
> 
> Hi all,
>  
> I see there is a new client API available for sssd 1.16. Is it possible to 
> integrate it somehow with Apache/php?
> I.e. example: I authenticate user via mod_auth_gssapi obtaining username (and 
> possibly TGT) so I need to lookup user’s email address, say….
>  
> Ondrej
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: 
> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
> (S3 Group). Registered in Ireland no. 378073. Registered Office: South County 
> Business Park, Leopardstown, Dublin 18.
> ___
> 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: Announcing SSSD 1.16.1

[Jakub Hrozek]

> On 9 Mar 2018, at 14:45, Joakim Tjernlund <joakim.tjernl...@infinera.com> 
> wrote:
> 
> On Fri, 2018-03-09 at 13:28 +0100, Jakub Hrozek wrote:
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you recognize the sender and know the 
>> content is safe.
>> 
>> 
>> SSSD 1.16.1
>> ===
>> 
>> The SSSD team is proud to announce the release of version 1.16.1 of the
>> System Security Services Daemon.
>> 
>> The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/
>> 
>> RPM packages will be made available for Fedora shortly.
>> 
>> Feedback
>> 
>> Please provide comments, bugs and other feedback
>> via the sssd-devel or sssd-users mailing lists:
>>   https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>   https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>> 
> 
> Did a quick test here and it seems like enumerate = true is
> broken. Is it just me or .. ?

I don’t know about any bugs around enumeration in 1.16.1. Maybe you found an 
issue, but it’s hard to say without more context.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Experiencing a bug on users' name and ID

[Jakub Hrozek]

I think the next good step would be to show the LDIF and logs of a resolution 
of a single faulty entry, e.g. 80974 which you used earlier as an example of an 
entry that doesn’t work.

> On 28 Feb 2018, at 01:30, Asif Iqbal  wrote:
> 
> 
> 
> On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal  wrote:
> 
> 
> On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose  wrote:
> On Mon, Feb 26, 2018 at 10:21:14PM -0500, Asif Iqbal wrote:
> > I have 300 out of 3000 users whose /home/ dir shows uid and gid
> > instead of username and groupname.
> >
> > It seems to be behaving like a bug
> >
> > As soon I become a user with `sudo su - username' the uid of the home dir
> > changes to username but gid still does not change to groupname.
> >
> > I also get an error message, but still successfully become that user
> >
> > $ ls -ld /home/mbniels
> > drwx--. 3 80974 80974 4096 Feb 27 02:15 /home/mbniels
> >
> > $ su - mbniels
> > Last login: Tue Feb 27 02:34:04 UTC 2018 on pts/39
> > /usr/bin/id: cannot find name for group ID 80974
> > groups: cannot find name for group ID 80974
> >
> > $ ls -ld /home/mbniels
> > drwx--. 3 mbniels 80974 4096 Feb 27 02:15 /home/mbniels
> >
> > Then to check the groups of username I get another error which then gets
> > cleared by next command.
> >
> > $ groups mbniels
> > mbniels : groups: cannot find name for group ID 80974
> > 80974 users
> >
> > $ getent group mbniels
> > mbniels:*:80974
> >
> > $ groups mbniels
> > mbniels : mbniels users
> >
> > It also fixes the gid to groupname
> >
> > $ ls -ld /home/mbniels/
> > drwx--. 3 mbniels mbniels 4096 Feb 27 02:15 /home/mbniels/
> >
> > I noticed it reverts after may be within half an hour, not exact sure when.
> > Almost behaves like `quantum entanglement'.
> > As soon as I try to check by trying to become that user the issue
> > disappears.
> >
> > This is not just cosmetic issue, when the home dir shows ownership with
> > uid, instead of username, the user fails some commands.
> >
> > We just started noticing today, since we just built this box and only few
> > months ago and users are being invited to start using this server
> >
> > Some annoying error it is showing like below and user then fails to ssh
> >
> >  $ ssh remote
> > No user exists for uid 80974
> >
> > I am using centos 7 and  sssd 1.15.2
> >
> > $ cat /etc/redhat-release
> > CentOS Linux release 7.4.1708 (Core)
> >
> > $ sssd --version
> > 1.15.2
> >
> > Here are some relevant logs
> > https://paste.fedoraproject.org/paste/gBaZ-Vr8Urh-M5ABpaRNuA
> 
> It looks like you are not using a plain RFC2307bis LDAP schema. Can you
> send you sssd.conf and a typical LDAP user and group object?
> 
> bye,
> Sumit
> 
> 
> Here is an ldap user and I using same info as group (sanitized)
> 
>  dn: uid=mbniels,ou=People,dc=example,dc=com
> roomNumber: 123456
> departmentNumber: 3.11.3
> tier1: Technology
> joblevel: 6
> legacycompany: G
> mobile: +11234567890
> manager: uid=managerid,ou=People,dc=example,dc=com
> departmentname: TESTING & INTEG
> costcenter: S0019751
> companynumber: S001
> companyname: EXAMPLE COMPANY
> displayName: FOO, BAR
> preferredname: Mark
> docshareaccess: TRUE
> sAMAccountName: mbniels
> l: XX
> street: 123 example ave
> saploginid: foobar
> title: LEAD ARCHITECT
> postalCode: 123456
> employeeNumber: 00112233
> mail: foo@example.com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: mnetPerson
> mnetid: 080974
> uid: mbniels
> givenName: Mark
> st: XX
> cn: Foo Bar
> sn: Bar
> employeeType: Management
> initials: X
> nationnumber: USA
> nationname: United States
> 
> 
> 
> I am still looking for some help on this.
> 
> 
> 
> -- 
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> 
> ___
> 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: Multiple logins by the same user at the same host at nearly the exact time

[Jakub Hrozek]

> On 13 Mar 2018, at 04:44, Jim Richard  wrote:
> 
> result in:
> 
> pam_sss(sshd:account): Access denied for user rundeck: 4 (System error)
> 
> I know this has been an issue in the past per some info I see in places like:
> https://access.redhat.com/solutions/1477473
> 
> any chance there's been a regression bringing this issue back?
> 

System Error is the default catch-all if SSSD can’t map some internal error 
onto a more specific error code. A bit like an unhandled exception. You need to 
enable the debug logs as per 
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html and look into the 
logs what’s going on.

> 
>   Jim Richard 
> SYSTEM ADMINISTRATOR III
> (646) 338-8905  
> 
> 
> 
> ___
> 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: Multiple logins by the same user at the same host at nearly the exact time

[Jakub Hrozek]

> On 14 Mar 2018, at 20:14, Jim Richard <jrich...@placeiq.com> wrote:
> 
> Thanks.
> 
> I deployed a clean/new Fedora 27 minimal, installed ipa-client/sssd, we have 
> sssd version 1.16.0-6.fc27 on that virtual machine now, and then enrolled the 
> host in our FreeIPA.
> 
> Then I did a:
> service sssd stop ; rm -rvf /var/lib/sss/db/* ; rm -rvf /var/lib/sss/mc/* ; 
> rm -rvf /var/log/sssd/* ; service sssd start
> 
> added log level 9 to all sections of the sssd config file
> 
> Ran my test and then tar'd up the sssd log files and attached them here.
> I did look them over beforehand but I'm not seeing anything interesting that 
> I would recognize other than:
> 
> (Wed Mar 14 14:50:06 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200): 
> received: [4 (System error)][placeiq.net]
> 

There was a segfault coming from the selinux_child. We recently had a bug 
(fixed upstream already) where the selinux_child would segfault on a system 
where SELinux was completely disabled and also the selinux policy was not 
installed. Could it be your case?

If you don’t use the SELinux user context mapping feature, you can safely 
disable the selinux provider by setting selinux_provider=none.

> A little more background. 
> 
> Of course we don't run Fedora in production, it's all CentOS, mostly 7 and 
> some 6. And we use FreeIPA.
> 
> We use Rundeck (http://rundeck.org/) for job scheduling and we have a few 
> jobs that can, if not properly scheduled, trigger multiple logins to the same 
> host, by the same FreeIPA user, at the same time.
> 
> This did not used to cause problems but unfortunately Puppet pushed out an 
> update to sssd to all of our CentOS nodes last Friday, March 9 and with this 
> updated sssd version we started seeing failures.
> 
> 
> 
> 
> 
> 
> 
> 
>   Jim Richard 
> SYSTEM ADMINISTRATOR III
> (646) 338-8905  
> 
> 
> 
>> On Mar 13, 2018, at 6:41 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>> 
>> 
>> 
>>> On 13 Mar 2018, at 04:44, Jim Richard <jrich...@placeiq.com> wrote:
>>> 
>>> result in:
>>> 
>>> pam_sss(sshd:account): Access denied for user rundeck: 4 (System error)
>>> 
>>> I know this has been an issue in the past per some info I see in places 
>>> like:
>>> https://access.redhat.com/solutions/1477473
>>> 
>>> any chance there's been a regression bringing this issue back?
>>> 
>> 
>> System Error is the default catch-all if SSSD can’t map some internal error 
>> onto a more specific error code. A bit like an unhandled exception. You need 
>> to enable the debug logs as per 
>> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html and look into 
>> the logs what’s going on.
>> 
>>> 
>>> Jim Richard 
>>> SYSTEM ADMINISTRATOR III
>>> (646) 338-8905  
>>> 
>>> 
>>> 
>>> ___
>>> 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 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] Announcing SSSD 1.16.1

[Jakub Hrozek]

E: Add checks for user and host category
  * DESKPROFILE: Harden the permission of deskprofilepath
  * DESKPROFILE: Soften umask for the domain's dir
  * DESKPROFILE: Fix the permissions and soften the umask for user's dir
  * DESKPROFILE: Use seteuid()/setegid() to create the profile
  * DESKPROFILE: Use seteuid()/setegid() to delete the profile/user's dir
  * DESKPROFILE: Set the profile permissions to read-only
  * PYSSS_MURMUR: Fix [-Wsign-compare] found by gcc
  * DESKPROFILE: Document it doesn't work when run as unprivileged user

* Hristo Venev (1):

  * providers: Move hostid from ipa to sdap, v2

* Jakub Hrozek (35):

  * Update the version number to track 1.16.1 development
  * CONFIG: Add a new option auto_private_groups
  * CONFDB: Remove the obsolete option magic_private_groups
  * SDAP: Allow the mpg flag for the main domain
  * LDAP: Turn group request into user request for MPG domains if needed
  * SYSDB: Prevent users and groups ID collision in MPG domains except for 
id_provider=local
  * TESTS: Add integration tests for the auto_private_groups option
  * RESP: Add some missing NULL checks
  * TOOLS: Add a new sssctl command access-report
  * SDAP: Split out utility function sdap_get_object_domain() from 
sdap_object_in_domain()
  * LDAP: Extract the check whether to run a POSIX check to a function
  * LDAP: Only run the POSIX check with a GC connection
  * SDAP: Search with a NULL search base when looking up an ID in the 
Global Catalog
  * SDAP: Rename sdap_posix_check to sdap_gc_posix_check
  * DP: Create a new handler function getAccountDomain()
  * AD: Implement a real getAccountDomain handler for the AD provider
  * RESP: Expose DP method getAccountDomain() to responders
  * NEGCACHE: Add API for setting and checking locate-account-domain 
requests
  * TESTS: Add tests for the object-by-id cache_req interface
  * CACHE_REQ: Export cache_req_search_ncache_add() as cache_req private 
interface
  * CACHE_REQ: Add plugin methods required for the domain-locator request
  * CACHE_REQ: Add a private request cache_req_locate_domain()
  * CACHE_REQ: Implement the plugin methods that utilize the domain locator 
API
  * CACHE_REQ: Use the domain-locator request to only search domains where 
the entry was found
  * MAN: Document how the Global Catalog is used currently
  * IPA: Include SYSDB_OBJECTCATEGORY, not OBJECTCLASS in cache search 
results
  * MAN: Document that auth and access IPA and AD providers rely on 
id_provider being set to the same type
  * MAN: Improve enumeration documentation
  * MAN: Describe the constrains of ipa_server_mode better in the man page
  * IPA: Delay the first periodic refresh of trusted domains
  * AD: Inherit the MPG setting from the main domain
  * SYSDB: Fix sysdb_search_by_name() for looking up groups in MPG domains
  * SYSDB: Use sysdb_domain_dn instead of raw ldb_dn_new_fmt
  * SYSDB: Read the ldb_message from loop's index counter when reading 
subdomain UPNs
  * AD: Use the right sdap_domain for the forest root

* Lukas Slebodnik (51):

  * KCM: Fix typo in comments
  * CI: Ignore source file generated by systemtap
  * UTIL: Add wrapper function to configure logger
  * Add parameter --logger to daemons
  * SYSTEMD: Replace parameter --debug-to-files with ${DEBUG_LOGGER}
  * SYSTEMD: Add environment file to responder service files
  * UTIL: Hide and deprecate parameter --debug-to-files
  * KCM: Fix restart during/after upgrade
  * BUILD: Properly expand variables in sssd-ifp.service
  * SYSTEMD: Clean pid file in corner cases
  * CHILD: Pass information about logger to children
  * BUILD: Disable tests with know failures
  * SPEC: Reduce build time dependencies
  * sysdb-test: Fix warning may be used uninitialized
  * responder: Fix talloc hierarchy in sized_output_name
  * test_responder: Check memory leak in sized_output_name
  * confdb: Move detection files to separate function
  * confdb: Fix starting of implicit files domain
  * confdb: Do not start implicit_files with proxy domain
  * test_files_provider: Regression test for implicit_files + proxy
  * SDAP: Fix typo in debug message
  * Revert "intg: Disable add_remove tests"
  * libnfsidmap: Use public plugin header file if available
  * dyndns_tests: Fix unit test with missing features in nsupdate
  * Remove unnecessary script for upgrading debug_levels
  * Remove legacy script for upgrading sssd.conf
  * BUILD: Add missing libs found by -Wl,-z,defs
  * BUILD: Fix using of libdlopen_test_providers.so in tests
  * SYSDB: Decrese debuglevel in sysdb_get_certmap
  * KRB5: Pass special flag to krb5_child
  * krb5_child: Distinguish between expired & disabled AD user
  * AD: Suppre

[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4

[Jakub Hrozek]

> On 3 Apr 2018, at 02:24, Lachlan Musicman  wrote:
> 
> On 3 April 2018 at 08:23, Lachlan Musicman  wrote:
> On 29 March 2018 at 20:23, Valentin Fischer  wrote:
> Permission issue.
> 
> Reinstall sssd-common
> 
> 
> 
> I tried this on two different machines an it didn't work on either. Am 
> getting identical output.
> 
> 
> I found this old thread
> 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/
> 
> I tried running 
> 
> sssd -i -d9 
> 
> and it works fine, the /var/lib/sss/pipes have returned (I deleted them, 
> reinstalled sssd-common, they weren't replaced), and I can login successfully.
> 
> So it's just running 
> 
> systemctl start sssd
> or
> systemctl restart sssd
> 
> fails with the same errors as reported initially. So running manually in 
> interactive mode works, but starting via systemctl doesn’t

One difference I can think of between running the deamon on the foreground 
versus running as a service is SELinux context. Did you check if maybe there 
are some AVC denials if you run sssd as a service?

> .
> 

> I can't apply the update to production in that state, but if you want any 
> more logs or testing done, let me know.
> 
> Here are the permissions on the file system (I've not changed them by hand), 
> but they look the same as a working 1.16.0_4 sssd installation.
> 
> [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/
> total 8
> drwxr-xr-x.  3 sssd sssd   71 Apr  3 10:11 .
> drwxr-xr-x. 10 root root 4096 Mar 29 03:01 ..
> srw-rw-rw-   1 root root0 Apr  3 10:11 nss
> srw-rw-rw-   1 root root0 Apr  3 10:11 pac
> srw-rw-rw-   1 root root0 Apr  3 10:11 pam
> drwxr-x---.  2 sssd root 4096 Apr  3 10:11 private
> srw-rw-rw-   1 root root0 Apr  3 10:11 ssh
> srw-rw-rw-   1 root root0 Apr  3 10:11 sudo
> [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/private/
> total 4
> drwxr-x---. 2 sssd root 4096 Apr  3 10:11 .
> drwxr-xr-x. 3 sssd sssd   71 Apr  3 10:11 ..
> srw---  1 root root0 Apr  3 10:11 pam
> lrwxrwxrwx  1 root root   63 Apr  3 10:11 sbus-dp_mycompany.com -> 
> /var/lib/sss/pipes/private/sbus-dp_mycompany.com.3913
> srw---  1 root root0 Apr  3 10:11 sbus-dp_mycompany.com.3913
> srw---  1 root root0 Apr  3 10:11 sbus-monitor
> 
> 
> Cheers
> L.
> 
> 
> 
>  
>  
> On Thu 29. Mar 2018 at 00:20, Lachlan Musicman  wrote:
> Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't 
> restart.
> 
> ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) 
> 
> The journalctl -xe shows:
> 
> -- Unit sssd.service has begun starting up.
> Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up
> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service: 
> main process exited, code=exited, status=3/NOTIMPLEMENTED
> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to start 
> System Security Services Daemon.
> -- Subject: Unit sssd.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 
> The /var/log/sssd/sssd.log shows
> 
> 
> (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: 
> /var/lib/sss/db/config.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch 
> for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
> function resolv_conf_inotify_cb after delay 1.0
> (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): Using 
> re 
> [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
> (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq 
> format [%1$s].
> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB 
> File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): 
> Timestamp file for unixdev.company.com: 
> /var/lib/sss/db/timestamps_unixdev.company.com.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register 
> control with rootdse!
> (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): 
> dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, 
> message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": 
> Permission denied)
> (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: 
> /var/lib/sss/db/config.ldb
> (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch 
> for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
> function resolv_conf_inotify_cb after delay 1.0
> (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): Using 
> re 
> [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
> (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq 
> 

[SSSD-users] Re: Config for joining AD forest and Kerberos cross-domain authentication

[Jakub Hrozek]

> On 6 Apr 2018, at 17:54, Bastian Rosner  wrote:
> 
> Unfortunately, users from other domains can't use their Kerberos ticket, only 
> password works. These users are specifying their domain on login.

This all sounds like the issue is not on the SSSD level, but either the 
krb5.conf configuration might be perhaps missing the domain-realm mappings, but 
what you said next was interesting:

> Surprisingly, once logged in after authenticating with a password, 
> foreign-domain users are able to issue a Kerberos ticket with kinit if they 
> specify username@FQDN 

Hmm, are you saying that if you log in with a password you don’t get a TGT?
___
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-1.16.1 loses POSIX group mapped from AD trusted domain

[Jakub Hrozek]

> On 11 Apr 2018, at 17:26, a.miroshniche...@rtk-dc.ru wrote:
> 
> Hi,
> 
> We have AD-trusted FreeIPA environment.
> I installed sssd-1.16.1 on IPA servers and client hosts.
> Posix user group "ad_app_admins" mapped to app-admins@ADTrustedDomain.
> Sometimes AD user fails to login on hosts. sssd can not see mapping. AD user 
> groups show correct for user, but POSIX user group lost.
> 
> When login success:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x1000): [16] groups for [ADuser@ADTrustedDomain]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x0200): Skipping non-IPA group 
> name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb
> ...
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x0200): Skipping non-IPA group 
> name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x1000): Added group [ad_app_admins] for user 
> [ADuser]
> 
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] 
> [ENABLED]:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_debug_print] (0x2000): services:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): category [0] [NONE]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): services_names:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): [sshd]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): services_groups 
> (none)
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_debug_print] (0x2000): users:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): category [0] [NONE]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): users_names (none)
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): users_groups:
> ...
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): 
> [ad_app_admins]
> ...
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_debug_print] (0x2000): targethosts:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): category [0] [NONE]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): targethosts_names 
> (none)
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): targethosts_groups:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): 
> [admin-mng-hosts]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_debug_print] (0x2000): srchosts:
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_evaluate] (0x0100): ALLOWED by rule [allow_admin_mgmt_hosts].
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [hbac_evaluate] (0x0100): hbac_evaluate() >]
> sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] 
> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule 
> [allow_admin_mgmt_hosts]
> 
> 
> 
> When login failed:
> sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x1000): [15] groups for [ADuser@ADTrustedDomain]

OK, here the user is missing one group membership.

But I’m not sure how to help you with this limited log snippet. Did you observe 
some pattern that could help us reproduce the issue locally? Can you share the 
log files?

> sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] 
> [hbac_eval_user_element] (0x0200): Skipping non-IPA group 
> name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb
> ...
> sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] 

[SSSD-users] Re: AD sudo rules have no values for attributes?

[Jakub Hrozek]

> On 5 Apr 2018, at 19:56, Max DiOrio  wrote:
> 
> I’m guessing someone was thinking that the group lookup was case sensitive 
> and entered it both ways to rule that out.

I wonder if you know how did they manage to put the duplicate entries into AD? 
I tried with ADSI edit and got an error about a duplicate attribute value. I 
suspect this might be a bug in SSSD. If the domain is known to be 
case-insensitive, like AD and if the values differ by case only, then the 
values can be just lowercased and sssd should write only the single lowercase 
value (and then sssd-sudo knows to look up the rules in a case-insensitive 
manner).

>  Ends up breaking the storing of the rules and it seems if one rule fails to 
> be stored, they all are.  Not necessarily the best thing to do maybe?

In the typical case I would agree, but sudo also supports exclusion 
(“!command", run any command except the specified one) which I think is quite a 
misfeature and then failing to save a rule might cause to fail to save the 
exclusion..

I don’t know if anyone actually uses the exclusion, because, realistically, 
with LDAP it would have to be used together with sudoOrder to make sure you get 
the right ordering of rules. Maybe we could fix/extend SSSD so that if no 
sudoCommand contains the exclamation, then we can be permissive in saving the 
rules. Would you mind opening an upstream ticket for that? I’m not sure if it’s 
something any of the core developers would jump to fixing, but it sounds to me 
like a nice task for someone looking to contribute to sssd :-)

> 
> (Thu Apr  5 13:30:44 2018) [sssd[be[internal.ieeeglobalspec.com]]] 
> [sysdb_store_custom] (0x0020): Failed to store custom entry: Attribute or 
> value exists(20)[attribute 'sudoUser': value #5 on 
> 'name=DevTest,cn=sudorules,cn=custom,cn=internal.ieeeglobalspec.com,cn=sysdb' 
> provided more than once]
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Automatic parameter update in /etc/sssd/sssd.conf

[Jakub Hrozek]

> On 15 Apr 2018, at 18:19, TomK  wrote:
> 
> Hey All,
> 
> Is there a way to add or modify parameters in sssd.conf without having to 
> grep, sed or awk things to get the same thing done?
> 
> I know Ansible / Salt are one way but wondering if there are any IPA / SSSD 
> specific commands to do the same.

There is no “sssctl set-parameter”, although libini, which is the underlying 
parser, does have write support.

But you can drop a config snippet into /etc/sssd.conf.d and then restart the 
sssd service, would that help?

> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> ___
> 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: sudo rules do not get ALL run-as-user

[Jakub Hrozek]

On Fri, Apr 20, 2018 at 01:20:50PM +0200, Dominik George wrote:
> [ Not subscribed, please Cc in replies. ]
> 
> Hi,
> 
> we are usign sssd 1.15.0 on Debian stretch, for everything including sudo.
> 
> The following LDAP entry…
> 
> dn: cn=%supraadmin,ou=SUDOers,dc=teckids,dc=org
> objectClass: top
> objectClass: sudoRole
> cn: %supraadmin
> description: Allow everything for supraadmins
> sudoUser: %supraadmin
> sudoCommand: ALL
> sudoHost: ALL
> 
> …keeps rendering as this insudo…
> 
> User nik may run the following commands on ticdesk:
> (root) ALL
> 
> …even if I add sudoRunAsUser: ALL explicitly.
> 
> I already tried wiping the sss cache, with no success.

I'm sorry, but what should the desired output be here?

> 
> Any hints on why this happens:
> 
> Cheers,
> Nik
> 
> -- 
> Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
> Teckids e.V. - Erkunden, Entdecken, Erfinden.
> https://www.teckids.org/



> ___
> 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: sudo rules do not get ALL run-as-user

[Jakub Hrozek]

> On 20 Apr 2018, at 14:53, Dominik George  wrote:
> 
> Hi,
> 
>>>(root) ALL
>>> 
>>> …even if I add sudoRunAsUser: ALL explicitly.
>>> 
>>> I already tried wiping the sss cache, with no success.
>> 
>> I'm sorry, but what should the desired output be here?
> 
> ()ALL) ALL
> 
> -nik

Ah, I see what you mean now, but I can’t reproduce the problem. I have an entry 
that in the cache looks like this:

n: name=admin_all,cn=sudorules,cn=custom,cn=ipa.test,cn=sysdb
cn: admin_all
dataExpireTimestamp: 1524480254
name: admin_all
objectClass: sudoRule
sudoCommand: ALL
sudoHost: ALL
sudoRunAsUser: ALL
sudoUser: ad...@ipa.test
distinguishedName: name=admin_all,cn=sudorules,cn=custom,cn=ipa.test,cn=sysdb

Then sudo output gives me:
User admin may run the following commands on unidirect:
(root) /usr/bin/systemctl
(ALL) ALL

The systemctl allowed command comes from another rule, but I do get the (all) 
all from the admin_all rule. How does your rule look like in the cache if you 
run:
ldbsearch -H /var/lib/sss/db/cache_$yourdomain.ldb objectclass=sudorule

> 
> -- 
> Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
> Teckids e.V. - Erkunden, Entdecken, Erfinden.
> https://www.teckids.org/
> ___
> 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: Ubuntu 16.04.4 LTS 4.4.0-108+ and sssd freezes virtual server

[Jakub Hrozek]

> On 16 Mar 2018, at 23:48, David Hunter  wrote:
> 
> (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging 
> ad.domain.com
> 
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88a9d0
> (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging nss
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x8904c0
> (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging pam
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88ede0
> (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging ssh
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x889710
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88a9d0
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 
> 0x888c10
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
> (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service 
> ad.domain.com
>  replied to ping
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88ede0
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 
> 0x890e00
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
> (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service pam replied 
> to ping
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x889710
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 
> 0x88d5f0
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
> (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service ssh replied 
> to ping
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x8904c0
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 
> 0x88eae0
> (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
> (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service nss replied 
> to ping
> 
> sssd_nss.log:
> (Fri Mar 16 13:05:06 2018) [sssd[nss]] [id_callback] (0x0010): The Monitor 
> returned an error [org.freedesktop.DBus.Error.NoReply]
> 
> sssd_ad.domain.com.log:
> (Fri Mar 16 13:05:13 2018) [sssd[be[ad.domain.com
> ]]] [sbus_message_handler] (0x2000): Received SBUS method 
> org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service
> (Fri Mar 16 13:05:13 2018) [sssd[be[
> ad.domain.com
> ]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Fri Mar 16 13:05:23 2018) [sssd[be[
> ad.domain.com
> ]]] [sbus_dispatch] (0x4000): dbus conn: 0xf1e840
> (Fri Mar 16 13:05:23 2018) [sssd[be[
> ad.domain.com]]] [sbus_dispatch] (0x4000): Dispatching.

Is this really all that is in the logs? I would have expected at least the 
lookup start to show up.

Does this happen with any user or even just e.g. when you run ‘id’ for a user 
who is a member of many large group?
___
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 strangeness

[Jakub Hrozek]

The first step in debugging any strangeness is usually 
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

> On 14 Mar 2018, at 16:18, simon...@hotmail.com wrote:
> 
> Hi All
> 
> We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
> 

But this is quite an old version. I would first check if the 7.4 version 
behaves any better. About the ‘phantom groups, there was a fix that sounds 
related that will be released in 7.4.6 in a couple of weeks and actually even 
sooner in 7.5.0.

> We've used realmd to join the host concerned to our 2008R2 AD system. This 
> went really well, and consequently we've been using SSSD to provide login 
> services and kerberos integration for our fairly large hadoop system.
> 
> The authconfig that's implicitly run as part of realmd produces the following 
> sssd.conf:
> 
> [sssd]
> domains = 
> config_file_version = 2
> services = nss, pam
> 
> [pam]
> debug_level = 0x0080
> 
> [nss]
> timeout = 20
> force_timeout = 600
> debug_level = 0x0080
> 
> [domain/]
> ad_domain = 
> krb5_realm = 
> realmd_tags = manages-system joined-with-samba
> cache_credentials = true
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = False
> fallback_homedir = /home/%u@%d
> access_provider = simple
> simple_allow_groups = 
> krb5_use_kdc_info = False
> entry_cache_timeout = 300
> debug_level = 0x0080
> ad_server = 
> 
> As I've said - this works really well. We did have some stability issues 
> initially, but they've been fixed by defining the 'ad_server' rather than 
> using autodiscovery.
> 
> Logins work fine, kerberos TGTs are issued on login, and password changes are 
> honoured correctly.
> 
> However, in general day to day use, we have noticed a few anomalies, that we 
> just can't track down.  
> 
> Firstly (this has happened a few times), a user will change their AD password 
> (via a Windows PC). 
> 
> Subsequent logins - sometimes with specific client software - fail with
> 
> pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh 
> ruser= rhost= user=
> pam_sss(sshd:auth): received for user : 17 (failure setting user 
> credentials)
> 
> So in this example, the person concerned has changed their AD password. 
> Further attempts to access this system via SSH work fine. However, using SFTP 
> doesn't work (the above is output into /var/log/secure).
> 
> There are no local controls on sftp logins, and the user concerned was 
> working fine (using both sftp and ssh) until they updated their password.
> 
> There is no separate sftp daemon running, and it only affects one individual 
> currently (but we have seen some very similar instances before)
> 
> The second issue we have is around phantom groups in AD.
> 
> Hadoop uses an id -Gn command to see group membership for authorisation.
> 
> With some users - we've seen 6 currently - we see certain groups failing to 
> be looked up:
> 
> id -Gn 
> 
> id: cannot find name for group ID y
> 
> 
> The y indicates:
> 
>  = hashed realm name
> y = RID from group in AD
> 
> We can't find any group with that number on the AD side!
> 
> We can work around this by adding a local group (into /etc/group) for the 
> GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode 
> can function correctly - but this is a workaround and we'd like to get to the 
> bottom of the issue.
> 
> Rather than flooding this post now with logfiles, just thought I'd see if 
> this looked familiar to anyone. Happy to upload any logs, amend logging 
> levels, etc.
> 
> Many thanks
> Simon
> ___
> 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: sssctl & InfoPipe

[Jakub Hrozek]

> On 10 Oct 2018, at 14:04, Ondrej Valousek  wrote:
> 
> Hi list.
>  
> When I run 
> # sssctl user-checks 
> The command will,  under the “SSSD InfoPipe user lookup result” section:
> -  Print some information no matter if I enable InfoPipe in the 
> configuration or not
> -  When I enable [ifp] and add an extra attributes, such as 
> “user_attributes = +mail, +telephoneNumber, +givenname, +sn”, they does not 
> appear in the sssctl output as per above
> Is it intentional behavior?

As you found out, it’s sort of a missing feature. Thanks for filing the bug, it 
should be possible to fix that.

>  
> Thanks,
> Ondrej
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: 
> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
> (S3 Group). Registered in Ireland no. 378073. Registered Office: South County 
> Business Park, Leopardstown, Dublin 18.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Is it possible for SSSD to handle NTLMSSP authentication somehow?

[Jakub Hrozek]

> On 11 Oct 2018, at 02:08, Reinaldo Souza Gomes 
>  wrote:
> 
> I know that this is an old topic, but I've seen contradictory answers in 
> different places.
> 
> Some topics say that SSSD has no support for NTLM due to its inherently 
> unsecure nature, and will never have.

Currently SSSD cannot handle NTLM. We thought about a long time about handling 
NTLM, but it’s a lot of work for not so much gain…


> 
> But others such as this 
> topic(https://bugzilla.redhat.com/show_bug.cgi?id=963341) seem to state that 
> it could be possible through gssntlmssp package.
> 

Since Simo commented on the bug some time ago, maybe he still remembers how 
gssntlmssp was supposed to help there?

> The reason for my question is that I'm trying to use Samba with SSSD, and its 
> authentication fail when the windows client falls back from kerberos to 
> NTLMv2 for any reason:

> [2018/10/10 20:43:32.382948,  2] 
> ../source3/auth/auth.c:332(auth_check_ntlm_password)
>   check_ntlm_password:  Authentication for user [myusername] -> [myusername] 
> FAILED with error NT_STATUS_NO_LOGON_SERVERS, authoritative=1
> [2018/10/10 20:43:32.382989,  2] 
> ../auth/auth_log.c:760(log_authentication_event_human_readable)
>   Auth: [SMB2,(null)] user [MYDOMAIN]\[myusername] at [Wed, 10 Oct 2018 
> 20:43:32.382980 -03] with [NTLMv2] status [NT_STATUS_NO_LOGON_SERVERS] 
> workstation [NTB005] remote host [ipv4:192.168.1.1:1914] mapped to 
> [MYDOMAIN]\[myusername]. local host [ipv4:10.1.1.1:445]
> 
> 
> Is there anything I can do to make SSSD able to deal with NTLMv2/NTLMSSP?
> 
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: local id_provider krb5 auth_provider

[Jakub Hrozek]

> On 10 Oct 2018, at 21:11, Ken Teh  wrote:
> 
> I tried setting up a domain that uses files for the account id but to use our 
> active directory for authentication in sssd.conf. But when I fire up the sssd 
> daemon, it reports that it is using files for the auth_provider. Is this 
> setup possible? I know I can add the pam_krb5 directly into the pam stack to 
> get what I need.  I thought I'd try to do this within the pam_sss module 
> framework.

How does your config look like?

You probably want:

id_provider=files
auth_provider=krb5

> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Wed, Oct 31, 2018 at 08:20:55PM +, Jay McCanta wrote:
> Yes.  Kinit -R renews the ticket (if it hasn't expired).

OK, can you attach a snippet of the logs? I thiknk the domain log and
the krb5_child.log are the most important.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Default user quotas with SSSD

[Jakub Hrozek]

On Fri, Oct 19, 2018 at 12:26:28AM -0400, TomK wrote:
> Does SSSD allow setting quotas for existing or newly authenticated users?

No. We've talked with the systemd developers about the possibility of
sssd fetching cgroups limits from LDAP and passing them on to
pam_systemd.so to set limits on processes. IIRC the person who
originally requested this was a university admin who wanted to restrict
what the students can and can't do on the machines centrally.

But it's not implemented yet.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Wed, Oct 31, 2018 at 07:19:44PM +, Jay McCanta wrote:
> I have a new server running Ubuntu Bionic (18.04.01) with sssd 
> 1.16.1-1ubuntu1.  The problem is that our Kerberos tickets are not being 
> renewed while we are logged in.  I have tried using FILE and KEYRING 
> credential caches.  SSH has Kerberos disabled, GSSAPI disabled, and is 
> configured to use PAM.  Logging works, but the ticket expires without being 
> renewed. We are using sssd-ad for auth.   I've cranked up the debug to level 
> 9.  I am unsure where to start to try to troubleshoot.  Advice is appreciated.
> 
> Jay McCanta
> F5 Networks, Inc.
> 
> Here's a sample ticket:
> 
> Ticket cache: KEYRING:persistent:27644:krb_ccache_pBjYhsU
> Default principal: mccanta-ad...@olympus.f5net.com
> 
> 10/31/2018 16:15:51  11/01/2018 02:15:51  krbtgt/example@example.com
>   renew until 11/07/2018 16:15:51

Can you renew the ticket with kinit -R ?

> 
> /etc/sssd/sssd.conf (ad_access_filter omitted for security):
> [sssd]
> config_file_version = 2
> domains = example.com
> services = nss, pam
> debug_level = 9
> reconnection_retries = 3
> 
> [nss]
> debug_level = 9
> 
> [pam]
> debug_level = 9
> 
> [domain/example.com]
> debug_level = 9
> id_provider = ad
>   default_ccache_tempate=KEYRING:persistent:%U
>   krb5_renewable_lifetime=10d
>   krb_renew_interval=2h
>   auth_provider = ad
> access_provider = ad
> ldap_id_mapping = False
> ad_gpo_access_control = permissive
> 
> Krb5.conf:
> [libdefaults]
>   default_realm = EXAMPLE.COM
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   ticket_lifetime = 24h
>   renew_lifetime = 7d
>   rdns = false
>   forwardable = yes
> default_ccache_name=KEYRING:persistent:%{uid}
> 
> [realms]
>   EXAMPLE.COM = {
>  default_domain = example.com
>#site=SE3CIP
>kdc=dc01.example.com:88
>kdc=dc02.example.com:88
>   }
> 
> [domain_realm]
>   example.com = EXAMPLE.COM
>   .example.com = EXAMPLE.COM

> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Thu, Nov 01, 2018 at 05:20:57PM +, Jay McCanta wrote:
> I have the snippets.  May I mail them to you directly.  I was trying to 
> cleanse them, but I'm afraid I'm changing them too much.  

Yes, sure.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Id vs ldapsearch

[Jakub Hrozek]

On Tue, Nov 06, 2018 at 05:22:52PM -0500, Tom wrote:
> Just a general question about the behaviour of sss_cache , is and ldapsearch.
> 
> Id will return say 8 groups and for the same user ldapsearch will return 10.
> 
> Now as long as if returns 8 apps report authentication denied because the 
> user is not in an expected group.  Now when we run sss_cache -E to invalidate 
> the cache, id Will now return all 10 groups.
> 
> Now the group change was done days ago and our entry_cache_timeout is at 
> default of 5400.
> 
> Why do we still need to run sss_cache -E if the timeout should take care of 
> things?  We are directly authenticated against AD via computer objects.  
> 
> Just asking a general question as I’m curious how this works.  

Sounds like an issue, can you capture it with logs?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> Hi,
> 
> I am from AIX OS development team here in IBM. We have some customers
> who are interested in running SSSD in AIX. So i basically invested
> some amount of time to first build SSSD in AIX. I built the recent
> version 1.16.3 after working around some build issues. Below is the
> configure options.
> ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> --without-python3-bindings --with-selinux=no --with-semanage=no
> --with-crypto=libcrypto --without-secrets --without-kcm
> 
> I started the daemon but then it failed later with no stderr / logs
> produced anywhere.
> 
> # /opt/freeware/sbin/sssd -i -d4

Are there also no messages if you run with -d 10 ?

On Linux, I would have said that strace with -ff would be also helpful,
but I have no idea if something like this exists on AIX.

> 
> (1) root @ fvt-p7a2-lp16: /
> 
> I see it invokes two other child process which also failed
> /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> --gid 0 -d 0x01f0 --logger=stderr
> /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 --logger=stderr
> 
> Any help would be appreciated.
> 
> Thanks
> Ayappan P
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd with sudo and non posix groups

[Jakub Hrozek]

On Wed, Nov 14, 2018 at 09:45:23AM -0800, Leonard Lawton wrote:
> On 11/14/2018 12:28 AM, Jakub Hrozek wrote:
> > On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> > > I have a group in ldap(I'm using 389DS) called "_all" which has a
> > > groupofnames object class. Members are stored with the uniquemember
> > > attrtibute. The users in the group are able to login fine via ssh using 
> > > this
> > > setup. However, I can't seem to figure out how to get sudo(via ldap) to 
> > > work
> > > with my needs.
> > > The problem seems to be that I am using uniquemember which my 
> > > configuration
> > > is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> > > memberUID) only as I rely heavily on the groupofnames's functionality, so 
> > > I
> > > really need to keep that. How can I configure sssd to let me use sudo 
> > > while
> > > having a groupofnames as an authoritative source?
> > Do the groups have a gidNumber? I assume not, otherwise you'd probably
> > create the groups with the posixGroup objectclass as well.
> They do have a gidNumber and have both posixGroup and groupofnames object
> classes.

Do they show up in the id output?

> > 
> > In general, I don't think sudo allows this, because sudo calls
> > getgrouplist(3) to see which groups the user belongs to and this call,
> > being POSIX only returns POSIX groups.
> > 
> > The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
> > relevant is that the groups must be visible on the OS level, e.g. with
> > the id(1) call. I guess one way to go might be to create a POSIX group
> > (sudo_allowed) and add the _all group as a member of this sudo_allowed
> > group?
> The rfc2307 vs rfc2307bis comes into play as the group members have
> different attributes in posix vs groupofnames
> 
> Example membership of group _all when populating with posixGroup
> attritbutes:
> memberUid: bob

posixGroup does not imply memberUid, does it?

> 
> Example membership of group _all when populating with groupofnames
> attritbutes:
> uniqueMember: uid=bob,dc=something
> 
> sssd will never seem to allow memberUid /and/ uniqueMember to be searched as
> group membership.

yes, with ldap_schema=rfc2307bis, only 'member: $dn' is used by default by
SSSD. btw it looks like your configuration doesn't override the
ldap_group_member option, so I guess the uniqueMember attribute is not
used?

> > > Here is my config:
> > > 
> > > [domain/dingos]
> > > ldap_schema = rfc2307bis
> > > ldap_group_search_base = dc=dingos?sub?
> > > ldap_user_search_base = ou=people,dc=dingos
> > > ldap_uri = ldaps://ldap-server
> > > ldap_tls_cacertdir = /etc/openldap/cacerts
> > > sudo_provider = ldap
> > > ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> > > id_provider = ldap
> > > auth_provider = ldap
> > > chpass_provider = ldap
> > > cache_credentials = false
> > > access_provider = ldap
> > > debug_level = 0x3ff0
> > > ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> > > entry_cache_timeout = 1
> > > 
> > > [sssd]
> > > config_file_version = 2
> > > services = nss, pam, sudo
> > > domains = dingos
> > > ___
> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> 
> 

> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 05:24:54PM +0530, Ayappan wrote:
> On Mon, Nov 12, 2018 at 4:56 PM Jakub Hrozek  wrote:
> >
> > On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> > > Hi,
> > >
> > > I am from AIX OS development team here in IBM. We have some customers
> > > who are interested in running SSSD in AIX. So i basically invested
> > > some amount of time to first build SSSD in AIX. I built the recent
> > > version 1.16.3 after working around some build issues. Below is the
> > > configure options.
> > > ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> > > --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> > > --without-python3-bindings --with-selinux=no --with-semanage=no
> > > --with-crypto=libcrypto --without-secrets --without-kcm
> > >
> > > I started the daemon but then it failed later with no stderr / logs
> > > produced anywhere.
> > >
> > > # /opt/freeware/sbin/sssd -i -d4
> >
> > Are there also no messages if you run with -d 10 ?
> >
> 
> I just ran it and attached the output. It is showing lot of messges
> with "ldb" tag. Not sure how to interpret it.

Hmm, this is strange, for some reson the ldb library debug hooks work,
but not the sssd debugging itself? I don't know what to make of it
because both should be routed to the sss_vdebug_fn() function. I guess
it should be possible to gdb the monitor process and see what gets
called e.g. inside server_setup() when one of the DEBUG messages is
reached?

> 
> > On Linux, I would have said that strace with -ff would be also helpful,
> > but I have no idea if something like this exists on AIX.
> >
> 
> AIX strace seems to be different. But it has truss command which is
> similar to Linux strace. Just ran that as well. It provides
> good deal of info. Seems like i need to analyze the output to make out
> anything meaningful.
> 
> > >
> > > (1) root @ fvt-p7a2-lp16: /
> > >
> > > I see it invokes two other child process which also failed
> > > /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> > > --gid 0 -d 0x01f0 --logger=stderr
> > > /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 
> > > --logger=stderr
> > >
> > > Any help would be appreciated.
> > >
> > > Thanks
> > > Ayappan P
> > > ___
> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

> _poll(0x20057788, 4, 1928)  = 4
> _enrecvmsg(10, 0x2FF22358, 0, 0x)   = 1
> getpeereid(10, 0x2FF22380, 0x2FF2237C)  Err#76 ENOTCONN
> kread(10, " A U T H   E X T E R N A".., 2048)   = 18
> _poll(0x20057788, 4, 1926)  = 4
> _esend(10, 0x200575F8, 46, 256, 0x) Err#32 EPIPE
> Received signal #20, SIGCHLD [caught]

Here the child process (sssd_be) tries to connect to the sssd main
processes' D-Bus socket, sends the AUTH EXTERNAL command to try to
authenticate, but when the sssd tries to reply, the send
call returns EPIPE..this indicates the sssd_be process is exiting after
startup.

I can't tell from the truss output what makes the sssd_be fail. It would
be best to first figure out why the logger is not working..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: SSSD login delay

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 04:25:30PM -, Jonathan Gray wrote:
> Hello,
> 
> We need help debugging this issue.
> 
> For some servers we're experiencing over 10 second delay logging in with IPA 
> user.
> Since the issue isn't present everywhere we're finding it hard to debug.
> 
> 
> SSSD config looks like this::
> 
> [domain/hostname.com]
> 
> cache_credentials = true
> krb5_store_password_if_offline = true
> ipa_domain = hostname.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = hostname.com
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = ipa1-hostname, ipa2-hostname
> dyndns_iface = eth0
> dns_discovery_domain = hostname.com
> debug_level = 9
> 
> [sssd]
> services = nss, sudo, pam, ssh
> 
> domains = hostname.com
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> We're wondering if there's any obvious configurations we could apply above 
> that would improve SSSD performance

There's no make_sssd_faster=True switch :-), it's hard to give an advise
without at least a little understanding of what might be the root cause.

In general, login consists of:
- retrieving the user information
- you can simulate the worst case by running "sss_cache -E; id
  $username". Above you said that the user is an IPA one, does the
  user really come from the IPA directory or e.g. IPA-AD trusts? The
  difference would be that with IPA, the sssd on the clients talks
  directly to the IPA directory server, with IPA-AD trusts the SSSD on
  the clients talks to the DS on the IPA servers which ask SSSD on the
  servers which ask the AD DS.  So in the trust case, typically you want
  to first make sure the servers are fast. If this is the slow piece,
  then look into the SSSD logs for messages like dp_get_account_info_send
  (this is the beginning of a lookup) and dp_req_reply_std (this is
  the end of a lookup). Are there many of these messages or is there
  a long delay between them? Some time ago we also instrumented the
  SSSD code with systemtap probes, so maybe it would be easier to
  run a systemtap script and see what is slow, e.g.
  
http://justin-stephenson.blogspot.com/2017/05/measuring-sssd-performance-with.html

- authentication
- you can simulate the SSSD authentication /partially/ with
  kinit. But SSSD also does some extra steps like verifying the
  TGT comes from the same KDC that issued the keytab. But all in
  all you can look for messages like dp_pam_handler_send for the
  pam request beginning and dp_req_done for PAM request end.

- authorization
- similar to above, dp_pam_handler_send followed by
  SSS_PAM_ACCT_MGMT marks the beginning of the account control check
  and dp_req_done marks the account check end

- session setup
- unless you use FleetCommander to control your desktop systems,
  SSSD typically does nothing in this step

>, and what exactly to look out for in sssd debug logs that would help us with 
>our investigation.

I'd advise to experiment with the lookups, kinit and check the systemtap
scripts or check which PAM phase might be slow for you.

Also, if you have many groups or especially many large groups, it might
be worth a try to suppress group members (ignore_group_members=True)
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd with sudo and non posix groups

[Jakub Hrozek]

On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> I have a group in ldap(I'm using 389DS) called "_all" which has a
> groupofnames object class. Members are stored with the uniquemember
> attrtibute. The users in the group are able to login fine via ssh using this
> setup. However, I can't seem to figure out how to get sudo(via ldap) to work
> with my needs.
> The problem seems to be that I am using uniquemember which my configuration
> is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> memberUID) only as I rely heavily on the groupofnames's functionality, so I
> really need to keep that. How can I configure sssd to let me use sudo while
> having a groupofnames as an authoritative source?

Do the groups have a gidNumber? I assume not, otherwise you'd probably
create the groups with the posixGroup objectclass as well.

In general, I don't think sudo allows this, because sudo calls
getgrouplist(3) to see which groups the user belongs to and this call,
being POSIX only returns POSIX groups.

The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
relevant is that the groups must be visible on the OS level, e.g. with
the id(1) call. I guess one way to go might be to create a POSIX group
(sudo_allowed) and add the _all group as a member of this sudo_allowed
group?

> 
> Here is my config:
> 
> [domain/dingos]
> ldap_schema = rfc2307bis
> ldap_group_search_base = dc=dingos?sub?
> ldap_user_search_base = ou=people,dc=dingos
> ldap_uri = ldaps://ldap-server
> ldap_tls_cacertdir = /etc/openldap/cacerts
> sudo_provider = ldap
> ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> cache_credentials = false
> access_provider = ldap
> debug_level = 0x3ff0
> ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> entry_cache_timeout = 1
> 
> [sssd]
> config_file_version = 2
> services = nss, pam, sudo
> domains = dingos
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: ad_access_filter and splitting group listing with backslash

[Jakub Hrozek]

On Fri, Oct 05, 2018 at 12:25:08PM +0200, Michal Židek wrote:
> On 09/27/2018 10:55 PM, Tom wrote:
> > FYI tested this and though it doesn’t work for ad_access_filter it does for 
> > the ldap_access_filter .   Any reason why one works but not the other?
> 
> Hi,
> 
> I would like to see logs in this case in order to
> undrestand where the issue may be.
> 
> If the sssd does not even start and logs show that the option
> could not be parsed then it could be an issue in libini.
> 
> If it fails later then maybe we handle the multiline option
> badly in SSSD.
> 
> Also I am not sure what 'doesn't work' in this context means. Is
> the filter not effective or is SSSD failing to start/do some
> operation?

To put a little more context, the only difference between the
ldap_access_filter and ad_access_filter should be that the former use
whatever ldap authentiation you configure (bind DN, SASL GSSAPI, ...)
and the latter re-uses the GSSAPI authenticated connection that the ID
provider uses.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd fails to start when I enable [ifp]

[Jakub Hrozek]

Do you run sssd as root or the unprivileged sssd user?

> On 8 Oct 2018, at 15:29, Ondrej Valousek  wrote:
> 
> Hi List,
> Seems like sssd fails to start when I enable infopipe (i.e. add “ifp” to the 
> services list).
> Log says:
> (Mon Oct  8 14:18:08 2018) [sssd[ifp]] [sysbus_init] (0x0020): Unable to 
> request name on the system bus: [Connection ":1.33273" is not allowed to own 
> the service "org.freedesktop.sssd.infopipe" due to security policies in the 
> configuration file]
> (Mon Oct  8 14:18:08 2018) [sssd[ifp]] [sysbus_init] (0x0040): DBus error 
> message: Connection ":1.33273" is not allowed to own the service 
> "org.freedesktop.sssd.infopipe" due to security policies in the configuration 
> file
> (Mon Oct  8 14:18:08 2018) [sssd[ifp]] [ifp_process_init] (0x0020): Failed to 
> connect to the system message bus
>  
> This is Centos-7, all updates applied, i.e. dbus-1.10.24, sssd-1.16.0-19.el7
>  
> Thanks,
> Ondrej
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: 
> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
> (S3 Group). Registered in Ireland no. 378073. Registered Office: South County 
> Business Park, Leopardstown, Dublin 18.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: realm re-join....

[Jakub Hrozek]

> On 8 Oct 2018, at 16:16, Spike White  wrote:
> 
> All,
> 
> I had a VM down for a great number of days.  Apparently, it was not 30 days.  
> Because even though it initially didn't correct do AD authentication, I fixed 
> one misconfiguration in /etc/krb5.conf, restarted SSSD and it did.
> 
> But that raises a bigger question.  If it's been >30 days and my machine 
> account is no longer valid, how do I rejoin the domain?
> 
> Is it:
>realm leave (no flags)
>readlm join (with all my usual flags that I use on the initial realm join)
> 

Wouldn’t it be safer to just use adcli update? Looking at the man page, it 
appears you can also kinit as another user (since your machine credentials are 
probably gone now) and point adcli there with —login-ccache

I don’t know realmd into too many details, but I wonder if realm leave && realm 
join would rewrite any config changes you do.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd fails to start when I enable [ifp]

[Jakub Hrozek]

Interesting..Pavel, do you have some idea?

> On 9 Oct 2018, at 10:27, Ondrej Valousek  wrote:
> 
> Ok, obviously this error message does not appear when using SystemD, 
> therefore I try to start it as root interactively, i.e.
> # /usr/sbin/sssd -i
> 
> -Original Message-
> From: Ondrej Valousek [mailto:ondrej.valou...@s3group.com] 
> Sent: Tuesday, October 09, 2018 10:25 AM
> To: End-user discussions about the System Security Services Daemon 
> 
> Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]
> 
> Hi,
> As root, i.e. "systemctl start sssd"
> Ondrej
> 
> -Original Message-
> From: Jakub Hrozek [mailto:jhro...@redhat.com]
> Sent: Tuesday, October 09, 2018 10:24 AM
> To: End-user discussions about the System Security Services Daemon 
> 
> Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]
> 
> Do you run sssd as root or the unprivileged sssd user?
> 
>> On 8 Oct 2018, at 15:29, Ondrej Valousek  wrote:
>> 
>> Hi List,
>> Seems like sssd fails to start when I enable infopipe (i.e. add “ifp” to the 
>> services list).
>> Log says:
>> (Mon Oct  8 14:18:08 2018) [sssd[ifp]] [sysbus_init] (0x0020): Unable 
>> to request name on the system bus: [Connection ":1.33273" is not 
>> allowed to own the service "org.freedesktop.sssd.infopipe" due to 
>> security policies in the configuration file] (Mon Oct  8 14:18:08
>> 2018) [sssd[ifp]] [sysbus_init] (0x0040): DBus error message: 
>> Connection ":1.33273" is not allowed to own the service 
>> "org.freedesktop.sssd.infopipe" due to security policies in the 
>> configuration file (Mon Oct  8 14:18:08 2018) [sssd[ifp]] 
>> [ifp_process_init] (0x0020): Failed to connect to the system message 
>> bus
>> 
>> This is Centos-7, all updates applied, i.e. dbus-1.10.24,
>> sssd-1.16.0-19.el7
>> 
>> Thanks,
>> Ondrej
>> -
>> 
>> The information contained in this e-mail and in any attachments is 
>> confidential and is designated solely for the attention of the intended 
>> recipient(s). If you are not an intended recipient, you must not use, 
>> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
>> have received this e-mail in error, please notify the sender by return 
>> e-mail and delete all copies of this e-mail from your computer system(s). 
>> Please direct any additional queries to: 
>> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
>> (S3 Group). Registered in Ireland no. 378073. Registered Office: South 
>> County Business Park, Leopardstown, Dublin 18.
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org To 
>> unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: 
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedoraho
>> sted.org
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe 
> send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> 
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: communicati...@s3group.com. Thank You. 
> Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 
> 378073. Registered Office: South County Business Park, Leopardstown, Dublin 
> 18.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe 
> send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-use

[SSSD-users] Re: sssd.conf sections only work if they reflect existing AD domain, why?

[Jakub Hrozek]

SSSD logs would show this better, but I wonder if this is related to also using 
the AD domain name in the simple access filter. Do logins work if you use the 
name of the sssd section there instead of the AD domain name? Or, do the logins 
work if you comment out the access provider for a test?

> On 3 Sep 2018, at 10:32, D R  wrote:
> 
> An user belonging to the Simple Users group is resolved correctly via either 
> one of these commands:
> 
> id simpleuser@FOOBAR_NOLOGIN.GLOBAL
> id simpleuser@FOOBAR.GLOBAL
> 
> Similarly, an user belonging to the Administrators group can be seen via 
> either one of these commands:
> 
> id adminuser@FOOBAR_ADMINS.GLOBAL
> id adminuser@FOOBAR.GLOBAL
> 
> However, no user is able to log in.  I've tried all these commands:
> 
> ssh simpleuser@FOOBAR_NOLOGIN.GLOBAL@
> ssh simpleuser@FOOBAR.GLOBAL@
> ssh adminuser@FOOBAR_ADMINS.GLOBAL@
> ssh adminuser@FOOBAR.GLOBAL@
> 
> Here's the ssh -vvv output after that  requests the password: 
> 
> debug3: send packet: type 50
> debug2: we sent a password packet, wait for reply
> Authentication failed.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd.conf sections only work if they reflect existing AD domain, why?

[Jakub Hrozek]

> On 31 Aug 2018, at 17:34, Daniele Raffo  wrote:
> 
> Hello,
> 
> I'm trying to define two sssd groups in order to assign a different login 
> shell to AD users belonging to two different AD groups in our domain 
> FOOBAR.GLOBAL.
> However, all users are unable to login and get an error "Authentication 
> failed”.  

Are you able to at least resolve the users? What exact name are you using to 
resolve the users, username@foobar_nologin.global or username@foobar.global? 
The former would work, the latter would not.

btw if all you want is to munge the shell based on group memberships, maybe the 
sss_override tool would help?

> If I change a sssd section to [domain/FOOBAR.GLOBAL] so to reflect the 
> existing AD domain, users defined in that sssd group are able to login.  
> However, clearly in this way I cannot define more than one section.
> Why is that?  How to define sssd sections with names different than the 
> existing AD domain?
> 
> Thanks in advance.  Below is my sssd.conf.
> 
> 
> [sssd]
> domains = FOOBAR_ADMINS.GLOBAL,FOOBAR_NOLOGIN.GLOBAL
> config_file_version = 2
> services = nss, pam
> 
> [domain/FOOBAR_NOLOGIN.GLOBAL]
> ldap_user_search_filter = (memberOf=CN=Simple Users,OU=Security 
> Groups,DC=FOOBAR,DC=GLOBAL)
> default_shell = /bin/sh
> ad_server = ad01.foobar.global
> ad_domain = FOOBAR.GLOBAL
> krb5_realm = FOOBAR.GLOBAL
> realmd_tags = manages-system joined-with-adcli 
> cache_credentials = False
> id_provider = ad
> krb5_store_password_if_offline = True
> ldap_id_mapping = True
> use_fully_qualified_names = True
> fallback_homedir = /home/%u@%d
> access_provider = simple
> simple_allow_groups = Simple Users@FOOBAR.GLOBAL
> 
> [domain/FOOBAR_ADMINS.GLOBAL]
> ldap_user_search_filter = (memberOf=CN=Administrators,OU=Security 
> Groups,DC=FOOBAR,DC=GLOBAL)
> default_shell = /bin/bash
> ad_server = ad01.foobar.global
> ad_domain = FOOBAR.GLOBAL
> krb5_realm = FOOBAR.GLOBAL
> realmd_tags = manages-system joined-with-adcli 
> cache_credentials = False
> id_provider = ad
> krb5_store_password_if_offline = True
> ldap_id_mapping = True
> use_fully_qualified_names = True
> fallback_homedir = /home/%u@%d
> access_provider = simple
> simple_allow_groups = Administrators@FOOBAR.GLOBAL
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Issues with SSSD cache on version 1.13.4

[Jakub Hrozek]

> On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
> 
> For our case, say we have a set of groups abcd..1, abcd..2 etc, all with the 
> same GID. I would expect the first lookup (e.g. abcd..1) to put an entry in 
> the cache. If there is then a lookup by GID, (getent group ) it would 
> return this entry. However a lookup by name (e.g. abcd..2) would have to 
> query LDAP, right? Then what happens, does this new data overwrite the old 
> GID entry in the cache? Or is there some bug whereby sometimes a duplicate 
> entry gets made? Why is there a check for duplicates when a GID is looked up 
> as opposed to when an entry is placed in the cache?

I’m not so sure it would be a good idea to support this, honestly. What do you 
suggest would then be returned for lookups by GID (getgrgid 1234) if there are 
multiple entries with GID=1234 in the cache? Just let the first match win? I 
know this is what nss_ldap does, whatever is returned from LDAP is then passed 
on to NSS, but I’m mostly concerned about consistency, suppose a first machine 
does getent group abcd..1, another one does geten group abcd..2. Then you get a 
different result on each machine for by-GID request..

LDAP also doesn’t guarantee any ordering of results AFAIK (even though in 
practice I’ve seen the replies are quite consistent), so it’s even not 
guaranteed to always receive the same answer for the by-GID LDAP search..

btw it’s a good question to ask why isn’t the check done on saving the group. I 
thought it was and I see code that checks for ID uniqueness and even a test..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Issues with SSSD cache on version 1.13.4

[Jakub Hrozek]

On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > btw it’s a good question to ask why isn’t the check done on saving
> > the group. I thought it was and I see code that checks for ID
> > uniqueness and even a test..
> 
> In current code, saving would override data as if the group was renamed
> changed I think ?

The way the code is currently written is, if there is a duplicate:
- check if the "new" group has the same SID, uniqueID or original DN
  as the "old" one
  - yes, same: this is a rename, allow
  - no, different: this is a duplicate, error
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Issues with SSSD cache on version 1.13.4

[Jakub Hrozek]

On Mon, Sep 24, 2018 at 04:40:34PM +0200, Michael Ströder wrote:
> On 9/24/18 4:12 PM, Beale (US), Gareth wrote:
> >> I’m not so sure it would be a good idea to support this, honestly.
> > 
> > Well that rather depends on what you mean by "this". I was reporting
> > a problem that seemed an inconsistency to me. Either multiple groups
> > with the same GID are supported, or they aren't. The current
> > implementation is inconsistent in its response over time, and it
> > flags an error and then fails - that should not happen in either
> > scenario.
> 
> You're absolutely right that the sssd behaviour you've observed is
> inconsistent.

Yes, I think it's a bug in SSSD. We should either fail right away or
permit the duplicates.

Would either of you care to file a bug? :)

> 
> That's why Jakub Hrozek wrote:
> > btw it’s a good question to ask why isn’t the check done on saving
> > the group. I thought it was and I see code that checks for ID
> > uniqueness andeven a test..
> 
> So for me it boils down to:
> Multiple group entries with same GID are not supported in sssd and
> should never be added to the cache. Why it happened in your case has to
> be examined.

Yes, this is what I meant.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Issues with SSSD cache on version 1.13.4

[Jakub Hrozek]

> On 24 Sep 2018, at 20:25, Simo Sorce  wrote:
> 
> On Mon, 2018-09-24 at 19:59 +0200, Jakub Hrozek wrote:
>> On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
>>>> btw it’s a good question to ask why isn’t the check done on saving
>>>> the group. I thought it was and I see code that checks for ID
>>>> uniqueness and even a test..
>>> 
>>> In current code, saving would override data as if the group was renamed
>>> changed I think ?
>> 
>> The way the code is currently written is, if there is a duplicate:
>>- check if the "new" group has the same SID, uniqueID or original DN
>>  as the "old" one
>>  - yes, same: this is a rename, allow
>>  - no, different: this is a duplicate, error
> 
> not sure how the original DN would match if you rename the object and
> that changes the DN too ?

Yes, in that case, the rename would throw an error. The originalDN handling was 
meant to support renames in the case the RDN doesn’t contain the name and 
therefore doesn’t change.

This is honestly something where I don’t know what is the right thing to do. If 
we detect that a group with some GID already exists, then how do we distinguish 
between “err, there are duplicates on the LDAP side” and “look, the group was 
renamed” without any peristent identifier like a SID? At the point the code was 
changed the last time we also thought about returning an error code from the 
sysdb save operation and then running an LDAP search by GID before deciding 
about rename or duplicate. But we also thought that a) a rename was not very 
common operation and b) because IPA and especially AD form the bulk of the 
deployments, we could go away with the SID or uniqueID helper..

Of course, if more people complain about group renames with a “plain LDAP” 
server, then we should implement the more complex logic, but my take at the 
time was that SSSD is complex as it is already, so I didn’t think it was worth 
adding a complex logic for a corner case.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-
> > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 12:47
> > À : End-user discussions about the System Security Services Daemon
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > >Hi
> > >I am trying to find out how th sssd cache is being populated.
> > >I couldn't find much about it so I did some tests.
> > >It seems that with enumerate = true, the cache holds all the information
> > needed as soon as sssd is started.
> > >With enumerate = false, the cache holds information about someone only
> > after his first connection.
> > >Is that right ?
> > >I would like to be sure that user's passwords are stored in the cache but
> > couldn't find any way to verify this
> > >With sssctl user-show  I can find if a user is in the cache but with no 
> > >details.
> > >With sssctl user-checks I get some information about the user but nothing
> > about the password.
> > >By examining directly the cache with ldbsearch I don't find any password
> > information either, only maybe shadowLastChange: with a number which I
> > don't understand.
> > >Is there any documentation about the cache management ?
> > >
> >
> > Hashed password is cached only after successful authentication. It is not
> > rerieved by "getent passwd $user".
> >
> > sssd cache is internal cache and should not be used directly by user.
> I understand that and was looking at it only to try to understand how it 
> works.
> 
> > May I know what do you want to achieve?
> When using regular ssh access the the ssh publickey is in the cache if needed.
> A user who had not connected previously is able to connect even if the 
> backend is unreachable
> When using the console, we have to rely on the password.
> When something goes wrong (sshd down or network issue), there is a high 
> probability that the user would connect to the console for the first time.
> So if there is no guarantee the login could be successful offline we need to 
> have a local  (shared) account to connect to the console.
> A shared account is a nightmare to manage and a sore point for audits, we 
> would like to remove it.

The sss_seed tool was meant as a way to mitigate this.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-----
> > De : Jakub Hrozek [mailto:jhro...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 15:24
> > À : sssd-users@lists.fedorahosted.org
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> > >
> > >
> > > > -Message d'origine-
> > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > > > Envoyé : mercredi 16 janvier 2019 12:47
> > > > À : End-user discussions about the System Security Services Daemon
> > > > Objet : [SSSD-users] Re: Understanding sssd cache
> > > >
> > > > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > > > >Hi
> > > > >I am trying to find out how th sssd cache is being populated.
> > > > >I couldn't find much about it so I did some tests.
> > > > >It seems that with enumerate = true, the cache holds all the 
> > > > >information
> > > > needed as soon as sssd is started.
> > > > >With enumerate = false, the cache holds information about someone
> > only
> > > > after his first connection.
> > > > >Is that right ?
> > > > >I would like to be sure that user's passwords are stored in the cache 
> > > > >but
> > > > couldn't find any way to verify this
> > > > >With sssctl user-show  I can find if a user is in the cache but with no
> > details.
> > > > >With sssctl user-checks I get some information about the user but
> > nothing
> > > > about the password.
> > > > >By examining directly the cache with ldbsearch I don't find any 
> > > > >password
> > > > information either, only maybe shadowLastChange: with a number which
> > I
> > > > don't understand.
> > > > >Is there any documentation about the cache management ?
> > > > >
> > > >
> > > > Hashed password is cached only after successful authentication. It is 
> > > > not
> > > > rerieved by "getent passwd $user".
> > > >
> > > > sssd cache is internal cache and should not be used directly by user.
> > > I understand that and was looking at it only to try to understand how it
> > works.
> > >
> > > > May I know what do you want to achieve?
> > > When using regular ssh access the the ssh publickey is in the cache if
> > needed.
> > > A user who had not connected previously is able to connect even if the
> > backend is unreachable
> > > When using the console, we have to rely on the password.
> > > When something goes wrong (sshd down or network issue), there is a high
> > probability that the user would connect to the console for the first time.
> > > So if there is no guarantee the login could be successful offline we need 
> > > to
> > have a local  (shared) account to connect to the console.
> > > A shared account is a nightmare to manage and a sore point for audits, we
> > would like to remove it.
> >
> > The sss_seed tool was meant as a way to mitigate this.
> If I understand it correctly to have only nominative account in place for 
> console login, each user would have to put his own password in the cache 
> before something goes wrong.
> Obviously it won't work in a large environment.
> So we can't rely on SSSD and its cache for console login, a local user is 
> mandatory.

If you're going to orchestrate useradd for each local user, how is that
more difficult than sss_seed for each remote user?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Sssd and gidNumber

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 05:33:41AM -, Dmitrij S. Kryzhevich wrote:
> I have setup with 3 clients and server. Server runs samba as AD and ldap + 
> kerberos. Clients use sss: 1) fedora with 2.0.0, 2) centos with 1.16.0 and 3) 
> centos with 1.16.2. All clients use 1:1 sssd.conf. I want sss to use primary 
> group id from gidNumber record in ldap and I have no issues with first and 
> second clients. But not third. I don't understand why but primary gid is set 
> equal to uid. Can't see anything relevant in logs.
> 
> Where to dig?

I would start with comparing logs for a 'working' and a 'non-working'
client. The config looks OK to me and in general the plain LDAP provider
should only ever generate the gidNumber value if
ldap_auto_private_groups is set to True

> 
> sssd.conf:
> [domain/default]
> id_provider = ldap
> ldap_uri = ldap://pdc.lkkm/
> ldap_id_use_start_tls = True
> ldap_tls_cacertdir = /etc/openldap/cacerts
> ldap_search_base = dc=pdc,dc=lkkm
> ldap_default_bind_dn = 
> ldap_default_authtok_type = password
> ldap_default_authtok = 
> ldap_user_search_base = cn=Users,dc=pdc,dc=lkkm
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_object_class = person
> ldap_group_search_base = dc=PosixGroups,dc=pdc,dc=lkkm
> ldap_group_object_class = group
> 
> auth_provider = krb5
> chpass_provider = krb5
> krb5_server = pdc.lkkm
> krb5_kpasswd = pdc.lkkm
> krb5_realm = PDC.LKKM
> krb5_store_password_if_offline = False
> krb5_ccname_template = KEYRING:persistent:%{uid}
> krb5_auth_timeout = 15
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org