[SSSD-users] Nested group lookups

[Tom]

Hey All,

If I want sssd to lookup if I belong in any groups or nested groups based on a 
string ( wildcard) in a group, what be my best options?

I would like to keep the ad_access_filter to a minimum and grant access if a 
user is part of a subgroup.  

If user is in B and B is in A, allow access as long as A appears on the filter 
list for example.

Cheers,
Tom

Sent from my iPhone
___
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/633P4FU2JYLIAGKB4K3XOJPL4RDXZW3U/

[SSSD-users] Re: sss_override user-export is empty

[Spike White]

vadud,

I'm guessing a bug.  I tried similar, but with a different AD user.  Looks
fine, before and after systemctl restart.

[root@spikerealmd02 sssd]# id spike_white
uid=25431(spike_white) gid=25431(spike_white)
groups=25431(spike_white),1010(amerunixusers)
[root@spikerealmd02 sssd]# sss_override user-add spike_white -u 4311
SSSD needs to be restarted for the changes to take effect.
[root@spikerealmd02 sssd]# sss_override  user-show spike_white
spike_wh...@amer.dell.com::4311:
[root@spikerealmd02 sssd]# systemctl restart sssd
[root@spikerealmd02 sssd]# sss_override  user-show spike_white
spike_wh...@amer.dell.com::4311:
[root@spikerealmd02 sssd]# sss_override  user-export foo
[root@spikerealmd02 sssd]# cat foo
spike_wh...@amer.dell.com::4311:
[root@spikerealmd02 sssd]# sssd --version
1.16.0
[root@spikerealmd02 sssd]#

So -- good on version 1.16.0.

I'm curious where these sssd overrides reside.  I know for 'user' and
'group' access additions, they ultimately end up in /etc/sssd/sssd.conf
file.  Not so for sss overrides.

Spike

On Sat, Jun 23, 2018 at 10:04 PM  wrote:

> I made a change in UID for a user with sss_override but user-export to a
> file does not export anything. I am using sssd version 1.15.2. Is this a
> bug or may be I am doing something wrong? I followed the steps from this
> https://jhrozek.wordpress.com/2016/02/15/sssd-local-overrides/
>
> I ran these as root
> # sssd --version
> 1.15.2
> # sss_override user-add mwvande -u 4311
> # systemctl restart sssd
> # sss_override user-export foo
> # cat foo
> (no output)
>
> I also tried it without the restart
>
> # sss_override user-add mwvande -u 4311
> # sss_override user-export foo
> # cat foo
> (no output)
>
>
> --
> 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
> 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/OP6PWABJVAKWJ7PI3ALK7FNXJNC6VLMT/
>
___
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/O24TLOUHCYB2H2BZG2GVAVBTXD2PF7AU/

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Sumit Bose]

