Discussion:
kerberos ticket not renewed in 15.2/master
(too old to reply)
Joakim Tjernlund
2017-05-18 14:58:32 UTC
Permalink
Sequence:

login into MATE or Plasma
suspend to ram
wait until krbtgt expires
wakeup computer
unlock screen
klist will show the old expired ticket.

lock/unlock screen again(well after networking is up)
klist still shows the old ticket.

No SSO/NFS possible until manually doing a kinit to get a fresh ticket

Anyone else see this?

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leav
Striker Leggette
2017-05-18 15:40:18 UTC
Permalink
I can understand the first unlock from waking up from sleep. For the
second, bump your debug_level in sssd.conf up to 7 and then check to see
if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for
the second login attempt from the lock screen. You should be able to
see if it is using cached creds or actively trying to parse the domain
server.

Can you paste your sssd.conf also?
Post by Joakim Tjernlund
login into MATE or Plasma
suspend to ram
wait until krbtgt expires
wakeup computer
unlock screen
klist will show the old expired ticket.
lock/unlock screen again(well after networking is up)
klist still shows the old ticket.
No SSO/NFS possible until manually doing a kinit to get a fresh ticket
Anyone else see this?
Jocke
_______________________________________________
Jakub Hrozek
2017-05-18 18:37:26 UTC
Permalink
Post by Striker Leggette
I can understand the first unlock from waking up from sleep. For the
second, bump your debug_level in sssd.conf up to 7 and then check to see if
you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the
second login attempt from the lock screen. You should be able to see if it
is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
In addition, one more question:
- when you unlock after wakeup, is the Kerberos server reachable or
do you e.g. first need to connect to a VPN to be able to reach the
server?
Post by Striker Leggette
Post by Joakim Tjernlund
login into MATE or Plasma
suspend to ram
wait until krbtgt expires
wakeup computer
unlock screen
klist will show the old expired ticket.
lock/unlock screen again(well after networking is up)
klist still shows the old ticket.
No SSO/NFS possible until manually doing a kinit to get a fresh ticket
Anyone else see this?
Jocke
_______________________________________________
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd
Joakim Tjernlund
2017-05-19 10:37:09 UTC
Permalink
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
I not using a VPN, local ethernet (got wifi too bu in this case eth is connected) 

[sssd]
config_file_version = 2
domains = infinera.com
services = nss, pam
debug_level = 0xffff

[nss]
fallback_homedir = /home/%u
default_shell = /bin/bash
debug_level = 0xffff
enum_cache_timeout = 3600
entry_negative_timeout = 300

[pam]
debug_level = 0xffff

[domain/infinera.com]
#debug_level = 0xffff

ignore_group_members = false
ldap_id_mapping = false
cache_credentials = true
enumerate = false
ldap_enumeration_refresh_timeout = 1800
entry_cache_timeout = 3600
refresh_expired_interval = 2700

id_provider = ad
auth_provider = ad
access_provider = permit
chpass_provider = ad

ad_server = se-dc01.infinera.com,se-dc02.infinera.com
ad_backup_server = sv-dc01.infinera.com,sv-dc02.infinera.com

dyndns_iface = vpn0, wlan0, eth0
dyndns_update = true
dyndns_refresh_interval = 600
dyndns_update_ptr = true
dyndns_ttl = 3600
case_sensitive = false

ldap_referrals = false
ldap_sasl_mech = GSSAPI
ldap_schema = rfc2307bis

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true

krb5_realm = INFINERA.COM
krb5_canonicalize = true
krb5_store_password_if_offline = true
krb5_use_kdcinfo = False
krb5_renewable_lifetime = 7d
krb5_lifetime = 24h
krb5_renew_interval = 4h

Here is an excerpt from the log:

