Understanding dynamic radiusClients in openldap
Hello, Looking here: https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/schemas/ldap... And here: https://github.com/FreeRADIUS/freeradius-server/blob/9e6d1e60aa2e829a186b873... Im trying to create a client for a NAS in my ldap service dn: cn=xx:xx:xx:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: radiusClient cn: xx:xx:xx:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: name-of-nas radiusClientSecret: asdfasdfasdfasdf123123asdf But I get: ldap_add: Object class violation (65) additional info: attribute 'cn' not allowed Which makes sense since the schema does not have `cn` .... so trying to understand how to add a radiusClient. I've also tried instead of cn, ou but same output. Does anyone have a sample ldif? Looking at the dynamic-clients file, it says about setting the "location" attribute but I don't see it... Any input is much appreciated! Thank you, Dave
On Feb 3, 2022, at 2:57 PM, Dave Macias <davama@gmail.com> wrote:
Looking here: https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/schemas/ldap...
And here:
https://github.com/FreeRADIUS/freeradius-server/blob/9e6d1e60aa2e829a186b873...
As a minor note, don't use the "master" branch. It's not yet released. It may or may not work on a daily basis. Use v3.0.x instead.
Im trying to create a client for a NAS in my ldap service
dn: cn=xx:xx:xx:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: radiusClient cn: xx:xx:xx:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: name-of-nas radiusClientSecret: asdfasdfasdfasdf123123asdf
But I get: ldap_add: Object class violation (65) additional info: attribute 'cn' not allowed
Which makes sense since the schema does not have `cn` .... so trying to understand how to add a radiusClient. I've also tried instead of cn, ou but same output. Does anyone have a sample ldif?
Looking at the dynamic-clients file, it says about setting the "location" attribute but I don't see it...
To be perfectly honest, I don't think anyone has looked at that in a while. "git annotate" says that the examples are from 2011. I can't recall anyone else using it since then. So if you figure it out, we're happy to accept a patch. Until then, we can add it to the list of "todo" items. Alan DeKok.
On 2/3/22 20:57, Dave Macias wrote:
Im trying to create a client for a NAS in my ldap service
dn: cn=xx:xx:xx:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: radiusClient cn: xx:xx:xx:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: name-of-nas radiusClientSecret: asdfasdfasdfasdf123123asdf
But I get: ldap_add: Object class violation (65) additional info: attribute 'cn' not allowed
Object class radiusClient is not defined to allow attribute 'cn'. You probably want to combine that with another AUXILIARY object class. I can only guess what 'cn' is supposed to store in your example. An IPv6 address? Or MAC address? Depending on your particular needs combining radiusClient with AUXILIARY object class(es) ipHost and/or ieee802Device might be what you're looking for. Look at the MUST attributes of those object classes though. Ciao, Michael. P.S.: A schema-aware LDAP client with decent schema browser might lead you more quickly into the right direction. Being the author of https://www.web2ldap.de/ I'm biased of course. P.P.S.: Doing something similar is on my Æ-DIR to-do list for quite a while...
Thank you both for the quick responses!! master vs v3.X noted! Object class radiusClient is not defined to allow attribute 'cn'. You
probably want to combine that with another AUXILIARY object class
Good point! I can only guess what 'cn' is supposed to store in your example. An IPv6
address? Or MAC address?
The ipv6 address, since if using flat files for dynamic clients, the file should be the <ipv6>.conf to my understanding... So I supposed since my clients will be defined in ldap, it should be cn=<ipv6> because I see this in the dynamic-clients file: https://github.com/FreeRADIUS/freeradius-server/blob/4f78232d924261dc0374f75...
Depending on your particular needs combining radiusClient with AUXILIARY object class(es) ipHost and/or ieee802Device might be what you're looking for. Look at the MUST attributes of those object classes though.
I'll give this a try. Appreciate the input!
Ciao, Michael.
P.S.: A schema-aware LDAP client with decent schema browser might lead you more quickly into the right direction. Being the author of https://www.web2ldap.de/ I'm biased of course.
Ha! This is very interesting. Thank you Alan and Michael again for the input! I will report back for posterity Best, Dave
Update: added ldif client as so: dn: cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: top objectClass: radiusClient objectClass: ipHost cn: xxx:xx:x:x:x:xxff:fe57:cd00 ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: my-nas-name radiusClientSecret: mysecret Not a fan of the repeated IP but just testing for now. Next will be making it work as a dynamic client, but that's a separate thread. Thank you again for the awesome support! Best, Dave On Thu, Feb 3, 2022 at 3:52 PM Dave Macias <davama@gmail.com> wrote:
Thank you both for the quick responses!!
master vs v3.X noted!
Object class radiusClient is not defined to allow attribute 'cn'. You
probably want to combine that with another AUXILIARY object class
Good point!
I can only guess what 'cn' is supposed to store in your example. An IPv6
address? Or MAC address?
The ipv6 address, since if using flat files for dynamic clients, the file should be the <ipv6>.conf to my understanding... So I supposed since my clients will be defined in ldap, it should be cn=<ipv6> because I see this in the dynamic-clients file: https://github.com/FreeRADIUS/freeradius-server/blob/4f78232d924261dc0374f75...
Depending on your particular needs combining radiusClient with AUXILIARY object class(es) ipHost and/or ieee802Device might be what you're looking for. Look at the MUST attributes of those object classes though.
I'll give this a try. Appreciate the input!
Ciao, Michael.
P.S.: A schema-aware LDAP client with decent schema browser might lead you more quickly into the right direction. Being the author of https://www.web2ldap.de/ I'm biased of course.
Ha! This is very interesting.
Thank you Alan and Michael again for the input!
I will report back for posterity
Best, Dave
On 2/4/22 18:13, Dave Macias wrote:
Update:
added ldif client as so:
dn: cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: top objectClass: radiusClient objectClass: ipHost cn: xxx:xx:x:x:x:xxff:fe57:cd00 ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: my-nas-name radiusClientSecret: mysecret
Not a fan of the repeated IP but just testing for now.
You can use OpenLDAP's slapo-constraint with set-based constraints to ensure consistency across attributes to avoid errors when maintaining the entries. This example ensures that cn and ipHostNumber contain the same values (not tested and probably sub-optimal line-wrapping): overlay constraint constraint_attribute cn,ipHostNumber set "this/cn & this/ipHostNumber" restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)" Probably you want to constrain these attrs to single value even though they are declared as multi-valued in the schema: constraint_attribute cn count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)" constraint_attribute ipHostNumber count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)" See also slapo-constraint(5): https://www.openldap.org/software/man.cgi?query=slapo-constraint These OpenLDAP details are probably considered off-topic here. You're welcome to ask for more on openldap-technical mailing list. Ciao, Michael.
Is there a reason you need a CN other than convention? radiusClientIdentifier looks like an appropriate attribute to use in the DN. -Arran
On Feb 4, 2022, at 1:13 PM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 2/4/22 18:13, Dave Macias wrote:
Update: added ldif client as so: dn: cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: top objectClass: radiusClient objectClass: ipHost cn: xxx:xx:x:x:x:xxff:fe57:cd00 ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: my-nas-name radiusClientSecret: mysecret Not a fan of the repeated IP but just testing for now.
You can use OpenLDAP's slapo-constraint with set-based constraints to ensure consistency across attributes to avoid errors when maintaining the entries.
This example ensures that cn and ipHostNumber contain the same values (not tested and probably sub-optimal line-wrapping):
overlay constraint
constraint_attribute cn,ipHostNumber set "this/cn & this/ipHostNumber" restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
Probably you want to constrain these attrs to single value even though they are declared as multi-valued in the schema:
constraint_attribute cn count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
constraint_attribute ipHostNumber count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
See also slapo-constraint(5):
https://www.openldap.org/software/man.cgi?query=slapo-constraint
These OpenLDAP details are probably considered off-topic here. You're welcome to ask for more on openldap-technical mailing list.
Ciao, Michael. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hmm, thats an interesting idea… Was using cn because thats what i saw in the dynamic clients config…doesnt have to be cn Will give it a try and report. Thank you for the tip! On Feb 8, 2022, 5:23 PM -0600, Arran Cudbard-Bell <a.cudbardb@freeradius.org>, wrote:
Is there a reason you need a CN other than convention? radiusClientIdentifier looks like an appropriate attribute to use in the DN.
-Arran
On Feb 4, 2022, at 1:13 PM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 2/4/22 18:13, Dave Macias wrote:
Update: added ldif client as so: dn: cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: top objectClass: radiusClient objectClass: ipHost cn: xxx:xx:x:x:x:xxff:fe57:cd00 ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: my-nas-name radiusClientSecret: mysecret Not a fan of the repeated IP but just testing for now.
You can use OpenLDAP's slapo-constraint with set-based constraints to ensure consistency across attributes to avoid errors when maintaining the entries.
This example ensures that cn and ipHostNumber contain the same values (not tested and probably sub-optimal line-wrapping):
overlay constraint
constraint_attribute cn,ipHostNumber set "this/cn & this/ipHostNumber" restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
Probably you want to constrain these attrs to single value even though they are declared as multi-valued in the schema:
constraint_attribute cn count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
constraint_attribute ipHostNumber count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
See also slapo-constraint(5):
https://www.openldap.org/software/man.cgi?query=slapo-constraint
These OpenLDAP details are probably considered off-topic here. You're welcome to ask for more on openldap-technical mailing list.
Ciao, Michael. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 2/9/22 00:23, Arran Cudbard-Bell wrote:
Is there a reason you need a CN other than convention? radiusClientIdentifier looks like an appropriate attribute to use in the DN.
Object class 'ipHost' requires 'cn'. So the best solution would be a custom object class. But I did explain that because I did not want to flood this mailing list with LDAP schema discussion too much. Ciao, Michael.
On Feb 4, 2022, at 1:13 PM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 2/4/22 18:13, Dave Macias wrote:
Update: added ldif client as so: dn: cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net objectClass: top objectClass: radiusClient objectClass: ipHost cn: xxx:xx:x:x:x:xxff:fe57:cd00 ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00 radiusClientShortname: location1 radiusClientIdentifier: my-nas-name radiusClientSecret: mysecret Not a fan of the repeated IP but just testing for now.
You can use OpenLDAP's slapo-constraint with set-based constraints to ensure consistency across attributes to avoid errors when maintaining the entries.
This example ensures that cn and ipHostNumber contain the same values (not tested and probably sub-optimal line-wrapping):
overlay constraint
constraint_attribute cn,ipHostNumber set "this/cn & this/ipHostNumber" restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
Probably you want to constrain these attrs to single value even though they are declared as multi-valued in the schema:
constraint_attribute cn count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
constraint_attribute ipHostNumber count 1 restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
See also slapo-constraint(5):
https://www.openldap.org/software/man.cgi?query=slapo-constraint
These OpenLDAP details are probably considered off-topic here. You're welcome to ask for more on openldap-technical mailing list.
Ciao, Michael.
Just to update:
Arran,
I was able to use just radiusdClientIdentifier but with this ldap object we
lose having the hostname since radiusClientShortname is set to location.
dn: radiusClientIdentifier=2xx:xx:xx,ou=clients,ou=radius,dc=datacom,dc=net
objectClass: radiusClient
radiusClientComment: USA-location
radiusClientShortname: hostnameofclient
radiusClientSecret: blabla
radiusClientIdentifier: 2xx:xx:xx
Yes, I tried radiusClientComment but there is no FreeRadius-Client-Comment
that I can use to pass to the python module
if
("%{ldap:ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address}))}")
{
update control {
&FreeRADIUS-Client-IPv6-Address = "%{Packet-Src-IPv6-Address}"
&FreeRADIUS-Client-Shortname =
"%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientShortname?}"
&FreeRADIUS-Client-Secret =
"%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientSecret?}"
}
}
So having it with cn is more useful to us since we can get the data and
pass it to the python module.
Hope this made sense.
Thank you for the awesome support!
On Wed, Feb 9, 2022 at 6:01 AM Michael Ströder via Freeradius-Users <
freeradius-users@lists.freeradius.org> wrote:
> On 2/9/22 00:23, Arran Cudbard-Bell wrote:
> > Is there a reason you need a CN other than convention?
> radiusClientIdentifier looks like an appropriate attribute to use in the DN.
>
> Object class 'ipHost' requires 'cn'. So the best solution would be a
> custom object class.
>
> But I did explain that because I did not want to flood this mailing list
> with LDAP schema discussion too much.
>
> Ciao, Michael.
>
> >> On Feb 4, 2022, at 1:13 PM, Michael Ströder via Freeradius-Users <
> freeradius-users@lists.freeradius.org> wrote:
> >>
> >> On 2/4/22 18:13, Dave Macias wrote:
> >>> Update:
> >>> added ldif client as so:
> >>> dn:
> cn=xxx:xx:x:x:x:xxff:fe57:cd00,ou=clients,ou=radius,dc=datacom,dc=net
> >>> objectClass: top
> >>> objectClass: radiusClient
> >>> objectClass: ipHost
> >>> cn: xxx:xx:x:x:x:xxff:fe57:cd00
> >>> ipHostNumber: xxx:xx:x:x:x:xxff:fe57:cd00
> >>> radiusClientShortname: location1
> >>> radiusClientIdentifier: my-nas-name
> >>> radiusClientSecret: mysecret
> >>> Not a fan of the repeated IP but just testing for now.
> >>
> >> You can use OpenLDAP's slapo-constraint with set-based constraints to
> ensure consistency across attributes to avoid errors when maintaining the
> entries.
> >>
> >> This example ensures that cn and ipHostNumber contain the same values
> (not tested and probably sub-optimal line-wrapping):
> >>
> >> overlay constraint
> >>
> >> constraint_attribute cn,ipHostNumber
> >> set "this/cn & this/ipHostNumber"
> restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
> >>
> >> Probably you want to constrain these attrs to single value even though
> they are declared as multi-valued in the schema:
> >>
> >> constraint_attribute cn count 1
> restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
> >>
> >> constraint_attribute ipHostNumber count 1
> restrict="ldap:///dc=datacom,dc=net??sub?(objectClass=radiusClient)"
> >>
> >> See also slapo-constraint(5):
> >>
> >> https://www.openldap.org/software/man.cgi?query=slapo-constraint
> >>
> >> These OpenLDAP details are probably considered off-topic here. You're
> welcome to ask for more on openldap-technical mailing list.
> >>
> >> Ciao, Michael.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
On 2/22/22 19:23, Dave Macias wrote:
if ("%{ldap:ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address}))}") { update control { &FreeRADIUS-Client-IPv6-Address = "%{Packet-Src-IPv6-Address}" &FreeRADIUS-Client-Shortname = "%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientShortname?}" &FreeRADIUS-Client-Secret = "%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientSecret?}" } }
Because I want to add RADIUS client management to my Æ-DIR I'd like to know how many LDAP search requests are caused by the above. Could you please have a look at your logs? Ciao, Michael.
On Feb 22, 2022, at 1:30 PM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 2/22/22 19:23, Dave Macias wrote:
if ("%{ldap:ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address}))}") { update control { &FreeRADIUS-Client-IPv6-Address = "%{Packet-Src-IPv6-Address}" &FreeRADIUS-Client-Shortname = "%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientShortname?}" &FreeRADIUS-Client-Secret = "%{ldap:ldap:///cn=%{Packet-Src-IPv6-Address},ou=clients,ou=radius,dc=datacom,dc=net?radiusClientSecret?}" } }
Because I want to add RADIUS client management to my Æ-DIR I'd like to know how many LDAP search requests are caused by the above. Could you please have a look at your logs?
At least three. It's better to use the map keyword... I think that made it into v3.0.x. If it's there it'll be something like: map ldap "%{ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address})}" { &control:FreeRADIUS-Client-IPv6-Address = cn &control:FreeRADIUS-Client-Shortname = radiusClientShortname &control:FreeRADIUS-Client-Secret = radiusClientSecret } That picks out the fields from a single search result. -Arran
If it's there it'll be something like:
map ldap "%{ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address})}" { &control:FreeRADIUS-Client-IPv6-Address = cn &control:FreeRADIUS-Client-Shortname = radiusClientShortname &control:FreeRADIUS-Client-Secret = radiusClientSecret }
That picks out the fields from a single search result.
that is soo cool! let me give that a shot! thank you!! @Michael Ströder <michael@stroeder.com> without map these are the logs: Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SRCH base="ou=radius,dc=datacom,dc=net" scope=2 deref=0 filter="(&(objectClass=radiusClient)(cn=<redactedipv6>))" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SRCH attr=cn Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000049 etime=0.000346 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SRCH attr=radiusClientShortname Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000017 etime=0.000297 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SRCH attr=radiusClientSecret Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.000287 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1426 op=1 SRCH base="dc=datacom,dc=net" scope=2 deref=0 filter="(uid=myusername)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1426 op=1 SRCH attr=userPassword radiusControlAttribute radiusRequestAttribute radiusReplyAttribute Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1426 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.346607 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 fd=20 ACCEPT from IP=[::1]:38854 (IP=[::]:389) Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 BIND dn="cn=authuser,dc=datacom,dc=net" method=128 Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 BIND dn="cn=authuser,dc=datacom,dc=net" mech=SIMPLE bind_ssf=0 ssf=0 Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 RESULT tag=97 err=0 qtime=0.000017 etime=0.011889 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SRCH base="ou=radius,dc=datacom,dc=net" scope=2 deref=0 filter="(&(objectClass=radiusClient)(cn=<redactedipv6>))" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SRCH attr=cn Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000800 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SRCH attr=radiusClientShortname Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000025 etime=0.000312 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1423 op=2 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1423 op=2 SRCH attr=radiusClientSecret
Arran, i tried your map as so: if ("%{ldap:ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address}))}") { map ldap "%{ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address}}}" { &control:FreeRADIUS-Client-IPv6-Address = cn &control:FreeRADIUS-Client-Shortname = radiusClientShortname &control:FreeRADIUS-Client-Secret = radiusClientSecret } } but radiusd -X errors out : including configuration file /etc/raddb/sites-enabled/dynamic-clients /etc/raddb/sites-enabled/dynamic-clients[107]: Expecting section start brace '{' after "map ldap" Errors reading or parsing /etc/raddb/radiusd.conf Using: [root@openldap1-lab ~]# rpm -qa | grep -i freer freeradius-rest-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 freeradius-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 freeradius-utils-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 freeradius-doc-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 freeradius-ldap-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 python3-freeradius-3.0.20-11.module+el8.5.0+730+ecaca518.x86_64 I put the previous block which I had posted and radiusd -X runs fine Am I doing something wrong? Thank you! On Tue, Feb 22, 2022 at 2:17 PM Dave Macias <davama@gmail.com> wrote:
If it's there it'll be something like:
map ldap "%{ldap:///ou=radius,dc=datacom,dc=net?cn?sub?(&(objectClass=radiusClient)(cn=%{Packet-Src-IPv6-Address})}" { &control:FreeRADIUS-Client-IPv6-Address = cn &control:FreeRADIUS-Client-Shortname = radiusClientShortname &control:FreeRADIUS-Client-Secret = radiusClientSecret }
That picks out the fields from a single search result.
that is soo cool! let me give that a shot! thank you!!
@Michael Ströder <michael@stroeder.com>
without map these are the logs: Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SRCH base="ou=radius,dc=datacom,dc=net" scope=2 deref=0 filter="(&(objectClass=radiusClient)(cn=<redactedipv6>))" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SRCH attr=cn Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1423 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000049 etime=0.000346 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SRCH attr=radiusClientShortname Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1424 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000017 etime=0.000297 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SRCH attr=radiusClientSecret Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1425 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.000287 nentries=1 text= Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1426 op=1 SRCH base="dc=datacom,dc=net" scope=2 deref=0 filter="(uid=myusername)" Feb 22 14:12:52 openldap1-lab slapd[36643]: conn=1426 op=1 SRCH attr=userPassword radiusControlAttribute radiusRequestAttribute radiusReplyAttribute Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1426 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.346607 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 fd=20 ACCEPT from IP=[::1]:38854 (IP=[::]:389) Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 BIND dn="cn=authuser,dc=datacom,dc=net" method=128 Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 BIND dn="cn=authuser,dc=datacom,dc=net" mech=SIMPLE bind_ssf=0 ssf=0 Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1428 op=0 RESULT tag=97 err=0 qtime=0.000017 etime=0.011889 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SRCH base="ou=radius,dc=datacom,dc=net" scope=2 deref=0 filter="(&(objectClass=radiusClient)(cn=<redactedipv6>))" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SRCH attr=cn Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1422 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000800 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SRCH attr=radiusClientShortname Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1427 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000025 etime=0.000312 nentries=1 text= Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1423 op=2 SRCH base="cn=<redactedipv6>,ou=clients,ou=radius,dc=datacom,dc=net" scope=0 deref=0 filter="(objectClass=*)" Feb 22 14:12:53 openldap1-lab slapd[36643]: conn=1423 op=2 SRCH attr=radiusClientSecret
Thank you Alan for the input Looking at /etc/raddb/mods-enabled/ldap I see a client section client { base_dn = "${..base_dn}" filter = '(objectClass=radiusClient)' template { } attribute { ipaddr = 'radiusClientIdentifier' secret = 'radiusClientSecret' } } Is this relevant to what I'm trying to do? Im assuming I should update it to something like: base_dn= "ou=radius,${..base_dn}" scope = 'sub' attribute { hostname = 'radiusClientIdentifier' secret = 'radiusClientSecret' shortname = 'radiusClientShortname' } Assuming this is relevant, how could I correlate the new attributes to FreeRADIUS-Client-Blah within my dynamic-clients site? Thank you On Tue, Feb 22, 2022 at 2:54 PM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 22, 2022, at 2:29 PM, Dave Macias <davama@gmail.com> wrote:
Arran,
i tried your map as so:
"map" isn't in v3. It's only in v4.
v3 has the "sql_map" module, which only works for SQL. It should be possible to create an "ldap_map" module to do something similar.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 22, 2022, at 3:45 PM, Dave Macias <davama@gmail.com> wrote:
Looking at /etc/raddb/mods-enabled/ldap
I see a client section
client {
There's no need to post the default configuration files to the list. We've seen them already.
Is this relevant to what I'm trying to do?
It can load clients when the server starts. It can't load clients dynamically. Alan DeKok.
There's no need to post the default configuration files to the list. We've seen them already.
Is this relevant to what I'm trying to do?
It can load clients when the server starts. It can't load clients dynamically.
Understood thank you for the input! So I guess under V3 using the non-map way is the way to go for dynamic clients in ldap. Thank you again
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Dave Macias -
Michael Ströder