On Wed, Jul 04, 2018 at 03:24:47AM -0500, Spike White wrote:
> Thanks for responding.
> 
> what you said was not exactly my situation, but it got me poking around and
> finally I got the configuration working.
> 
> I find this interesting item when looking at various sssd subcommands;
> 
> [root@spikerealmd02 ~]# sssctl domain-list
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> 
> 
> *Why are the remote subdomains duplicated?  *
> 
> Ultimately, this was my problem.
> 
> When I clear my logs:
> 
> sssctl remove-logs
> 
> 
> and II do a: getent passwd admjesse_chan
> which still fails.
> 
> via 'grep -il admjesse_chan sssd_*.log',  I find string only in
> sssd_amer.dell.com.log  and sssd_nss.log.
> 
> sssd_apac.dell.com.log does the usual site-awareness lookup and identified
> primary LDAP server optimally.  So this sssd_be subprocess is working
> correctly.
> 
> Yet this log file never receives a query request for '
> admjesse_c...@apac.dell.com'.
> 
> sssd_nss.log gets a query request for admjesse_chan.  It knows about remote
> subdomains:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR
> #1753: Setting "User by name" plugin
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #1753:
> New request 'User by name'
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
> CR #1753: Parsing input name [admjesse_chan]
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain apac.dell.com  is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain emea.dell.com  is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain japn.dell.com  is Active*
> 
> 
> Since admjesse_chan was specified with domain, it performs a multi-domain
> search.  it searches local domain first.  It searches cache for
> admjesse_c...@amer.dell.com and then data_provider first:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_parse_name_for_domains]
> (0x0200): name 'admjesse_chan' matched without domain, user is admjesse_chan
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
> #1753: Setting name [admjesse_chan]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_select_domains] (0x0400):
> CR #1753: Performing a multi-domain search
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_domains] (0x0400):
> CR #1753: Search will check the cache and check the data provider
> ...
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> CR #1753: Object [admjesse_c...@amer.dell.com] was not found in cache
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
> #1753: Looking up [admjesse_c...@amer.dell.com] in data provider
> 
> 
> It dispatches to data_provider (child process sssd_be for amer.dell.com)
> and receives successful response back (no records found):
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [amer.dell.com
> ][0x1][BE_REQ_USER][name=admjesse_c...@amer.dell.com:-]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_add_timeout] (0x2000):
> 0x55f844a5cac0
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
> Entering request [0x55f842febb50:1:admjesse_c...@amer.dell.com@amer.dell.com
> ]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_remove_timeout] (0x2000):
> 0x55f844a5cac0
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn:
> 0x55f844a330f0
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
> Dispatching.*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 0 errno: 0 error message: Success*
> 
> 
> 
> So next, it searches the next domain -- emea.dell.com:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [emea.dell.com
> ][0x1][BE_REQ_USER][name=admjesse_c...@emea.dell.com:-]
> ...
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
> Dispatching.
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 3 errno: 5 error message:
> Input/output error*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
> (0x0040): CR #1753: Data Provider Error: 3, 5, Input/output error*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
> (0x0400): CR #1753: Due to an error we will return cached data*
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> CR #1753: Looking up [admjesse_c...@emea.dell.com] in cache
> 
> 
> It catches the same I/O error when dispatching to the other
> data_providers:  apac.dell.com, japn.dell.com
> 
> So I focused on -- why are there duplicate entries in  sssctl

[SSSD-users] Re: Behaviour of refresh_expired_interval

[Sumit Bose]

On Wed, Jul 04, 2018 at 11:30:21AM +0200, John Hearns wrote:
> One thing I do note. I have reduced refresh_expired_interval to 40 seconds,
> which is clearly a ridiculously low time.
> However when I look at the cached information I always see Initgroups
> expiration time:Expired
> 
> I am not sure what this means.
> 
> root@ibis:~# sssctl user-show abc
> Name: abc
> Cache entry creation date: 06/27/18 17:09:58
> Cache entry last update time: 07/04/18 11:28:16
> Cache entry expiration time: 07/04/18 11:29:16
> Initgroups expiration time: Expired
> Cached in InfoPipe: No
> 

Yes, this is expected because the groupmemberships are not updated here
because it would be too expensive. But if you use the AD provider with
tokenGroups enabled (the default) it should help nonetheless because all
groups in the cache should be valid and after the single tokenGroups
LDAP request the user "just" has to be added to all the group it is a
member of.

Please let me know if it still needs 20s or more to update the group
memberships with tokenGroups enabled if all groups are still valid.

bye,
Sumit

