FreeRADIUS 3 LDAP Questions
Hello list members, I am migrating here from FreeRADIUS v2 to v3 and have some questions regarding the ldap module. As I understand everyone has to do the LDAP Attribute Mapping manually: - It would be much easier if the old ldap.attrmap would be translated already, maybe commented. - All checkItems have to defined with "control: ... := ..."? valuepair_attribute - Can I define multiple valuepair attributes? I just want radiusCheckItem and radiusReplyItem By default there are no hardcoded attribute mappings? Our servers here just asking a read-only ldap server. The new accounting options of the ldap module need to write to ldap. - Would it be sufficient just to comment the whole accounting and post-auth section if we do not need them? Kind regards, Tobias Hachmer
On 26 Nov 2013, at 06:56, Hachmer, Tobias <Tobias.Hachmer@stadt-frankfurt.de> wrote:
Hello list members,
I am migrating here from FreeRADIUS v2 to v3 and have some questions regarding the ldap module.
As I understand everyone has to do the LDAP Attribute Mapping manually: - It would be much easier if the old ldap.attrmap would be translated already, maybe commented.
Feel free to write a perl script to translate it into an update stanza.
- All checkItems have to defined with “control: … := …”?
or request: or reply: and it will default to request.
valuepair_attribute - Can I define multiple valuepair attributes? I just want radiusCheckItem and radiusReplyItem
No, and they wouldn't operate how you expect anyway. They would both go into the request list. Again, a migration script might be useful.
By default there are no hardcoded attribute mappings?
Correct. Though LDAP-User-DN will usually be populated.
Our servers here just asking a read-only ldap server. The new accounting options of the ldap module need to write to ldap. - Would it be sufficient just to comment the whole accounting and post-auth section if we do not need them?
Correct, or, just don't list LDAP in Post-Auth or Accounting... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hello Arran, thanks for your answer! -----Ursprüngliche Nachricht----- Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org [mailto:freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org] Im Auftrag von Arran Cudbard-Bell Gesendet: Dienstag, 26. November 2013 08:30 An: FreeRadius users mailing list Betreff: Re: FreeRADIUS 3 LDAP Questions On 26 Nov 2013, at 06:56, Hachmer, Tobias <Tobias.Hachmer@stadt-frankfurt.de> wrote:
As I understand everyone has to do the LDAP Attribute Mapping manually: - It would be much easier if the old ldap.attrmap would be translated already, maybe commented. Feel free to write a perl script to translate it into an update stanza.
I was afraid the answer would be like this. I just assume that there are a lot of systems out there using the freeradius provided ldap schema. Therefore I also assumed that this mapping is already done as it was in v2. But I know, it's open source, so somebody has to do this.
- All checkItems have to defined with "control: . := ."? or request: or reply: and it will default to request.
Thanks for the hint!
valuepair_attribute - Can I define multiple valuepair attributes? I just want radiusCheckItem and radiusReplyItem No, and they wouldn't operate how you expect anyway. They would both go into the request list. Again, a migration script might be useful.
Yeah, in my tests I recognized there are problem with some operators, like: (0) ERROR: ldap : Invalid list qualifier "Aruba-User-Role :" (0) WARNING: ldap : Failed parsing 'radiusReplyItem' value "Aruba-User-Role := "root"" as valuepair, skipping... Could you please clarify here how this works and how could I translate this in a correct way from: checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem This is very important. I don't want to define a ldap attribute for each VSA. Thanks in advance, Tobias Hachmer
As I understand everyone has to do the LDAP Attribute Mapping manually: - It would be much easier if the old ldap.attrmap would be translated already, maybe commented. Feel free to write a perl script to translate it into an update stanza.
I was afraid the answer would be like this. I just assume that there are a lot of systems out there using the freeradius provided ldap schema. Therefore I also assumed that this mapping is already done as it was in v2. But I know, it's open source, so somebody has to do this.
:)
- All checkItems have to defined with "control: . := ."? or request: or reply: and it will default to request.
Thanks for the hint!
valuepair_attribute - Can I define multiple valuepair attributes? I just want radiusCheckItem and radiusReplyItem No, and they wouldn't operate how you expect anyway. They would both go into the request list. Again, a migration script might be useful.
Yeah, in my tests I recognized there are problem with some operators, like: (0) ERROR: ldap : Invalid list qualifier "Aruba-User-Role :" (0) WARNING: ldap : Failed parsing 'radiusReplyItem' value "Aruba-User-Role := "root"" as valuepair, skipping...
Could you please clarify here how this works and how could I translate this in a correct way from:
Hm. That should be fixed, it shouldn't *require* list qualifiers. I'll take a look.
checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem
This is very important. I don't want to define a ldap attribute for each VSA.
All check items should be modified to include the 'control:' list qualifier, all replyItems should be modified to include the 'reply:' list qualifier. All generic RADIUS attributes should be stored in the same LDAP attribute. Slight correction to what I said earlier, you can actually use any list qualifier that you'd use in an update section. I think it even takes request qualifiers (outer.) too. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hello Arran, ________________________________________ Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org [freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org]" im Auftrag von "Arran Cudbard-Bell [a.cudbardb@freeradius.org] Gesendet: Dienstag, 26. November 2013 13:58 An: FreeRadius users mailing list Betreff: Re: FreeRADIUS 3 LDAP Questions
Yeah, in my tests I recognized there are problem with some operators, like: (0) ERROR: ldap : Invalid list qualifier "Aruba-User-Role :" (0) WARNING: ldap : Failed parsing 'radiusReplyItem' value "Aruba-User-Role := "root"" as valuepair, skipping... Hm. That should be fixed, it shouldn't *require* list qualifiers. I'll take a look.
Ok, do you take care about this issue or do I have to create an issue on github?
checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem This is very important. I don't want to define a ldap attribute for each VSA. All check items should be modified to include the 'control:' list qualifier, all replyItems should be modified to include the 'reply:' list qualifier. All generic RADIUS attributes should be stored in the same LDAP attribute. Slight correction to what I said earlier, you can actually use any list qualifier that you'd use in an update section. I think it even takes request qualifiers (outer.) too.
Ahh, I think I have got it now. The list qualifier has to be part of the ldap attribute value. Well, this is quite good. For this it might be useful to get rid of the ldap attributes "radiusCheckItem" and "radiusReplyItem" in order to use a new one like e.g. "radiusGenericItem" in the freeradius ldap schema. Thanks for clarification, Arran! Regards, Tobias Hachmer
Hm. That should be fixed, it shouldn't *require* list qualifiers. I'll take a look.
Ok, do you take care about this issue or do I have to create an issue on github?
Just testing the code now...
checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem This is very important. I don't want to define a ldap attribute for each VSA. All check items should be modified to include the 'control:' list qualifier, all replyItems should be modified to include the 'reply:' list qualifier. All generic RADIUS attributes should be stored in the same LDAP attribute. Slight correction to what I said earlier, you can actually use any list qualifier that you'd use in an update section. I think it even takes request qualifiers (outer.) too.
Ahh, I think I have got it now. The list qualifier has to be part of the ldap attribute value. Well, this is quite good. For this it might be useful to get rid of the ldap attributes "radiusCheckItem" and "radiusReplyItem" in order to use a new one like e.g. "radiusGenericItem" in the freeradius ldap schema.
That was the idea behind it. I've just fixed the code. It now takes a very similar codepath to a normal update block, which means in addition to request qualifiers and list qualifiers it will also now support list to list copies (request: += &reply:), and the crazy multi VP exec logic where you can do stuff like: request: += `<exec script which returns lots of VPs` Not that I ever recommend using that... It's just nice to be consistent. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hello Arran, -----Ursprüngliche Nachricht----- Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org [mailto:freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org] Im Auftrag von Arran Cudbard-Bell Gesendet: Dienstag, 26. November 2013 17:45 An: FreeRadius users mailing list Betreff: Re: FreeRADIUS 3 LDAP Questions
Ok, do you take care about this issue or do I have to create an issue on github? Just testing the code now...
Thanks for the fix. This is working now as expected, here. For the LDAP generic attribute I used 'radiusVSA' Regards, Tobias Hachmer
participants (2)
-
Arran Cudbard-Bell -
Hachmer, Tobias