Hi Dimitar!
FreeIPA might be worth a look. We already have a user management system
that currently manages passwd/shadow. The idea was to migrate
passwd/shadow info to 389DS so we could distribute the users across
multiple servers. Perhaps our management system could use FreeIPA's
tools for user management.
I could not find find the attachment in your last email, could you
please send it again?
Do you perhaps have experience in managing a SSSD-389DS system with 70k
users and about 500 queries per second to SSSD?
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 07. 01. 2014 21:27, Dimitar Georgievski wrote:
> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