> 
> 
> 
> On 4 July 2018 at 11:01, John Hearns  wrote:
> 
> > Thankyou Sumit. I think you might be trying to tel lme something with the
> > debug_level=6   :-)
> >
> > On 4 July 2018 at 09:04, Sumit Bose  wrote:
> >
> >> On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
> >> > I have an AD setup where users can be a member of perhaps 130 groups.
> >> > When I run 'groups jbloggs' this can take 90 seconds or even longer.
> >> > I have reduced that time to perhaps 20 seconds by setting
> >> > ignore_group_members = TRUE
> >> >
> >> > Once the information is cached the groups command returns in less that
> >> one
> >> > second.
> >> > However, after a length of time the cache seems to be invalidated and
> >> the
> >> > information is fetched again from the server, taking 20 seconds again.
> >> > The cacheing parameters are set to:
> >> >
> >> > entry_cache_timeout = 5400
> >> > entry_cache_user_timeout = 5400
> >> > entry_cache_group_timeout = 5400
> >> > refresh_expired_interval = 4000
> >> >
> >> > Surely this means that after 4000 seconds the user and group
> >> information is
> >> > refreshed in the background.
> >> > So a user running the groups command would always see freshly cached
> >> values?
> >>
> >> With 'debug_level=6' or higher in the [domain/...] section of sssd.conf
> >> you
> >> should be able to see messages like 'Refreshing  in domain
> >> ' in domain log file when is refresh task is running.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > Clearly I am not understanding something here.
> >>
> >> > ___
> >> > 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.or
> >> g/archives/list/sssd-users@lists.fedorahosted.org/message/M4
> >> R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
> >> ___
> >> 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.or
> >> g/archives/list/sssd-users@lists.fedorahosted.org/message/GY
> >> L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
> >>
> >
> >

> ___
> 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/P3WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/
___
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/RUJIULW2YG7NJZPU64NHTCR2GSAIQZE4/

[SSSD-users] Re: sss_override - when to run it?

[Sumit Bose]

On Wed, Jul 04, 2018 at 09:06:50AM +0200, John Hearns wrote:
> Sumit, thankyou.
> What I have done is to write a Python script which loops over all local
> users.
> The script calls sss_override user-set for each user. Then the script runs
> user-export to create a file as you suggest.
> 
> I have edited the sssd.service unit file, and placed the changed copy in
> /etc/systemd/system/sssd.service
> This has an added Post Start action to read in the file using user-import.
> These are the lines I added:
> 
> 
> ExecStartPost=-/usr/sbin/sss_override user-import /etc/sssd/overrides
> TimeoutStartSec=180

ok, this should do no harm, but as said, as long as the cache file is on
a disk and is not removed during reboots or on other circumstances this
should not be needed.

bye,
Sumit

> 
> 
> 
> 
> On 4 July 2018 at 08:41, Sumit Bose  wrote:
> 
> > On Thu, Jun 14, 2018 at 02:33:22PM +0200, John Hearns wrote:
> > > We have an existing set of users in a local passwd file
> > > I want to run sss_override to create mappings from the AD SID numbers to
> > > the existing uid numbers.
> > >
> > > What is the concensus on running sss_override?
> > > I can script it to either parse through the existing passwd file and make
> > > an override entry per user,
> > > or to parse the file and create an import file which is run once with
> > > import-user
> > >
> > > But when is a good time to run this?
> > >
> > > In a daily cron job
> > >
> > > When sssd is started, which would involve editing the systemd unit file
> > >
> > > Creating a new systemd service which depends on sssd.service . This
> > service
> > > runs sss_override and then restarts sssd.service
> > >
> > > Or am I misunderstanding something?
> > >
> > > I am assuming here we have on-disk sssd databases. If the databases are
> > on
> > > a tmpfs then clearly the sss_override must be run at boot time by one of
> > > the above methods also.
> >
> > As long as the cache file in /var/lib/sss/db is not removed it should be
> > sufficient to run sss_override for each user once and then the override
> > data should stay in the cache.
> >
> > I once got a report that the link between the original user data and the
> > override data got lost, but I wasn't able to reproduce this so far.
> >
> > It is always a good idea to call user-export/group-export to have a
> > backup file around.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> >
> > > ___
> > > 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/TMGIPZGSONS6Q62RGKFBI5EDZ7GPCEUU/
> > ___
> > 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/R3L7BBZGZ5URRV7VYSBIUMRSKVZRYIMJ/
> >

> ___
> 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/VGGBZZJLEZINWOJJTY7WEEQ4LVGVFZ2N/
___
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/2VXDFTQ7LU63YIIPBOCRD4KS2VKEJVOU/

[SSSD-users] Re: Behaviour of refresh_expired_interval

[John Hearns]

One thing I do note. I have reduced refresh_expired_interval to 40 seconds,
which is clearly a ridiculously low time.
However when I look at the cached information I always see Initgroups
expiration time:Expired

I am not sure what this means.

