After trying for several days, I want to ask if this is even possible:
I am running CentOS 6.4 and I have sssd-1.9.2-82 installed. I would like to log into my machine by querying an OpenLDAP server running else where. The big difference that I have from the normal sssd setup, is I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
So how do I do this? Should I be able to do all of this through pam? Either way, the issue I am seeing with sssd is the return value of pam when sssd can't connect to my ldap server. It always returns 'user_unknown' instead of 'authinfo_unavail' as I would expect. Am I configuring something incorrectly?
/etc/pam.d/password-auth:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=done new_authtok_reqd=done authinfo_unavail=ignore default=die] pam_sss.so forward_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
/etc/sssd/sssd.conf:
[domain/default] debug_level = 9
ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap access_provider = ldap ldap_access_filter = memberOf=cn=group,ou=Roles,dc=example,dc=com ldap_group_member = memberUid ldap_group_search_base = ou=Roles,dc=example,dc=com chpass_provider = ldap ldap_uri = ldap://test-server/
[sssd] debug_level = 9 services = pam config_file_version = 2
domains = default
[nss] debug_level = 9
[pam] debug_level = 9
[sudo] debug_level = 9
[autofs] debug_level = 9
[ssh] debug_level = 9
[pac] debug_level = 9
/var/log/sssd/sssd_default.log:
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [3][1][name=user] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x196b8f0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x196c2b0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Destroying timer event 0x196c2b0 "ltdb_timeout"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Ending timer event 0x196b8f0 "ltdb_callback"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [sbus_dispatch] (0x4000): dbus conn: 1964B00 (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [sbus_dispatch] (0x4000): Dispatching.
/var/log/sssd/sssd_pam.log:
(Tue Mar 18 19:09:52 2014) [sssd[pam]] [accept_fd_handler] (0x0400): Client connected to privileged pipe! (Tue Mar 18 19:09:52 2014) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x6cc030][19] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Tue Mar 18 19:09:52 2014) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x6cc030][19] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x6cc030][19] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'user' matched without domain, user is user (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): user: user (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): rhost: test-server (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): authtok size: 8 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): newauthtok size: 0 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 10665 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/default/user] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41b300:3:user@default] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [default][3][1][name=user] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x6cdf20 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x41b300:3:user@default] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x6cdf20 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 6C8DE0 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Offline (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_check_user_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Offline (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [user@default] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x6d7360
(Tue Mar 18 19:09:52 2014) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x6d7480
(Tue Mar 18 19:09:52 2014) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x6d7480 "ltdb_timeout"
(Tue Mar 18 19:09:52 2014) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x6d7360 "ltdb_callback"
(Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_check_user_search] (0x0080): No matching domain found for [user], fail! (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [10]. (Tue Mar 18 19:09:52 2014) [sssd[pam]] [pam_reply] (0x0100): blen: 8 (Tue Mar 18 19:09:52 2014) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x41b300:3:user@default] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x6cc030][19] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x6cc030][19] (Tue Mar 18 19:09:52 2014) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Tue Mar 18 19:09:52 2014) [sssd[pam]] [client_destructor] (0x2000): Terminated client [0x6cc030][19]
I tried to provide only the portions of files that I found relevant. I can provide more upon request.
Thanks,
Kevin
On (18/03/14 15:35), kevin sullivan wrote:
After trying for several days, I want to ask if this is even possible:
I am running CentOS 6.4 and I have sssd-1.9.2-82 installed. I would like to
I would recommend to update to CentOS 6.5 (lot of crashes and bugs were fixed in 6.5)
log into my machine by querying an OpenLDAP server running else where. The big difference that I have from the normal sssd setup, is I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
So how do I do this? Should I be able to do all of this through pam? Either way, the issue I am seeing with sssd is the return value of pam when sssd can't connect to my ldap server. It always returns 'user_unknown' instead of 'authinfo_unavail' as I would expect. Am I configuring something incorrectly?
/etc/pam.d/password-auth:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=done new_authtok_reqd=done authinfo_unavail=ignore default=die] pam_sss.so forward_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
You can use authconfig to configure pam-stack and nsswitch on CentOS/Fedora
This is part of my /etc/pam.d/password-auth ---------------------------------------------------------------------- auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so ----------------------------------------------------------------------
/etc/sssd/sssd.conf:
[domain/default] debug_level = 9
ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap access_provider = ldap ldap_access_filter = memberOf=cn=group,ou=Roles,dc=example,dc=com ldap_group_member = memberUid ldap_group_search_base = ou=Roles,dc=example,dc=com chpass_provider = ldap ldap_uri = ldap://test-server/
[sssd] debug_level = 9 services = pam config_file_version = 2
domains = default
[nss] debug_level = 9
[pam] debug_level = 9
[sudo] debug_level = 9
[autofs] debug_level = 9
[ssh] debug_level = 9
[pac] debug_level = 9
/var/log/sssd/sssd_default.log:
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [3][1][name=user] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x196b8f0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x196c2b0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Destroying timer event 0x196c2b0 "ltdb_timeout"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Ending timer event 0x196b8f0 "ltdb_callback"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline
SSSD could not connect to the LDAP server. We will need whole log file sssd_default.log.
LS
Lukas,
Thank you for your quick response.
You can use authconfig to configure pam-stack and nsswitch on CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
Won't this allow local accounts before network accounts? I only want to revert to local accounts if my ldap server is down.
SSSD could not connect to the LDAP server. We will need whole log file sssd_default.log.
I am working on getting you that log file. I am running into some more issues, so I will get it to you as soon as I can.
Thanks again!
Kevin
On Tue, Mar 18, 2014 at 3:55 PM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (18/03/14 15:35), kevin sullivan wrote:
After trying for several days, I want to ask if this is even possible:
I am running CentOS 6.4 and I have sssd-1.9.2-82 installed. I would like
to I would recommend to update to CentOS 6.5 (lot of crashes and bugs were fixed in 6.5)
log into my machine by querying an OpenLDAP server running else where. The big difference that I have from the normal sssd setup, is I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP
server
is offline.
So how do I do this? Should I be able to do all of this through pam?
Either
way, the issue I am seeing with sssd is the return value of pam when sssd can't connect to my ldap server. It always returns 'user_unknown' instead of 'authinfo_unavail' as I would expect. Am I configuring something incorrectly?
/etc/pam.d/password-auth:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=done new_authtok_reqd=done authinfo_unavail=ignore default=die] pam_sss.so forward_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
You can use authconfig to configure pam-stack and nsswitch on CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
/etc/sssd/sssd.conf:
[domain/default] debug_level = 9
ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap access_provider = ldap ldap_access_filter = memberOf=cn=group,ou=Roles,dc=example,dc=com ldap_group_member = memberUid ldap_group_search_base = ou=Roles,dc=example,dc=com chpass_provider = ldap ldap_uri = ldap://test-server/
[sssd] debug_level = 9 services = pam config_file_version = 2
domains = default
[nss] debug_level = 9
[pam] debug_level = 9
[sudo] debug_level = 9
[autofs] debug_level = 9
[ssh] debug_level = 9
[pac] debug_level = 9
/var/log/sssd/sssd_default.log:
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [3][1][name=user] (Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x196b8f0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x196c2b0
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Destroying timer event 0x196c2b0 "ltdb_timeout"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [ldb] (0x4000): Ending
timer
event 0x196b8f0 "ltdb_callback"
(Tue Mar 18 19:09:52 2014) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline
SSSD could not connect to the LDAP server. We will need whole log file sssd_default.log.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (18/03/14 17:42), kevin sullivan wrote:
Lukas,
Thank you for your quick response.
You can use authconfig to configure pam-stack and nsswitch on CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
You wrote in the 1st mail:
I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Won't this allow local accounts before network accounts? I only want to revert to local accounts if my ldap server is down.
Yes, local accounts have higher priority with this pam configuration.
I do not really understand what do you mean by "revert to local accounts if my ldap server is down."
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
LS
Lukas,
Thanks for your input. I can't reproduce what I was seeing right now, so I can't send you my log files because I deleted them earlier to make issues easier to find (which in retrospect was dumb). But just to explain what I was talking about earlier, below are some more explanations.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Yes they can.
I do not really understand what do you mean by "revert to local accounts
if my
ldap server is down."
What I mean is that I only want accounts from the LDAP server to be used when LDAP is up. So I would store root and all other system users in LDAP. If my LDAP server is online, I only want users to authenticate through LDAP, no local logins. The only time I want local accounts is if the LDAP server is no longer responsive.
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
I don't know if I want to rely on caching as it depends on actually having to login as that user in the first place. This leads to inconsistency and hard to reproduce issues.
Thanks again for your help.
Kevin
On Tue, Mar 18, 2014 at 6:25 PM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (18/03/14 17:42), kevin sullivan wrote:
Lukas,
Thank you for your quick response.
You can use authconfig to configure pam-stack and nsswitch on
CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
You wrote in the 1st mail:
I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Won't this allow local accounts before network accounts? I only want to revert to local accounts if my ldap server is down.
Yes, local accounts have higher priority with this pam configuration.
I do not really understand what do you mean by "revert to local accounts if my ldap server is down."
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Mar 20, 2014 at 07:14:36PM -0400, kevin sullivan wrote:
Lukas,
Thanks for your input. I can't reproduce what I was seeing right now, so I can't send you my log files because I deleted them earlier to make issues easier to find (which in retrospect was dumb). But just to explain what I
Instead of deleting the log files you can use logrotate on systems where is is available. E.g. on Fedora you can call
logrotate -f /etc/logrotate.d/sssd
to save to old logs and start with fresh and empty log files.
bye, Sumit
was talking about earlier, below are some more explanations.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Yes they can.
I do not really understand what do you mean by "revert to local accounts
if my
ldap server is down."
What I mean is that I only want accounts from the LDAP server to be used when LDAP is up. So I would store root and all other system users in LDAP. If my LDAP server is online, I only want users to authenticate through LDAP, no local logins. The only time I want local accounts is if the LDAP server is no longer responsive.
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
I don't know if I want to rely on caching as it depends on actually having to login as that user in the first place. This leads to inconsistency and hard to reproduce issues.
Thanks again for your help.
Kevin
On Tue, Mar 18, 2014 at 6:25 PM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (18/03/14 17:42), kevin sullivan wrote:
Lukas,
Thank you for your quick response.
You can use authconfig to configure pam-stack and nsswitch on
CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
You wrote in the 1st mail:
I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Won't this allow local accounts before network accounts? I only want to revert to local accounts if my ldap server is down.
Yes, local accounts have higher priority with this pam configuration.
I do not really understand what do you mean by "revert to local accounts if my ldap server is down."
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 03/20/2014 07:14 PM, kevin sullivan wrote:
Lukas,
Thanks for your input. I can't reproduce what I was seeing right now, so I can't send you my log files because I deleted them earlier to make issues easier to find (which in retrospect was dumb). But just to explain what I was talking about earlier, below are some more explanations.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Yes they can.
I do not really understand what do you mean by "revert to local
accounts if my
ldap server is down."
What I mean is that I only want accounts from the LDAP server to be used when LDAP is up. So I would store root and all other system users in LDAP. If my LDAP server is online, I only want users to authenticate through LDAP, no local logins. The only time I want local accounts is if the LDAP server is no longer responsive.
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
I don't know if I want to rely on caching as it depends on actually having to login as that user in the first place. This leads to inconsistency and hard to reproduce issues.
So you put all users and even root into the central server? This is usually not the best idea. You still need to have some system accounts that are local. The recommendation is to have system accounts that are related to the installed software and root in /etc/passwd and then the rest in the LDAP. You authenticate with locally with local accounts and central accounts can be cached by SSSD. It is up to you where you draw the line between local accounts and central accounts but moving everything including root seems to me to be too much.
Thanks again for your help.
Kevin
On Tue, Mar 18, 2014 at 6:25 PM, Lukas Slebodnik <lslebodn@redhat.com mailto:lslebodn@redhat.com> wrote:
On (18/03/14 17:42), kevin sullivan wrote: >Lukas, > >Thank you for your quick response. > >>You can use authconfig to configure pam-stack and nsswitch on CentOS/Fedora >> >>This is part of my /etc/pam.d/password-auth >>---------------------------------------------------------------------- >>auth required pam_env.so >>auth sufficient pam_unix.so try_first_pass nullok >>auth requisite pam_succeed_if.so uid >= 1000 quiet_success >>auth sufficient pam_sss.so use_first_pass >>auth required pam_deny.so You wrote in the 1st mail: >I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) >if my LDAP server is offline. Do users from /etc/passwd have the same uid/name as user from LDAP? >Won't this allow local accounts before network accounts? I only want to >revert to local accounts if my ldap server is down. > Yes, local accounts have higher priority with this pam configuration. I do not really understand what do you mean by "revert to local accounts if my ldap server is down." SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down. LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thanks for the input Dmitri!
It is up to you where you draw the line between local accounts and central
accounts but moving everything including root seems to me to be too much. I agree that it might be too much, however, it is something that I felt needed investigation.
Thanks again,
Kevin
On Fri, Mar 21, 2014 at 9:28 AM, Dmitri Pal dpal@redhat.com wrote:
On 03/20/2014 07:14 PM, kevin sullivan wrote:
Lukas,
Thanks for your input. I can't reproduce what I was seeing right now, so I can't send you my log files because I deleted them earlier to make issues easier to find (which in retrospect was dumb). But just to explain what I was talking about earlier, below are some more explanations.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Yes they can.
I do not really understand what do you mean by "revert to local
accounts if my
ldap server is down."
What I mean is that I only want accounts from the LDAP server to be used when LDAP is up. So I would store root and all other system users in LDAP. If my LDAP server is online, I only want users to authenticate through LDAP, no local logins. The only time I want local accounts is if the LDAP server is no longer responsive.
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
I don't know if I want to rely on caching as it depends on actually having to login as that user in the first place. This leads to inconsistency and hard to reproduce issues.
So you put all users and even root into the central server? This is usually not the best idea. You still need to have some system accounts that are local. The recommendation is to have system accounts that are related to the installed software and root in /etc/passwd and then the rest in the LDAP. You authenticate with locally with local accounts and central accounts can be cached by SSSD. It is up to you where you draw the line between local accounts and central accounts but moving everything including root seems to me to be too much.
Thanks again for your help.
Kevin
On Tue, Mar 18, 2014 at 6:25 PM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (18/03/14 17:42), kevin sullivan wrote:
Lukas,
Thank you for your quick response.
You can use authconfig to configure pam-stack and nsswitch on
CentOS/Fedora
This is part of my /etc/pam.d/password-auth
auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
You wrote in the 1st mail:
I only want to use the local Unix accounts (/etc/passwd and /etc/shadow) if my LDAP server is offline.
Do users from /etc/passwd have the same uid/name as user from LDAP?
Won't this allow local accounts before network accounts? I only want to revert to local accounts if my ldap server is down.
Yes, local accounts have higher priority with this pam configuration.
I do not really understand what do you mean by "revert to local accounts if my ldap server is down."
SSSD caches all information about authenticated users. It will be possible to authenticate even if LDAP server is down.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing listsssd-users@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/21/2014 12:40 PM, kevin sullivan wrote:
Thanks for the input Dmitri!
It is up to you where you draw the line between local accounts and central accounts but moving everything including root seems to me to be too much.
I agree that it might be too much, however, it is something that I felt needed investigation.
For the record, root (and UID/GID zero) is special-cased in SSSD. You *cannot* log in as root through SSSD. (The reasoning is that if SSSD was broken, you wouldn't be able to get into the system at all to fix it).
Stephen Gallagher wrote:
For the record, root (and UID/GID zero) is special-cased in SSSD. You *cannot* log in as root through SSSD. (The reasoning is that if SSSD was broken, you wouldn't be able to get into the system at all to fix it).
And there are myriads of security issues with putting root in a central user DB.
Ciao, Michael.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Kevin Sullivan -
Lukas Slebodnik -
Michael Ströder -
Stephen Gallagher -
Sumit Bose