Hey all! First off, sorry for the noob questions. I've been reading the docs and previous mailing posts, but I'm still a little unclear on some things and wanted to run something by the list first for a sanity check/to see if there's a better way of doing this. I store NASes in MySQL and user accounts in LDAP (if necessary, this can be changed to store NASes in LDAP as well). I want to only allow users to authenticate if they're coming from a specific NAS associated with their account. 1.) What would be the most appropriate attribute for this in LDAP? Accounts currently have the following objectClasses: account, extensibleObject, radiusprofile, simpleSecurityObject, top. I'm thinking radiusClientShortname (since this attribute wouldn't have a "meaningful" association for radiusprofile but is available for use via extensibleObject objectClass - I would store the NASes in a separate base DN from the users). 2.) Can I even use the ${shortname} macro in a raddb/mods-available/ldap:ldap{user{filter=}} context? I would *assume* so since the NAS handling is done before the authentication handling, but assumptions are a bad thing to operate off of. The unlang documentation indicates I can't use unlang in this context, which is fine since I can just incorporate it into the LDAP filter, but I'm having some difficulty finding which macros are available where. 3.) Is there a better way to do this (preferably without duplicating NAS entries)? Ideally without using huntgroups or the like, which is how I usually see this sort of functionality achieved. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On May 9, 2018, at 12:07 PM, brent s. <bts@square-r00t.net> wrote:
I've been reading the docs and previous mailing posts, but I'm still a little unclear on some things and wanted to run something by the list first for a sanity check/to see if there's a better way of doing this.
I store NASes in MySQL and user accounts in LDAP (if necessary, this can be changed to store NASes in LDAP as well). I want to only allow users to authenticate if they're coming from a specific NAS associated with their account.
1.) What would be the most appropriate attribute for this in LDAP? Accounts currently have the following objectClasses: account, extensibleObject, radiusprofile, simpleSecurityObject, top.
The best way is to put the users into an LDAP group, and then do LDAP group checking.
2.) Can I even use the ${shortname} macro in a raddb/mods-available/ldap:ldap{user{filter=}} context? I would *assume* so since the NAS handling is done before the authentication handling, but assumptions are a bad thing to operate off of. The unlang documentation indicates I can't use unlang in this context, which is fine since I can just incorporate it into the LDAP filter, but I'm having some difficulty finding which macros are available where.
The ${...} macros are expanded when the configuration file is read. And are static after that.
3.) Is there a better way to do this (preferably without duplicating NAS entries)? Ideally without using huntgroups or the like, which is how I usually see this sort of functionality achieved.
LDAP groups are by far and away the best solution. Alan DeKok.
Thanks, Alan! Responses inline. On 05/09/2018 12:28 PM, Alan DeKok wrote:
1.) What would be the most appropriate attribute for this in LDAP? Accounts currently have the following objectClasses: account, extensibleObject, radiusprofile, simpleSecurityObject, top.
The best way is to put the users into an LDAP group, and then do LDAP group checking.
Ah, okay. This makes sense.
2.) Can I even use the ${shortname} macro in a raddb/mods-available/ldap:ldap{user{filter=}} context? I would *assume* so since the NAS handling is done before the authentication handling, but assumptions are a bad thing to operate off of. The unlang documentation indicates I can't use unlang in this context, which is fine since I can just incorporate it into the LDAP filter, but I'm having some difficulty finding which macros are available where.
The ${...} macros are expanded when the configuration file is read. And are static after that.
Oops, sorry - I meant the %{...} dynamic string expansions. In other words, based on the above it would seem I can do this (pardon the linebreaking): :raddb/mods-available/ldap ... ldap { ... user { ... # ignore the linebreak; mail client is wrapping filter=(&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=ou=%{NAS-Identifier},ou=Groups,dc=domain,dc=tld)) ... } ... } ... correct?
3.) Is there a better way to do this (preferably without duplicating NAS entries)? Ideally without using huntgroups or the like, which is how I usually see this sort of functionality achieved.
LDAP groups are by far and away the best solution.
Looks like groups would need to be the way to go, yeah. The above, if correct, would also work with dynamic-clients as well, yes? -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On May 9, 2018, at 2:42 PM, brent s. <bts@square-r00t.net> wrote:
Oops, sorry - I meant the %{...} dynamic string expansions. In other words, based on the above it would seem I can do this (pardon the line breaking):
The filter is expanded dynamically. You can put anything you want in it, so long as the attribute exists.
filter=(&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=ou=%{NAS-Identifier},ou=Groups,dc=domain,dc=tld)) correct?
That should be fine.
3.) Is there a better way to do this (preferably without duplicating NAS entries)? Ideally without using huntgroups or the like, which is how I usually see this sort of functionality achieved.
LDAP groups are by far and away the best solution.
Looks like groups would need to be the way to go, yeah.
The above, if correct, would also work with dynamic-clients as well, yes?
No. Dynamic clients are only matched by source IP. You can't look at the packet contents. That's changed in v4. v4 supports connection-based clients. i.e. different shared secrets for each machine behind a NAT gateway. v4 isn't released yet, though. You can try it, and if it works, that's nice. But if anything goes wrong, we still recommend using v3. Alan DeKok.
On 05/09/2018 04:35 PM, Alan DeKok wrote:
On May 9, 2018, at 2:42 PM, brent s. <bts@square-r00t.net> wrote:
Oops, sorry - I meant the %{...} dynamic string expansions. In other words, based on the above it would seem I can do this (pardon the line breaking):
The filter is expanded dynamically. You can put anything you want in it, so long as the attribute exists.
filter=(&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=ou=%{NAS-Identifier},ou=Groups,dc=domain,dc=tld)) correct?
That should be fine.
3.) Is there a better way to do this (preferably without duplicating NAS entries)? Ideally without using huntgroups or the like, which is how I usually see this sort of functionality achieved.
LDAP groups are by far and away the best solution.
Looks like groups would need to be the way to go, yeah.
The above, if correct, would also work with dynamic-clients as well, yes?
No. Dynamic clients are only matched by source IP. You can't look at the packet contents.
That's changed in v4. v4 supports connection-based clients. i.e. different shared secrets for each machine behind a NAT gateway.
v4 isn't released yet, though. You can try it, and if it works, that's nice. But if anything goes wrong, we still recommend using v3.
Alan DeKok.
Thanks again, Alan. That answers all the questions I had. You've been a big help. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
participants (2)
-
Alan DeKok -
brent s.