root@ibis:~# sssctl user-show abc
Name: abc
Cache entry creation date: 06/27/18 17:09:58
Cache entry last update time: 07/04/18 11:28:16
Cache entry expiration time: 07/04/18 11:29:16
Initgroups expiration time: Expired
Cached in InfoPipe: No




On 4 July 2018 at 11:01, John Hearns  wrote:

> Thankyou Sumit. I think you might be trying to tel lme something with the
> debug_level=6   :-)
>
> On 4 July 2018 at 09:04, Sumit Bose  wrote:
>
>> On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
>> > I have an AD setup where users can be a member of perhaps 130 groups.
>> > When I run 'groups jbloggs' this can take 90 seconds or even longer.
>> > I have reduced that time to perhaps 20 seconds by setting
>> > ignore_group_members = TRUE
>> >
>> > Once the information is cached the groups command returns in less that
>> one
>> > second.
>> > However, after a length of time the cache seems to be invalidated and
>> the
>> > information is fetched again from the server, taking 20 seconds again.
>> > The cacheing parameters are set to:
>> >
>> > entry_cache_timeout = 5400
>> > entry_cache_user_timeout = 5400
>> > entry_cache_group_timeout = 5400
>> > refresh_expired_interval = 4000
>> >
>> > Surely this means that after 4000 seconds the user and group
>> information is
>> > refreshed in the background.
>> > So a user running the groups command would always see freshly cached
>> values?
>>
>> With 'debug_level=6' or higher in the [domain/...] section of sssd.conf
>> you
>> should be able to see messages like 'Refreshing  in domain
>> ' in domain log file when is refresh task is running.
>>
>> bye,
>> Sumit
>>
>> >
>> > Clearly I am not understanding something here.
>>
>> > ___
>> > 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/M4
>> R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
>> ___
>> 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/GY
>> L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
>>
>
>
___
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/P3WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/

[SSSD-users] Re: Behaviour of refresh_expired_interval

[John Hearns]

Thankyou Sumit. I think you might be trying to tel lme something with the
debug_level=6   :-)

On 4 July 2018 at 09:04, Sumit Bose  wrote:

> On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
> > I have an AD setup where users can be a member of perhaps 130 groups.
> > When I run 'groups jbloggs' this can take 90 seconds or even longer.
> > I have reduced that time to perhaps 20 seconds by setting
> > ignore_group_members = TRUE
> >
> > Once the information is cached the groups command returns in less that
> one
> > second.
> > However, after a length of time the cache seems to be invalidated and the
> > information is fetched again from the server, taking 20 seconds again.
> > The cacheing parameters are set to:
> >
> > entry_cache_timeout = 5400
> > entry_cache_user_timeout = 5400
> > entry_cache_group_timeout = 5400
> > refresh_expired_interval = 4000
> >
> > Surely this means that after 4000 seconds the user and group information
> is
> > refreshed in the background.
> > So a user running the groups command would always see freshly cached
> values?
>
> With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you
> should be able to see messages like 'Refreshing  in domain
> ' in domain log file when is refresh task is running.
>
> bye,
> Sumit
>
> >
> > Clearly I am not understanding something here.
>
> > ___
> > 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/M4R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
> ___
> 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/GYL5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
>
___
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/LBG3C5FR3QTQ3UTJL623UOVBX7YI642B/

[SSSD-users] Re: sss_override - when to run it?

[John Hearns]

Sumit, thankyou.
What I have done is to write a Python script which loops over all local
users.
The script calls sss_override user-set for each user. Then the script runs
user-export to create a file as you suggest.

I have edited the sssd.service unit file, and placed the changed copy in
/etc/systemd/system/sssd.service
This has an added Post Start action to read in the file using user-import.
These are the lines I added:


ExecStartPost=-/usr/sbin/sss_override user-import /etc/sssd/overrides
TimeoutStartSec=180




On 4 July 2018 at 08:41, Sumit Bose  wrote:

