A sensible way to use this, is to combine this action in a policy with the client parameter: requiring the users to login to the Web UI remotely from the internet with OTP but still login from within the LAN with the domain password.
Basicly i want the user to login with domain credentals when they are on the lan ( I.E. 192.168.0.0/24
Your information is rather sparse. Are you talking about authentication at the webui?
I recommend taking a look at the audit log and there check the client IP for the authentication requests you are looking at. The client IP in the audit log is the client IP the privacyIDEA system actually “sees”.
If I understand correctly, @rwel wants a policy that checks the incoming user’s IP. If they are on his predefined LAN subnet (192.168.0.0/24 in his example), then they authenticate against only the AD userstore. If they are coming in from any other network (i.e. home ISP), then they are required to use their token plus AD user store.
I haven’t seen an option like that in the policies before (I could have easily missed it), but maybe the device being logged in to (i.e. a file server) itself could do that kind of check. If they are coming from 192.168.0.0/24, send the auth request to AD only. If they are coming in from any other network, send the auth request to the PI server.
I’ve been playing around with my lab this morning trying to get this to work, and no matter what I tried, it didn’t work, and finally I noticed something. I don’t know what your devices are that are sending authentication requests to the PI server, but in my set up, I use PAM on Linux servers. PAM, using Python, sends the authentication requests to the PI server. But the PI server does not see the user’s IP address, it sees the “client” as being the server sending the request.
So, if the flow is User(192.168.0.5) connects to a file server (192.168.0.100), the file server sends the request to the PI server (192.168.0.200). If you look in the AUdit log, you’ll see that the “client” is 192.168.0.100, not 192.168.0.5 Point being, the PI server doesn’t see the network the user is coming in from.
So, back to my original conclusion, unless your authentication method works differently than PAM (it might), then the only way you can send the requests to different places is to do a check on the server that sends the authentication request (192.168.0.100 in this example), not check on the PI server before processing.
cornelinux is by far the expert here, so maybe he knows of a way, but based on my limited experience with it over the past 6 months, I don’t see how to do it on the PI server itself.
In principle, authentication servers (like FreeRADIUS or the file server in your examples) can pass the client’s IP in the client API parameter. If the OverrideAuthorizationClient setting (see here) allows it, policies are then matched against the client’s IP instead of the authentication server’s IP. Maybe this helps?
Our FreeRADIUS plugin supports this, but I don’t think our PAM module currently passes the client parameter (and I’m not so sure if that’s a good idea security-wise?).
due to vacation i wasn’t able to respond. All works well if i use webui1 policy template, the users must authenticate with the token but if a user doesn’t have a token, the user can’t login. I want the users to login with their ad credentials if they are in the LAN.
The problem is, if we roll out push in the future the PI server has to be available for initial negotiation.