AD Auth cache?

mmerlone

Hi all,

We have a pfsense server with openvpn road warriors set to auth over our AD domain. Works like a charm.
Now I have to kick a user from the service, I lock his account on AD, but pfsense still auth this user for openvpn as if it were not locked.
Is there some cache made by pfsense? How can I prevent those locked users from login in openvpn?

Thanks, best regards.

stephenw10

Is it falling back to local auth? Does that user exist locally?

If you test from Diag > Auth against AD does it show success there. Not much pfSense can do if it does.

Steve

mmerlone

Is it falling back to local auth? Does that user exist locally?

No and no.

If you test from Diag > Auth against AD does it show success there. Not much pfSense can do if it does.

I just don't understand: a joe.doe login is locked out from AD and becomes unable to auth on any service, be it dovecot, postfix, squid, samba, windows, php apps, etc. Why doesn't my pfsense?

For instance, for now I'm using an extended query to quickly kick undesired users like this, if that matters or help:

(&(objectClass=user)(!(|(uid=joe.doe)(uid=foo.bar))))

And the question remains: how can i debug this lock issue, how to make pfsense honor AD account lockout?

Thanks, best regards.

stephenw10

So you are saying AD still returns success for that account when you test it from the webgui in Diag > Auth?

Steve

mmerlone

Yes, a locked user on AD still returns success on Diag -> Auth and thus is able to auth and use the vpn connection.

stephenw10

Ok well that's a question for AD, why is it returning success there?
pfSense is just reflecting the returned successful authentication.

Steve

mmerlone

The question remains: why just pfsense while all other services honor the lock? I am not saying it is a pfsense bug, but rather some mis-configuration on my side, how can I find what's wrong?

stephenw10

I'd have to guess it's because you are locking the account rather than disabling or removing it. AD it probably returning that in some additional string that only applies to Windows and not general LDAP auth.
Try running a pcap and see what it's sending if you can. If any of it in unencrypted.
I doubt you are the first to hit this.

Steve