[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Realm Config
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2023-08-25 12:51:53
Message-ID: 602A5DAF-7F4E-4040-BD63-FA421102C169 () deployingradius ! com
[Download RAW message or body]

On Aug 24, 2023, at 5:28 PM, Carlos Botejara <cbotejara@gmail.com> wrote:
> I have two scenarios, and I need to authorize users and devices separately.
> In the first case, I have remote users that need to access a specific
> network.
> In the second case, I have remote devices installed in the field and I need
> to access another network.

  You can write a bunch of if / then / else statements to implement any logic you \
want.

  The usual recommendation is to write down exactly what you have, and what you want \
the server to do.  Be as specific as possible.  Just use normal language.

  When all that's done, translate it to "unlang".  It will generally be fairly \
simple.

> Now, I need to send specific configurations to both scenarios, depending on
> the Realm on where the connection comes from, like vlan-id, bandwidth,
> quota, etc.

  if (realm a) {
		... stuff for realm a ...
  }

  if (realm b) {
		... stuff for realm b ...
  }

  You can put anything inside of the "if" block.  You can have two different SQL \
modules, which look at different tables, or even different databases.

> For example, for scenario1 (users), the authentication is through pppoe,
> and the Mikrotik sends User and Password, and works fine.
> 
> Attach a log.
> 
> (9)   Mikrotik-Rate-Limit = "3584K/7168K"
> (9)   Acct-Input-Octets = 2513739245

  That's an accounting packet.  It's not an authentication packet.  You can't apply \
VLAN assignment to accounting packet.

  I would suggest paying attention to what's going on, and how the server works.  If \
you're trying to write rules for Access-Request packets, then there is absolutely no \
reason to post an example accounting packet to the list.

  Attention to detail is critical here.  If you're randomly trying things, you will \
never get anything done.  If you don't look at what you're doing, you will also never \
get anything done.

> For scenario2, the devices need to be authenticated through mac address,
> via DHCP server.

  What does that mean?

  DHCP servers don't authenticate MAC addresses.  If you just put random words \
together, they don't make sense.

  You have to describe (and understand) exactly what happens.

  WHEN the user connects, THEN it does DHCP to the mikrotik.  THEN the mikrotik sends \
an Access-Request packet to the RADIUS server.  The Access-Request packet contains \
the MAC in attribute X, and also some other attributes, A, B, C, etc.

> The DHCP Server sends to Radius the mac address device as username but
> doesn't send a password.

  So?

  And... is that packet a secret?  Did you pay attention to any documentation which \
said "POST THE DEBUG OUTPUT" ?

  We also don't need to see an accounting packet which has no MAC address or anything \
else interesting in it.  I don't understand why you would ask about Access-Request \
packets and MAC addresses... and then post an Accounting-Request packet with no MAC.

  None of that makes sense.  It's just wasting everyones time.

> I hope I have been clear now, and I hope you can help me.
> If you need more information, please let me know.

  How about posting information about the problem you have?  I.e. the full debug log \
of an Access-Request.  Not part of a random Accounting-Request packet.

  I don't understand why this has to be so difficult.  I can't read your mind.  I \
don't have access to your systems.  I only know what you post to the list.  Yet over \
and over, you don't post anything useful, or you post irrelevant information.

  Do you want this problem solved?  Then describe what you're doing.  Accurately.  If \
this doesn't happen, I'm just going to give up.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]