> On Thu, Jun 14, 2018 at 02:33:22PM +0200, John Hearns wrote:
> > We have an existing set of users in a local passwd file
> > I want to run sss_override to create mappings from the AD SID numbers to
> > the existing uid numbers.
> >
> > What is the concensus on running sss_override?
> > I can script it to either parse through the existing passwd file and make
> > an override entry per user,
> > or to parse the file and create an import file which is run once with
> > import-user
> >
> > But when is a good time to run this?
> >
> > In a daily cron job
> >
> > When sssd is started, which would involve editing the systemd unit file
> >
> > Creating a new systemd service which depends on sssd.service . This
> service
> > runs sss_override and then restarts sssd.service
> >
> > Or am I misunderstanding something?
> >
> > I am assuming here we have on-disk sssd databases. If the databases are
> on
> > a tmpfs then clearly the sss_override must be run at boot time by one of
> > the above methods also.
>
> As long as the cache file in /var/lib/sss/db is not removed it should be
> sufficient to run sss_override for each user once and then the override
> data should stay in the cache.
>
> I once got a report that the link between the original user data and the
> override data got lost, but I wasn't able to reproduce this so far.
>
> It is always a good idea to call user-export/group-export to have a
> backup file around.
>
> HTH
>
> bye,
> Sumit
>
>
> > ___
> > 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/TMGIPZGSONS6Q62RGKFBI5EDZ7GPCEUU/
> ___
> 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/R3L7BBZGZ5URRV7VYSBIUMRSKVZRYIMJ/
>
___
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/VGGBZZJLEZINWOJJTY7WEEQ4LVGVFZ2N/

[SSSD-users] Re: Logging of scheduled tasks - password renewal

[John Hearns]

Thankyou Sumit. Indeed I do have adcli installed, and I am investigating
this issue usign the higher log level which you suggest.

I think this is a problem with domain names.
When I use msktutil to renew the machine password I must explicitly run
msktutil ..auto-update --computer-name  myhostname

This is because  the DNS domain of my workstation does not match the Active
Directory realm name




On 4 July 2018 at 08:48, Sumit Bose  wrote:

> On Mon, Jun 25, 2018 at 05:12:25PM +0200, John Hearns wrote:
> > After 30 days of running sssd I found that my test workstation no longer
> > connected to the domain.
> > The machine account password had timed out.
> > I now run a daily cron job using msktutil wihch will auto-update the
> > password.
> >
> > However I should not have to do this. sssd should update the machine
> > password.
> >
> > I can see entries in the logs such that the machine account password
> > renewal task is enabled.
> > Then:
> >
> > [be_ptask_execute] (0x0400): Task [AD machine account password renewal]:
> > executing task, timeout 60 seconds
> >
> > How though can I see if this taks is successful or not?
> > I realise that if the machine account is less than 30 days old the task
> > probably silently completes OK without any logging.
>
> Do you have adcli installed?
>
> If you set 'debug_level=7' or higher in the [domain/...] section of
> sssd.conf you should be able to find the debug output of adcli in the
> logs, it will start with '--- adcli output start---'.
>
> HTH
>
> bye,
> Sumit
>
> >
> > The version of sssd is 16.1 running on Ubuntu
> >
> >
> > John Hearns
>
> > ___
> > 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/2F77SPP4CXHS4YMKCMHIA5EJHI424VNV/
> ___
> 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/EHQHLPX24S45CM4ELUUDG7NHQHWQK7TE/
>
___
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/37DC57E5CBCUE2UKPHLDTRRYOQKQ3TKE/

[SSSD-users] Re: Who and w not nss aware?

[John Hearns]

Thanks Sumit.  Rather bizzarely my workstation has no /var/run/utmp file.
I rebooted yesterday - you would think a file like that would be created at
boot time if it did not exist. Weird!


On 4 July 2018 at 08:54, Sumit Bose  wrote:

