ldap filter depending on NAS
Hello, My freeRadius setup works very well using PEAP/TLS binding on the ldap using only one filter. Now I have two very different types of NAS and I need to filter users that may have access to one NAS or the other or both. My idea was to use the unlang in the ldap module to write my policy, but it's not working. in /etc/freeradius/modules/ldap we have: ldap { # # Note that this needs to match the name in the LDAP # server certificate, if you're using ldaps. server = "127.0.0.1" identity = "__snipped__" password = "__snipped__" basedn = "dc=__snipped__,dc=com" #WORKING : #filter = "(&(|(accessTo=WIFI_FR)(accessTo=WIFI_ALL))(uid=%{Stripped-User-Name:-%{User-Name}}))" #NOT working: if (NAS-IP-Address == 10.1.1.2) { filter = "(&(|(accessTo=WIFI_XX)(accessTo=WIFI_YY))(uid=%{Stripped-User-Name:-%{User-Name}}))" } else { filter = "(&(accessTo=VPN)(uid=%{Stripped-User-Name:-%{User-Name}}))" } base_filter = "(objectclass=radiusprofile)" ___snipped-the rest of this section is OK___ } It all happens as if the "if () { ... } else { ... } " is completely ignored (and thus it defaults to check if the uid exists) (ie: neither filter1 nor filter2 appears when debugging. But when we only put filter, it appears when debugging) I think I'm missing a lot of details in the configuration and I have not figured out how to do this with hints|huntgroups|clients files. Any help on why this is not working or an other simple solution is welcome. Best Regards, Matt
My freeRadius setup works very well using PEAP/TLS binding on the ldap using only one filter. Now I have two very different types of NAS and I need to filter users that may have access to one NAS or the other or both. My idea was to use the unlang in the ldap module to write my policy, but it's not working.
No. It works in server, not module configuration. Use group membership filter as well. Then use unlang in authorize to check Ldap-Group. Ivan Kalik Kalik Informatika ISP
Matthieu Lazaro wrote:
It all happens as if the "if () { ... } else { ... } " is completely ignored (and thus it defaults to check if the uid exists)
Yes.
(ie: neither filter1 nor filter2 appears when debugging. But when we only put filter, it appears when debugging)
I think I'm missing a lot of details in the configuration and I have not figured out how to do this with hints|huntgroups|clients files. Any help on why this is not working or an other simple solution is welcome.
You cannot dynamically change the module configuration. Those are static. The "unlang" policies can only go in the "authorize", "authenticate", etc. sections. Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
It all happens as if the "if () { ... } else { ... } " is completely ignored (and thus it defaults to check if the uid exists)
Yes.
(ie: neither filter1 nor filter2 appears when debugging. But when we only put filter, it appears when debugging)
I think I'm missing a lot of details in the configuration and I have not figured out how to do this with hints|huntgroups|clients files. Any help on why this is not working or an other simple solution is welcome.
You cannot dynamically change the module configuration. Those are static. The "unlang" policies can only go in the "authorize", "authenticate", etc. sections.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK. I have understood now why it was not working. However, this should be clarified in http://freeradius.org/radiusd/man/unlang.html . But I have good news, I have found the solution using the huntgroups file and activating "groupmembership" in the LDAP module: WIFI NAS-IP-Address == 10.1.1.2 Ldap-Group = WIFI_FR, Ldap-Group = WIFI_ALL VPN NAS-IP-Address == 10.1.1.3 Ldap-Group = VPN Flexibility comes when modifying the groupmembership_attribute so that you can use what ever you want in your LDAP. Still I find a lot of points in Freeradius that are obscure because it's not enough documented. For example: filtering with more than on attribute in checkval ( MAC / TUNNEL TYPE), sending orders to the NAS to change VLAN depending on the user, etc... Thanks for your help.
Matthieu Lazaro wrote:
OK. I have understood now why it was not working. However, this should be clarified in http://freeradius.org/radiusd/man/unlang.html .
Feel free to submit suggested text.
Still I find a lot of points in Freeradius that are obscure because it's not enough documented.
Feel free to submit documentation. Other people have, and it has been included in the server.
For example: filtering with more than on attribute in checkval ( MAC / TUNNEL TYPE), sending orders to the NAS to change VLAN depending on the user, etc...
Write down the policies, and then implement them in the policy language. Feel free to submit example policies and configurations. Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
For example: filtering with more than on attribute in checkval ( MAC / TUNNEL TYPE), sending orders to the NAS to change VLAN depending on the user, etc...
Write down the policies, and then implement them in the policy language.
Feel free to submit example policies and configurations.
Alan DeKok.
Yet, I have not been able to: - Tell the NAS to change the VLAN depending on LDAP account info, - Tell the NAS to change the SSiD + VLAN depending on user LDAP account - Filter MAC + MEDIUM TYPE + PORT Number depending on LDAP account info Also, the reply messages like "call your helpdesk" doesn't work. And honestly, I don't know where to start. Matt
Matthieu Lazaro wrote:
Yet, I have not been able to: - Tell the NAS to change the VLAN depending on LDAP account info, - Tell the NAS to change the SSiD + VLAN depending on user LDAP account - Filter MAC + MEDIUM TYPE + PORT Number depending on LDAP account info
Perhaps part of the problem is that your requirements are vague to the point of being unhelpful.
Also, the reply messages like "call your helpdesk" doesn't work.
Who's told you that>
And honestly, I don't know where to start.
Start by defining your policies in a DETAILED manner: - when I see a packet containing User-Name "foo" - look up THIS in THAT database using SOME information - return these attributes to the NAS: (Foo = Bar, Other = whatever) If you don't have a clear definition of what you want to do and when you want to do it, you will be unable to get *anything* done. e.g. "Tell the NAS to change the VLAN depending on LDAP account info," WHAT "ldap account info"? Figure that out. Figure out what information you need to query that data in LDAP. Figure out what you are going to do with the results. And then find out how to assign VLANs. And you can't tell the NAS to change SSID's. It's impossible. What does this mean? "Filter MAC + MEDIUM TYPE + PORT Number depending on LDAP account info" What is "Filter mac"? Allow? Disallow? Do... what? Your examples are pretty close to "do stuff when I see stuff". It's a grammatically correct English sentence, but nearly meaningless. Alan DeKok.
Alan DeKok a écrit :
Your examples are pretty close to "do stuff when I see stuff". It's a grammatically correct English sentence, but nearly meaningless.
Alan DeKok.
-
Ok, So I will try to make myself clear. Here is one policy that I wish to make work. 1- a client connects to a 802.1x protected VLAN ID 10 ( per port basis configuration on the switch) --> this client has some of the following LDAP attributes: uid = bobalice radiusTunnelPrivateGroupID = 20 radiusTunnelType = VLAN radiusMediumType = IEEE-802 radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN 2- Fisrt I want to checkthe following attributes, and if not correct, reject the user: radiusTunnelType = VLAN radiusMediumType = IEEE-802 radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN 3- Then I want to authenticate and authorise the user if login/password are correct 4 - Then Move him into the appropriate VLAN ID 20 instead of ID10 based on this attribute: radiusTunnelPrivateGroupID = 20 For now, I only have been able to make work the RadiusCallingStationId using checkval. Hoping this is much much more precise and clearer, I really wish to discover what am I missing. Best Regards, Matt
Matthieu Lazaro wrote:
1- a client connects to a 802.1x protected VLAN ID 10 ( per port basis configuration on the switch)
The client connects via 802.1X. It doesn't connect on a VLAN. VLAN assignment comes *after* the client has been authenticated.
--> this client has some of the following LDAP attributes: uid = bobalice radiusTunnelPrivateGroupID = 20 radiusTunnelType = VLAN radiusMediumType = IEEE-802
If you list those in raddb/ldap.attrmap, they should automatically be returned. But they're not in the default ldap.attrmap.
radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN
There is no such thing as "radiusUserCategory" in the default configuration. Part of the issue is that you're confusing *reply* attributes with *check* attributes. See ldap.attrmap for more information on how LDAP attributes are used.
2- Fisrt I want to checkthe following attributes, and if not correct, reject the user: radiusTunnelType = VLAN radiusMediumType = IEEE-802 radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN
What do you mean "Not correct"? Those are *LDAP* attributes. The RADIUS server receives *RADIUS* attributes. *PLEASE* ensure that you use the correct terminology. Using the wrong terminology is bad. i.e. referring to RADIUS concepts by LDAP names. And the RADIUS request will *not* contain Tunnel-Type, Tunnel-Medium-Type, or "user category". It *will* contain the Calling-Station-Id. Maybe you missed the part of my email where I said look at the contents of the *RADIUS* packet. You don't seem to have done that. I don't give suggestions at random. They're here for a *reason*.
3- Then I want to authenticate and authorise the user if login/password are correct
OK.
4 - Then Move him into the appropriate VLAN ID 20 instead of ID10 based on this attribute: radiusTunnelPrivateGroupID = 20
If you add that as a replyItem to ldap.attrmap, it should work.
For now, I only have been able to make work the RadiusCallingStationId using checkval.
That shouldn't be necessary. The LDAP module will treat it as a checkItem all by itself. See ldap.attrmap.
Hoping this is much much more precise and clearer, I really wish to discover what am I missing.
You're using the wrong terminology. You're not following instructions. Alan DeKok.
Here is one policy that I wish to make work.
1- a client connects to a 802.1x protected VLAN ID 10 ( per port basis configuration on the switch) --> this client has some of the following LDAP attributes: uid = bobalice radiusTunnelPrivateGroupID = 20 radiusTunnelType = VLAN radiusMediumType = IEEE-802 radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN 2- Fisrt I want to checkthe following attributes, and if not correct, reject the user: radiusTunnelType = VLAN radiusMediumType = IEEE-802
Are those two attributes in the access request? If they are, map them as check items in ldap.attrmap.
radiusCallingStationId = 00-21-42-42-87-b1
This is already in ldap.attrmap.
radiusUserCategory = ADMIN
Where is that suposed to come from?
3- Then I want to authenticate and authorise the user if login/password are correct
Fine. Nothing to do.
4 - Then Move him into the appropriate VLAN ID 20 instead of ID10 based on this attribute: radiusTunnelPrivateGroupID = 20
Map that as reply item in ldap.attrmap. You will need tunnel and medium type in the reply as well. So add them too. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net a écrit :
Here is one policy that I wish to make work.
1- a client connects to a 802.1x protected VLAN ID 10 ( per port basis configuration on the switch) --> this client has some of the following LDAP attributes: uid = bobalice radiusTunnelPrivateGroupID = 20 radiusTunnelType = VLAN radiusMediumType = IEEE-802 radiusCallingStationId = 00-21-42-42-87-b1 radiusUserCategory = ADMIN 2- Fisrt I want to checkthe following attributes, and if not correct, reject the user: radiusTunnelType = VLAN radiusMediumType = IEEE-802
Are those two attributes in the access request? If they are, map them as check items in ldap.attrmap.
radiusCallingStationId = 00-21-42-42-87-b1
This is already in ldap.attrmap.
radiusUserCategory = ADMIN
Where is that suposed to come from?
3- Then I want to authenticate and authorise the user if login/password are correct
Fine. Nothing to do.
4 - Then Move him into the appropriate VLAN ID 20 instead of ID10 based on this attribute: radiusTunnelPrivateGroupID = 20
Map that as reply item in ldap.attrmap. You will need tunnel and medium type in the reply as well. So add them too.
Ivan Kalik Kalik Informatika ISP
Here is the content of a packet received by radiusd: rad_recv: Access-Request packet from host 10.1.1.2 port 1692, id=171, length=302 Framed-MTU = 1480 NAS-IP-Address = 10.1.1.2 NAS-Identifier = "Test Switch " User-Name = "bobalice" Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 1 NAS-Port-Type = Ethernet NAS-Port-Id = "20" Called-Station-Id = "00-11-f3-1d-5d-00" Calling-Station-Id = "00-14-b2-7a-87-b4" Connect-Info = "CONNECT Ethernet 100Mbps Full duplex" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "1" State = 0xff747043ff76690706eed2dfa8b93b90 EAP-Message = 0x0202005019800981004616030100410100003d030149dce2350a464fb33bb5333ee36c942769f84056fcb49ef5371ee91f0503103800001600040005000a000990640062000300060013001200630100 Message-Authenticator = 0xec90edc178afb509db4131a36bfe42fe Futhermore, to reply to Alan about the radiusUserCategory, it is given with the radius.schema for ldap. Is it a useless attribute then? I'll be checking this afternoon and testing about putting more info in ldap.attrmap to see if the filters work. I let you know. Regards, Matt
Matthieu Lazaro wrote:
Here is the content of a packet received by radiusd:
Weird, but OK.
Futhermore, to reply to Alan about the radiusUserCategory, it is given with the radius.schema for ldap. Is it a useless attribute then?
Yes.
I'll be checking this afternoon and testing about putting more info in ldap.attrmap to see if the filters work.
See also doc/rlm_ldap. This *is* documented. Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
Here is the content of a packet received by radiusd:
Weird, but OK.
Futhermore, to reply to Alan about the radiusUserCategory, it is given with the radius.schema for ldap. Is it a useless attribute then?
Yes.
I'll be checking this afternoon and testing about putting more info in ldap.attrmap to see if the filters work.
See also doc/rlm_ldap. This *is* documented.
Alan DeKok.
When filling the ldap.attrmap, here is what I get: Info: [ldap] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details Info: [ldap] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=bobalice) Info: [ldap] expand: dc=testbed,dc=lan -> dc=testbed,dc=lan Debug: rlm_ldap: ldap_get_conn: Checking Id: 0 Debug: rlm_ldap: ldap_get_conn: Got Id: 0 Debug: rlm_ldap: performing search in dc=testbed,dc=lan, with filter (uid=bobalice) Info: [ldap] checking if remote access for bobalice is allowed by radiusTunnelPrivateGroupId Info: [ldap] Added User-Password = in check items Info: [ldap] No default NMAS login sequence Info: [ldap] looking for check items in directory... Debug: rlm_ldap: radiusTunnelPrivateGroupId -> Tunnel-Private-Group-Id:0 == "34" Debug: rlm_ldap: radiusTunnelMediumType -> Tunnel-Medium-Type:0 == IEEE-802 Debug: rlm_ldap: radiusTunnelType -> Tunnel-Type:0 == VLAN Debug: rlm_ldap: userPassword -> User-Password == " " Debug: rlm_ldap: radiusNASIpAddress -> NAS-IP-Address == 10.1.1.2 Debug: rlm_ldap: sambaNtPassword -> NT-Password == Debug: rlm_ldap: sambaLmPassword -> LM-Password == Debug: rlm_ldap: ntPassword -> NT-Password == Debug: rlm_ldap: lmPassword -> LM-Password == Debug: rlm_ldap: radiusCallingStationId -> Calling-Station-Id == "00-15-42-7a-82-b4" Info: [ldap] looking for reply items in directory... Info: [ldap] user bobalice authorized to use remote access Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Info: ++[ldap] returns ok The thing is, it is just READING the ldap content.... and not comparing to what the NAS is sending. Tunnel-Private-Group-Id:0 == "34" actually I logged in using Tunnel-Private-Group-Id:0 == "1" . I tried to add those check in the users file, but it didn't work. I read the rlm_ldap manual, and it's not talking about those types of attributes.... So I'm wondering where to tell radius: "compare the ldap attributes with what the NAS sent you, and if anything is different, reject the packet". I guess that I'll have to wait this is resolved before trying to have radius putting the user in the proper vlan. (doing things in the right order???) Regards, Matt
Matthieu Lazaro wrote:
The thing is, it is just READING the ldap content.... and not comparing to what the NAS is sending.
Yes.. because you (or the defaults) configured those LDAP attributes in ldap.attrmap as "replyItems". This means that they are read from LDAP, and added to the RADIUS reply. That's how it works. That's how it's documented as working. Can you PLEASE stop expecting the server to behave like you *think* it works, and instead believe that it behaves the way it's *documented* as working, as they way that we are *telling* you it works? That confusion is the cause of the vast majority of the problems you are running into. If you can't get past that, then there is no point in anyone answering your questions.
Tunnel-Private-Group-Id:0 == "34" actually I logged in using Tunnel-Private-Group-Id:0 == "1" .
Yes. And it was explained WHY that happens.
I tried to add those check in the users file, but it didn't work.
Again, see the FAQ for "it doesn't work".
I read the rlm_ldap manual, and it's not talking about those types of attributes....
What does that mean? Could be be any less vague?
So I'm wondering where to tell radius: "compare the ldap attributes with what the NAS sent you, and if anything is different, reject the packet".
The checkItem attributes in ldap.attrmap either match, or they don't match. You can then configure policies based on that match. You CANNOT have an attribute as both a checkItem and a replyItem.
I guess that I'll have to wait this is resolved before trying to have radius putting the user in the proper vlan. (doing things in the right order???)
You need to test SMALL changes from the default configuration. You need to test SMALL pieces of your policy. See "man radiusd" for a suggested method of creating policies. Right now, it looks like you've configured your entire policy, and are then wondering why it doesn't work. The policy is made up of a number of tiny pieces, all of which have to work together. Test the pieces in isolation *before* creating your final policy. Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
The thing is, it is just READING the ldap content.... and not comparing to what the NAS is sending.
Yes.. because you (or the defaults) configured those LDAP attributes in ldap.attrmap as "replyItems". This means that they are read from LDAP, and added to the RADIUS reply.
No, I have set them up to checkItems: checkItem Tunnel-Type:0 radiusTunnelType checkItem Tunnel-Medium-Type:0 radiusTunnelMediumType checkItem Tunnel-Private-Group-Id:0 radiusTunnelPrivateGroupId So if there are configured somewhere by default, how can I change that?
That's how it works. That's how it's documented as working.
Can you PLEASE stop expecting the server to behave like you *think* it works, and instead believe that it behaves the way it's *documented* as working, as they way that we are *telling* you it works?
That confusion is the cause of the vast majority of the problems you are running into. If you can't get past that, then there is no point in anyone answering your questions.
Tunnel-Private-Group-Id:0 == "34" actually I logged in using Tunnel-Private-Group-Id:0 == "1" .
Yes. And it was explained WHY that happens.
Because it just read the info from the ldap, so it's not considered like a checkItem: understood.
I tried to add those check in the users file, but it didn't work.
Again, see the FAQ for "it doesn't work".
I inspired my configuration based on "man 5 users" and I didn't find an FAQ article that covers using policies with an LDAP backend.
I read the rlm_ldap manual, and it's not talking about those types of attributes....
What does that mean? Could be be any less vague?
rlm_ldap manual covers the options to use with the ldap module like server , tls binding, basic filters, etc... not " how to use extended ldap attributes based on the content of the RADIUS-LDAPv3.schema". At least, the ldap_howto.txt covers some parts about huntgroups and users files that seem to stick more to what I want to do.
So I'm wondering where to tell radius: "compare the ldap attributes with what the NAS sent you, and if anything is different, reject the packet".
The checkItem attributes in ldap.attrmap either match, or they don't match. You can then configure policies based on that match.
You CANNOT have an attribute as both a checkItem and a replyItem.
I guess that I'll have to wait this is resolved before trying to have radius putting the user in the proper vlan. (doing things in the right order???)
You need to test SMALL changes from the default configuration. You need to test SMALL pieces of your policy. See "man radiusd" for a suggested method of creating policies.
This is true, and I'm sometimes too impatient to do little by little.
Right now, it looks like you've configured your entire policy, and are then wondering why it doesn't work. The policy is made up of a number of tiny pieces, all of which have to work together. Test the pieces in isolation *before* creating your final policy.
I have my basic policy depending on NAS and groups working. Now I'm putting small bricks to filter the requests and clients. When I show you all the attributs, it's to tell you what I have been using. But I have tested them one by one. For sure I'm confused because radius is so huge and does many many things. Regards, Matt
No, I have set them up to checkItems: checkItem Tunnel-Type:0 radiusTunnelType checkItem Tunnel-Medium-Type:0 radiusTunnelMediumType checkItem Tunnel-Private-Group-Id:0 radiusTunnelPrivateGroupId
And what is the point of that? Why do you care what VLAN is in the request? You should set up VLAN in the reply. Also, checking NAS-Port makes very little sense. NAS-Port has a role in accounting but it's of very little use during authentication. Mac (Calling-Station-Id) is the only thing worth checking. Don't bother with checking tunnel attributes - use them just in the reply. Ivan Kalik Kalik Informatika ISP
Matthieu Lazaro wrote:
No, I have set them up to checkItems:
I agree with Ivan here: don't do this.
I inspired my configuration based on "man 5 users" and I didn't find an FAQ article that covers using policies with an LDAP backend.
There is a FAQ entry for "it doesn't work".
rlm_ldap manual covers the options to use with the ldap module like server , tls binding, basic filters, etc... not " how to use extended ldap attributes based on the content of the RADIUS-LDAPv3.schema".
Exactly. It describes how the LDAP module works. It does NOT describe how to implement complex policies that cannot be implemented with the LDAP module. Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
rlm_ldap manual covers the options to use with the ldap module like server , tls binding, basic filters, etc... not " how to use extended ldap attributes based on the content of the RADIUS-LDAPv3.schema".
Exactly. It describes how the LDAP module works. It does NOT describe how to implement complex policies that cannot be implemented with the LDAP module.
Alan DeKok.
OK, so tell me where to implement complex policies? And when you say "that cannot be implemented with the LDAP module", do you mean that all those fields added by RADIUS-LDAPv3.schema are useless? And finally, can you say that when a dumb users plugs in the wrong VLAN, like a admin VLAN, I cannot deny him or put him automatically in the right VLAN with radius? Best regards, Matt
Matthieu Lazaro wrote:
OK, so tell me where to implement complex policies?
I've been trying. You need to write down what you have (in RADIUS packets, LDAP, etc.). You need to write down what you want (contents of reply packets, behaviors, etc.). You then need to write down a process for converting one into the other. This is programming. It is practically and theoretically impossible to describe how to write any program. You MUST figure it out for yourself.
And when you say "that cannot be implemented with the LDAP module", do you mean that all those fields added by RADIUS-LDAPv3.schema are useless?
Ah, yes. You didn't get *exactly* what you wanted, so you're looking for ways to fight back, and claim that the software is crappy.
And finally, can you say that when a dumb users plugs in the wrong VLAN, like a admin VLAN, I cannot deny him or put him automatically in the right VLAN with radius?
I didn't say that, and no amount of distortion of my messages could lead you to believe I said that. You seemed to have turned my response of "assign users into a vlan", into "you cannot assign users into a vlan". While ingenious, it is distinctly unproductive. As a simple hint: Why the HELL do you care which VLAN the user is requesting? Just assign them to the right VLAN. If the switch doesn't enforce that VLAN assignment, then BLAME THE SWITCH. Don't blame FreeRADIUS, like most people do in this situation. Again, you are going out of your way to create complexity where none is necessary. This causes you to be confused about how the server works. It causes you to try to configure impossible things. It causes you to be rude on the list when we tell you "don't do it that way." Alan DeKok.
Alan DeKok a écrit :
Matthieu Lazaro wrote:
OK, so tell me where to implement complex policies?
I've been trying.
You need to write down what you have (in RADIUS packets, LDAP, etc.). You need to write down what you want (contents of reply packets, behaviors, etc.). You then need to write down a process for converting one into the other.
This is programming. It is practically and theoretically impossible to describe how to write any program. You MUST figure it out for yourself.
And when you say "that cannot be implemented with the LDAP module", do you mean that all those fields added by RADIUS-LDAPv3.schema are useless?
Ah, yes. You didn't get *exactly* what you wanted, so you're looking for ways to fight back, and claim that the software is crappy.
And finally, can you say that when a dumb users plugs in the wrong VLAN, like a admin VLAN, I cannot deny him or put him automatically in the right VLAN with radius?
I didn't say that, and no amount of distortion of my messages could lead you to believe I said that.
You seemed to have turned my response of "assign users into a vlan", into "you cannot assign users into a vlan". While ingenious, it is distinctly unproductive.
As a simple hint: Why the HELL do you care which VLAN the user is requesting? Just assign them to the right VLAN. If the switch doesn't enforce that VLAN assignment, then BLAME THE SWITCH. Don't blame FreeRADIUS, like most people do in this situation.
Again, you are going out of your way to create complexity where none is necessary. This causes you to be confused about how the server works. It causes you to try to configure impossible things. It causes you to be rude on the list when we tell you "don't do it that way."
Alan DeKok. -
Sorry if you thought I was being rude, this was not my intention. I think we didn't understand each other and this is probably because my questions are not clear enough because I have such precise idea of what I want radius to do. I should have explained the problem the other way round maybe. Furthermore, I never though that it was"crappy" software and I actually thinks it's amazing what we can do with it and it seems like it is unlimited. But it is very complex, and there is lot of different actors in the process that must be taken into account ( like the supplicant, the NAS, the backends (ldap, sql,etc..)). I try to ask my questions more precisely: * what are the radius ldap attributes meant for? Is only for accounting or can we use them for something else? * I have understood that it is better to put the user directly in the correct VLAN rather than checking his request and deny him: do I have to do something special in Radius to forward LDAP attributes info to the switch? ( I am reading again the switch's documentation to figure how to parse the attributes instead of using static vlans) Best regards, Matt
I try to ask my questions more precisely: * what are the radius ldap attributes meant for? Is only for accounting or can we use them for something else?
They can be used for authorization as well. You put them in your Access-Accept packet (reply) and if your switch supports those attributes it does certain things (assigns VLANs, sets various timeouts, restricts bandwidth etc.).
* I have understood that it is better to put the user directly in the correct VLAN rather than checking his request and deny him: do I have to do something special in Radius to forward LDAP attributes info to the switch? ( I am reading again the switch's documentation to figure how to parse the attributes instead of using static vlans)
Ah, you should of done that first. Many vendors advertize "dynamic VLAN assignment" but when you read through the documentation it turns out that the assignment is static and that only thing "dynamic" about them is that you can change them via a console. Make sure first that your switch supports dynamic VLAN assignment via radius. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net a écrit :
I try to ask my questions more precisely: * what are the radius ldap attributes meant for? Is only for accounting or can we use them for something else?
They can be used for authorization as well. You put them in your Access-Accept packet (reply) and if your switch supports those attributes it does certain things (assigns VLANs, sets various timeouts, restricts bandwidth etc.).
* I have understood that it is better to put the user directly in the correct VLAN rather than checking his request and deny him: do I have to do something special in Radius to forward LDAP attributes info to the switch? ( I am reading again the switch's documentation to figure how to parse the attributes instead of using static vlans)
Ah, you should of done that first. Many vendors advertize "dynamic VLAN assignment" but when you read through the documentation it turns out that the assignment is static and that only thing "dynamic" about them is that you can change them via a console. Make sure first that your switch supports dynamic VLAN assignment via radius.
Ivan Kalik Kalik Informatika ISP
Thanks for your help. I have check the switch manual and it says it's possible to assign VLANs using the radius accept-accept message. Apparently, it's the first ting it should do, then it checks it's own auth policy (if present) or it puts the user in the default untagged VLAN setup on that port. I can quote parts of the manual if you need. I have configured the ldap VLANiD attribute as a replyItem and I see it the ldap section in debug mode. However, it is not present in the accept-accept message at the end of the debug so the switch stays in "default" VLAN. I am now trying to figure how to have the replyItem in my accept-accept message. Best Regards, Matt
I am now trying to figure how to have the replyItem in my accept-accept message.
Just map appropriate attributes in ldap.attrmap as replyItem. I can see tunnel attributes in default ldap.attrmap in stable branch now, so that will be there in future. For PEAP you should list ldap only in inner-tunnel server (you don't even need it in default server for that protocol) and enable use_tunneled_reply in peap section of eap.conf in order to get tunnel attributes in the final Access-Accept. If you are going to check Calling-Station-Id enable copy_request_to_tunnel as well. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net a écrit :
I am now trying to figure how to have the replyItem in my accept-accept message.
Just map appropriate attributes in ldap.attrmap as replyItem. I can see tunnel attributes in default ldap.attrmap in stable branch now, so that will be there in future. For PEAP you should list ldap only in inner-tunnel server (you don't even need it in default server for that protocol) and enable use_tunneled_reply in peap section of eap.conf in order to get tunnel attributes in the final Access-Accept. If you are going to check Calling-Station-Id enable copy_request_to_tunnel as well.
Ivan Kalik Kalik Informatika ISP
Hello, Thanks for your prompt reply. Everything is working now!!! Just had to figure out that the switch needed 3 items to be able to change VLAN and not only Tunnel-Private-Group-ID ( http://wiki.freeradius.org/HP#ProCurve_port_authentication_special_features ): Tunnel-Type Tunnel-Medium-Type Tunnel-Private-Group-ID I also cleaned my configuration files between default and inner-tunnel. I have been able to check Calling-Station-Id *only* using the checkval module. I hope this is normal. Again, thank you very much! Best regards, Matt
Matthieu Lazaro wrote:
I think we didn't understand each other and this is probably because my questions are not clear enough because I have such precise idea of what I want radius to do.
I disagree that that is the cause of the confusion.
I should have explained the problem the other way round maybe. Furthermore, I never though that it was"crappy" software and I actually thinks it's amazing what we can do with it and it seems like it is unlimited. But it is very complex, and there is lot of different actors in the process that must be taken into account ( like the supplicant, the NAS, the backends (ldap, sql,etc..)).
It also requires you to UNDERSTAND how it works. Without that step, there's no point in doing anything else.
I try to ask my questions more precisely: * what are the radius ldap attributes meant for? Is only for accounting or can we use them for something else?
Nothing in any of my messages said anything about the LDAP attributes being used only for accounting. Yet here you are... ignoring all of my comments about what those attributes do, and inventing that they are "only for accounting". This is known as "being rude". You might disagree, but the reality is you've gone out of your way to ignore, distort, and misinterpret what I've said.
* I have understood that it is better to put the user directly in the correct VLAN rather than checking his request and deny him: do I have to do something special in Radius to forward LDAP attributes info to the switch?
I've been trying to explain it. If you haven't gotten it by now, it's clear that I am incapable of helping you. Alan DeKok.
I try to ask my questions more precisely: * what are the radius ldap attributes meant for? Is only for accounting or can we use them for something else?
Nothing in any of my messages said anything about the LDAP attributes being used only for accounting. Yet here you are... ignoring all of my comments about what those attributes do, and inventing that they are "only for accounting".
This is known as "being rude". You might disagree, but the reality is you've gone out of your way to ignore, distort, and misinterpret what I've said.
There's a proverb "Don't attribute to malice that what can be explained by incompetence" maybe his english skills are just not so great so he mis-represented what he was trying to do. -- damjan | дамјан This is my jabber ID --> damjan@bagra.net.mk -- not my mail address, it's a Jabber ID --^ :)
And finally, can you say that when a dumb users plugs in the wrong VLAN, like a admin VLAN, I cannot deny him or put him automatically in the right VLAN with radius?
If he can plug into a switch and get access to admin VLAN it's network admin that is dumb, not the user. If your switch supports dynamic VLAN assignment via radius and you are using port authentication it shouldn't be possible (if your switch doesn't support this - this talk is pointless). 1. Why is default VLAN (1) enabled on your ports? You are just asking foir trouble doing that. 2. User can't just "plug into the admin VLAN". If admin unplugs, even without logging off, switch should terminate the session and return the port to default state. 3. If your switch supports dynamic VLAN assignment via radius it should respect VLAN info sent in Access-Accept. If your user ends up in a different VLAN you have set your switch wrongly. In many cases you can't send arbitrary VLAN id - it has to be defined on the switch already. You should consult your switch documentation about proper VLAN setup. It seems that you don't understand how switch and port based authentication works. There is no point in checking VLAN info in the request. Just send VLAN info in the reply - it will (if hardware is set up properly) override it. Ivan Kalik Kalik Inf
Yet, I have not been able to: - Tell the NAS to change the VLAN depending on LDAP account info,
Have you read you NAS documentation regarding assigning VLANs? If you know which attributes you need to pass you map them to ldap attributes in ldap.attrmap as reply items.
- Tell the NAS to change the SSiD + VLAN depending on user LDAP account
Same as above.
- Filter MAC + MEDIUM TYPE + PORT Number depending on LDAP account info
Mac should be in the Calling-Station-Id, medium type is unlikely to be in the request and Port-Number is. Add them and map them to ldap attributes in ldap.attrmap as check items. Use of ldap.attrmap is commented on in ldap module configuration file (raddb/modules/ldap). But that is for those who bother to read existing documentation. Ivan Kalik Kalik Informatika ISP
participants (4)
-
Alan DeKok -
Damjan -
Matthieu Lazaro -
tnt＠kalik.net