(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_execute] (0x0400): Back end is offline
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_execute] (0x0400): Task [Check if online (periodic)]: executing task, timeout 60 seconds
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_reset_services] (0x1000): Resetting all servers in all services
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_attach_req] (0x0400): DP Request [Online Check #48]: New request. Flags [0000].
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'se-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'se-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_done] (0x0400): Task [Check if online (periodic)]: finished successfully
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 84 seconds from last execution time [1495189632]
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'se-dc01.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_execute] (0x0400): Back end is offline
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_schedule] (0x0400): Task [Refresh Records]: scheduling task 2700 seconds from now [1495192248]
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (se-dc01.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'se-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'se-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'se-dc02.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (se-dc02.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc01.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (sv-dc01.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (sv-dc02.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_req_done] (0x0400): DP Request [Online Check #48]: Request handler finished [0]: Success
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [_dp_req_recv] (0x0400): DP Request [Online Check #48]: Receiving request data.
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_req_destructor] (0x0400): DP Request [Online Check #48]: Request removed.
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_check_online_done] (0x0400): Error during online check [0]: Success
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_reset_services] (0x1000): Resetting all servers in all services
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'se-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc01.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [reactivate_subdoms] (0x1000): Resetting all subdomains
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain transmode.se is Active
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain transmode.se is Active
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_ptask_disable] (0x0400): Task [Check if online (periodic)]: disabling task
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_run_online_cb] (0x0080): Going online. Running callbacks.
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4294967295]
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_attach_req] (0x0400): DP Request [Account #49]: New request. Flags [0x0001].
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'se-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'se-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'se-dc01.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc01.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (se-dc01.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'se-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'se-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'se-dc02.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'se-dc02.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (se-dc02.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc01.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc01.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc01.infinera.com' as 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (sv-dc01.infinera.com), resolver returned [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x1000): Trying with the next one!
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'neutral'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'resolving name'
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc02.infinera.com' in files
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in DNS
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(Fri May 19 12:25:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers

....
Post by Joakim Tjernlund
login into MATE or Plasma
suspend to ram
wait until krbtgt expires
wakeup computer
unlock screen
klist will show the old expired ticket.
lock/unlock screen again(well after networking is up)
klist still shows the old ticket.
No SSO/NFS possible until manually doing a kinit to get a fresh ticket
Anyone else see this?
Jocke
_______________________________________________
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedora
Lukas Slebodnik
2017-05-19 11:22:24 UTC
Permalink
Post by Joakim Tjernlund
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
I not using a VPN, local ethernet (got wifi too bu in this case eth is connected) 
And log file says there are problem with resolution of DNS names.

e.g.
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers

Therefore sssd works in offline mode and therefore cannot renew a ticket.

LS
Post by Joakim Tjernlund
[sssd]
config_file_version = 2
domains = infinera.com
services = nss, pam
debug_level = 0xffff
[nss]
fallback_homedir = /home/%u
default_shell = /bin/bash
debug_level = 0xffff
enum_cache_timeout = 3600
entry_negative_timeout = 300
[pam]
debug_level = 0xffff
[domain/infinera.com]
#debug_level = 0xffff
ignore_group_members = false
ldap_id_mapping = false
cache_credentials = true
enumerate = false
ldap_enumeration_refresh_timeout = 1800
entry_cache_timeout = 3600
refresh_expired_interval = 2700
id_provider = ad
auth_provider = ad
access_provider = permit
chpass_provider = ad
ad_server = se-dc01.infinera.com,se-dc02.infinera.com
ad_backup_server = sv-dc01.infinera.com,sv-dc02.infinera.com
dyndns_iface = vpn0, wlan0, eth0
dyndns_update = true
dyndns_refresh_interval = 600
dyndns_update_ptr = true
dyndns_ttl = 3600
case_sensitive = false
ldap_referrals = false
ldap_sasl_mech = GSSAPI
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
krb5_realm = INFINERA.COM
krb5_canonicalize = true
krb5_store_password_if_offline = true
krb5_use_kdcinfo = False
krb5_renewable_lifetime = 7d
krb5_lifetime = 24h
krb5_renew_interval = 4h
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedorahoste
Lukas Slebodnik
2017-05-19 11:43:26 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
I not using a VPN, local ethernet (got wifi too bu in this case eth is connected) 
And log file says there are problem with resolution of DNS names.
e.g.
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers
Therefore sssd works in offline mode and therefore cannot renew a ticket.
ping and nslookup work fine, I just did a new lock unlock and this is the log from this that action.
I still did not get a new ticket.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'neutral'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'resolving name'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in DNS
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0200): Found address for server sv-dc02.infinera.com: [10.100.98.22] TTL 3600
looks like name was properly resolved here
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_primary_server_timeout_activate] (0x0400): The primary server reconnection is already scheduled
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
SSSD tried to authenticate online here.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x1000): Waiting for child [15431].
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x0100): child [15431] finished successfully.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_mark_dom_offline] (0x1000): Marking back end offline
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 81 seconds from now [1495193169]
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response] (0x0020): message too short.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0200): Giving back pam data.
But renew failed and sssd went offline.

Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files. Attachments or pastebin are usually better
then direct inclusion of log into mail.

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users
Joakim Tjernlund
2017-05-19 12:07:59 UTC
Permalink
Post by Lukas Slebodnik
Post by Lukas Slebodnik
Post by Joakim Tjernlund
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
I not using a VPN, local ethernet (got wifi too bu in this case eth is connected) 
And log file says there are problem with resolution of DNS names.
e.g.
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers
Therefore sssd works in offline mode and therefore cannot renew a ticket.
ping and nslookup work fine, I just did a new lock unlock and this is the log from this that action.
I still did not get a new ticket.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'neutral'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'resolving name'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in DNS
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0200): Found address for server sv-dc02.infinera.com: [10.100.98.22] TTL 3600
looks like name was properly resolved here
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_primary_server_timeout_activate] (0x0400): The primary server reconnection is already scheduled
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
SSSD tried to authenticate online here.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x1000): Waiting for child [15431].
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x0100): child [15431] finished successfully.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_mark_dom_offline] (0x1000): Marking back end offline
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 81 seconds from now [1495193169]
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response] (0x0020): message too short.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0200): Giving back pam data.
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
Post by Lukas Slebodnik
Attachments or pastebin are usually better
then direct inclusion of log into mail.
Sure, will attach next time
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe
Lukas Slebodnik
2017-05-19 12:14:42 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Lukas Slebodnik
Post by Joakim Tjernlund
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
I not using a VPN, local ethernet (got wifi too bu in this case eth is connected) 
And log file says there are problem with resolution of DNS names.
e.g.
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'se-dc02.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc01.infinera.com': Could not contact DNS servers
[fo_resolve_service_done] (0x0020): Failed to resolve server 'sv-dc02.infinera.com': Could not contact DNS servers
Therefore sssd works in offline mode and therefore cannot renew a ticket.
ping and nslookup work fine, I just did a new lock unlock and this is the log from this that action.
I still did not get a new ticket.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'neutral'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name not resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'resolving name'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'sv-dc02.infinera.com' in files
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'sv-dc02.infinera.com' in DNS
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [set_server_common_status] (0x0100): Marking server 'sv-dc02.infinera.com' as 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_process] (0x0200): Found address for server sv-dc02.infinera.com: [10.100.98.22] TTL 3600
looks like name was properly resolved here
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://sv-dc02.infinera.com'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_primary_server_timeout_activate] (0x0400): The primary server reconnection is already scheduled
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [sss_domain_get_state] (0x1000): Domain infinera.com is Active
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
SSSD tried to authenticate online here.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x1000): Waiting for child [15431].
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [child_sig_handler] (0x0100): child [15431] finished successfully.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'sv-dc02.infinera.com' as 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc01.infinera.com' is 'working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'se-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'se-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc01.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc01.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_server_status] (0x1000): Status of server 'sv-dc02.infinera.com' is 'name resolved'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'sv-dc02.infinera.com' is 'not working'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD'
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_mark_dom_offline] (0x1000): Marking back end offline
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 81 seconds from now [1495193169]
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response] (0x0020): message too short.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed.
(Fri May 19 13:24:48 2017) [sssd[be[infinera.com]]] [renew_tgt_done] (0x0200): Giving back pam data.
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Attachments or pastebin are usually better
then direct inclusion of log into mail.
Sure, will attach next time
Looking forward to new log files :-)

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-lea
Joakim Tjernlund
2017-05-19 12:50:50 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
I can see:

