I am joining a machine to a domain via Realmd and then filling out the SSSD config with a few more directives such as setting dyndns_update = false. Every once in a while, I'm finding that SSSD is using the old configuration even after restarting the service or starting it interactively.
Sanitized config: [root@host]# cat /etc/sssd/sssd.conf [domain/<domain.com>] access_provider = simple ad_domain = <domain.com> ad_hostname = <host.domain.com> cache_credentials = true debug_level = 6 default_shell = /bin/bash dyndns_update = false fallback_homedir = /home/%u id_provider = ad krb5_realm = <DOMAIN.COM> krb5_store_password_if_offline = true ldap_id_mapping = true realmd_tags = manages-system joined-with-adcli simple_allow_groups = <group> use_fully_qualified_names = false
[sssd] config_file_version = 2 domains = <domain.com> services = nss,pam
If I restart the service, all logs are blank under /var/log/sssd/* so it is not picking up the debug level in the config and I also have trouble logging in. If I start the service interactively: [root@host]# sssd -d 6 -i ...snip... (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [ad_failover_init] (0x0100): No primary servers defined, using service discovery (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD_GC' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [_ad_servers_init] (0x0100): Added service discovery for AD (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_refresh_interval has value 86400 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_iface has no value (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_ttl has value 3600 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update_ptr is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_force_tcp is FALSE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_auth has value gss-tsig (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_server has no value ...snip...
It clearly sees dyndns_update as TRUE even though its set to false in the config. It remains stuck in this state until i remove /var/lib/sss/db/config.ldb and restart the service, after which everything is fine.
Is there any way for me to dig into why the config.ldb file would not be refreshed after config changes and service restart?
Hi,
What OS is this on? I would like to try and reproduce the issue on my side.
Striker
On 03/18/2016 02:31 PM, chadwickbanning@gmail.com wrote:
I am joining a machine to a domain via Realmd and then filling out the SSSD config with a few more directives such as setting dyndns_update = false. Every once in a while, I'm finding that SSSD is using the old configuration even after restarting the service or starting it interactively.
Sanitized config: [root@host]# cat /etc/sssd/sssd.conf [domain/<domain.com>] access_provider = simple ad_domain = <domain.com> ad_hostname = <host.domain.com> cache_credentials = true debug_level = 6 default_shell = /bin/bash dyndns_update = false fallback_homedir = /home/%u id_provider = ad krb5_realm = <DOMAIN.COM> krb5_store_password_if_offline = true ldap_id_mapping = true realmd_tags = manages-system joined-with-adcli simple_allow_groups = <group> use_fully_qualified_names = false
[sssd] config_file_version = 2 domains = <domain.com> services = nss,pam
If I restart the service, all logs are blank under /var/log/sssd/* so it is not picking up the debug level in the config and I also have trouble logging in. If I start the service interactively: [root@host]# sssd -d 6 -i ...snip... (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [ad_failover_init] (0x0100): No primary servers defined, using service discovery (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD_GC' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [_ad_servers_init] (0x0100): Added service discovery for AD (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_refresh_interval has value 86400 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_iface has no value (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_ttl has value 3600 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update_ptr is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_force_tcp is FALSE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_auth has value gss-tsig (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_server has no value ...snip...
It clearly sees dyndns_update as TRUE even though its set to false in the config. It remains stuck in this state until i remove /var/lib/sss/db/config.ldb and restart the service, after which everything is fine.
Is there any way for me to dig into why the config.ldb file would not be refreshed after config changes and service restart? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
This is on a RHEL 7.2 box
On Fri, Mar 18, 2016 at 3:32 PM, Striker Leggette striker@terranforge.com wrote:
Hi,
What OS is this on? I would like to try and reproduce the issue on my side.
Striker
On 03/18/2016 02:31 PM, chadwickbanning@gmail.com wrote:
I am joining a machine to a domain via Realmd and then filling out the
SSSD config with a few more directives such as setting dyndns_update = false. Every once in a while, I'm finding that SSSD is using the old configuration even after restarting the service or starting it interactively.
Sanitized config: [root@host]# cat /etc/sssd/sssd.conf [domain/<domain.com>] access_provider = simple ad_domain = <domain.com> ad_hostname = <host.domain.com> cache_credentials = true debug_level = 6 default_shell = /bin/bash dyndns_update = false fallback_homedir = /home/%u id_provider = ad krb5_realm = <DOMAIN.COM> krb5_store_password_if_offline = true ldap_id_mapping = true realmd_tags = manages-system joined-with-adcli simple_allow_groups = <group> use_fully_qualified_names = false
[sssd] config_file_version = 2 domains = <domain.com> services = nss,pam
If I restart the service, all logs are blank under /var/log/sssd/* so it
is not picking up the debug level in the config and I also have trouble logging in.
If I start the service interactively: [root@host]# sssd -d 6 -i ...snip... (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [ad_failover_init]
(0x0100): No primary servers defined, using service discovery
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server]
(0x0400): Adding new SRV server to service 'AD_GC' using 'tcp'.
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server]
(0x0400): Adding new SRV server to service 'AD' using 'tcp'.
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [_ad_servers_init]
(0x0100): Added service discovery for AD
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_update is TRUE
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_refresh_interval has value 86400
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_iface has no value
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_ttl has value 3600
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_update_ptr is TRUE
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_force_tcp is FALSE
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_auth has value gss-tsig
(Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options]
(0x0400): Option dyndns_server has no value
...snip...
It clearly sees dyndns_update as TRUE even though its set to false in
the config. It remains stuck in this state until i remove /var/lib/sss/db/config.ldb and restart the service, after which everything is fine.
Is there any way for me to dig into why the config.ldb file would not be
refreshed after config changes and service restart?
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (18/03/16 15:57), Chadwick Banning wrote:
This is on a RHEL 7.2 box
sssd daemon check the modified time of configuration time (mtime) and if it is newerthen last configuration then it is replaced.
IIRC ls will print mtime and not atime.
So could you check output of following command: ls -l /var/lib/sss/db/config.ldb /etc/sssd/sssd.conf
LS
I just finally got a pristine test case for doing this and here are the results:
[root@host ~]# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 559 Mar 29 09:29 /etc/sssd/sssd.conf
[root@host ~]# ls -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 Mar 29 09:29 /var/lib/sss/db/config.ldb
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l /etc/sssd/sssd.conf
-rw------- 1 root root 559 29-03-2016 09:29:58 /etc/sssd/sssd.conf
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 29-03-2016 09:29:59 /var/lib/sss/db/config.ldb
These times make sense as the sssd.conf file was put into place and then the service restarted and the config.ldb built. From /var/log/messages:
Mar 29 09:29:58 localhost puppet-agent[2865]: (/Stage[main]/Realmd::Sssd:: Config/File[/etc/sssd/sssd.conf]/content) content changed '{md5} 4b5234cb037adcfb49887c0616773efb' to '{md5}30e2784e49079c59193eeeae21d48c65'
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Config]) Scheduling refresh of Class[Realmd::Sssd::Service]
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Service]) Scheduling refresh of Service[sssd]
Mar 29 09:29:58 localhost systemd: Stopping System Security Services Daemon...
Mar 29 09:29:58 localhost sssd[nss]: Shutting down
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Shutting down
Mar 29 09:29:58 localhost sssd[pam]: Shutting down
Mar 29 09:29:58 localhost systemd: Starting System Security Services Daemon...
Mar 29 09:29:58 localhost sssd: Starting up
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Starting up
Mar 29 09:29:59 localhost sssd[nss]: Starting up
Mar 29 09:29:59 localhost sssd[pam]: Starting up
Mar 29 09:29:59 localhost systemd: Started System Security Services Daemon.
At the point of restart shouldn't it have seen the updated time on sssd.conf and rebuilt config.ldb?
On Fri, Mar 18, 2016 at 6:00 PM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (18/03/16 15:57), Chadwick Banning wrote:
This is on a RHEL 7.2 box
sssd daemon check the modified time of configuration time (mtime) and if it is newerthen last configuration then it is replaced.
IIRC ls will print mtime and not atime.
So could you check output of following command: ls -l /var/lib/sss/db/config.ldb /etc/sssd/sssd.conf
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (29/03/16 09:52), Chadwick Banning wrote:
I just finally got a pristine test case for doing this and here are the results:
[root@host ~]# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 559 Mar 29 09:29 /etc/sssd/sssd.conf
[root@host ~]# ls -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 Mar 29 09:29 /var/lib/sss/db/config.ldb
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l /etc/sssd/sssd.conf
-rw------- 1 root root 559 29-03-2016 09:29:58 /etc/sssd/sssd.conf
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 29-03-2016 09:29:59 /var/lib/sss/db/config.ldb
These times make sense as the sssd.conf file was put into place and then the service restarted and the config.ldb built. From /var/log/messages:
Mar 29 09:29:58 localhost puppet-agent[2865]: (/Stage[main]/Realmd::Sssd:: Config/File[/etc/sssd/sssd.conf]/content) content changed '{md5} 4b5234cb037adcfb49887c0616773efb' to '{md5}30e2784e49079c59193eeeae21d48c65'
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Config]) Scheduling refresh of Class[Realmd::Sssd::Service]
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Service]) Scheduling refresh of Service[sssd]
Mar 29 09:29:58 localhost systemd: Stopping System Security Services Daemon...
Mar 29 09:29:58 localhost sssd[nss]: Shutting down
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Shutting down
Mar 29 09:29:58 localhost sssd[pam]: Shutting down
Mar 29 09:29:58 localhost systemd: Starting System Security Services Daemon...
Mar 29 09:29:58 localhost sssd: Starting up
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Starting up
Mar 29 09:29:59 localhost sssd[nss]: Starting up
Mar 29 09:29:59 localhost sssd[pam]: Starting up
Mar 29 09:29:59 localhost systemd: Started System Security Services Daemon.
At the point of restart shouldn't it have seen the updated time on sssd.conf and rebuilt config.ldb?
It should and according to timestamps it was done.
If you think it was not done then could you provide latest sssd.conf and output of following command? ldbsearch -H /var/lib/sss/db/config.ldb ^^^^^^^^^ This utility is part of package ldb-tools
LS
There are settings in the sssd.conf file that aren't in the ldbsearch output or that have the wrong values in the output:
[root@host ~]# cat /etc/sssd/sssd.conf
[domain/domain.com]
access_provider = simple
ad_domain = domain.com
ad_hostname = host.domain.com
cache_credentials = true
debug_level = 6
default_shell = /bin/bash
dyndns_update = false
fallback_homedir = /home/%u
id_provider = ad
krb5_realm = DOMAIN.COM http://domain.com/
krb5_store_password_if_offline = true
ldap_id_mapping = true
realmd_tags = manages-system joined-with-adcli
simple_allow_groups = Group1
use_fully_qualified_names = false
[sssd]
config_file_version = 2
domains = domain.com
override_space = _
services = nss,pam
[root@host ~]# ldbsearch -H /var/lib/sss/db/config.ldb
server_sort:Unable to register control with rootdse!
# record 1
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
domains: domain.com
services: nss, pam
distinguishedName: cn=sssd,cn=config
# record 2
dn: cn=config
version: 2
lastUpdate: 1459260529
distinguishedName: cn=config
# record 3
dn: cn=domain.com,cn=domain,cn=config
access_provider: ad
ad_domain: domain.com
cache_credentials: True
cn: domain.com
default_shell: /bin/bash
fallback_homedir: /home/%u@%d
id_provider: ad
krb5_realm: DOMAIN.COM http://domain.com/
krb5_store_password_if_offline: True
ldap_id_mapping: True
realmd_tags: manages-system joined-with-adcli
use_fully_qualified_names: True
case_sensitive: false
distinguishedName: cn=domain.com,cn=domain,cn=config
# returned 3 records
# 3 entries
# 0 referrals
On Tue, Mar 29, 2016 at 10:23 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (29/03/16 09:52), Chadwick Banning wrote:
I just finally got a pristine test case for doing this and here are the results:
[root@host ~]# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 559 Mar 29 09:29 /etc/sssd/sssd.conf
[root@host ~]# ls -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 Mar 29 09:29 /var/lib/sss/db/config.ldb
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l
/etc/sssd/sssd.conf
-rw------- 1 root root 559 29-03-2016 09:29:58 /etc/sssd/sssd.conf
[root@host ~]# ls --time-style='+%d-%m-%Y %H:%M:%S' -l /var/lib/sss/db/config.ldb
-rw------- 1 root root 1286144 29-03-2016 09:29:59 /var/lib/sss/db/config.ldb
These times make sense as the sssd.conf file was put into place and then the service restarted and the config.ldb built. From /var/log/messages:
Mar 29 09:29:58 localhost puppet-agent[2865]: (/Stage[main]/Realmd::Sssd:: Config/File[/etc/sssd/sssd.conf]/content) content changed '{md5} 4b5234cb037adcfb49887c0616773efb' to
'{md5}30e2784e49079c59193eeeae21d48c65'
Mar 29 09:29:58 localhost puppet-agent[2865]:
(Class[Realmd::Sssd::Config])
Scheduling refresh of Class[Realmd::Sssd::Service]
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Service]) Scheduling refresh of Service[sssd]
Mar 29 09:29:58 localhost systemd: Stopping System Security Services Daemon...
Mar 29 09:29:58 localhost sssd[nss]: Shutting down
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Shutting down
Mar 29 09:29:58 localhost sssd[pam]: Shutting down
Mar 29 09:29:58 localhost systemd: Starting System Security Services Daemon...
Mar 29 09:29:58 localhost sssd: Starting up
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Starting up
Mar 29 09:29:59 localhost sssd[nss]: Starting up
Mar 29 09:29:59 localhost sssd[pam]: Starting up
Mar 29 09:29:59 localhost systemd: Started System Security Services
Daemon.
At the point of restart shouldn't it have seen the updated time on sssd.conf and rebuilt config.ldb?
It should and according to timestamps it was done.
If you think it was not done then could you provide latest sssd.conf and output of following command? ldbsearch -H /var/lib/sss/db/config.ldb ^^^^^^^^^ This utility is part of package ldb-tools
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (29/03/16 10:48), Chadwick Banning wrote:
There are settings in the sssd.conf file that aren't in the ldbsearch output or that have the wrong values in the output:
[root@host ~]# cat /etc/sssd/sssd.conf
[domain/domain.com]
access_provider = simple
ad_domain = domain.com
ad_hostname = host.domain.com
cache_credentials = true
debug_level = 6
default_shell = /bin/bash
dyndns_update = false
fallback_homedir = /home/%u
id_provider = ad
krb5_realm = DOMAIN.COM http://domain.com/
krb5_store_password_if_offline = true
ldap_id_mapping = true
realmd_tags = manages-system joined-with-adcli
simple_allow_groups = Group1
use_fully_qualified_names = false
[sssd]
config_file_version = 2
domains = domain.com
override_space = _
services = nss,pam
[root@host ~]# ldbsearch -H /var/lib/sss/db/config.ldb
server_sort:Unable to register control with rootdse!
# record 1
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
domains: domain.com
services: nss, pam
distinguishedName: cn=sssd,cn=config
# record 2
dn: cn=config
version: 2
lastUpdate: 1459260529
Are you really sure that sssd was restarted after changing sssd.conf? The attribute lastUpdate says taht sssd.conf was changed at "Tuesday, 29-Mar-16 14:08:49 UTC"
Your timezeone seems to be -4:00 according to mail header.
But in your previous mail configuration file was changed earlier (13:29:58 UTC)
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Service]) Scheduling refresh of Service[sssd]
Mar 29 09:29:58 localhost systemd: Stopping System Security Services Daemon...
Mar 29 09:29:58 localhost sssd[nss]: Shutting down
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Shutting down
Mar 29 09:29:58 localhost sssd[pam]: Shutting down
Mar 29 09:29:58 localhost systemd: Starting System Security Services Daemon...
Mar 29 09:29:58 localhost sssd: Starting up
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Starting up
Mar 29 09:29:59 localhost sssd[nss]: Starting up
Mar 29 09:29:59 localhost sssd[pam]: Starting up
Mar 29 09:29:59 localhost systemd: Started System Security Services Daemon.
Is it possible that sssd.conf was changed more often with different versions ?
LS
Yes -- it does look like something strange happened with time on the server during provisioning, which might cause this issue. I'm looking into why time shifted.
On Tue, Mar 29, 2016 at 11:15 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (29/03/16 10:48), Chadwick Banning wrote:
There are settings in the sssd.conf file that aren't in the ldbsearch output or that have the wrong values in the output:
[root@host ~]# cat /etc/sssd/sssd.conf
[domain/domain.com]
access_provider = simple
ad_domain = domain.com
ad_hostname = host.domain.com
cache_credentials = true
debug_level = 6
default_shell = /bin/bash
dyndns_update = false
fallback_homedir = /home/%u
id_provider = ad
krb5_realm = DOMAIN.COM http://domain.com/
krb5_store_password_if_offline = true
ldap_id_mapping = true
realmd_tags = manages-system joined-with-adcli
simple_allow_groups = Group1
use_fully_qualified_names = false
[sssd]
config_file_version = 2
domains = domain.com
override_space = _
services = nss,pam
[root@host ~]# ldbsearch -H /var/lib/sss/db/config.ldb
server_sort:Unable to register control with rootdse!
# record 1
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
domains: domain.com
services: nss, pam
distinguishedName: cn=sssd,cn=config
# record 2
dn: cn=config
version: 2
lastUpdate: 1459260529
Are you really sure that sssd was restarted after changing sssd.conf? The attribute lastUpdate says taht sssd.conf was changed at "Tuesday, 29-Mar-16 14:08:49 UTC"
Your timezeone seems to be -4:00 according to mail header.
But in your previous mail configuration file was changed earlier (13:29:58 UTC)
Mar 29 09:29:58 localhost puppet-agent[2865]: (Class[Realmd::Sssd::Service]) Scheduling refresh of Service[sssd]
Mar 29 09:29:58 localhost systemd: Stopping System Security Services Daemon...
Mar 29 09:29:58 localhost sssd[nss]: Shutting down
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Shutting down
Mar 29 09:29:58 localhost sssd[pam]: Shutting down
Mar 29 09:29:58 localhost systemd: Starting System Security Services Daemon...
Mar 29 09:29:58 localhost sssd: Starting up
Mar 29 09:29:58 localhost sssd[be[domain.com]]: Starting up
Mar 29 09:29:59 localhost sssd[nss]: Starting up
Mar 29 09:29:59 localhost sssd[pam]: Starting up
Mar 29 09:29:59 localhost systemd: Started System Security Services Daemon.
Is it possible that sssd.conf was changed more often with different versions ?
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Chadwick Banning -
Lukas Slebodnik -
Striker Leggette