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