Learn more about these different git repos.
Other Git URLs
When negotiating encryption using either StartTLS or during the initial setup of an LDAPS connection, the client may be offered the opportunity to offer up its own certificate in order to authenticate to the directory server as part of the handshake.
Some servers will allow the client to subsequently "authenticate" using SASL/EXTERNAL and then proceed as an authenticated client. Since we support SASL/GSSAPI and simple binds, we should probably add the necessary plumbing to let SSSD authenticate this way, too.
Fields changed
component: SSSD => LDAP Provider
milestone: NEEDS_TRIAGE => SSSD 1.6.0 version: => 1.2.1
coverity: => milestone: SSSD 1.6.0 => SSSD 1.7.0 upgrade: => 0
To clarify, this is something along the lines of using the client system's certificate and private key to authenticate as part of the TLS or SSL handshake. SASL/EXTERNAL should (hopefully?) be available as an option to instruct the server to authorize the client to use the directory based on naming information present in the client certificate (by mapping the subject DN to an entry in the directory, or by pulling out a subjectAltName value and using that, or something else).
milestone: SSSD 1.8.0 => SSSD 1.9.0 patch: => 0
blockedby: => blocking: => milestone: SSSD 1.9.0 => SSSD Deferred rhbz: =>
rhbz: => 0
feature_milestone: => proposed_priority: => Important
priority: minor => critical
milestone: SSSD Deferred => SSSD 1.10.0
proposed_priority: Important => Core
Hmm, at least some of this appears to have been done as part of ticket #780.
SSSD may need to be able to diagnose cases where the client's certificate is no longer valid, or at least have someone else (e.g., certmonger) watching out for that eventuality.
In at least some cases, the system which is running the directory server that SSSD is contacting will also be running a CA provided by the directory server's vendor. While certmonger can already handle that when the directory server and CA are IPA, SSSD also runs in other environments. We're going to teach certmonger to [talk to standalone Dogtag instances], and also look at teaching it to https://fedorahosted.org/certmonger/ticket/11 talk to ADCS. You may want to make use of that capability if/when it becomes available.
I don't know if that means a new ticket of some sort for SSSD, so I'm just making a note here so it won't come as a complete surprise later.
rhbz: 0 => todo summary: Add support for certificate-based authentication to directory servers => [RFE] Add support for certificate-based authentication to directory servers
Cleaning the 1.10 milestones before putting tickets into it.
milestone: SSSD 1.10.0 => Temp milestone
Moving planned features and bug fixes into the 1.10 bucket.
milestone: Temp milestone => SSSD 1.10.0
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: Temp milestone => SSSD 1.10 beta
design: => design_review: => 0 fedora_test_page: => selected: => Not need
Moving tickets that are not a priority for SSSD 1.10 into the next release.
milestone: SSSD 1.10 beta => SSSD 1.11 beta
priority: critical => minor
mark: => 0
changelog: => milestone: SSSD 1.13 beta => SSSD 1.13 backlog review: => 0
Mass-moving tickets not planned for the next two releases.
Please reply with a comment if you disagree about the move..
milestone: SSSD 1.13 backlog => SSSD 1.15 beta
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1292505 (Red Hat Enterprise Linux 7)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1292505 1292505]
Metadata Update from @nalin: - Issue set to the milestone: SSSD Future releases (no date set yet)
Login to comment on this ticket.