I've been running FreeRadius 2 on Centos 5.5 for a while now. So far so good. I'm now looking to make connecting to our WPA secured wireless easier. The RADIUS server is running in a VM and since the system is in use I have copied the original and used that copy to create a test environment. I have run through all system updates and have upgraded all relevant packages. The test system is at 5.6 now. Currently with Windows machines I can't just connect to the SSID and enter in a username and password. I have to go and manually add the SSID, modify some settings; specifically turning off validating server certificate, turning off automatically use my Windows login, and turning on User or computer authentication mode. We also have some OS X clients. Fortunately connecting via OS X is easier. The catch is that I have to join the machine to our domain. After that it's pretty much username and password, and they are on. Ideally I would like to have a simple "connect to this SSID, enter your username and password and that's it" solution and still have all requests checked against our Active Directory server. On a side note. I'm going through my settings trying to get this working more smoothly and I ran across: wbinfo --a user%password (yes I'm adding in my username and pass) plaintext password authentication succeeded challenge/response password authentication failed error code was NT_STATUS_ACCESS_DENIED (0xc0000022) error messsage was: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly. Could not authenticate user MYUSERNAME with challenge/response I know the 2 error lines are permissions related. I'm not sure what the permissions should be on this file/folder. Can someone let me know this? The tutorial from FreeRadius says that I should get output similar to: plaintext password authentication failed error code was NT_STATUS_NO_SUCH_USER (0xc0000064) error message was: No such user Could not authenticate user CHSchwartz%mypassword with plaintext password Yet ntlm_auth --request-nt-key --domain=MYDOMAIN --username=MYUSERNAME NT_STATUS_OK: Success (0x0) So the Auth is working. I don't understand though why my AD server is letting cleartext passwords through. It shouldn't right? Any help would be greatly appreciated. Dan <http://www.liai.org> <http://www.liai.org> <http://www.liai.org>
You didn't give much information regarding your environment, so some of the responses below are based upon assumptions: that you manage all devices that are connecting, that they are joined to your A/D domain and that you are using the Windows supplicant. You haven't said what version of Windows you are running and what version of FreeRADIUS you are running!
Currently with Windows machines I can't just connect to the SSID and enter in a username and password. I have to go and manually add the SSID, modify some settings;
If you are referring to PEAP vs. TLS, that's a Windows XP issue. XP defaults to TLS and won't connect automatically if you are using PEAP. However, you can push wireless policy to your Windows devices using A/D group policy and set this up automatically.
specifically turning off validating server certificate
This is a bad idea as you could be passing your credentials to someone else's RADIUS server. It's best to generate a certificate signed by an internal Certificate Authority and require a cert signed by that CA in your 802.1x config. This too can be pushed to Windows devices as part of your A/D policy assuming they are joined to your domain and run Windows.
turning off automatically use my Windows login, and turning on User or computer authentication mode.
Why do you want to use manual authentication as opposed to automatic? If the machines that are connecting are joined to your A/D domain, you may want to consider using machine authentication. User authentication, in the current release, doesn't support MS-CHAP password change. Also, user authentication with the Windows supplicant requires the presence of cached credentials (because you logon locally first and then connect to the wireless network) which may not match current A/D credentials.
error messsage was: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly.
Use "sudo wbinfo" or run it as root if you don't use sudo. That said, wbinfo isn't used by FreeRADIUS to authenticate to A/D (ntlm_auth is used for PEAP/MS-CHAPv2).
Garber, Thanks for your reply. We do not manage every machine in the building. We allow for users to bring in there personal laptops to work and they vary in manufacture and OS. We have machines with Windows versions ranging from XP to 7. Same is true with Mac OS X, the oldest version we run is 10.4.11 and the newest is 10.6.8. We have some Linux clients be these are all hardwired so they aren't a concern. All of the Macs in our building, that is the ones that aren't personal machines, are joined to our domain. The few PC machines that we do manage are joined to our AD server but I would say that the vast majority of the PCs are not managed and not joined to out AD server. All windows systems--XP through 7--have to be setup the way I described earlier in order for this to work.<http://www.liai.org> I don't think that I'm using the supplicant but I could be wrong. I'm running FreeRadius 2.1.7-7.e15 ( I believe this is the latest) with freeradius2-krb5-2.1.7-7.e15 and freeradius2-utils-2.1.7-7.e15. I'm pretty sure I'm using PEAP. I realize that and I'm going to work on using our wild card cert to better secure this. However the question still arises on will our SSL cert validate properly on a Windows system. When I initially set this up I never saw anything regarding and 802.11x config. After updating I seem to remember seeing this config file mentioned. "Why do you want to use manual authentication as opposed to automatic? If the machines that are connecting are joined to your A/D domain, you may want to consider using machine authentication. User authentication, in the current release, doesn't support MS-CHAP password change. Also, user authentication with the Windows supplicant requires the presence of cached credentials (because you logon locally first and then connect to the wireless network) which may not match current A/D credentials." Like I mentioned above not all, actually few machines, are managed via our AD server. I would love to change this but it would require far more administrative changes that I'm unable to make. Dan Like I mentioned our Windows versions vary from XP to 7. On 7/26/11 12:30 PM, Garber, Neal wrote:
You didn't give much information regarding your environment, so some of the responses below are based upon assumptions: that you manage all devices that are connecting, that they are joined to your A/D domain and that you are using the Windows supplicant.
You haven't said what version of Windows you are running and what version of FreeRADIUS you are running!
Currently with Windows machines I can't just connect to the SSID and enter in a username and password. I have to go and manually add the SSID, modify some settings; If you are referring to PEAP vs. TLS, that's a Windows XP issue. XP defaults to TLS and won't connect automatically if you are using PEAP. However, you can push wireless policy to your Windows devices using A/D group policy and set this up automatically.
specifically turning off validating server certificate This is a bad idea as you could be passing your credentials to someone else's RADIUS server. It's best to generate a certificate signed by an internal Certificate Authority and require a cert signed by that CA in your 802.1x config. This too can be pushed to Windows devices as part of your A/D policy assuming they are joined to your domain and run Windows.
turning off automatically use my Windows login, and turning on User or computer authentication mode. Why do you want to use manual authentication as opposed to automatic? If the machines that are connecting are joined to your A/D domain, you may want to consider using machine authentication. User authentication, in the current release, doesn't support MS-CHAP password change. Also, user authentication with the Windows supplicant requires the presence of cached credentials (because you logon locally first and then connect to the wireless network) which may not match current A/D credentials.
error messsage was: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly. Use "sudo wbinfo" or run it as root if you don't use sudo. That said, wbinfo isn't used by FreeRADIUS to authenticate to A/D (ntlm_auth is used for PEAP/MS-CHAPv2).
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 07/26/2011 04:10 PM, Dan wrote:
I'm running FreeRadius 2.1.7-7.e15 ( I believe this is the latest) with freeradius2-krb5-2.1.7-7.e15 and freeradius2-utils-2.1.7-7.e15.
2.1.7 is the latest in RHEL5. 2.1.11 is the latest from the FreeRADIUS project (just released a few weeks ago). Fedora has the latest upstream 2.1.11, but RHEL does not, why? See: http://wiki.freeradius.org/Red_Hat_FAQ We've been rebasing FreeRADIUS in the RHEL versions on average every other update cycle, no guarantee though. RHEL is generally not amenable to software rebases (i.e. changing to a new upstream version) because it's in conflict with RHEL's goal of long term stability. But we've got special dispensation for FreeRADIUS because of it's high churn rate. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
I don't think that I'm using the supplicant but I could be wrong.
The supplicant is the software on the client device that manages wireless profiles/connections. If Windows controls the wireless connections (Wireless Zero Config service) then you are using the Windows supplicant.
I'm running FreeRadius 2.1.7-7.e15 ( I believe this is the latest) with freeradius2-krb5-2.1.7-7.e15 and freeradius2- utils-2.1.7-7.e15.
2.1.7 is old! 2.1.11 is the latest version of FreeRADIUS..
I'm pretty sure I'm using PEAP.
This would be obvious in the wireless settings on the device.
I realize that and I'm going to work on using our wild card cert to better secure this. However the question still arises on will our SSL cert validate properly on a Windows system. When I initially set this up I never saw anything regarding and 802.11x config. After updating I seem to remember seeing this config file mentioned.
Windows clients require that certain extensions be present in the certificate (you can thank Microsoft for that - it's not a FreeRADIUS issue). If most of the machines are not joined to your domain and are personal devices and you want easy access, you'll want to use a certificate signed by a CA that's in the Windows root CA list. Just be aware that this is not as secure as an internal or self-signed cert. because any certificate from the CA you choose would be accepted (even if it's from someone else's RADIUS server); but, the alternative is that you would need to distribute the CA's cert to each user that wants to connect. I can't answer your question regarding whether your SSL cert will validate properly on Windows because you haven't said how it was generated? Is it self-signed? Is it signed by a CA that's in the root CA list of a device you were using to test? Does it include the required Windows extensions? There have been considerable discussion on the mailing list regarding the creation of certs that will work with Windows clients. Google is your friend (along with the doc inside the FR files).
Like I mentioned above not all, actually few machines, are managed via our AD server. I would love to change this but it would require far more administrative changes that I'm unable to make.
Makes sense..
Like I mentioned our Windows versions vary from XP to 7.
I thought, but can't verify right now, that starting with Vista, Windows will connect using PEAP without manual wireless configuration (i.e., it doesn't assume TLS as a default the way XP does). Perhaps your only issue with Vista/7 is that the cert doesn't have the required extensions or isn't signed by a CA that's in the root CA list of the device?
participants (3)
-
Dan -
Garber, Neal -
John Dennis