[PATCH] nested groups unit test
by Pavel Březina
Hi,
this is the first unit test for nested groups. It covers only the most
basic situation when we are trying to resolve one group with no members.
Even though it is only one test, the patch set is quite big. This is
because it creates the possibility to mock providers related modules.
Most of the patches are just a preparation for unit testing providers.
Patches 1-5
Moves the code around to reduce number of dependencies. (E.g. you do not
want to load fail over when you are testing nested groups.)
Patch 6
Mocks basic SDAP interface.
Patch 7
Mocks sysdb objects - currently user and rfc2307bis group. You can
decide what set of attributes the object should posses. For example,
creating a user requires only basedn and name parameter, to construct
originalDN and name attributes. The rest is provided by (attrname,
value) pairs via variadic function.
E.g.:
mock_sysdb_user(mem_ctx, basedn, name, SYSDB_UIDNUM, uid, ...)
get_attr_type() translates the sysdb attribute name to proper data type.
This should be extended as needed.
Patch 8
Adds provider tests related common object files and cflags in makefile
Patch 9
New macro sss_will_return_always(fn, value). This can be used to mock
function data in such way that any call of mock() will return the value.
It was just pushed also to cmocka upstream as will_return_always().
Patch 10-11
Unit test.
Patch 12
Removes a noisy debug message.
I would like to get this reviewed before I continue with more test
cases, so the framework is tuned enough.
Off topic:
I also created new macro called fail_msg, which will make the test fail
printing a message. I didn't use this macro in the end, but it made its
way to cmocka upstream.
9 years, 3 months
[PATCH] PROXY: Handle empty GECOS
by Jakub Hrozek
I found this bug while triaging a customer case with Chris Hudson who
ran into the same issue Simo fixed recently in the proxy provider.
9 years, 6 months
Fix proxy backend initgroups_dyn code
by Simo Sorce
Tested fix for #2051 and seem to work.
However it just occurred to me we may always want to check if pwd.pw_gid
is listed in the gids returned and add it if not ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9 years, 6 months
[PATCHES] Alignment issues reported by Clang
by Michal Židek
Patches 1-4 and 9:
These patches use the SAFEALIGN macros where it is appropriate. I split
them into several patches for easier review, so that client code changes
are not mixed with the rest of the code and changes that are a little
different than the rest have their own patch.
Patches 5-6:
Here I think it is not needed to use uint8_t* or char*. We cast the
pointer anyway and there are no real alignment issues (the memory is
aligned properly). I was thinking about suppressing the warnings with
#pragma here, but in this particular situation it is IMO better to have
just void*.
Patches 7-8:
These were all false positive warnings. It is possible to suppress them
with additional casting but I found it less readable so I used #pragma.
Patch 10:
We had improperly aligned part of a buffer used in client code. Also
some code blocks here must rely on fact that the buffer they get is
aligned properly (they can do nothing about it if it isn't). In these
cases it is better to silence the warnings, so that it does not make
permanent noise during compilation.
Thanks
Michal
9 years, 6 months
[PATCH] responder: Access packet header using SAFEALIGN macros
by Michal Židek
Hello,
the attached patch should uses the SAFEALIGN macros to access data in
the packet header (in sss_packet structure) so that it does not depend
on proper memory alignment (currently the alignment is OK, but if we add
something to the packet header later, it is probably safer not to depend
on proper alignment). It also silences a lot of alignment warnings.
Thanks
Michal
9 years, 7 months
[PATCH] ad: support cross domain membership
by Pavel Březina
https://fedorahosted.org/sssd/ticket/2064
These patch set depends on:
[PATCH] ad: store group in correct tree on initgroups via tokenGroups
You can also pull it with all dependencies from my repository:
fedorapeople.org:public_git/sssd.git #ad-groups
The fundamental changes in this patch set are:
- lookup groups in global catalog
- pick up member domain from its originalDN
9 years, 7 months
[PATCH] IPA: Do not enable IPA sites in server mode
by Jakub Hrozek
I realized this might be a nice chance when I was working on #2079. In
the server mode, the IPA sites should be ignored, I think. But I don't
think this patch is too important as IPA sites are still only
experimental patches.
9 years, 7 months
Design Discussion: Improving AD provider access control
by Jakub Hrozek
Hi,
I created a design page that describes a proposed way of improving the
current AD provider access control. The main ticket that tracks the work
is https://fedorahosted.org/sssd/ticket/2082 and the full design page
can be found here:
https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryAccessControl
Comments and review are mostly welcome.
For your convenience, the text of the design page is also copied below,
in wiki syntax:
== Active Directory client access control ==
Related ticket(s):
* [https://fedorahosted.org/sssd/ticket/2082 RFE:Add a new option ad_access_filter]
* [https://fedorahosted.org/sssd/ticket/1975 RFE:Change the default of ldap_access_order]
* [https://fedorahosted.org/sssd/ticket/1977 issues when combining the AD provider and ldap_access_filter]
Somewhat related:
* [https://fedorahosted.org/sssd/ticket/2083 Document the best practices for AD access control]
=== Problem Statement ===
The recommended way of connecting a Linux client to an Active Directory domain
is using the [http://jhrozek.fedorapeople.org/sssd/1.11.0/man/sssd-ad.5.html AD provider].
However, in the default configuration of the Active Directory
provider, only account expiration is checked. Very often, the administrator
needs to restrict the access to the client machine further, limiting the
access to a certain user, group of users, or using some other custom filtering
mechanism. In order to do so, the administrator is required to use an alternative access control provider.
However, none of the alternatives provide the full required functionality for all users
resolvable by the AD provider, moreover they are hard to configure. This design page proposes extension
of the AD access provider to address these concerns.
=== Current access control options ===
With the existing SSSD, the administrator has two basic means
to restrict access control to the Linux client - using the
[http://jhrozek.fedorapeople.org/sssd/1.11.0/man/sssd-simple.5.html simple access control provider]
or configuring the LDAP access control provider. Each approach has its pros and cons.
==== Using the simple access provider ====
The simple access provider grants or denies access based on the contents
of allow and deny lists. There are separate lists for user and group
names as well as allowed and denied objects.
The following example shows configuration that grants access to user named
`tux` and group called `linuxadmins`.
{{{
access_provider = simple
simple_allow_users = tux
simple_allow_groups = linuxadmins
}}}
* Pros:
* Easy to configure
* Realmd provides an interface to configure the simple access provider using its CLI
* Cons:
* Account expiration is not checked
* Limited expresiveness. No way to combine several clauses
* Does not align with the LDAP structure the Active Directory uses
==== Using the LDAP access provider ====
The LDAP access provider offers a way to configure the access control
decision based on whether the user matches a preconfigured filter. Moreover,
the LDAP access provider also offers chaining other LDAP based checks. For
the vanilla AD environment, only account expiration check applies.
The following example illustrates configuration that allows access to those
users, who are members of group named `linuxadmins` AND have a valid home
directory set using the `ldap_access_filter` directive. The users who
match the configured filter are also checked whether they are expired
(`ldap_access_order` contains `expire`).
{{{
access_provider = ldap
ldap_access_order = filter, expire
ldap_account_expire_policy = ad
ldap_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = CLIENT_SHORTNAME$(a)EXAMPLE.COM
ldap_schema = ad
}}}
* Pros:
* Allows the administrator to base access control on a custom LDAP filter, making it possible to combine several conditions
* Conditions are not limited to user names or group membership
* Cons:
* Nontrivial and clumsy configuration that must include several low level LDAP settings, otherwise set automatically by the AD provider. Defeats the whole purpose of the AD provider
* The admin needs to combine AD and LDAP providers. Judging by experience from triaging support cases with Red Hat support, this is a problem for many admins.
* Account expiration check must be configured separately, which is not obvious
* No support for users from trusted AD domains
* No realmd integration
=== Proposed solution ===
The proposal is to add a new access filter configuration option to the
existing AD access provider. Adding the option to the AD provider would
greatly simplify the configuration when compared to the LDAP access control,
while maintaining the full expresiveness of `ldap_access_filter`. The
new option would be called `ad_access_filter`. If the new option was set,
then the AD access provider would first match the entry against the filter
in that option. If the entry matched, then the account would be checked
for expiration.
The following exapmple illustrates an example similar to the one above, using the proposed AD options:
{{{
access_provider = ad
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
}}}
The main advantage is simplified configuration. The admin doesn't have to know or understand what "SASL ID" is.
In comparison with the two legacy solutions explained above:
* Pros
* Easy and intuitive configuration. Only one provider type is configured
* Sane defaults - always checks for expiration, also checks access filter if configured that way
* Would support users and groups from trusted domains by leveraging the existing AD provider infrastructure
* Cons
* No realmd integration
=== Realmd integration ===
After a short discussion with the realmd upstream maintainer, it was decided that these options do not fit the realmd use-cases well. If the user needs to use such advanced techniques as LDAP filters,
chances are that he doesn't need a tool like realmd to set them up in the config file.
=== Implementation details ===
1. The default value of what AD access_provider is set to should be changed
* Currently, if `access_provider` is not set explicitly, the default is `permit`, thus allowing even expired accounts
* The new default would be `ad`, checking account expiration even with a minimal configuration
1. A new option would be added. The new option would be called `ad_access_filter`
1. The LDAP access provider must be extended to allow connecting to a GC and support subdomains in general
* Pass in `struct sdap_domain` and `id_conn` instead of using the connection from `sdap_id_ctx` directly
* The code must not read the `sss_domain_info` from `be_ctx` but only from `sdap_domain` in order to support subdomain users
1. The AD access provider must call the improved LDAP access provider internally with the right connection
* The default should be GC
* If POSIX attributes are in use and GC lookup wouldn't match, optionally fall back to LDAP. This fallback could be tried just once to speed up subsequent access control
1. The default chain of LDAP access filter the AD provider sets internally must be changed.
* Currently AD provider sets `ldap_access_order=expire`. If (and only if) `ad_access_filter` was set, the LDAP chain would become `ldap_access_order=filter,expire`
==== Parsing the `ad_access_filter` option ====
1. The `ad_access_filter` option is a comma-separated list of filters that apply globally, per-domain or per-forest. The most specific match is used
1. If the `ad_access_filter` value starts with an opening bracket `(`, it is used as a filter for all entries from all domains and forests
* example: `(&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))`
1. More advanced format can be used to restrict the filter to a specific domain or a specific forest. This format is `KEYWORD:NAME:FILTER`
* KEYWORD can be one of `DOM` or `FOREST`
* KEYWORD can be missing
* NAME is a label.
* if KEYWORD equals `DOM` or missing completely, the filter is applied for users from domain named NAME only
* if KEYWORD equals `FOREST`, the filter is applied on users from forest named NAME only
* examples of valid filters are:
* apply filter on domain called dom1 only:
* `dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)`
* apply filter on domain called dom2 only:
* `DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)`
* apply filter on forest called EXAMPLE.COM only:
* `FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)`
1. If no filter matches the user's domain, access is denied
* example `ad_access_filter = dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com), dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)`, user logs in from dom3
=== Contingency plan ===
None needed. The existing options would still exist and function as they do now.
=== How to test ===
1. Check that `access_provider=ad` without any other options allows non-expired users
1. Check that `access_provider=ad` without any other options denies expired users
1. Test that setting `ad_access_filter` restricts access to users who match the filter
* test that an expired user, even though he matches the filter, is denied access
* this test must include users from the primary domain as well as a sub domain
* Different filters should be tested to make sure the most speficic filter applies
* example: add a restrictive filter for dom1 and permissive filter without specifying the domain. A user from dom1 must be denied access, while a user from other domain must be allowed access
1. When access is denied, the SSSD PAM responder must return a reasonable return code (6)
=== Future and optional enhancements ===
In the future, we should extend the `access_provider` option itself and allow
chaining access providers. This enhancement would allow even more flexibility
and would allow the administrator to combine different access providers,
but is outside the scope of the change described by this design page.
=== Author(s) ===
* Jakub Hrozek <jhrozek(a)redhat.com>
* Sumit Bose <sbose(a)redhat.com>
9 years, 7 months