Help on TLS+Active Directory
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 Administrator account to bind to it, and using commonname as a filter. Then I configured the portal captive from the mob-con to authenticate through the radius server, and it worked fine, even using the simultaneous-use attribute. Then, I tried to go ahead configuring EAP-TLS. At first I recompiled the source code to include support for ssl. Then I created the certs on freeradius using the Makefile which comes on the package. I signed up the client certificates using the CA ones, not the server ones. Next, I configured the corresponding sections on eap.conf and default (enabling eap) and started freeradius -X. After copying the certificates to the Windows Vista machines, I started the association. Everything was well, and the client authenticated without problems. Even trying to use the same certificate on another machine reached the simultaneous-use count and didn't allow the client to connect. 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 login because of simultaneous use, he still can change the username which he uses specifying another one (whichever, even if it doesn't exist) and voilá! He can now log in. I'm sure I'm missing something, but I'm not sure what. Any clue? Will supply log or conf files upon request (right now, I'm not sure what parts could be relevant to you).
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, in this case, if the user isn't allowed to login because of simultaneous use, he still can change the username which he uses specifying another one (whichever, even if it doesn't exist) and voilá! He can now log in.
I'm sure I'm missing something, but I'm not sure what.
You need to update the CRL to revoke the certificate. The user then can't use it for authentication. Alan DeKok.
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 as the certificate is fine.
That's how EAP-TLS works.
Ok, I understand. But, is it any way in what we can only take care of the commonName on the certificate, ignoring what the user is sending in?
So, in this case, if the user isn't allowed to login because of simultaneous use, he still can change the username which he uses specifying another one (whichever, even if it doesn't exist) and voilá! He can now log in.
I'm sure I'm missing something, but I'm not sure what.
You need to update the CRL to revoke the certificate. The user then can't use it for authentication.
But in this case, the user will no longer be able to login to the system, until he gets a new certificate, right?
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 login because of simultaneous use, he still can change the username which he uses specifying another one (whichever, even if it doesn't exist) and voilá! He can now log in.
I'm sure I'm missing something, but I'm not sure what.
Any clue?
Read doc/rlm_ldap, bit about access attribute. Ivan Kalik
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 login because of simultaneous use, he still can change the username which he uses specifying another one (whichever, even if it doesn't exist) and voilá! He can now log in.
I'm sure I'm missing something, but I'm not sure what.
Any clue?
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. Alan Dekok already said that this is how EAP-TLS works, but I'm not sure if it's normal to have freeradius ignoring what rlm_ldap say about the account. Shouldn't be something like "grant access ONLY if all conditions (valid certificates, valid ldap account) apply"?
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 doc/rlm_ldap, bit about access attribute." Your problem is that you haven't set up ldap to reject users without valid accounts. How do you do that? Read the document and find out. Ivan Kalik
participants (3)
-
Alan DeKok -
gera -
tnt＠kalik.net