[SSSD] pam_pkcs11.so is missing for LOCAL domain?

Stephen Gallagher sgallagh at redhat.com
Mon Apr 26 11:56:11 UTC 2010


On 04/24/2010 02:27 AM, David O'Brien wrote:
> Stephen Gallagher wrote:
>> On 04/21/2010 08:35 AM, David O'Brien wrote:
>>> Stephen Gallagher wrote:
>>>> On 04/21/2010 03:10 AM, Tomas Mraz wrote:
>>>>> On Wed, 2010-04-21 at 14:04 +1000, David O'Brien wrote:
>>>>>> Tomas Mraz wrote:
>>>>>>> On Thu, 2010-04-15 at 14:24 +1000, David O'Brien wrote:
>>>>>>>> I'm using the authconfig gui on rhel6 beta to set up SSSD, and I get the
>>>>>>>> following message:
>>>>>>>>
>>>>>>>> Authentication module /lib/security/pam_pkcs11.so is missing.
>>>>>>>> Authentication process might not work correctly.
>>>>>>>>
>>>>>>>> /var/log/sssd/sssd_pam.log is empty
>>>>>>>> /var/log/messages has nothing significant
>>>>>>>>
>>>>>>>> The sssd service is running, but I don't know what's going to work (or not).
>>>>>>>>
>>>>>>>> Is there something else I need to install for this?
>>>>>>>> I'll provide more info if I get it.
>>>>>>> Please try newer authconfig packages. The current build in brew for
>>>>>>> RHEL-6 is authconfig-6.1.3-3.el6.
>>>>>>> https://brewweb.devel.redhat.com/buildinfo?buildID=130102
>>>>>>>
>>>>>> Yes, I did that, and I now have a completely different GUI for
>>>>>> Authentication Configuration, which lacks any (visible) means of
>>>>>> configuring SSSD.
>>>>>>
>>>>>> Where should I go from here?
>>>>> The GUI automatically chooses to use the SSSD if the configured
>>>>> combination of user-id and authentication methods are supported by it.
>>>>>
>>>>> You can see whether SSSD is used if you find sss in /etc/nsswitch.conf
>>>>> instead of ldap in the passwd line.
>>>>
>>>> As Tomas said, we have eliminated the need for the user of the
>>>> authconfig UI to know that SSSD is being used under the hood. The old UI
>>>> was much too confusing for SSSD (and required a level of knowledge equal
>>>> to or greater than editing the config file directly)
>>>>
>>>> Now, customers will be provided with SSSD silently if their
>>>> configuration supports it.
>>>>
>>>> The configurations that will trigger the use of SSSD are:
>>>>
>>>> User Account Database: LDAP
>>>> Authentication Method: LDAP or Kerberos
>>>>
>>> What happened to LOCAL/LOCAL?
>>>
>>> There is an example in the current doc that explains how to set up a
>>> standalone, local SSSD domain, and I was in the process of using that to
>>> put together a procedure using the GUI. That's what led to the initial
>>> problem that started this thread. Maybe I need to rewind and start over...
>>>
>>
>> LOCAL/LOCAL was put on the back-burner for the SSSD. It's not an
>> interesting case at this time.
>>
> ok, thanks. I've raised a BZ (585075) for me to fix the relevant bits in
> the Deployment Guide; how about the man page? Is anyone looking at that?
>
> cheers
>

There's no reason to change the manpage. The functionality is still 
present, and it's perfectly fine to use it. However, in RHEL6 it is not 
an interesting case, and thus should be removed from the deployment guide.

The issue here is that, because of the elimination of InfoPipe from the 
roadmap, the SSSD-provided local users have no benefits over using the 
standard POSIX /etc/passwd and /etc/shadow files (except for nested 
groups, but that's such a rare case that it's not worth discussing right 
now)

The original plan for the local domain was so that we could carry 
additional information in the same data store as the user (such as 
locale preferences, face browser image, etc.). This additional 
functionality has been postponed indefinitely, so we should reduce 
confusion in the RHEL documentation and not bring it up.


-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



More information about the sssd-devel mailing list