ad_access_filter and nested groups

[Bosnian Ace]

Hi guys (and girls if any)...

First of all - great piece of software. Merging the worlds of Linux and
Windows got pretty simple and advanced as well.

I've got sssd 1.11.6 on a CentOS 6.6 test box talking to AD on a Windows
2008R2. Password and public key auth are working almost out of the box.

Since I would like to restrict SSH access to my boxes, I discovered the
"ad_access_filter" and added a simple

ad_access_filter =
memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local

"Unfortunately" I have nested groups and in the group called
"permunix.adm.tvie02s010" there is another group that holds my admins -
called "permunix.adm.admins". Since there is a group in a group I could not
get any results that would match my user that is in the group "..admins".

When I do a simple id -a username, I get the both groups for my admin user.
But the login via SSH would fail with ...

[sdap_process_result] (0x2000): Trace: ldap_result found nothing!

My domain portion of sssd.conf looks like this:
 id_provider = ad
        auth_provider = ad
        access_provider = ad

ldap_search_base = dc=my01,dc=local
        ldap_id_mapping = false
        ldap_access_order = expire
        ldap_account_expire_policy = ad
        ldap_schema = ad
        cache_credentials = false
        ldap_user_ssh_public_key = extensionAttribute15
        ldap_sasl_mech = GSSAPI
        ldap_sasl_authid = TVIE02S010$
        ldap_krb5_keytab = /etc/krb5.keytab
        ldap_krb5_init_creds = true
        ldap_krb5_ticket_lifetime = 28800

ldap_groups_use_matching_rule_in_chain = true
        ldap_initgroups_use_matching_rule_in_chain = true
        ldap_use_tokengroups = false
        ldap_group_nesting_level = 5

debug_level = 9
        ad_access_filter =
memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local

Any ideas why the LDAP_MATCHING_RULE_IN_CHAIN doesn't resolve the group
members?

When I use a simple ldapsearch on the console with
(&(sAMAccountName=myusername)(objectclass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local))

I get one result with my user object... Since you parse the
ad_access_filter I cannot enter the LDAP_MATCHING_RULE_IN_CHAIN OID in the
filter itself.

Thank you in advance!

[Jakub Hrozek]

On Tue, Dec 09, 2014 at 03:59:58PM +0100, Bosnian Ace wrote:
> Hi guys (and girls if any)...
>
> First of all - great piece of software. Merging the worlds of Linux and
> Windows got pretty simple and advanced as well.
>
> I've got sssd 1.11.6 on a CentOS 6.6 test box talking to AD on a Windows
> 2008R2. Password and public key auth are working almost out of the box.
>
> Since I would like to restrict SSH access to my boxes, I discovered the
> "ad_access_filter" and added a simple
>
> ad_access_filter =
> memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local

The thing to keep in mind is that the access_filter is applied on the
user entry in LDAP. If you search your user in AD's LDAP, does it show
this memberof attribute? If not, then the filter won't match..

If you run "id $user", does it show the group you'd like to restrict
access with? If yes, then it would be much simpler to just use:
    access_provider=simple
    simple_allow_groups=permunix.adm.tvie02s010
> "Unfortunately" I have nested groups and in the group called
> "permunix.adm.tvie02s010" there is another group that holds my admins -
> called "permunix.adm.admins". Since there is a group in a group I could not
> get any results that would match my user that is in the group "..admins".
>
> When I do a simple id -a username, I get the both groups for my admin user.
> But the login via SSH would fail with ...
>
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!

This is a misleading DEBUG message at best, we should really change it.
The message IIRC just means the search ran to completion, not that it
didn't find anything.
> My domain portion of sssd.conf looks like this:

See my comments inline:
> id_provider = ad
>         auth_provider = ad
>         access_provider = ad
>     ldap_search_base = dc=my01,dc=local

Do you really need this parameter? The AD provider should be able to
autodetect the search base from the rootDSE. If the autodetection
selects a different search base than the one you'd like to use, then
it's fine to use a custom one.
>     ldap_id_mapping = false
>     ldap_access_order = expire

A filter is only in effect if
>     ldap_account_expire_policy = ad

The two above should already be the default for the ad PVODIER, YOU CAN
JUST LEAVE THEM OUT
>     ldap_schema = ad
>     cache_credentials = false
>     ldap_user_ssh_public_key = extensionAttribute15

Ah, nice :-)
>     ldap_sasl_mech = GSSAPI
>     ldap_sasl_authid = TVIE02S010$
>     ldap_krb5_keytab = /etc/krb5.keytab
>     ldap_krb5_init_creds = true

The four parameters above should already be defaults (sasl_authid should
already be autodetected)
>     ldap_krb5_ticket_lifetime = 28800
>
>     ldap_groups_use_matching_rule_in_chain = true
>     ldap_initgroups_use_matching_rule_in_chain = true
>     ldap_use_tokengroups = false

Did you have some problems using tokengroups? Why did you decide to use
the matching rule instead?
>     ldap_group_nesting_level = 5
>
>     debug_level = 9
>     ad_access_filter =
>
> memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local
>
> Any ideas why the LDAP_MATCHING_RULE_IN_CHAIN doesn't resolve the group
> members?
>
> When I use a simple ldapsearch on the console with
> (&(sAMAccountName=myusername)(objectclass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local))
>
> I get one result with my user object... Since you parse the
> ad_access_filter I cannot enter the LDAP_MATCHING_RULE_IN_CHAIN OID in the
> filter itself.
>
> Thank you in advance!
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

On Tue, Dec 09, 2014 at 04:13:50PM +0100, Jakub Hrozek wrote:
> >     ldap_id_mapping = false
> >     ldap_access_order = expire
>
> A filter is only in effect if

Sorry, I left the sentence unfinished. The ldap and ad filter options
are only in effect if the ldap_access_order contains filter. So my guess
is that the ad_access_filter option was pretty much ignored.