se-jocke-lx sssds # grep write_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All
data has been sent!
se-jocke-lx sssds # grep read_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
se-jocke-lx sssds # grep parse_krb5_child_response *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response]
(0x1000): child response [0][3][33].

but only these files:
ls
./  ../  sssd_infinera.com.log  sssd.log  sssd_nss.log  sssd_pam.log


to start debug logging I did a:
# > sss_debuglevel 7
should I do something more?
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Attachments or pastebin are usually better
then direct inclusion of log into mail.
Sure, will attach next time
Looking forward to new log files :-)
Yes, but ATM I don't have anything new to add :(
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an e
Lukas Slebodnik
2017-05-19 13:24:25 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
se-jocke-lx sssds # grep write_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All
data has been sent!
se-jocke-lx sssds # grep read_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
se-jocke-lx sssds # grep parse_krb5_child_response *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response]
(0x1000): child response [0][3][33].
ls
./  ../  sssd_infinera.com.log  sssd.log  sssd_nss.log  sssd_pam.log
# > sss_debuglevel 7
should I do something more?
That's weird. Is there something in journald from that time

If not then I would recommend to stop sssd; clena log file
rm -f /var/log/sssd/*
* set debug_level = 9 in domain section
* start sssd
* reproduce bug

And then there should be *child log files

Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-
Joakim Tjernlund
2017-05-19 14:07:07 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
se-jocke-lx sssds # grep write_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All
data has been sent!
se-jocke-lx sssds # grep read_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
se-jocke-lx sssds # grep parse_krb5_child_response *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response]
(0x1000): child response [0][3][33].
ls
./  ../  sssd_infinera.com.log  sssd.log  sssd_nss.log  sssd_pam.log
# > sss_debuglevel 7
should I do something more?
That's weird. Is there something in journald from that time
If not then I would recommend to stop sssd; clena log file
rm -f /var/log/sssd/*
* set debug_level = 9 in domain section
* start sssd
* reproduce bug
And then there should be *child log files
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
I have tried both 1.15.2 and git master(using that ATM)
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-user
Lukas Slebodnik
2017-05-19 14:34:01 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
se-jocke-lx sssds # grep write_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All
data has been sent!
se-jocke-lx sssds # grep read_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
se-jocke-lx sssds # grep parse_krb5_child_response *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response]
(0x1000): child response [0][3][33].
ls
./  ../  sssd_infinera.com.log  sssd.log  sssd_nss.log  sssd_pam.log
# > sss_debuglevel 7
should I do something more?
That's weird. Is there something in journald from that time
If not then I would recommend to stop sssd; clena log file
rm -f /var/log/sssd/*
* set debug_level = 9 in domain section
* start sssd
* reproduce bug
And then there should be *child log files
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
Ahh sorry;

I cannot see 1.15.2 in portage.
Which arguments did you pass to configure?

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedo
Joakim Tjernlund
2017-05-19 14:41:23 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
I can understand the first unlock from waking up from sleep.  For the second, bump your debug_level in sssd.conf up to 7 and then check to see if you have any "Got request" lines in /var/log/sssd/sssd_domain.log for the second login attempt from the lock screen.  You should be able to see if it is using cached creds or actively trying to parse the domain server.
Can you paste your sssd.conf also?
But renew failed and sssd went offline.
Could you truncate sssd log file (truncate -s 0 /var/log/sssd/*)
Then try to reproduce one more time and provide not only domain log file but
also *child log files.
Did that but I did not get a child log file at all.
If you can see debug messages from following functions
write_pipe_handler
read_pipe_handler
parse_krb5_child_response
Then krb5_child was executed. And there will be non-empty file
/var/log/sssd/krb5_child.log.
se-jocke-lx sssds # grep write_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [write_pipe_handler] (0x0400): All
data has been sent!
se-jocke-lx sssds # grep read_pipe_handler *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
se-jocke-lx sssds # grep parse_krb5_child_response *
sssd_infinera.com.log:(Fri May 19 13:45:06 2017) [sssd[be[infinera.com]]] [parse_krb5_child_response]
(0x1000): child response [0][3][33].
ls
./  ../  sssd_infinera.com.log  sssd.log  sssd_nss.log  sssd_pam.log
# > sss_debuglevel 7
should I do something more?
That's weird. Is there something in journald from that time
If not then I would recommend to stop sssd; clena log file
rm -f /var/log/sssd/*
* set debug_level = 9 in domain section
* start sssd
* reproduce bug
And then there should be *child log files
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
Ahh sorry;
I cannot see 1.15.2 in portage.
Which arguments did you pass to configure?
Sending the ebuilds I use, made by myself as upstream is lagging behind.
Lukas Slebodnik
2017-05-19 14:59:58 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
Ahh sorry;
I cannot see 1.15.2 in portage.
Which arguments did you pass to configure?
Sending the ebuilds I use, made by myself as upstream is lagging behind.
Logging to journald is not enabled enabled. So I do not think
you fwill find anything in journald :-)

sssd is not compiled with non-privileged user therefore
it should not cause problems.

We will not be able to move it forward without
*child log files.

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users
Joakim Tjernlund
2017-05-19 15:22:17 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
Ahh sorry;
I cannot see 1.15.2 in portage.
Which arguments did you pass to configure?
Sending the ebuilds I use, made by myself as upstream is lagging behind.
Logging to journald is not enabled enabled. So I do not think
you fwill find anything in journald :-)
Sure, I am on openrc :)
Post by Lukas Slebodnik
sssd is not compiled with non-privileged user therefore
it should not cause problems.
We will not be able to move it forward without
*child log files.
I think I messed up log file handling, possibly by rm -f * while sssd
running.

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an e
Joakim Tjernlund
2017-05-22 14:53:39 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Will do over the week end
Post by Lukas Slebodnik
Please also provide an output of following command
rpm -V sssd-common sssd-krb5-common
That is a bit hard as this is Gentoo :)
Ahh sorry;
I cannot see 1.15.2 in portage.
Which arguments did you pass to configure?
Sending the ebuilds I use, made by myself as upstream is lagging behind.
Logging to journald is not enabled enabled. So I do not think
you fwill find anything in journald :-)
sssd is not compiled with non-privileged user therefore
it should not cause problems.
We will not be able to move it forward without
*child log files.
LS
Hi again
Got some *child logs now. Can you make something of these?
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x0400): ldap_child started.
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): context initialized
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): total buffer size: 49
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): realm_str size: 12
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): got realm_str: INFINERA.COM
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): princ_str size: 13
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): got princ_str: GENTOO-LABBB$
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): keytab_name size: 0
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): lifetime: 86400
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x0200): Will run as [0][0].
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): Kerberos context initialized
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [become_user] (0x0200): Trying to become user [0][0].
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [become_user] (0x0200): Already user [0].
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): Running as [0][0].
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): getting TGT sync
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [INFINERA.COM]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430585: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, aes128-cts, aes256-cts, rc4-hmac
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430660: Sending request (203 bytes) to INFINERA.COM
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430840: Resolving hostname se-dc01.infinera.com
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.431709: Sending initial UDP request to dgram 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432672: Received answer (266 bytes) from dgram 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432741: Response was not from master KDC
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432786: Received error from KDC: -1765328359/Additional pre-authentication required
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432851: Processing preauth types: 16, 15, 19, 2
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432880: Selected etype info: etype aes256-cts, salt "INFINERA.COMhostgentoo-labbb.infinera.com", params ""
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432960: AS key obtained for encrypted timestamp: aes256-cts/645C
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433059: Encrypted timestamp (for 1495435577.276052): plain 301AA011180F32303137303532323036343631375AA1050203043654, encrypted 08B7186DAB549BD6AC8DCC76C9E88A5FB59619A42672B848C1CF6605E2AB5EFB54D0EDD8B8FC3D9BC154519791BD77F8938FBADEB6C9F65C
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433087: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433103: Produced preauth for next request: 2
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433137: Sending request (283 bytes) to INFINERA.COM
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433172: Resolving hostname se-dc01.infinera.com
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433387: Sending initial UDP request to dgram 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434554: Received answer (96 bytes) from dgram 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434603: Response was not from master KDC
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434624: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434636: Request or response is too big for UDP; retrying with TCP
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434647: Sending request (283 bytes) to INFINERA.COM (tcp only)
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434665: Resolving hostname se-dc01.infinera.com
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434807: Initiating TCP connection to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.435110: Sending TCP request to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436061: Received answer (1543 bytes) from stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436086: Terminating TCP connection to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436130: Response was not from master KDC
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436166: Processing preauth types: 19
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436180: Selected etype info: etype aes256-cts, salt "INFINERA.COMhostgentoo-labbb.infinera.com", params ""
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436191: Produced preauth for next request: (empty)
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436204: AS key determined by preauth: aes256-cts/645C
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436268: Decrypted AS reply; session key is: aes256-cts/00F2
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436287: FAST negotiation: unavailable
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb] to [/var/lib/sss/db/ccache_INFINERA.COM]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [prepare_response] (0x0400): Building response for result [0]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [pack_buffer] (0x2000): response size: 60
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [40] msg [FILE:/var/lib/sss/db/ccache_INFINERA.COM]
(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x0400): ldap_child completed successfully
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): krb5_child started.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [unpack_buffer] (0x1000): total buffer size: [154]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1001] old_ccname: [FILE:/tmp/krb5cc_1001] keytab: [/etc/krb5.keytab]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [check_use_fast] (0x0100): Not using FAST.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [switch_creds] (0x0200): Switch user to [1001][100].
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [switch_creds] (0x0200): Switch user to [0][0].
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1001] and is active and TGT is valid.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [become_user] (0x0200): Trying to become user [1001][100].
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x2000): Running as [1001][100].
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_setup] (0x2000): Running as [1001][100].
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_lifetime_options] (0x0100): Renewable lifetime is set to [7d]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_lifetime_options] (0x0100): Lifetime is set to [24h]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_canonicalize_option] (0x0100): Canonicalization is set to [true]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): Will perform ticket renewal
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [renew_tgt_child] (0x1000): Renewing a ticket
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515681: Generated subkey for TGS request: aes256-cts/2D54
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515747: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515862: Encoding request body and padata into FAST request
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515973: Sending request (1901 bytes) to INFINERA.COM
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516194: Resolving hostname se-dc01.infinera.com
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516448: Initiating TCP connection to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516778: Sending TCP request to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517190: Received answer (123 bytes) from stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517203: Terminating TCP connection to stream 10.210.34.21:88
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517247: Response was not from master KDC
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517270: Got cred; -1765328352/Ticket expired
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_send_data] (0x0200): Received error code 1432158229
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [pack_response_packet] (0x2000): response packet size: [4]
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_send_data] (0x4000): Response sent.
(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): krb5_child completed successfully
There were 5 more attempts to renew tickets within a second.
4 of them failed due to expired ticket. And the last one failed
due to offline mode.
Few seconds later (7) user was authenticated in offline mode.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): krb5_child started.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [unpack_buffer] (0x1000): total buffer size: [141]
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1001] old_ccname: [FILE:/tmp/krb5cc_1001] keytab: [/etc/krb5.keytab]
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [check_use_fast] (0x0100): Not using FAST.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [switch_creds] (0x0200): Switch user to [1001][100].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [switch_creds] (0x0200): Switch user to [0][0].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1001] and is active and TGT is valid.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Trying to become user [1001][100].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x2000): Running as [1001][100].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Trying to become user [1001][100].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Already user [1001].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_setup] (0x2000): Running as [1001][100].
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [set_lifetime_options] (0x0100): Renewable lifetime is set to [7d]
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [set_lifetime_options] (0x0100): Lifetime is set to [24h]
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): Will perform offline auth
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_send_data] (0x0200): Received error code 0
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [pack_response_packet] (0x2000): response packet size: [45]
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_send_data] (0x4000): Response sent.
(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): krb5_child completed successfully
LS
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave
Lukas Slebodnik
2017-05-22 20:29:03 UTC
Permalink
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.

Configure ntpd/chrony on client and server is not a rocket science :-)
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.

I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.

With 1.15 you can use sssctl e.g.

sssctl domain-status example.com
Online status: Online

Active servers:
KPASSWD: not connected
KERBEROS: not connected
LDAP: ldap.abc.example.com

Discovered KPASSWD servers:
- kerberos.abc.example.com

Discovered KERBEROS servers:
- kerberos.abc.example.com

Discovered LDAP servers:
- ldap.abc.example.com
- ldap.corp.example.com

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-us
Joakim Tjernlund
2017-05-23 08:11:25 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
I did run sssctl domain-status infinera.com and it came back with:
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status

I then just added 'ifp' to 'services' and restarted sssd and now it works:
sssctl domain-status infinera.com
Online status: Online

Active servers:
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....

Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.

Jocke
Post by Lukas Slebodnik
sssctl domain-status example.com
Online status: Online
KPASSWD: not connected
KERBEROS: not connected
LDAP: ldap.abc.example.com
- kerberos.abc.example.com
- kerberos.abc.example.com
- ldap.abc.example.com
- ldap.corp.example.com
LS
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@li
Lukas Slebodnik
2017-05-23 08:50:51 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
On another machine I added ifp to services and just reloaded the sssd config (signal HUG to sssd) and
The only way how sssd can use new configuration is to RESTART sssd.
sssd does not reload configuration after receiving SIGHUP.

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedorahost
Lukas Slebodnik
2017-05-23 08:46:36 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
ifp service does not have any effect on ticket renewal.

it is just required by sssctl

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-user
Lukas Slebodnik
2017-05-23 09:07:18 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [renew_tgt_child] (0x1000): Renewing a ticket
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.638788: Generated subkey for TGS request: aes256-cts/3F94
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.638841: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.638944: Encoding request body and padata into FAST request
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.639036: Sending request (1901 bytes) to INFINERA.COM
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.639179: Resolving hostname se-dc01.infinera.com
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.639483: Initiating TCP connection to stream 10.210.34.21:88
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.639888: Sending TCP request to stream 10.210.34.21:88
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640356: Received answer (123 bytes) from stream 10.210.34.21:88
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640375: Terminating TCP connection to stream 10.210.34.21:88
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.

We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2

https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64

It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.

Thank you very much for bug report.
And sorry that it took me so long to find a bug.

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an ema
Joakim Tjernlund
2017-05-23 09:19:14 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fe
Lukas Slebodnik
2017-05-23 09:40:26 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.

The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-
Joakim Tjernlund
2017-05-23 13:03:49 UTC
Permalink
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.
The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.
Right, this seems to be the right thing anyhow, mapping these to errors to network IO error
does seem odd.

While I am at it, if you look in the ebuild I sent earlier you will find:
append-libs "-ldl"
This is because sssd underlinks wbclient, without -ldl I get runtime error, cannot find
dlopen" (or similar to that msg)

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedoraho
Jakub Hrozek
2017-05-23 13:31:07 UTC
Permalink
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.
The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.
Right, this seems to be the right thing anyhow, mapping these to errors to network IO error
does seem odd.
So what would you propose the deamon does if libkrb5 tells it that the
server is out of sync?
Post by Joakim Tjernlund
append-libs "-ldl"
This is because sssd underlinks wbclient, without -ldl I get runtime error, cannot find
dlopen" (or similar to that msg)
Jocke
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-user
Joakim Tjernlund
2017-05-23 13:45:14 UTC
Permalink
Post by Jakub Hrozek
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.
The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.
Right, this seems to be the right thing anyhow, mapping these to errors to network IO error
does seem odd.
So what would you propose the deamon does if libkrb5 tells it that the
server is out of sync?
Not sure, possibly the same as now but it should be handled separately so one
can differentiate(don't pretend it is an network error).
Post by Jakub Hrozek
Post by Joakim Tjernlund
append-libs "-ldl"
This is because sssd underlinks wbclient, without -ldl I get runtime error, cannot find
dlopen" (or similar to that msg)
Jocke
_______________________________________________
_______________________________________________
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an em
Joakim Tjernlund
2017-05-23 15:40:49 UTC
Permalink
Post by Joakim Tjernlund
Post by Jakub Hrozek
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.
The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.
Right, this seems to be the right thing anyhow, mapping these to errors to network IO error
does seem odd.
So what would you propose the deamon does if libkrb5 tells it that the
server is out of sync?
Not sure, possibly the same as now but it should be handled separately so one
can differentiate(don't pretend it is an network error).
hmm, what will happen now that I have reverted the above patch w.r.t KRB5KRB_AP_ERR_TKT_EXPIRED ?
Will sssd not let me in at all unless I get a network connection to the AD?

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an
Joakim Tjernlund
2017-05-29 13:45:00 UTC
Permalink
Post by Joakim Tjernlund
Post by Joakim Tjernlund
Post by Jakub Hrozek
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Post by Lukas Slebodnik
Post by Joakim Tjernlund
The time is not synchronised between client and server.
MIT krb5 can handle small offset. But I would highly recommends
to keep time in sync.
There is some time problem on and off but this has never been too much. I don't
think this was the root problem here ?
As I already mention I would highly recommend to keep time in sync.
It will reduce possible errors.
Configure ntpd/chrony on client and server is not a rocket science :-)
Sure, no rocket science but I have little control over the AD servers. :(
Anyhow, I did a "net ads info" and it came back with Server time offset: 0
so I don't think there is a time difference(or very small)?
The clients are already on NTP.
Post by Lukas Slebodnik
Post by Joakim Tjernlund
Renewing of a ticket failed because it is already expired.
Maybe due to time shift between client and server(KDC)
Yes, it is expired to begin with. I got a ticket, then suspended the computer long enough for
the ticket to expire(10 hours here) and then woke up and unlocked the screen.
The problem is that sssd never tries to get a new ticket using my creds I gave when unlocking.
Even if I do several lock/unlocks after the network is restored, sssd will not get me a new ticket.
sssd would get new ticket if it was in online mode.
But it offline mode.
I would highly recommend to keep time in sync with server
and then debug why sssd was in offline mode.
Or why it went to offline mode.
With 1.15 you can use sssctl e.g.
Unable to get online status [3]: Communication error
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services'
option in sssd.conf.
Unable to get online status
sssctl domain-status infinera.com
Online status: Online
AD Global Catalog: not connected
AD Domain Controller: se-dc01.infinera.com
.....
Could the problem I saw be related to not having ifp in services ?
I will check again when the ticket expires again.
Jocke
[SNIP]
Post by Lukas Slebodnik
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: Response was not from master KDC
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: Got cred; -1765328352/Ticket expired
(Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired]
The most confusing for me was a reason why we went offline.
And after checking the source code I found out a reason.
We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error
(ERR_NETWORK_IO) since 1.14.2
https://pagure.io/SSSD/sssd/issue/3174
https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64
It might be a reasonable with first kinit. Because new ticket should be valid.
But we should treat it differently for renewing ticket.
Ahh, nice. I wonder though if there could be a short wait for the network to come on?
Usually the unlock window is presented shortly before network is on so when fast unlock
sssd will be offline and no new ticket which causes some grief for users.
Post by Lukas Slebodnik
Thank you very much for bug report.
And sorry that it took me so long to find a bug.
NP, glad you found something. Please send patch my way, I will test it directly.
ATM I do not have a higher priority tasks. And I am not sure when someone
from developers will have a time to fix it.
The fastest workaround should be to revert the patch
d3348f49260998880bb7cd3b2fb72d562b1b7a64.
Right, this seems to be the right thing anyhow, mapping these to errors to network IO error
does seem odd.
So what would you propose the deamon does if libkrb5 tells it that the
server is out of sync?
Not sure, possibly the same as now but it should be handled separately so one
can differentiate(don't pretend it is an network error).
hmm, what will happen now that I have reverted the above patch w.r.t KRB5KRB_AP_ERR_TKT_EXPIRED ?
Will sssd not let me in at all unless I get a network connection to the AD?
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedorahost
Jakub Hrozek
2017-07-19 14:28:03 UTC
Permalink
Post by Joakim Tjernlund
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.
Jocke
Hi Joakim,
could you please test if this commit:
https://github.com/SSSD/sssd/compare/master...jhrozek:renew-offline
also fixes the problem for you?

Thank you..
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-lea
Joakim Tjernlund
2017-07-19 14:42:54 UTC
Permalink
Post by Jakub Hrozek
Post by Joakim Tjernlund
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.
Jocke
Hi Joakim,
https://github.com/SSSD/sssd/compare/master...jhrozek:renew-offline
also fixes the problem for you?
Thank you..
Sure, what is the clone/branch URL for this? It is not visible on that page.
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedo
Joakim Tjernlund
2017-07-19 15:34:04 UTC
Permalink
Post by Joakim Tjernlund
Post by Jakub Hrozek
Post by Joakim Tjernlund
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.
Jocke
Hi Joakim,
https://github.com/SSSD/sssd/compare/master...jhrozek:renew-offline
also fixes the problem for you?
Thank you..
Sure, what is the clone/branch URL for this? It is not visible on that page.
Found it ...
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedorahosted.o
Joakim Tjernlund
2017-07-20 07:32:24 UTC
Permalink
Post by Joakim Tjernlund
Post by Joakim Tjernlund
Post by Jakub Hrozek
Post by Joakim Tjernlund
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.
Jocke
Hi Joakim,
https://github.com/SSSD/sssd/compare/master...jhrozek:renew-offline
also fixes the problem for you?
Thank you..
Sure, what is the clone/branch URL for this? It is not visible on that page.
Found it ...
Tested over night and login after all night suspend worked, thanks.

Jocke
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@lists.fedorahost
Jakub Hrozek
2017-07-20 08:00:52 UTC
Permalink
Post by Joakim Tjernlund
Post by Joakim Tjernlund
Post by Joakim Tjernlund
Post by Jakub Hrozek
Post by Joakim Tjernlund
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem is no more.
Jocke
Hi Joakim,
https://github.com/SSSD/sssd/compare/master...jhrozek:renew-offline
also fixes the problem for you?
Thank you..
Sure, what is the clone/branch URL for this? It is not visible on that page.
Found it ...
Tested over night and login after all night suspend worked, thanks.
Thank you very much for testing, I submitted the patch as
https://github.com/SSSD/sssd/pull/328

I think we can release 1.15.3 once this PR and
https://github.com/SSSD/sssd/pull/327 are merged..
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@li

Continue reading on narkive:
Loading...