> On Thu, Jun 28, 2018 at 10:11:28AM +0200, John Hearns wrote:
> > It seems bizarre, but the who and w utilities say there are no users on
> my
> > system.
> > My account  is an Active Direcotry account and sssd is running.
> >
> > johe@ibis:~$ who
> >
> > johe@ibis:~$ w
> >  10:09:26 up 16:47,  0 users,  load average: 0.60, 0.59, 0.48
> > USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
> >
> > I guess this is known behaviour?
>
> I would suggest to run the commands with strace to see what the
> command tries to do. Iirc the user name is actually read from the utmp
> file and SSSD is not called at all here. So the issue might already
> happen earlier that the needed entry isn't written to utmp.
>
> HTH
>
> bye,
> Sumit
>
> > ___
> > 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/L6PADDSQWYL2KIGBYKTJWM6OHW4FTML3/
> ___
> 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/TC6LM5BZMIK6QK5RV3MSKBKZ5VBGRT3O/
>
___
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/EEOEEZRY4242PIQTMBHPOL56PTRZBCQJ/

[SSSD-users] Re: Who and w not nss aware?

[John Hearns]

AAARHHH In the Nae of the Wee Man what posessed Poettering to place a
strange file name in /lib/systemd/system which stops you grepping in that
rather vital directory...

Looks like the utmp file should be created by the service
systemd-update-utmp.service
Iwill investigate on my system, clearly this is not one for this list, sorry




On 4 July 2018 at 09:11, John Hearns  wrote:

> Thanks Sumit.  Rather bizzarely my workstation has no /var/run/utmp file.
> I rebooted yesterday - you would think a file like that would be created
> at boot time if it did not exist. Weird!
>
>
> On 4 July 2018 at 08:54, Sumit Bose  wrote:
>
>> On Thu, Jun 28, 2018 at 10:11:28AM +0200, John Hearns wrote:
>> > It seems bizarre, but the who and w utilities say there are no users on
>> my
>> > system.
>> > My account  is an Active Direcotry account and sssd is running.
>> >
>> > johe@ibis:~$ who
>> >
>> > johe@ibis:~$ w
>> >  10:09:26 up 16:47,  0 users,  load average: 0.60, 0.59, 0.48
>> > USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
>> >
>> > I guess this is known behaviour?
>>
>> I would suggest to run the commands with strace to see what the
>> command tries to do. Iirc the user name is actually read from the utmp
>> file and SSSD is not called at all here. So the issue might already
>> happen earlier that the needed entry isn't written to utmp.
>>
>> HTH
>>
>> bye,
>> Sumit
>>
>> > ___
>> > 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/L6
>> PADDSQWYL2KIGBYKTJWM6OHW4FTML3/
>> ___
>> 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/TC
>> 6LM5BZMIK6QK5RV3MSKBKZ5VBGRT3O/
>>
>
>
___
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/TVMMDJNWDTRW6U23FSNV5KYBL3RWADJR/

[SSSD-users] Re: Who and w not nss aware?

[John Hearns]

Ending this one.  On an Ubuntu system /var/run is a link to /run . That
link was missing on my  system.
But WH  var things go into /var Not the root partition FFS.
' speaking as someone who builds HPC clusters. You might just have an NFS
mounted root partition, which is identical for thousands of compute nodes.
You might liek to have yiur /var as a local tmpfs in RAM, on a local
storage device, or as a uniqeuly named writeable NFS share on the
provisioning node.
Why in the heck assume that VARiable things should go elsewhere than VAR


On 4 July 2018 at 09:17, John Hearns  wrote:

