Thank you Jakub,

Those settings you gave me to minimally add back the ldap access_provider worked perfectly. All is working well again!

Best, Doug

On Sep 8, 2013, at 2:59 PM, Jakub Hrozek jhrozek@redhat.com wrote:

On Sat, Sep 07, 2013 at 07:16:09PM -0400, Dmitri Pal wrote:

...

On 09/07/2013 02:23 PM, Doug Clow wrote:

...

Hello,

I recently switched my sssd to 1.9 so I can try the native Active Directory support. Previously I was using:

id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap

And now with 1.9 I'm using:

id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad

This works great except for one thing. ldap_access_filter no longer does anything so everyone can log into all the machines. When I'm using access_provider = ad how do I restrict which users and groups have access to the machine?

There is no special access provider for AD back end

This is only correct to a certain extent. Quoting from the sssd-ad man page (and you didn't miss anything in the 1.9 docs, the following was added quite recently):

The AD access control provider checks if the account is expired. It has the same effect as the following configuration of the LDAP provider:

   access_provider = ldap
   ldap_access_order = expire
   ldap_account_expire_policy = ad

However, unless the “ad” access control provider is explicitly configured, the default access provider is “permit”.

The reason the AD access control provider is so simplistic at the moment is that future versions might suport access control based on group policies. I'm not aware of a firm ETA on leveraging GPOs, though.

...

so you still need to use ldap or simple access provider as you used to do in the past.

In order to configure the equivalent of a "filter" access control, you need to configure the LDAP access provider for the time being.

access_provider = ldap ldap_access_order = filter, expire ldap_account_expire_policy = ad ldap_access_filter = memberOf=cn=admins,ou=groups,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = CLIENT_SHORTNAME$@EXAMPLE.COM ldap_schema = ad

The reason for the setup being a little more complex is that the ldap_access_filter option is currently only reachable from the LDAP provider and the LDAP access provider currently depends on all the LDAP provider options being defined. Even though the AD provider is more or less a shorthand that expands to the above.

There is a ticket to handle this (arguably common) setup better: https://fedorahosted.org/sssd/ticket/1977

Hope this helps. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

On Fri, Sep 13, 2013 at 03:04:42PM +0200, Jakub Hrozek wrote:

On Mon, Sep 09, 2013 at 09:57:35AM -0700, Doug Clow wrote:

...

Thank you Jakub,

Those settings you gave me to minimally add back the ldap access_provider worked perfectly. All is working well again!

Best, Doug

Hi Doug,

I'm glad the access control is working for you now. We were thinking about means to improve the configuration and here is a first version of the design of proposed access control mechanism: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryAccessControl

If you have any comments, please let us know. In particular, as an admin, would you find the extended filter useful?

Also, would you be interested in testing this new feature?

On Mon, Sep 16, 2013 at 10:34:58AM -0700, Doug Clow wrote:

Hi Jakub,

I would definitely use that ad_access_filter feature. In fact that is how I expected it was going to work and tried it out originally.

Great, thank you! I flagged your e-mail so that I ping you when the new feature is ready (hopefully by the end of the week)

It would also be cool if there was a way to specify users and groups that did not require the whole distinguished name. A ldap-simple mode if you will. I know there are technical issues that make this hard to work for group membership. But, that way sssd could authenticate a user or group regardless if it had been moved to another OU. Maybe by using "pre-Windows 2000" name or SID. It would be more Windows like behavior.

I don't disagree, but at the very least I think that the option that behaves as you described should be named differently, not "filter". Also, do you see a reason why the simple access provider wouldn't be fit for this use case? (I can think of "not having to update all client sssd.conf files" for certain configurations, but I want to see if we're looking at the problem from the same angle)

Would you have time to quickly draft a use-case example of this option you propose? Just example of the config option is fine.

I'm happy to do some testing. Our environment here is CentOS 6.4

I'm working on the new option this week and will ping you when it's ready. Thank you again for the offer to test new functionality!