freeradius 3.0.13 LDAP - reply custom Vendor Specific
Hi I have connected freeradius to freeIPA's ldap ( https://www.freeipa.org/page/Using_FreeIPA_and_FreeRadius_as_a_RADIUS_based_...). I try to authenticate IPMI server trough freeradius but it require two custom attributes (Vendor Specfic) ie for admin H=4 and I=4. How should I configure freeradius to reply for every request with custom above attributes (without adding them in the ldap schema) I found here http://wiki.freeradius.org/modules/Rlm_ldap that I should add for example: radiusReplyAttribute: Cisco-AVPair := "ip:addr-pool=dialin_pool". Unfortunately I completely dont know where in raddb/mod-avaliable/ldap should I place similar line. Any help would be very appreciated Regards, Paweł
On Thu, 2017-11-30 at 15:56 +0100, Paweł Cituk wrote:
I try to authenticate IPMI server trough freeradius but it require two custom attributes (Vendor Specfic) ie for admin H=4 and I=4.
How should I configure freeradius to reply for every request with custom above attributes (without adding them in the ldap schema)
Use unlang in the post-auth section to add reply attributes, e.g. update reply { Attribute-1 = "value1" Attribute-2 = "value2" } If the attributes aren't already in the supplied FreeRADIUS dictionary files then you'll need to add them to raddb/dictionary. -- Matthew
In dictionary I have added: ATTRIBUTE I 5003 string ATTRIBUTE H 5004 string And section in mods-available/ldap looks like this: # # Post-Auth can modify LDAP objects too # post-auth { update { description := "Authenticated at %S" } update reply { H = "4" I = "4" } } I run : radiusd -Xxxx and login using IPMI Thu Nov 30 16:28:37 2017 : Debug: rlm_ldap (ldap): Reserved connection (1) Thu Nov 30 16:28:37 2017 : Debug: (0) ldap: Login attempt by "user1" Thu Nov 30 16:28:37 2017 : Debug: (0) ldap: Using user DN from request "uid=user1,cn=users,cn=accounts,dc=company,dc=com" Thu Nov 30 16:28:37 2017 : Debug: (0) ldap: Waiting for bind result... Thu Nov 30 16:28:37 2017 : Debug: (0) ldap: Bind successful Thu Nov 30 16:28:37 2017 : Debug: (0) ldap: Bind as user "uid=user1,cn=users,cn=accounts,dc=company,dc=com" was successful Thu Nov 30 16:28:37 2017 : Debug: rlm_ldap (ldap): Released connection (1) Thu Nov 30 16:28:37 2017 : Debug: (0) modsingle[authenticate]: returned from ldap (rlm_ldap) Thu Nov 30 16:28:37 2017 : Debug: (0) [ldap] = ok Thu Nov 30 16:28:37 2017 : Debug: (0) } # Auth-Type LDAP = ok Thu Nov 30 16:28:37 2017 : Debug: (0) # Executing section post-auth from file /etc/raddb/sites-enabled/default Thu Nov 30 16:28:37 2017 : Debug: (0) post-auth { Thu Nov 30 16:28:37 2017 : Debug: (0) update { Thu Nov 30 16:28:37 2017 : Debug: (0) No attributes updated Thu Nov 30 16:28:37 2017 : Debug: (0) } # update = noop Thu Nov 30 16:28:37 2017 : Debug: (0) modsingle[post-auth]: calling exec (rlm_exec) Thu Nov 30 16:28:37 2017 : Debug: (0) modsingle[post-auth]: returned from exec (rlm_exec) Thu Nov 30 16:28:37 2017 : Debug: (0) [exec] = noop Thu Nov 30 16:28:37 2017 : Debug: (0) policy remove_reply_message_if_eap { Thu Nov 30 16:28:37 2017 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) { Thu Nov 30 16:28:37 2017 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE Thu Nov 30 16:28:37 2017 : Debug: (0) else { Thu Nov 30 16:28:37 2017 : Debug: (0) modsingle[post-auth]: calling noop (rlm_always) Thu Nov 30 16:28:37 2017 : Debug: (0) modsingle[post-auth]: returned from noop (rlm_always) Thu Nov 30 16:28:37 2017 : Debug: (0) [noop] = noop Thu Nov 30 16:28:37 2017 : Debug: (0) } # else = noop Thu Nov 30 16:28:37 2017 : Debug: (0) } # policy remove_reply_message_if_eap = noop Thu Nov 30 16:28:37 2017 : Debug: (0) } # post-auth = noop Thu Nov 30 16:28:37 2017 : Debug: (0) Sent Access-Accept Id 0 from 10.10.11.11:1812 to 10.10.12.95:2048 length 0 Thu Nov 30 16:28:37 2017 : Debug: (0) Finished request Thu Nov 30 16:28:37 2017 : Debug: Waking up in 4.9 seconds. Thu Nov 30 16:28:42 2017 : Debug: (0) Cleaning up request packet ID 0 with timestamp +11 Thu Nov 30 16:28:42 2017 : Info: Ready to process requests Should I see my custom attributes in this output? 2017-11-30 16:09 GMT+01:00 Matthew Newton <mcn@freeradius.org>:
On Thu, 2017-11-30 at 15:56 +0100, Paweł Cituk wrote:
I try to authenticate IPMI server trough freeradius but it require two custom attributes (Vendor Specfic) ie for admin H=4 and I=4.
How should I configure freeradius to reply for every request with custom above attributes (without adding them in the ldap schema)
Use unlang in the post-auth section to add reply attributes, e.g.
update reply { Attribute-1 = "value1" Attribute-2 = "value2" }
If the attributes aren't already in the supplied FreeRADIUS dictionary files then you'll need to add them to raddb/dictionary.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Nov 30, 2017, at 10:34 AM, Paweł Cituk <pawelcit@gmail.com> wrote:
In dictionary I have added: ATTRIBUTE I 5003 string ATTRIBUTE H 5004 string
Don't do that. For one, adding single-letter attribute names is bad. You have NO IDEA what they mean. Use descriptive names. It's much more productive. On top of that, the comments in raddb/dictionary tell you what numbers to use, and why. The comments DON'T say "use numbers in the 5000 range". And, the comments in raddb/dictionary tell you which attributes can go into a RADIUS packet, and which can't. The dictionary entries you added above are NOT vendor specific attributes. And, you can't magically invent attributes, send them to the client, and have the client understand them. You can only send attributes that the client understands. What attributes are understood by the client? Go read the client documentation to see. There are tens of thousands of RADIUS clients, from thousands of different vendors, and we have no idea what each client can do. You also said:
I try to authenticate IPMI server trough freeradius but it require two custom attributes (Vendor Specfic) ie for admin H=4 and I=4.
What does that mean? The link you posted to the freeipa.org page had *nothing* about "H=4" or "I=4". Alan DeKok.
H and I are attributes required by IPMI to distinguish admin user from readonly user. freeipa is used as a user database; 2017-11-30 16:42 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Nov 30, 2017, at 10:34 AM, Paweł Cituk <pawelcit@gmail.com> wrote:
In dictionary I have added: ATTRIBUTE I 5003 string ATTRIBUTE H 5004 string
Don't do that.
For one, adding single-letter attribute names is bad. You have NO IDEA what they mean. Use descriptive names. It's much more productive.
On top of that, the comments in raddb/dictionary tell you what numbers to use, and why. The comments DON'T say "use numbers in the 5000 range".
And, the comments in raddb/dictionary tell you which attributes can go into a RADIUS packet, and which can't.
The dictionary entries you added above are NOT vendor specific attributes.
And, you can't magically invent attributes, send them to the client, and have the client understand them. You can only send attributes that the client understands.
What attributes are understood by the client? Go read the client documentation to see. There are tens of thousands of RADIUS clients, from thousands of different vendors, and we have no idea what each client can do.
You also said:
I try to authenticate IPMI server trough freeradius but it require two custom attributes (Vendor Specfic) ie for admin H=4 and I=4.
What does that mean? The link you posted to the freeipa.org page had *nothing* about "H=4" or "I=4".
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Nov 30, 2017, at 10:48 AM, Paweł cit <pawelcit@gmail.com> wrote:
H and I are attributes required by IPMI to distinguish admin user from readonly user.
I think you didn't read my message. "H" and "I" are *NOT RADIUS ATTRIBUTES*. You CANNOT INVENT MAGIC NUMBERS FOR THEM IN RADIUS AND EXPECT IT TO WORK. Is that clear? What part of the FreeIPA documentation told you to edit the "dictionary" file and add those as attributes? Alan DEKok.
I have a feeling that you mistook Supermicro's IPMI with freeIPA. Am I right? freeradius is just using freeipa's user database. I try to configure freeradius to work with IPMI. My problem is similar to this: http://lists.freeradius.org/pipermail/freeradius-users/2015-October/080240.h... I still have no idea how to connect IPMI to freeradius. In Supermicro's documentation there's only: 2.2. Configuring User information #vi /etc/raddb/users Example: myuser Auth-Type :=Local, User-Password == “123456” Vendor-Specific = “H=4, I=4” testuser Auth-Type :=Local, User-Password == “654321” Vendor-Specific = “H=3, I=3” 2.3. Configuring Client information #vi /etc/raddb/client.conf Example: client 192.168.0.200 { secret = radiustest shortname = ikvmdevice client 192.168.0.100 { secret = radiustest shortname = osaka In my case difference is that I have user's in LDAP, not in file. 2017-11-30 16:53 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Nov 30, 2017, at 10:48 AM, Paweł cit <pawelcit@gmail.com> wrote:
H and I are attributes required by IPMI to distinguish admin user from readonly user.
I think you didn't read my message.
"H" and "I" are *NOT RADIUS ATTRIBUTES*. You CANNOT INVENT MAGIC NUMBERS FOR THEM IN RADIUS AND EXPECT IT TO WORK.
Is that clear?
What part of the FreeIPA documentation told you to edit the "dictionary" file and add those as attributes?
Alan DEKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Nov 30, 2017, at 11:17 AM, Paweł cit <pawelcit@gmail.com> wrote:
I have a feeling that you mistook Supermicro's IPMI with freeIPA. Am I right?
I have no idea what you're doing. I can only go by what you say. If what you say is confusing (and it is), then... that's to be expected.
freeradius is just using freeipa's user database. I try to configure freeradius to work with IPMI. My problem is similar to this: http://lists.freeradius.org/pipermail/freeradius-users/2015-October/080240.h... I still have no idea how to connect IPMI to freeradius. In Supermicro's documentation there's only:
2.2. Configuring User information #vi /etc/raddb/users
Example: myuser Auth-Type :=Local, User-Password == “123456” Vendor-Specific = “H=4, I=4”
Oh god, THAT shit again? I should find the SuperMicro people and slap them. That's a *stupid* thing to do, which violates all of the RADIUS RFCs. It's really quite simple then. You use THAT EXAMPLE to send the data back. You DON'T edit the dictionaries.
In my case difference is that I have user's in LDAP, not in file.
So you need to configure the attribute "Vendor-Specific" as an LDAP reply, with contents "H=4,I=4" The LDAP module documentation describes how to configure reply attributes. Follow that. If you can't send "Vendor-Specific" back as-is (and I think you can't), you will need to use raw attributes. i.e. use "Attr-26" as the attribute name, and a hex string as the contents. The hex string should be the hex version of the "H=4, I=4” string. e.g. Attr-26 = 0x48.... and convert the rest of the string to hex. Alan DeKok.
I try many possibilities but still no luck. In documentation: http://wiki.freeradius.org/modules/Rlm_ldap there is: in file raddb/mods-available/ldap put: For Example: radiusReplyAttribute: Cisco-AVPair := "ip:addr-pool=dialin_pool" So I try radiusReplyAttribute: Attr-26 := "0x483d342c20493d34" (with space between "bute: Attr" and without (both this gives error): update { control:Password-With-Header += 'userPassword' # control:NT-Password := 'ntPassword' reply:Reply-Message := 'radiusReplyMessage' radiusReplyAttribute: attr-26 := "0x483d342c20493d34" # reply:Tunnel-Type := 'radiusTunnelType' # reply:Tunnel-Medium-Type := 'radiusTunnelMediumType' # reply:Tunnel-Private-Group-ID := 'radiusTunnelPrivategroupId' # Where only a list is specified as the RADIUS attribute, # the value of the LDAP attribute is parsed as a valuepair # in the same format as the 'valuepair_attribute' (above). control: += 'radiusControlAttribute' request: += 'radiusRequestAttribute' reply: += 'radiusReplyAttribute' } I also tried: post-auth { update { description := "Authenticated at %S" reply:Attr-26 := "0x483d342c20493d34" } } or post-auth { update { description := "Authenticated at %S" } reply { Attr-26 := "0x483d342c20493d34" } } doest work either :( 2017-11-30 17:39 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Nov 30, 2017, at 11:17 AM, Paweł cit <pawelcit@gmail.com> wrote:
I have a feeling that you mistook Supermicro's IPMI with freeIPA. Am I right?
I have no idea what you're doing. I can only go by what you say. If what you say is confusing (and it is), then... that's to be expected.
freeradius is just using freeipa's user database. I try to configure freeradius to work with IPMI. My problem is similar to this: http://lists.freeradius.org/pipermail/freeradius-users/ 2015-October/080240.html I still have no idea how to connect IPMI to freeradius. In Supermicro's documentation there's only:
2.2. Configuring User information #vi /etc/raddb/users
Example: myuser Auth-Type :=Local, User-Password == “123456” Vendor-Specific = “H=4, I=4”
Oh god, THAT shit again? I should find the SuperMicro people and slap them. That's a *stupid* thing to do, which violates all of the RADIUS RFCs.
It's really quite simple then. You use THAT EXAMPLE to send the data back. You DON'T edit the dictionaries.
In my case difference is that I have user's in LDAP, not in file.
So you need to configure the attribute "Vendor-Specific" as an LDAP reply, with contents "H=4,I=4"
The LDAP module documentation describes how to configure reply attributes. Follow that.
If you can't send "Vendor-Specific" back as-is (and I think you can't), you will need to use raw attributes.
i.e. use "Attr-26" as the attribute name, and a hex string as the contents. The hex string should be the hex version of the "H=4, I=4” string.
e.g. Attr-26 = 0x48....
and convert the rest of the string to hex.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Nov 30, 2017, at 12:08 PM, Paweł cit <pawelcit@gmail.com> wrote:
I try many possibilities but still no luck. In documentation: http://wiki.freeradius.org/modules/Rlm_ldap there is: in file raddb/mods-available/ldap put:
For Example: radiusReplyAttribute: Cisco-AVPair := "ip:addr-pool=dialin_pool"
That means you put the Cisco-AVPair into LDAP...
So I try radiusReplyAttribute: Attr-26 := "0x483d342c20493d34" (with space between "bute: Attr" and without (both this gives error): update { control:Password-With-Header += 'userPassword' # control:NT-Password := 'ntPassword' reply:Reply-Message := 'radiusReplyMessage' radiusReplyAttribute: attr-26 := "0x483d342c20493d34"
i.e. you didn't read the comments in the "ldap" module configuration which described what that section does, and how it works.
I also tried:
post-auth { update { description := "Authenticated at %S"
Is "description" a RADIUS attribute? No. Why do you think that adding random things to random configuration files will do what you want? Do you believe that FreeRADIUS can read your mind?
doest work either :(
See the FAQ for "it doesn't work". The problem here goes deeper than just configuring FreeRADIUS. You're lost, and are *not* reading the documentation. Instead, you're just trying random things in the hope that they will magically work. Don't do that. You need to *understand* things before editing them. And the documentation *does* help with understanding. I can't help you if you don't read it. Alan DeKok.
participants (4)
-
Alan DeKok -
Matthew Newton -
Paweł cit -
Paweł Cituk