Any other idea ? Here is the information I can provide you :

# /etc/nsswitch.conf

passwd:         compat sss ldap
group:          compat sss ldap
shadow:         compat ldap

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

my pam file 

# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_sss.so
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so

/etc/sssd/sssd.conf

[domain/default]
debug_level=0xFFF0
autofs_provider = ldap
ldap_default_bind_dn = uid=myuid,ou=Auth,dc=mydc1,dc=mydc2
ldap_default_authtok_type = password
ldap_default_authtok = mysecret
ldap_schema = rfc2307bis
krb5_realm = #
ldap_search_base = dc=mydc1,dc=mydc2
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://myldap
ldap_id_use_start_tls = True
cache_credentials = True
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_tls_reqcert=demand
[sssd]
services = nss, pam, autofs
config_file_version = 2

domains = default
[pam]

[nss]

[sudo]

[autofs]

[ssh]

[pac]

As said earlier, I tried with those 2 commands to simulate the lost of the ldap 
server :

iptables -A OUTPUT -p tcp --dport 636 -j REJECT
iptables -A OUTPUT -p tcp --dport 636 -j DROP


> On Mar 14, 2016, at 11:39, Cyril Scetbon <[email protected]> wrote:
> 
> Not better with REJECT
> 
> never tried start_tls. We currently use LDAP over/TLS (using pam_ldap) so I'm 
> trying with the same configuration
>> On Mar 14, 2016, at 11:22, Lukas Slebodnik <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> On (14/03/16 10:54), Cyril Scetbon wrote:
>>> The full log can be found at http://pastebin.com/pk5bD2ks 
>>> <http://pastebin.com/pk5bD2ks>
>>> 
>>> We can see that the ldap is marked as offline :
>>> 
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [fo_resolve_service_send] 
>>> (0x0020): No available servers for service 'LDAP' 
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [be_resolve_server_done] 
>>> (0x1000): Server resolution failed: 5 
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [sdap_id_op_connect_done] 
>>> (0x0020): Failed to connect, going offline (5 [Input/output error]) (Mon 
>>> Mar 14 15:40:06 2016) [sssd[be[default]]] [be_mark_offline] (0x2000): Going 
>>> offline! 
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [be_run_offline_cb] 
>>> (0x0080): Going offline. Running callbacks. 
>>> 
>>> Then I see :
>>> 
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [sdap_pam_auth_handler] 
>>> (0x0100): Backend is marked offline, retry later!
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [be_pam_handler_callback] 
>>> (0x0100): Backend returned: (1, 9, <NULL>) [Provider is Offline 
>>> (Authentication service cannot retrieve authentication info)]
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [be_pam_handler_callback] 
>>> (0x0100): Sending result [9][default]
>>> (Mon Mar 14 15:40:06 2016) [sssd[be[default]]] [be_pam_handler_callback] 
>>> (0x0100): Sent result [9][default]
>>> (Mon Mar 14 15:40:09 2016) [sssd[be[default]]] [sbus_dispatch] (0x4000): 
>>> dbus conn: 0x1c719d0
>>> (Mon Mar 14 15:40:09 2016) [sssd[be[default]]] [sbus_dispatch] (0x4000): 
>>> Dispatching.
>>> 
>>> So I was expecting to get an ok from pam, as we use cache_credentials = true
>>> 
>>> As I said, the only thing I did was drop my network paquets sent to port 
>>> 636 to simulate a dead ldap. It takes also ~36 seconds for the connection 
>>> to fail because of it
>> Could you try reject instead of drop?
>> 
>> Is there the same problem with ldap + start_tls?
>> 
>> LS
>> _______________________________________________
>> sssd-users mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.fedorahosted.org/admin/lists/[email protected] 
>> <https://lists.fedorahosted.org/admin/lists/[email protected]>
> _______________________________________________
> sssd-users mailing list
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]

_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]

Reply via email to