[PATCH] LDAP: Remove dead assignment
by Lukas Slebodnik
ehlo,
The variable ret was not read when function sysdb_has_enumerated
returned ENOENT. Just boolean variable has_enumerated need to be changed.
This dead assignment caused warning from clang static analyser
Value stored to 'ret' is never read
LS
8 years, 11 months
[DESIGN] Lookup Users by Certificate
by Sumit Bose
Hi,
I have created a design page for the InfoPipe method to look up users
based on a certificate as e.g. requested by
https://fedorahosted.org/sssd/ticket/2596 . Most of it will be needed
for certificate based authentication
https://fedorahosted.org/sssd/ticket/546 as well. It is available at
https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate
or for your convenience below.
Comments and suggestions are welcome.
bye,
Sumit
= Lookup Users by Certificate =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2596
* https://fedorahosted.org/sssd/ticket/546
* https://fedorahosted.org/freeipa/ticket/4238 (design page: http://www.freeipa.org/page/V4/User_Certificates)
=== Problem statement ===
As stated in ticket #2596 applications doing user authentication based on certificates, e.g. web servers, need a way to map the certificate presented by the client to a specific user. Although there are various ways to derive a user name from special entries in the certificate so far there is no generally accepted scheme. The most general and in some cases the only possible way is to look up the certificate directly in the LDAP server. This requires that the certificate is stored in the LDAP server which we will assume for this initial design. (In a second part user lookups based on the certificate content will be added, this requires that the syntax for the mapping is specified in http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Map...)
The primary interface to lookup users by certificate would be D-BUS.
=== Use cases ===
The primary use case is described in ticket #2596. If Apache is configured to use certificate based client authentication modules like mod_lookup_identity has access to the PAM encoded certificate via environment variables. With this data as input mod_lookup_identity should call a D-BUS method like ''org.freedesktop.sssd.infopipe.!GetUserAttrByCert'' which will return the data of the user the certificate belongs similar to the ''!GetUserAttr'' method.
=== Overview of the solution ===
Besides adding the D-Bus method to the !InfoPipe responder the generic LDAP backend should be able to search and read the certificate data if available from a LDAP server and store it to the cache. The internal sysdb interface must be extended to search cached entries with the certificate as input.
=== Implementation details ===
==== LDAP backend ====
Reading certificate data if available just requires adding a new user attribute which will be requested during LDAP searches for a user. In general the certificate is stored as a DER encoded binary on the LDAP server. '''Question: should we add an option like ldap_user_cert_encoding to support other encodings a server might send to us, or shall we add it only when there is a real use case?''' Internally the certificate should be stored DER encoded to the cache as well because this encoding is the most unambiguous encoding (e.g. with PEM encoding it is not clear if the base64 blob should have line breaks or not and if the enclosing '-----BEGIN CERTIFICATE-----' and '-----END CERTIFICATE-----' should be stored as well and if line break should be added here or not?)
To search a user with the help of the certificate the DER encoded binary ticket must be transformed into a search filter. In this case it would be something like 'userCertificate=\23\a5\3e......' where each byte from the certificate is is represented by a hex value pre-pendened by a '\'. The filter should be generated in a subroutine which accepts the DER encoded certificate with base64 ascii armor and returns the search filter. This way the subroutine can later be extended to accept configuration options for the identity mapping and can return different search filters for those cases. Since the requirement for LDAP and sysdb search filters are the same there should be an option indicating if a LDAP or sysdb filter is needed, because the attribute names might be different.
Although it would be possible to handle the binary DER data directly I think using a base64 ascii armor to handle the data as a string is useful to avoid adding code for handling binaries e.g. in the S-BUS requests to the backends.
==== SYSDB API ====
A new call sysdb_search_user_by_cert() should be added which get the DER encoded certificate with base64 ascii armor as input and use the function described above to get a proper search filter. Currently it will be only the search filter for the binary certificate. Other than that the new call will act like to other sysdb_search_user_by_*() calls.
==== !InfoPipe ====
A new method GetUSerAttrByCert() must be implemented which expected the PEM encoded certificate and an array of attrbute names. '''Question: Should we only support PEM here or other formats as well? In this case we need a third parameter indicating the encoding of the certificate data.'''. InfoPipe will convert the certificate into DER encoding with base64 ascii armor, search the cache and eventually forward the request to the backend. The request to the backend is processed similar to a request by name, only that a new filter name, e.g. DP_CERT_ID "cert", is needed.
Since it is in general not obvious to which domain a certificate belongs, the search must iterate over all domains in case no matching certificate was found. For the cases where there is a strong 1:1 relationship between the issuer of a certificate and a domain, configuration options for this can be added later.
=== Configuration changes ===
A new user attribute open 'ldap_user_certificate' will be added to the LDAP provider. By default only the IPA provider will set a value for it to avoid reading about 1k of data which is not needed in the other providers. '''Question: Does this make sense or shall we enable it for other providers as well?'''
=== How To Test ===
First a certificate must be load to a IPA user entry, it can be any kind of certificate as long as it is valid an DER or PEM encoded. Until IPA has some import utilities ldapmodify should be used. A LDIF file might look like this:
{{{
dn: uid=cert_user,cn=users,cn=accounts,dc=ipa,dc=devel
changetype: modify
add: userCertificate
userCertificate::MII...=
}}}
where MII...= indicates the base64 encoded certificate data. If you have a PEM encoded certificate you can just use the base64 part here. If the certificate is DER encoded it can be transformed to base64 with
{{{
base64 < ./certificate_file.der | tr -d '\n'
}}}
Testing can be done with the help of the dbus-send utility:
{{{
# dbus-send --system --print-reply --dest=org.freedesktop.sssd.infopipe \
/org/freedesktop/sssd/infopipe \
org.freedesktop.sssd.infopipe.GetUserAttrByCert
string:"-----BEGIN CERTIFICATE-----.......-----END CERTIFICATE-----" \
array:string:"name","uidNumber"
method return sender=:1.1807 -> dest=:1.1819 reply_serial=2
array [
dict entry(
string "name"
variant array [
string "cert_user"
]
)
dict entry(
string "uidNumber"
variant array [
string "1234567"
]
)
]
}}}
=== Authors ===
* Sumit Bose <sbose(a)redhat.com>
8 years, 11 months
[PATCH] LDAP: warn about lockout option being deprecated
by Pavel Reichl
Hello,
attached patch deprecates lockout option in 1-12 branch.
This was discussed in thread: SDAP: Lock out ssh keys when account naturally expires
This patch implements point number 2.
>> I would prefer if we didn't add a new option as well, but since we released
>> a version that only supported the lockout and not any other semantics,
>> I don't think we can get away with just changing the functionality. A
>> minor version can break functionality. But a major version can
>>
>> So I propose the following:
>> 1) Add a new value for ldap_access_order called "ppolicy" that would
>> evaluate the pwdAccountLockedTime fully, including the new
>> functionality in this patchset
>> 2) In 1.12, deprecate the "lockout" option and log a warning that it
>> will be removed in future relase and users should migrate to "ppolicy"
>> option
>> 3) In master (1.13), remove the "lockout" ldap_access_order value
I'll send patch for point number 3 in separate thread.
Thanks!
8 years, 11 months
[PATCH] krb5: remove field run_as_user
by Pavel Reichl
Hello,
this patch was already ACKed in another thread, I decided to move it
here as that thread is going to take some more time to finish.
>> From ffe3d9f0e0e697f565fb28861df41fdd9c7bbbe2 Mon Sep 17 00:00:00 2001
>> From: Pavel Reichl<preichl(a)redhat.com>
>> Date: Wed, 29 Apr 2015 06:03:04 -0400
>> Subject: [PATCH 3/3] krb5: remove field run_as_user
> Oops, this is a leftover from the rootless sssd changes. ACK.
> >From 50839ec51277cb9aa45c21b71bfb9dc5e8b0b553 Mon Sep 17 00:00:00 2001
>> From: Pavel Reichl<preichl(a)redhat.com>
>> Date: Wed, 29 Apr 2015 06:03:04 -0400
>> Subject: [PATCH 2/3] krb5: remove field run_as_user
>>
>> run_as_user is set set but never read.
>> ---
> LGTM
ci passed:
http://sssd-ci.duckdns.org/logs/job/15/14/summary.html
Thanks!
8 years, 11 months
[RFC] Remove enumeration support from the AD and IPA back ends
by Jakub Hrozek
Hi,
this proposal might be a bit controversial, so I hope there wouldn't be
any big flame.
In the past, the AD and IPA back ends were just a wrapper around the LDAP
provider that used different defaults customized for the particular server.
But that's not the case anymore. We keep adding features to the AD and IPA
back ends that require different smart logic to get the right data, might
require several lookups (IPA ID views), might require looking up huge amounts
of data (looking all users/groups from a trusted AD forest) or might not even
support the "get all" semantics (trusted AD users on an IPA client).
As a result, enumeration doesn't work at all for IPA ID views, doesn't
work at all for AD trusted users on IPA clients and performs badly (and
is not tested well) for trusted AD domains. If you cross out all the
use-cases that don't work, you end up with..what the LDAP provider
supports.
Therefore, I would like to propose that we remove enumeration support from AD
and IPA back ends eventually. Clearly, there must be some transition
period for such a big feature that /is/ being used by our users.
>From the top of my head, this could be a syslog warning for one release,
requiring to add another config option to get the deprecated functionality
back in another release and finally a cut in the next one. I know removing
functionality is always a sensitive topic, but I also think that removing
broken enumeration is also a better choice than pretending it works.
What are your thoughts?
8 years, 11 months
[PATCH] IPA: do not fail if view name lookup failed on older versions
by Sumit Bose
Hi,
this patch fixes an issue seen when newer idview-aware SSSD clients try
to connect to older IPA server. As mentioned in the commit message it is
due to different error codes returned by different versions of 389ds.
This issue only becomes important when the old IPA server has a trust to
AD because the issue prevents SSSD from reading the SID of the IPA
domain. Without trust the issue can be verified by checking the logs.
ipa_get_view_name_done() should fail with the message "get_view_name
request failed, looks like server does not support views." and continue
to read data about the IPA domain. Without this path you should see
"get_view_name request failed." and the whole request should be
canceled.
bye,
Sumit
8 years, 11 months