Hi Dimitar!
We only want to SSSD with 389DS instead of the local passwd/shadow
files. We do not want to go full IPA for this server.
Setting up SSSD with authconfig automatically set up PAM and
/etc/nsswitch.conf.
SSSD will only be used for these (nsswitch.conf):
passwd: files sss
shadow: files sss
services: files sss
I have also attached our sssd.conf.
Currently getent and id cmdline tools work as expected by getting user
info from SSSD which in turn gets it from 389DS/LDAP. SSH also works.
We are starting to lean toward the possibility, that usermod and its
sibling utils from shadow-utils do not support SSSD as fully as we were
expecting them to.
Is this the case and can any other cmdline user administration tools be
used to lock users?
I know there is the possibility of making our own tools for this, but
still...
Regards, Mitja
--
Mitja Mihelič
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8877, fax: +386 1 479 88 78
On 06. 01. 2014 16:02, Dimitar Georgievski wrote:
Hi MItja,
it looks like you are trying to integrate SSSD with FreeIPA. I think the
following presentation will help you review the SSSD configuration even if
you are trying to use 389DS independently:
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Check the page titled " Example configuration - SSSD with FreeIPA server".
SSSD has to be configured to talk to LDAP server. Check also the settings
in /etc/nsswitch.conf. You might need to modify it to enable SSSD
integration with other services.
This example comes from a host that is using SSSD for SSH authentication
and sudo integration with a FreeIPA server:
passwd: files sss
shadow: files sss
group: files sss
sudoers: files sss
Dimitar
On Fri, Jan 3, 2014 at 10:17 AM, Mitja Mihelič <mitja.mihelic@xxxxxxxx>wrote:
Hi!
How to get usermod working with SSSD/389DS ?
We have SSSD set up on our server and it uses 389DS.
SSSD was enabled with the following command:
authconfig --enablesssd --enablesssdauth --ldapbasedn=dc=example,dc=com
--enableshadow --enablemkhomedir --enablelocauthorize --update
Running for example "usermod -L username" returns:
usermod: user 'username' does not exist in /etc/passwd
Each time usermod is executed there is a query logged in 389DS, so SSSD
does pass the request to 389DS.
Strace (attached) of usermod shows that it gets at least gecos back from
SSSD and that it checked the /var/lib/sss/mc/passwd file which contains:
username
Name Lastname
/home/username
/bin/bash
Soon after that it starts to open /etc/shadow and /etc/passwd.
What are we missing?
Any insight would be appreciated.
Regards, Mitja
--
--
Mitja Mihelič
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8877, fax: +386 1 479 88 78
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
[domain/default]
ldap_tls_reqcert = demand
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = dc=users,dc=company,dc=tld
ldap_group_member = uniquemember
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldap.company.si
ldap_tls_cacertdir = /etc/openldap/cacerts
enumerate = false
min_id = 1
ldap_default_bind_dn = cn=SSSDUSER,ou=system,dc=company,dc=tld
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = PASSWORD_HERE
ldap_disable_paging = true
ldap_enumeration_refresh_timeout = 300
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
memcache_timeout = 1200
enum_cache_timeout = 400
entry_negative_timeout = 5
debug_level = 0x0400
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
debug_level = 0x0400
[sudo]
[autofs]
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
