On Fri, May 06, 2016 at 03:18:30PM +0200, Jakub Hrozek wrote:
On Fri, Apr 29, 2016 at 03:38:46PM +0200, Sumit Bose wrote:
> please find a new design document at
> It describes the extended support for user lookup by certificates namely
> for certificates stored in AD and overrides.
> The related patches are ready from the functional point of view but I
> want to add some more test before sending them to the list.
> For your convenience please find the text of the design document below
> as well.
I'm sorry it took so long to get back to this design page. In general
the design sounds good to me, just see two questions inline:
> === Configuration changes ===
> For the AD provider the currently unset option
> will be set to ''userCertificate;binary''. This means that is a
> certificate is available in the user entry it will be downloaded and
> written to the cache by default. To avoid this
> must be set to a non-existing attribute name like e.g.
> ldap_user_certificate = nonExistingAttributeName
What would be the use-case for this? To avoid growing the cache?
Yes, if someone cares. I added this because we will change the current
default and I want to show a way how to return the to previous
> The ''sss_override user-add'' utility has a new option
> (''-x'') which expects the base64-endode certificate as an
How would the export work here? Our export command is a CSV file, so I
guess for the first version we could just extend the export to also dump
this additional attribute, but I'm more concerned about someone
Yes, I added it to the export and import calls.
forgetting to export the certificate and wiping out their cache. So
wonder if we should (after the initial implementation) focus on
automatically backing up the exports or even storing the certificates in
the new 'secrets' provider.
Having some means to prevent that any of the local override data is lost
accidentally is a good idea. But I think using the 'secrets' provider
would be a misuse because none of the override data including the
certificate is secret.
> sssd-devel mailing list