First questions (Audit Log, Radius passthrough to RSA and so on .. )

#1

Hi all,

we have made first tests and have found some questions, but also some answers…
Currently we have configured a passthrough to forward users who do not have a token to our RSA appliance.

  1. is it correct / wanted that this forwarding does not appear in the audit log? It works but we would like to see it there as well.

  2. later we will have 2 Radius Clients and would like to authorize different user groups (VPN User and Citrix User) is this possible?

  3. with the RSA token we use a pin, if this must be set PrivacyIdea rejects the user. I have already searched for this and found an entry from 2019 that this is not supported and therefore assume that it is still immre so, then ok.

  4. if the RSA appliance wants a second token, PI denies the login as well. Can this be solved otherwise?

I hope it’s ok to start the thread this way, if it’s too much I’m happy to divide the questions into single posts.

Many thanks in advance!

Best regards
Markus

#2

This works for us, use different realms for different groups.
The default does not need to specify it, the rest must preempt the username with realm@…

Don’t know about RSA - we switched to PI to get rid of the latter…

1 Like
#3

Hi Henry,

thanks for the reply.
I will check this option.
I think we have a workaround for the RSA specific things. I will now try to find a solution for the logging options.

#4

It does appear there as an extened info for the successful /validate/check request.

#5

Ok, I will have a look at that again, but it is not that important because we want to get away from the RSA solution.
I have connected freeradius via the rest API, is it possible to see in the audit log from which radius client the request came? Currently I only see the successful authentication from 127.0.0.1.

#6

Yes.
Audit menu (top, second last) will show you all successful and failed user logins.
Client IP addresses will show up instead of 127.0.0.1…

#7

https://privacyidea.readthedocs.io/en/latest/configuration/system_config.html#override-authorization-client