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
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:
"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
Any ideas why the LDAP_MATCHING_RULE_IN_CHAIN doesn't resolve the group
When I use a simple ldapsearch on the console with
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
Thank you in advance!
sssd-users mailing list