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@xxxxxxxx>wrote: > 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 >> > > > _______________________________________________ > CentOS mailing list > CentOS@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos > >
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