> AAARHHH In the Nae of the Wee Man what posessed Poettering to place a
> strange file name in /lib/systemd/system which stops you grepping in that
> rather vital directory...
>
> Looks like the utmp file should be created by the service
> systemd-update-utmp.service
> Iwill investigate on my system, clearly this is not one for this list,
> sorry
>
>
>
>
> On 4 July 2018 at 09:11, John Hearns  wrote:
>
>> Thanks Sumit.  Rather bizzarely my workstation has no /var/run/utmp file.
>> I rebooted yesterday - you would think a file like that would be created
>> at boot time if it did not exist. Weird!
>>
>>
>> On 4 July 2018 at 08:54, Sumit Bose  wrote:
>>
>>> On Thu, Jun 28, 2018 at 10:11:28AM +0200, John Hearns wrote:
>>> > It seems bizarre, but the who and w utilities say there are no users
>>> on my
>>> > system.
>>> > My account  is an Active Direcotry account and sssd is running.
>>> >
>>> > johe@ibis:~$ who
>>> >
>>> > johe@ibis:~$ w
>>> >  10:09:26 up 16:47,  0 users,  load average: 0.60, 0.59, 0.48
>>> > USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
>>> >
>>> > I guess this is known behaviour?
>>>
>>> I would suggest to run the commands with strace to see what the
>>> command tries to do. Iirc the user name is actually read from the utmp
>>> file and SSSD is not called at all here. So the issue might already
>>> happen earlier that the needed entry isn't written to utmp.
>>>
>>> HTH
>>>
>>> bye,
>>> Sumit
>>>
>>> > ___
>>> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>>> > To unsubscribe send an email to sssd-users-leave@lists.fedorah
>>> osted.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.or
>>> g/archives/list/sssd-users@lists.fedorahosted.org/message/L6
>>> PADDSQWYL2KIGBYKTJWM6OHW4FTML3/
>>> ___
>>> 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.or
>>> g/archives/list/sssd-users@lists.fedorahosted.org/message/TC
>>> 6LM5BZMIK6QK5RV3MSKBKZ5VBGRT3O/
>>>
>>
>>
>
___
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/QLAIAKH3DGCQTF4RWTXVF3CX55665LFO/

[SSSD-users] Re: Logging of scheduled tasks - password renewal

[John Hearns]

Sumit,
thankyou for the advice here.
I reduced the password age value, and with the higher logging level the
password renewal using adcli was successful.
Thanks again.

On 4 July 2018 at 10:03, John Hearns  wrote:

> Thankyou Sumit. Indeed I do have adcli installed, and I am investigating
> this issue usign the higher log level which you suggest.
>
> I think this is a problem with domain names.
> When I use msktutil to renew the machine password I must explicitly run
> msktutil ..auto-update --computer-name  myhostname
>
> This is because  the DNS domain of my workstation does not match the
> Active Directory realm name
>
>
>
>
> On 4 July 2018 at 08:48, Sumit Bose  wrote:
>
>> On Mon, Jun 25, 2018 at 05:12:25PM +0200, John Hearns wrote:
>> > After 30 days of running sssd I found that my test workstation no longer
>> > connected to the domain.
>> > The machine account password had timed out.
>> > I now run a daily cron job using msktutil wihch will auto-update the
>> > password.
>> >
>> > However I should not have to do this. sssd should update the machine
>> > password.
>> >
>> > I can see entries in the logs such that the machine account password
>> > renewal task is enabled.
>> > Then:
>> >
>> > [be_ptask_execute] (0x0400): Task [AD machine account password renewal]:
>> > executing task, timeout 60 seconds
>> >
>> > How though can I see if this taks is successful or not?
>> > I realise that if the machine account is less than 30 days old the task
>> > probably silently completes OK without any logging.
>>
>> Do you have adcli installed?
>>
>> If you set 'debug_level=7' or higher in the [domain/...] section of
>> sssd.conf you should be able to find the debug output of adcli in the
>> logs, it will start with '--- adcli output start---'.
>>
>> HTH
>>
>> bye,
>> Sumit
>>
>> >
>> > The version of sssd is 16.1 running on Ubuntu
>> >
>> >
>> > John Hearns
>>
>> > ___
>> > 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/2F
>> 77SPP4CXHS4YMKCMHIA5EJHI424VNV/
>> ___
>> 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.or
>> g/archives/list/sssd-users@lists.fedorahosted.org/message/EH
>> QHLPX24S45CM4ELUUDG7NHQHWQK7TE/
>>
>
>
___
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/3NYQAUGJNSAUUSVDWLLC722J6JXVQZCY/

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Spike White]

Thanks for responding.

what you said was not exactly my situation, but it got me poking around and
finally I got the configuration working.

I find this interesting item when looking at various sssd subcommands;

[root@spikerealmd02 ~]# sssctl domain-list
amer.dell.com
apac.dell.com
emea.dell.com
japn.dell.com
dell.com
apac.dell.com
emea.dell.com
japn.dell.com


*Why are the remote subdomains duplicated?  *

Ultimately, this was my problem.

When I clear my logs:

sssctl remove-logs


and II do a: getent passwd admjesse_chan
which still fails.

via 'grep -il admjesse_chan sssd_*.log',  I find string only in
sssd_amer.dell.com.log  and sssd_nss.log.

sssd_apac.dell.com.log does the usual site-awareness lookup and identified
primary LDAP server optimally.  So this sssd_be subprocess is working
correctly.

Yet this log file never receives a query request for '
admjesse_c...@apac.dell.com'.

sssd_nss.log gets a query request for admjesse_chan.  It knows about remote
subdomains:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR
#1753: Setting "User by name" plugin
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #1753:
New request 'User by name'
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #1753: Parsing input name [admjesse_chan]
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain apac.dell.com  is Active*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain emea.dell.com  is Active*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain japn.dell.com  is Active*


Since admjesse_chan was specified with domain, it performs a multi-domain
search.  it searches local domain first.  It searches cache for
admjesse_c...@amer.dell.com and then data_provider first:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'admjesse_chan' matched without domain, user is admjesse_chan
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#1753: Setting name [admjesse_chan]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_select_domains] (0x0400):
CR #1753: Performing a multi-domain search
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_domains] (0x0400):
CR #1753: Search will check the cache and check the data provider
...

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1753: Object [admjesse_c...@amer.dell.com] was not found in cache
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#1753: Looking up [admjesse_c...@amer.dell.com] in data provider


It dispatches to data_provider (child process sssd_be for amer.dell.com)
and receives successful response back (no records found):

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [amer.dell.com
][0x1][BE_REQ_USER][name=admjesse_c...@amer.dell.com:-]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_add_timeout] (0x2000):
0x55f844a5cac0
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x55f842febb50:1:admjesse_c...@amer.dell.com@amer.dell.com
]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_remove_timeout] (0x2000):
0x55f844a5cac0
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn:
0x55f844a330f0
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
Dispatching.*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 0 errno: 0 error message: Success*



So next, it searches the next domain -- emea.dell.com:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [emea.dell.com
][0x1][BE_REQ_USER][name=admjesse_c...@emea.dell.com:-]
...
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
Dispatching.
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 3 errno: 5 error message:
Input/output error*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
(0x0040): CR #1753: Data Provider Error: 3, 5, Input/output error*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
(0x0400): CR #1753: Due to an error we will return cached data*
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1753: Looking up [admjesse_c...@emea.dell.com] in cache


It catches the same I/O error when dispatching to the other
data_providers:  apac.dell.com, japn.dell.com

So I focused on -- why are there duplicate entries in  sssctl domain-list?
Might it be trying to dispatch to some "ghost" data_provider (non-existent
sssd_be child process)?  Thus I focused on my sssd.conf file.

i realized I don't need this line:

[sssd]
debug_level = 6
domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
*domain_resolution_order = a

[SSSD-users] Re: Behaviour of refresh_expired_interval

[Sumit Bose]

On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
> I have an AD setup where users can be a member of perhaps 130 groups.
> When I run 'groups jbloggs' this can take 90 seconds or even longer.
> I have reduced that time to perhaps 20 seconds by setting
> ignore_group_members = TRUE
> 
> Once the information is cached the groups command returns in less that one
> second.
> However, after a length of time the cache seems to be invalidated and the
> information is fetched again from the server, taking 20 seconds again.
> The cacheing parameters are set to:
> 
> entry_cache_timeout = 5400
> entry_cache_user_timeout = 5400
> entry_cache_group_timeout = 5400
> refresh_expired_interval = 4000
> 
> Surely this means that after 4000 seconds the user and group information is
> refreshed in the background.
> So a user running the groups command would always see freshly cached values?

With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you
should be able to see messages like 'Refreshing  in domain
' in domain log file when is refresh task is running.

bye,
Sumit

> 
> Clearly I am not understanding something here.

> ___
> 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/M4R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
___
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/GYL5YCE73YNOBPV6JNY2F5WVSBBRMCEC/