On Wednesday 02 December 2009 12:05:14 am Alan DeKok wrote:
gera wrote:
BUT, we noted an interesting behaviour. If the client specify Windows to
use another username to login, although freeradius complaints that the
user doesn't exist on ldap, it seems it still accepts this user, as long
BUT, we noted an interesting behaviour. If the client specify Windows to
use
another username to login, although freeradius complaints that the user
doesn't exist on ldap, it seems it still accepts this user, as long as the
certificate is fine. So, in this case, if the user isn't allowed to
BUT, we noted an interesting behaviour. If the client specify Windows to
use
another username to login, although freeradius complaints that the user
doesn't exist on ldap, it seems it still accepts this user, as long as
the
certificate is fine. So, in this case, if the user isn't allowed to
Read doc/rlm_ldap, bit about access attribute.
Ivan Kalik
Thanks Ivan.
My problem is that it seems that even if the user is not allowed to login
according to ldap (account doesn't exist or is disabled), access is
granted as long as the certificate is valid.
Lets try again:
Read
Hi.
Need some help to understand this combination.
I'm trying to setup EAP-TLS + Active Directory Authentication on a wireless
mobility controller.
This mob con has this Portal Captive feature. To start testing, I configured
freeradius as a ldap client for Active Directory, using the
gera wrote:
BUT, we noted an interesting behaviour. If the client specify Windows to use
another username to login, although freeradius complaints that the user
doesn't exist on ldap, it seems it still accepts this user, as long as the
certificate is fine.
That's how EAP-TLS works.
So,
6 matches
Mail list logo
