ldap filter depending on NAS

[Alan DeKok]

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.