Hi Mitja,
From the description of the problem it seems that the usermod - SSSD
integration is not working. 389DS just stores the user information but SSSD is not enforcing the policy, and usermod fails because the user info is not stored locally.
I think you should consider using FreeIPA instead of just 389DS, because with it you would be able to manage centrally user policies (sudo, host access rules, account expiration etc). With this you would be able to enforce a lock of a user account on a particular host or group of hosts. FreeIPA would just give you the user friendly tools (Web UI and command line) to manage the user accounts and their policies. 389DS would still be storing and providing the information about these resources.
You should also try posting this question on the freeipa mailing list. It also covers the usage of the SSSD client. You could get answers to your questions directly from the developers and RH engineers.
If it's of any help I've attached a sample of SSSD configuration used in our environment.
Thanks
Dimitar
On Tue, Jan 7, 2014 at 7:57 AM, Mitja Mihelič mitja.mihelic@arnes.siwrote:
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos