Efficient AD group matching via the new wbclient interface
Hello all, I am working on improving AD group matching for mschap authentication, taking advantage of the new wbclient direct interface which returns the user's token (including group membership SIDs) as part of NTLM authentication. Work in progress: https://github.com/frenche/freeradius-server/commit/9af7dfd634a251f68b070646... I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome. @mcnewton, I noticed at last there is a similar group-compare function in v4 branch, though I think the two actually can complete each other. Thoughts? Thank you, Isaac B.
On Feb 10, 2018, at 10:22 AM, Isaac Boukris <iboukris@gmail.com> wrote:
I am working on improving AD group matching for mschap authentication, taking advantage of the new wbclient direct interface which returns the user's token (including group membership SIDs) as part of NTLM authentication.
Work in progress: https://github.com/frenche/freeradius-server/commit/9af7dfd634a251f68b070646...
It looks good.
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
@mcnewton, I noticed at last there is a similar group-compare function in v4 branch, though I think the two actually can complete each other.
I'd like Matthew's comments, too. Alan DeKok.
On Tue, 2018-02-13 at 09:07 -0500, Alan DeKok wrote:
On Feb 10, 2018, at 10:22 AM, Isaac Boukris <iboukris@gmail.com> wrote:
I am working on improving AD group matching for mschap authentication, taking advantage of the new wbclient direct interface which returns the user's token (including group membership SIDs) as part of NTLM authentication.
Work in progress: https://github.com/frenche/freeradius-server/commit/9af7dfd634a251f 68b07064603ccbbca308492bf
It looks good.
Yes, it's good to use the SIDs that are returned from wbcCtxAuthenticateUserEx as you get them for free, rather than having to query winbindd for them again. I'm not sure why you're creating AD-Group-SID in the outer - just create it in the current virtual server lists, and let the admin copy it to the outer if they need to using unlang.
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
Sounds sensible to me.
@mcnewton, I noticed at last there is a similar group-compare function in v4 branch, though I think the two actually can complete each other.
I'd like Matthew's comments, too.
I'm not sure if the same caveat applies to this as to using wbcCtxGetGroups; probably worth checking this reply: https://lists.samba.org/archive/samba-technical/2016-November/116996.ht ml I'd imagine it is the same. The good thing about your method is that you can /only/ use it after authentication, so that forces the data to be recent, at least. It also really needs to compare group names, and make SIDs the secondary comparison method. Names are nice and easy for admins, SIDs are things that should generally stay hidden. -- Matthew
On Tue, Feb 13, 2018 at 4:49 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-02-13 at 09:07 -0500, Alan DeKok wrote:
On Feb 10, 2018, at 10:22 AM, Isaac Boukris <iboukris@gmail.com> wrote:
I am working on improving AD group matching for mschap authentication, taking advantage of the new wbclient direct interface which returns the user's token (including group membership SIDs) as part of NTLM authentication.
Work in progress: https://github.com/frenche/freeradius-server/commit/9af7dfd634a251f 68b07064603ccbbca308492bf
It looks good.
Yes, it's good to use the SIDs that are returned from wbcCtxAuthenticateUserEx as you get them for free, rather than having to query winbindd for them again.
I'm not sure why you're creating AD-Group-SID in the outer - just create it in the current virtual server lists, and let the admin copy it to the outer if they need to using unlang.
Yea, I think the reason was I didn't manage to do it in unlang ;-) I'll re-look into this.
@mcnewton, I noticed at last there is a similar group-compare function in v4 branch, though I think the two actually can complete each other.
I'd like Matthew's comments, too.
I'm not sure if the same caveat applies to this as to using wbcCtxGetGroups; probably worth checking this reply:
https://lists.samba.org/archive/samba-technical/2016-November/116996.ht ml
I'd imagine it is the same.
The good thing about your method is that you can /only/ use it after authentication, so that forces the data to be recent, at least.
I'm not sure what caveat are you worried about, the SIDs are returned from the DC in the RPC call (NETLOGON_VALIDATION). To my understanding that's what windows use when login-in a user and applying permissions.
It also really needs to compare group names, and make SIDs the secondary comparison method. Names are nice and easy for admins, SIDs are things that should generally stay hidden.
The idea here is to allow for even more efficient matching, when using upper level user-interface (graphical or web) to create the policy, by showing the admin a group object but actually saving the SID in the policy. This is in fact what AD does when you set permissions on files or using ad-users-and-computers. Also, for other authentication methods I was thinking we could integrate with LDAP, query for the tokenGroups attribute and populate the SIDs attributes, then have it match the ad-group policies.
On Tue, Feb 13, 2018 at 6:27 PM, Isaac Boukris <iboukris@gmail.com> wrote:
On Tue, Feb 13, 2018 at 4:49 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-02-13 at 09:07 -0500, Alan DeKok wrote:
On Feb 10, 2018, at 10:22 AM, Isaac Boukris <iboukris@gmail.com> wrote:
I am working on improving AD group matching for mschap authentication, taking advantage of the new wbclient direct interface which returns the user's token (including group membership SIDs) as part of NTLM authentication.
Work in progress: https://github.com/frenche/freeradius-server/commit/9af7dfd634a251f 68b07064603ccbbca308492bf
It looks good.
Yes, it's good to use the SIDs that are returned from wbcCtxAuthenticateUserEx as you get them for free, rather than having to query winbindd for them again.
I'm not sure why you're creating AD-Group-SID in the outer - just create it in the current virtual server lists, and let the admin copy it to the outer if they need to using unlang.
Yea, I think the reason was I didn't manage to do it in unlang ;-) I'll re-look into this.
@mcnewton, I noticed at last there is a similar group-compare function in v4 branch, though I think the two actually can complete each other.
I'd like Matthew's comments, too.
I'm not sure if the same caveat applies to this as to using wbcCtxGetGroups; probably worth checking this reply:
https://lists.samba.org/archive/samba-technical/2016-November/116996.ht ml
I'd imagine it is the same.
The good thing about your method is that you can /only/ use it after authentication, so that forces the data to be recent, at least.
I'm not sure what caveat are you worried about, the SIDs are returned from the DC in the RPC call (NETLOGON_VALIDATION). To my understanding that's what windows use when login-in a user and applying permissions.
It also really needs to compare group names, and make SIDs the secondary comparison method. Names are nice and easy for admins, SIDs are things that should generally stay hidden.
Also, I think my assumption was that it would be cheaper to resolve policy group names to SIDs and compare SIDs, rather than resolve all user's SIDs to names and compare names. This is likely to be true for when the number of groups in the policy is small, but even with a large number I'd guess the caching will be more effective (over when resolving each of user's SIDs). BTW, I've read some more on the samba thread and I think I've done it similar to Metse's first suggestion: https://lists.samba.org/archive/samba-technical/2016-November/116997.html Regards.
On Tue, Feb 13, 2018 at 4:07 PM, Alan DeKok <aland@deployingradius.com> wrote:
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
The mapping I am interested at is of group-name to SID, which is relevant to *any* user and not related to what the AD-Group compare function actually does. I didn't figure yet how to use the cache module for that. Note that this cache will only miss if the group-name is changed, as that's what we cache, not if the user stops being a member (or if the group moves in the tree). So I think we can recommend long timeout by default.
On Tue, 2018-02-13 at 18:05 +0200, Isaac Boukris wrote:
On Tue, Feb 13, 2018 at 4:07 PM, Alan DeKok <aland@deployingradius.co m> wrote:
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
The mapping I am interested at is of group-name to SID, which is relevant to *any* user and not related to what the AD-Group compare function actually does. I didn't figure yet how to use the cache module for that.
I think winbindd already caches those mappings? Is so wbcCtxLookupSid / wbcCtxLookupSids and friends should be relatively fast (i.e. no network traffic unless needed). Though it does mean another call to winbindd, which needs the connection pool. Question is whether the added complexity of managing a cache in FreeRADIUS is worth it if there's already another cache on the same box anyway. -- Matthew
On Tue, Feb 13, 2018 at 6:13 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-02-13 at 18:05 +0200, Isaac Boukris wrote:
On Tue, Feb 13, 2018 at 4:07 PM, Alan DeKok <aland@deployingradius.co m> wrote:
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
The mapping I am interested at is of group-name to SID, which is relevant to *any* user and not related to what the AD-Group compare function actually does. I didn't figure yet how to use the cache module for that.
I think winbindd already caches those mappings? Is so wbcCtxLookupSid / wbcCtxLookupSids and friends should be relatively fast (i.e. no network traffic unless needed). Though it does mean another call to winbindd, which needs the connection pool.
Question is whether the added complexity of managing a cache in FreeRADIUS is worth it if there's already another cache on the same box anyway.
Good point, I'll look into it and run some tests. Thanks!
On Tue, Feb 13, 2018 at 6:29 PM, Isaac Boukris <iboukris@gmail.com> wrote:
On Tue, Feb 13, 2018 at 6:13 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-02-13 at 18:05 +0200, Isaac Boukris wrote:
On Tue, Feb 13, 2018 at 4:07 PM, Alan DeKok <aland@deployingradius.co m> wrote:
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
The mapping I am interested at is of group-name to SID, which is relevant to *any* user and not related to what the AD-Group compare function actually does. I didn't figure yet how to use the cache module for that.
I think winbindd already caches those mappings? Is so wbcCtxLookupSid / wbcCtxLookupSids and friends should be relatively fast (i.e. no network traffic unless needed). Though it does mean another call to winbindd, which needs the connection pool.
Question is whether the added complexity of managing a cache in FreeRADIUS is worth it if there's already another cache on the same box anyway.
Good point, I'll look into it and run some tests.
Actually, I am not so sure we want to rely on winbind's cache as there seem to be no easy way to configure it (seems indefinite). Also, I've ran some tests and had a look at the code, there seem to be no caching of name->sid in winbind (that is the result of wbcCtxLookupName), so we'll need a local cache. For other auth methods I suggest we call wbcCtxLookupUserSids(), add those to the request and continue processing normally. I'll update the code according and open a pull request.
Hi, On Tue, Feb 20, 2018 at 3:06 PM, Isaac Boukris <iboukris@gmail.com> wrote:
On Tue, Feb 13, 2018 at 6:29 PM, Isaac Boukris <iboukris@gmail.com> wrote:
On Tue, Feb 13, 2018 at 6:13 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-02-13 at 18:05 +0200, Isaac Boukris wrote:
On Tue, Feb 13, 2018 at 4:07 PM, Alan DeKok <aland@deployingradius.co m> wrote:
I'm now thinking on how to implement the caching of group-name to SID mapping with configurable timeout, ideally using existing interface - ideas welcome.
The "cache" module should be able to do that. My $0.02 is to just create the mappings, and let the rest of the policies decide what to cache (or not).
The mapping I am interested at is of group-name to SID, which is relevant to *any* user and not related to what the AD-Group compare function actually does. I didn't figure yet how to use the cache module for that.
I think winbindd already caches those mappings? Is so wbcCtxLookupSid / wbcCtxLookupSids and friends should be relatively fast (i.e. no network traffic unless needed). Though it does mean another call to winbindd, which needs the connection pool.
Question is whether the added complexity of managing a cache in FreeRADIUS is worth it if there's already another cache on the same box anyway.
Good point, I'll look into it and run some tests.
Actually, I am not so sure we want to rely on winbind's cache as there seem to be no easy way to configure it (seems indefinite). Also, I've ran some tests and had a look at the code, there seem to be no caching of name->sid in winbind (that is the result of wbcCtxLookupName), so we'll need a local cache.
For other auth methods I suggest we call wbcCtxLookupUserSids(), add those to the request and continue processing normally. I'll update the code according and open a pull request.
Just a quick update on this. The function wbcCtxLookupUserSids() doesn't really work as I thought, but I am still trying to figure out a proper solution for eap-tls use case (and the caching issue). I'll update asap (though it may take a while).
participants (3)
-
Alan DeKok -
Isaac Boukris -
Matthew Newton