Hi Guys,
I've made some tests and I have a few questions regarding sssd.
We were using pam_ldap and at first I thought that sssd could work with pam_ldap but I didn't find a way to make it work. If I enable the debug mode in the pam section, I don't see anything. As sssd can query for the ldap password + do the caching, it may be the reason why they can't work together.
I've been able to make it work by putting my ldap configuration in the domain section and I've verified that if the ldap server becomes unavailable then sssd uses the password version it has cached
[sssd[be[default]]] [sdap_pam_auth_done] (0x0100): Password successfully cached for mouser
However, when the ldap server is available, I see that every time I try to log in, it does a ldap request instead of reusing the value it has cached :
[sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=myuser)(objectclass=posixAccount))][dc=fti,dc=net]
As entry_cache_timeout is set to 600 per default, I would expect sssd to only query the ldap every 600 seconds and use the cached value otherwise. What am I missing ? I see sssd tries to access many attributes for my user and that some of them are missing. Can it be the reason it doesn't reuse the cache except if the ldap is offline ?
Thank you
One last information, we already use pam-ldap for other system users, so if there is a way to not duplicate the ldap configuration in sssd.conf or to not totally replace the current pam-ldap by sssd (which could make sense though), it would be great
Thanks
On Sat, Mar 12, 2016 at 10:27:20PM -0500, Cyril Scetbon wrote:
Hi Guys,
I've made some tests and I have a few questions regarding sssd.
We were using pam_ldap and at first I thought that sssd could work with pam_ldap but I didn't find a way to make it work.
I wonder why do you think mixing pam_ldap with sssd would be better than using sssd for everything? Normally I would prefer to use sssd for both identity and authentication..
If I enable the debug mode in the pam section, I don't see anything. As sssd can query for the ldap password + do the caching, it may be the reason why they can't work together.
If pam_sss is present in the PAM config, is there any message from pam_sss in either /var/log/secure or the journal, depending on the distribution?
I've been able to make it work by putting my ldap configuration in the domain section and I've verified that if the ldap server becomes unavailable then sssd uses the password version it has cached
[sssd[be[default]]] [sdap_pam_auth_done] (0x0100): Password successfully cached for mouser
However, when the ldap server is available, I see that every time I try to log in, it does a ldap request instead of reusing the value it has cached :
[sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=myuser)(objectclass=posixAccount))][dc=fti,dc=net]
As entry_cache_timeout is set to 600 per default, I would expect sssd to only query the ldap every 600 seconds and use the cached value otherwise. What am I missing ?
The cache is mostly used for authentication. Becaues the group membership on Linux can only be set during login, we always contact the server by default (there is an option to use the cache even for login in the latest versions, but it's still disabled by default..)
I see sssd tries to access many attributes for my user and that some of them are missing. Can it be the reason it doesn't reuse the cache except if the ldap is offline ?
Thank you
Cyril _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
I've never said that mixing both was the best option. It's just easier for me cause pam_ldap is already used and if I can avoid to change the current configuration I'll be glad.
I don't see any message in the log.
In my case, I don't need to access other information but the login (uses by a database that can use pam for authentication and all permissions are set at the database level). What is the option to not contact the server even for the group information if there is one ?
On Mar 13, 2016, at 12:37, Jakub Hrozek jhrozek@redhat.com wrote:
On Sat, Mar 12, 2016 at 10:27:20PM -0500, Cyril Scetbon wrote:
Hi Guys,
I've made some tests and I have a few questions regarding sssd.
We were using pam_ldap and at first I thought that sssd could work with pam_ldap but I didn't find a way to make it work.
I wonder why do you think mixing pam_ldap with sssd would be better than using sssd for everything? Normally I would prefer to use sssd for both identity and authentication..
If I enable the debug mode in the pam section, I don't see anything. As sssd can query for the ldap password + do the caching, it may be the reason why they can't work together.
If pam_sss is present in the PAM config, is there any message from pam_sss in either /var/log/secure or the journal, depending on the distribution?
I've been able to make it work by putting my ldap configuration in the domain section and I've verified that if the ldap server becomes unavailable then sssd uses the password version it has cached
[sssd[be[default]]] [sdap_pam_auth_done] (0x0100): Password successfully cached for mouser
However, when the ldap server is available, I see that every time I try to log in, it does a ldap request instead of reusing the value it has cached :
[sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=myuser)(objectclass=posixAccount))][dc=fti,dc=net]
As entry_cache_timeout is set to 600 per default, I would expect sssd to only query the ldap every 600 seconds and use the cached value otherwise. What am I missing ?
The cache is mostly used for authentication. Becaues the group membership on Linux can only be set during login, we always contact the server by default (there is an option to use the cache even for login in the latest versions, but it's still disabled by default..)
I see sssd tries to access many attributes for my user and that some of them are missing. Can it be the reason it doesn't reuse the cache except if the ldap is offline ?
Thank you
Cyril _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Sun, Mar 13, 2016 at 04:03:50PM -0400, Cyril Scetbon wrote:
I've never said that mixing both was the best option. It's just easier for me cause pam_ldap is already used and if I can avoid to change the current configuration I'll be glad.
If you're already running SSSD in your environment, then I don't see a reason to not go all in..I mean, the deamon would already be up and you'd actually centralize the configuration in one config file (sssd.conf) instead of a combination of sssd.conf + pam_ldap.conf.
I don't see any message in the log.
Not even in the secure log? If that's the case then pam_sss is not being contacted at all (if pam_sss is set up and not pam_ldap).
If you configured pam_sss in the pam stack but you're not seeing any messages by pam_sss in the secure log or journal then chances are then the pam_sss module is not being contacted at all (and another module might abort the PAM conversation sooner..)
In my case, I don't need to access other information but the login (uses by a database that can use pam for authentication and all permissions are set at the database level). What is the option to not contact the server even for the group information if there is one ?
I'm sorry, but I don't understand what do you mean by "even for the group
Jakub I'm not trying to know if I should or not use only sssd. I'd like to know if I can have both working together.
You said sssd contact the ldap even if the password is cached for the group information, right ? If yes, is there a way to ask it to not contact the ldap if it has the password and it has not expired yet (in the cache). I'd like to avoid as much as possible to contact the LDAP as I only need passwords and even if they change my application can wait for a day
In my case, I don't need to access other information but the login (uses by a database that can use pam for authentication and all permissions are set at the database level). What is the option to not contact the server even for the group information if there is one ?
I'm sorry, but I don't understand what do you mean by "even for the group _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Sun, Mar 13, 2016 at 04:57:37PM -0400, Cyril Scetbon wrote:
Jakub I'm not trying to know if I should or not use only sssd. I'd like to know if I can have both working together.
Yes, you can, both modules provide the interface that PAM calls to.
You said sssd contact the ldap even if the password is cached for the group information, right ? If yes, is there a way to ask it to not contact the ldap if it has the password and it has not expired yet (in the cache).
Yes, see: https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/
I'd like to avoid as much as possible to contact the LDAP as I only need passwords and even if they change my application can wait for a day
Understood; you might also want to check the pam_id_timeout option and the upstream ticket https://fedorahosted.org/sssd/ticket/2795
In my case, I don't need to access other information but the login (uses by a database that can use pam for authentication and all permissions are set at the database level). What is the option to not contact the server even for the group information if there is one ?
I'm sorry, but I don't understand what do you mean by "even for the group _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Cool exactly what I've been looking for.
Thank you.
Another question relates to offline caching. I've testing it and it has been working well. However I've seen a situation where credentials are not used in offline mode. I've used iptables to simulate an unreachable ldap server by blocking port 636. Here is what I see in such a situation http://pastebin.com/q1CNzPNL It seems to retry a few time to access the ldap server and to fail without trying to use cached passwords
On Mar 13, 2016, at 17:09, Jakub Hrozek jhrozek@redhat.com wrote:
Yes, see: https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/ https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/
On Sun, Mar 13, 2016 at 11:30:36PM -0400, Cyril Scetbon wrote:
Cool exactly what I've been looking for.
Thank you.
Another question relates to offline caching. I've testing it and it has been working well. However I've seen a situation where credentials are not used in offline mode. I've used iptables to simulate an unreachable ldap server by blocking port 636. Here is what I see in such a situation http://pastebin.com/q1CNzPNL It seems to retry a few time to access the ldap server and to fail without trying to use cached passwords
I don't see authentication in the logs, was this test done with pam_ldap (Please note that the cached authentication happends in the PAM responder which is only contacted with pam_sss)
On Mar 13, 2016, at 17:09, Jakub Hrozek jhrozek@redhat.com wrote:
Yes, see: https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/ https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
No pam_ldap was disabled
Cyril Scetbon
On Mar 14, 2016, at 4:18 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Sun, Mar 13, 2016 at 11:30:36PM -0400, Cyril Scetbon wrote: Cool exactly what I've been looking for.
Thank you.
Another question relates to offline caching. I've testing it and it has been working well. However I've seen a situation where credentials are not used in offline mode. I've used iptables to simulate an unreachable ldap server by blocking port 636. Here is what I see in such a situation http://pastebin.com/q1CNzPNL It seems to retry a few time to access the ldap server and to fail without trying to use cached passwords
I don't see authentication in the logs, was this test done with pam_ldap (Please note that the cached authentication happends in the PAM responder which is only contacted with pam_sss)
On Mar 13, 2016, at 17:09, Jakub Hrozek jhrozek@redhat.com wrote:
Yes, see: https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/ https://preichl.wordpress.com/2015/07/19/authenticate-against-cache-in-sssd/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The full log can be found at 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
On Mar 14, 2016, at 08:59, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Mar 14, 2016 at 08:43:05AM -0400, Cyril Scetbon wrote:
No pam_ldap was disabled
Then the logs either don't capture the auth at all (and maybe the complete logs would help) or you logged in with something like an ssh pubkey, not password? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (14/03/16 10:54), Cyril Scetbon wrote:
The full log can be found at 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
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 lslebodn@redhat.com wrote:
On (14/03/16 10:54), Cyril Scetbon wrote:
The full log can be found at 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 sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
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 cyril.scetbon@free.fr 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 <lslebodn@redhat.com mailto:lslebodn@redhat.com> 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 sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Wed, Mar 16, 2016 at 10:52:22PM -0400, Cyril Scetbon wrote:
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
Is it possible to see full logs from all responders?
By the way I suspect the reason Lukas asked about TLS vs LDAPs is https://fedorahosted.org/sssd/ticket/2878
(I know this doesn't help your problem, but I use cached credentials on my laptop as the only authentication source, so I know they work OK..)
Hey Jakub,
So I think I've provided you all the log files I could. The last version (first a connection with the reachable ldap, and then without) can be found at : http://pastebin.com/B3JnMr65
The other logs are empty :
# ls -lrt /var/log/sssd/ total 304 -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log -rw------- 1 root root 0 Mar 17 19:16 sssd.log -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log
However I found other logs :
Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user=myuser <==== ldap accessible
Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user= myuser <== no ldap Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP server ldaps://ldap.multis/: Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info (myuser) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session opened for user root by (uid=0) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session closed for user root
I'm wondering if another pam file is not included even if I thought it's not because of this unix_chkpwd issue
On Mar 17, 2016, at 13:13, Jakub Hrozek jhrozek@redhat.com wrote:
On Wed, Mar 16, 2016 at 10:52:22PM -0400, Cyril Scetbon wrote:
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
Is it possible to see full logs from all responders?
By the way I suspect the reason Lukas asked about TLS vs LDAPs is https://fedorahosted.org/sssd/ticket/2878 https://fedorahosted.org/sssd/ticket/2878
(I know this doesn't help your problem, but I use cached credentials on my laptop as the only authentication source, so I know they work OK..) _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Thu, Mar 17, 2016 at 02:29:33PM -0400, Cyril Scetbon wrote:
Hey Jakub,
So I think I've provided you all the log files I could. The last version (first a connection with the reachable ldap, and then without) can be found at : http://pastebin.com/B3JnMr65
The other logs are empty :
Because you didn't enable debugging in those respective sections, only in [domain]. We don't log anything except fatal failures by default..
# ls -lrt /var/log/sssd/ total 304 -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log -rw------- 1 root root 0 Mar 17 19:16 sssd.log -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log
However I found other logs :
Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user=myuser <==== ldap accessible
Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user= myuser <== no ldap Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP server ldaps://ldap.multis/: Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info (myuser) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session opened for user root by (uid=0) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session closed for user root
I'm wondering if another pam file is not included even if I thought it's not because of this unix_chkpwd issue
Yes, I would have also expected pam_sss to show up here because the domain log files you showed earlier included a PAM_* action, which must have been triggered by something..
Hi Jakub,
Here are the pam logs : - when the authentication is working http://pastebin.com/aDw3tfnL - when it's not http://pastebin.com/B7azEfn9
I'm trying to test it on another machine where pam_ldap is not used. Cause it could come from the fact that both are used and that the user I test exists on the system too (it is used by pam_ldap + pam_sssd).
On Mar 17, 2016, at 17:35, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 17, 2016 at 02:29:33PM -0400, Cyril Scetbon wrote:
Hey Jakub,
So I think I've provided you all the log files I could. The last version (first a connection with the reachable ldap, and then without) can be found at : http://pastebin.com/B3JnMr65 http://pastebin.com/B3JnMr65
The other logs are empty :
Because you didn't enable debugging in those respective sections, only in [domain]. We don't log anything except fatal failures by default..
# ls -lrt /var/log/sssd/ total 304 -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log -rw------- 1 root root 0 Mar 17 19:16 sssd.log -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log
However I found other logs :
Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user=myuser <==== ldap accessible
Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user= myuser <== no ldap Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP server ldaps://ldap.multis/: Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info (myuser) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session opened for user root by (uid=0) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session closed for user root
I'm wondering if another pam file is not included even if I thought it's not because of this unix_chkpwd issue
Yes, I would have also expected pam_sss to show up here because the domain log files you showed earlier included a PAM_* action, which must have been triggered by something.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Fri, Mar 18, 2016 at 11:06:53AM -0400, Cyril Scetbon wrote:
Hi Jakub,
Here are the pam logs :
- when the authentication is working http://pastebin.com/aDw3tfnL
- when it's not http://pastebin.com/B7azEfn9
(I'm stepping in here for Jakub because he might no be available during the next days).
The SSSD logs are looking good. The first show a successful online-authentication while the second shows a successful offline-authentication against cached credentials.
I'm trying to test it on another machine where pam_ldap is not used. Cause it could come from the fact that both are used and that the user I test exists on the system too (it is used by pam_ldap + pam_sssd).
On Mar 17, 2016, at 17:35, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 17, 2016 at 02:29:33PM -0400, Cyril Scetbon wrote:
Hey Jakub,
So I think I've provided you all the log files I could. The last version (first a connection with the reachable ldap, and then without) can be found at : http://pastebin.com/B3JnMr65 http://pastebin.com/B3JnMr65
The other logs are empty :
Because you didn't enable debugging in those respective sections, only in [domain]. We don't log anything except fatal failures by default..
# ls -lrt /var/log/sssd/ total 304 -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log -rw------- 1 root root 0 Mar 17 19:16 sssd.log -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log
However I found other logs :
Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user=myuser <==== ldap accessible
Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user= myuser <== no ldap
This is in agreement to the logs from above, both authentications are successful.
Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP server ldaps://ldap.multis/: Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info (myuser)
It looks like mysqld tries to lookup the user with all available NSS modules. Maybe it would help if you remove the 'ldap' entry in /etc/nsswitch.conf from passwd and group lines?
bye, Sumit
Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session opened for user root by (uid=0) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session closed for user root
I'm wondering if another pam file is not included even if I thought it's not because of this unix_chkpwd issue
Yes, I would have also expected pam_sss to show up here because the domain log files you showed earlier included a PAM_* action, which must have been triggered by something.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Hey
just a heads up. I've been able to make it work by removing the pam_ldap configuration as you proposed.
Thank you
On Mar 18, 2016, at 11:43, Sumit Bose sbose@redhat.com wrote:
On Fri, Mar 18, 2016 at 11:06:53AM -0400, Cyril Scetbon wrote:
Hi Jakub,
Here are the pam logs :
- when the authentication is working http://pastebin.com/aDw3tfnL http://pastebin.com/aDw3tfnL
- when it's not http://pastebin.com/B7azEfn9 http://pastebin.com/B7azEfn9
(I'm stepping in here for Jakub because he might no be available during the next days).
The SSSD logs are looking good. The first show a successful online-authentication while the second shows a successful offline-authentication against cached credentials.
I'm trying to test it on another machine where pam_ldap is not used. Cause it could come from the fact that both are used and that the user I test exists on the system too (it is used by pam_ldap + pam_sssd).
On Mar 17, 2016, at 17:35, Jakub Hrozek <jhrozek@redhat.com mailto:jhrozek@redhat.com> wrote:
On Thu, Mar 17, 2016 at 02:29:33PM -0400, Cyril Scetbon wrote:
Hey Jakub,
So I think I've provided you all the log files I could. The last version (first a connection with the reachable ldap, and then without) can be found at : http://pastebin.com/B3JnMr65 http://pastebin.com/B3JnMr65 <http://pastebin.com/B3JnMr65 http://pastebin.com/B3JnMr65>
The other logs are empty :
Because you didn't enable debugging in those respective sections, only in [domain]. We don't log anything except fatal failures by default..
# ls -lrt /var/log/sssd/ total 304 -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log -rw------- 1 root root 0 Mar 17 19:16 sssd.log -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log
However I found other logs :
Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user=myuser <==== ldap accessible
Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= user= myuser <== no ldap
This is in agreement to the logs from above, both authentications are successful.
Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP server ldaps://ldap.multis/: ldaps://ldap.multis/: Can't contact LDAP server Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info (myuser)
It looks like mysqld tries to lookup the user with all available NSS modules. Maybe it would help if you remove the 'ldap' entry in /etc/nsswitch.conf from passwd and group lines?
bye, Sumit
Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session opened for user root by (uid=0) Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session closed for user root
I'm wondering if another pam file is not included even if I thought it's not because of this unix_chkpwd issue
Yes, I would have also expected pam_sss to show up here because the domain log files you showed earlier included a PAM_* action, which must have been triggered by something.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org <https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org>
sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Do you mean that if I use both of them I can't use only one ldap configuration (the one used by pam_ldap) ? Today it's exactly what I have, twice the ldap configuration I thought it would be feasible to use pam_ldap for the ldap access and sssd only to cache the password.
On Mar 13, 2016, at 16:16, Jakub Hrozek jhrozek@redhat.com wrote:
you'd actually centralize the configuration in one config file (sssd.conf) instead of a combination of sssd.conf + pam_ldap.conf.
On Sun, Mar 13, 2016 at 05:00:45PM -0400, Cyril Scetbon wrote:
Do you mean that if I use both of them I can't use only one ldap configuration (the one used by pam_ldap) ? Today it's exactly what I have, twice the ldap configuration I thought it would be feasible to use pam_ldap for the ldap access and sssd only to cache the password.
Even though sssd reads ldap.conf for quite a few LDAP provider defaults, you might need to provide at least the DNS discovery domain and the id_provider type. The servers and the base DNs should be discovered automatically.
What about tls settings ? Does it pick them up from ldap.conf or do I have to copy them too
Cyril Scetbon
On Mar 13, 2016, at 5:11 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Sun, Mar 13, 2016 at 05:00:45PM -0400, Cyril Scetbon wrote: Do you mean that if I use both of them I can't use only one ldap configuration (the one used by pam_ldap) ? Today it's exactly what I have, twice the ldap configuration I thought it would be feasible to use pam_ldap for the ldap access and sssd only to cache the password.
Even though sssd reads ldap.conf for quite a few LDAP provider defaults, you might need to provide at least the DNS discovery domain and the id_provider type. The servers and the base DNs should be discovered automatically. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Cyril Scetbon wrote:
What about tls settings ? Does it pick them up from ldap.conf or do I have to copy them too
My recommendation: Don't muck around with your old ldap.conf. Read the fine sssd-ldap(5) man page and set everything in sssd.conf to get rid of strange dependencies/residues.
You will be more happy later. I promise.
Ciao, Michael.
That's what I did in the previous test ...
On Mar 14, 2016, at 11:57, Michael Ströder michael@stroeder.com wrote:
Cyril Scetbon wrote:
What about tls settings ? Does it pick them up from ldap.conf or do I have to copy them too
My recommendation: Don't muck around with your old ldap.conf. Read the fine sssd-ldap(5) man page and set everything in sssd.conf to get rid of strange dependencies/residues.
You will be more happy later. I promise.
Ciao, Michael.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Cyril Scetbon -
Jakub Hrozek -
Lukas Slebodnik -
Michael Ströder -
Sumit Bose