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