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
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
