[CentOS] SSSD and usermod

Tue Jan 7 12:57:04 UTC 2014
Mitja Mihelič <mitja.mihelic at arnes.si>

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 at arnes.si>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 at centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

-------------- next part --------------
[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]