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!
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
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.
sssd-users@lists.fedorahosted.org