How to get current datetime in freeradius?

[Houman]

Hi Alan,

Thank you very much for all your help on this.  I got in touch with the NAS
makers (StrongSwan) and did some analysis together. Essentially the NAS
only needs the User-Name for the disconnect request, which I'm already
providing. The reason why it sends a NAK is that no IKE_SA was found with a
matching remote identity. This is what happens on the NAS side in the log
file:

> received RADIUS DAE Disconnect-Request for houman from 127.0.0.1
> no IKE_SA matches houman, sending Disconnect-NAK

So the question is why the disconnect fails upon login, but a bit later on
it works again:

"You can't use this method for IKE_SAs that are concurrently being
established.  Such IKE_SAs are locked and, thus, skipped by the Disconnect
handler.  This particular IKE_SA is waiting for the EAP-Accounting response
and until that's received and the IKE_AUTH response has been sent, the
IKE_SA can't be closed via this code path. It also affects SAs later if
they are locked for some reason (e.g. handling rekeyings or DPDs, but not
interim Accounting updates as the SA is unlocked before sending those).  So
perhaps the RADIUS server could retry sending the Disconnect message if it
still has state around for the user but received a NAK (or delay sending
the Disconnect for a bit)."

It's a bit of a dilemma. I have a reason to disconnect the user based on a
condition. But the user can still reconnect and I won't be able to
disconnect him straight away. I have to wait until the next
Acct-Interim-Interval kicks in before I can actually disconnect him again.
Since the authentication happens through Freeradius, is there a way to
reject the user immediately during authentication other than sending
disconnect requests?

Many Thanks,
Houman

On Tue, 15 Oct 2019 at 04:24, Alan DeKok <aland at deployingradius.com> wrote:

> On Oct 14, 2019, at 4:03 PM, Houman <houmie at gmail.com> wrote:
> > There are only two issues, I wanted to discuss here with the group:
> >
> > 1) Is there a way to send a custom message to the NAS when a disconnect
> > based on the custom condition happens? This way the user is not wondering
> > why he keeps getting disconnected but gets to know the real reason behind
> > it.
>
>   No.  There is no ability in RADIUS to send custom messages in a
> Disconnect-Request packet.  Even if there was, the underlying protocols
> (PPP, EAP, etc.) usually don't provide for messages on disconnect.
>
> > 2) Even though I have added the condition to "authorize", "accounting"
> and
> > "preacct" sections, the initial disconnect attempt remains unresponsive.
>
>   Read the debug log to see why.
>
> > (11) Sent Disconnect-Request Id 221 from 0.0.0.0:48470 to 127.0.0.1:3799
> > length 28
> > (11)   User-Name = "houman"
> > ...
> > (11) Received Disconnect-NAK Id 221 from 127.0.0.1:3799 to
> 127.0.0.1:48470
> > length 20
>
>   The NAS sent a NAK.  Which meant that the NAS refused to disconnect the
> user.  Very likely because the attributes in the Disconnect-Request packet
> were not enough to identify the users session.
>
>   What attributes *should* be in the Disconnect-Request?  The short answer
> is to read the NAS documentation.  Generally the best guess is the same
> session attributes which are in the Accounting-Request packets.
>
> > Only after the 300 seconds pass (which is defined in
> Acct-Interim-Interval)
> > the second disconnect attempt successfully disconnects the user.
>
>   No.
>
> > (13) Sent Disconnect-Request Id 103 from 0.0.0.0:48470 to 127.0.0.1:3799
> > length 28
> > (13)   User-Name = "houman"
> > ...
> > (13) Received Disconnect-NAK Id 103 from 127.0.0.1:3799 to
> 127.0.0.1:48470
> > length 20
>
>   The NAS sends a NAK again.
>
>   The user might be disconnected at that time, but it has nothing to do
> with the Disconnect-Request packet that was sent.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html