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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users