2:35 p.m.
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
2:55 p.m.
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
4:42 p.m.
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(a)redhat.com>wrote:
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
5:25 p.m.
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
6:14 p.m.
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(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
3:17 a.m.
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(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
8:28 a.m.
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(a)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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://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/
11:40 a.m.
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(a)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(a)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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
2:33 p.m.
-----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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMsk/MACgkQeiVVYja6o6NlBwCfRuoCzMLyHcSj0kUiGmfq8nG7
T3IAnjlNYnV5GP22wBLKjLDw9uidG3e6
=GjkT
-----END PGP SIGNATURE-----
3:57 a.m.
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.
3682
days inactive
3686
days old
sssd-users@lists.fedorahosted.org
9 comments
6 participants
participants (6)
-
Dmitri Pal -
Kevin Sullivan -
Lukas Slebodnik -
Michael Ströder -
Stephen Gallagher -
Sumit Bose