I want to force our office users to enter their LDAP credentials when connecting to the WiFi in our office. So I installed FreeRadius as instructed at:
Using FreeIPA and FreeRadius .
Using radtest, I can successfully authenticate against our FreeIPA server using PAP. Moving on I configured a WiFi connection on my Windows 10 laptop to use EAP-TTLS as the authentication method along with selecting PAP as the non-EAP method. Again I can successfully authenticate against our FreeIPA server when connecting to the WiFi AP. But I realize that is not safe since passwords are sent as clear-text.
So next I configured a WiFi connection on my Windows 10 laptop to use PEAP as the authentication method with EAP method of EAP-MSCHAP v2. But now authentication fails. An excerpt from the FreeRadius debug log shows:
(8) mschap: WARNING: No Cleartext-Password configured. Cannot create NT-Password
(8) mschap: WARNING: No Cleartext-Password configured. Cannot create LM-Password
(8) mschap: Creating challenge hash with username: test55
(8) mschap: Client is using MS-CHAPv2
(8) mschap: ERROR: FAILED: No NT/LM-Password. Cannot perform authentication
(8) mschap: ERROR: MS-CHAP2-Response is incorrect
I’m struggling to figure out a solution. I have found various configurations of eap, mschap & ldap files online but so far I have not solved my issue.
I’m not sure if I’m asking the right question but is the password hash sent by the Windows client incompatible with the password hash used by FreeIPA?
It turns out mschapv2 is a challenge response protocol, and that does not work with an LDAP bind in the basic configuration of FreeRadius.
However I did find a solution where FreeRadius looks up a user by their LDAP DN, then reads (not bind) the NTHash of the user. From there, FreeRADIUS is able to process the challenge response.
First permissions have to be given to service accounts:
https://fy.blackhats.net.au/blog/html/2015/07/06/FreeIPA:_Giving_permissions_to_service_accounts..html
After performing these steps users will need to change their password in order to generate an ipaNTHash.
Then configure FreeRadius to use mschapv2 with FreeIPA:
https://fy.blackhats.net.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html
After completing all the steps described in both links, this radtest cli command should return an Access-Accept response.
radtest -t mschap <ldap-user-uid> <ldap-user-password> 127.0.0.1:1812 0 <FreeRadius-secret>
Related
I have a freeradius server setup on my ubuntu VM. My Edgecore AP is connected to a MicroTik and Laptop. I have OpenWRT running on the AP and I'm able to connect a client using WPA2 Enterprise encryption. I'm trying to send a CoA request from the VM such as "Session-Timeout" however, observing the logs on the AP, I receive the message I've included in the title. Is CoA completely unsupported or hostapd simply can't understand the incoming request?
Dynamic Authorization Extensions (RFC 5176) is default disabled in hostapd.
set radius_das_port=3799 in your conf to enable this feature.
https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf
I'm using a u-Blox SARA-R422M8S cellular module trying to connect to Azure Iot Hub with the MQTT AT commands. The module supports MQTT 3.1.1. The login request fails with Broker connection refused, not authorized. Using the same credentials in the python example at Microsoft Azure documentation, the login succeeds and I can publish. I've uploaded the Baltimore root cert and activated the TLS for the socket, so this seems ok as well as I get another error code elsewise.
Anyone experienced similar?
PS, here are the AT commands used:
AT+USECPRF=0
AT+USECPRF=0,0,1
AT+USECPRF=0,3,"root_ca"
AT+UPSD=0,0,0
AT+UPSD=0,100,1
AT+UMQTT=11,1,0
AT+UMQTT=2,".azure-devices.net",8883
AT+UMQTT=4,"myhub.azure-devices.net/mydev/?api-version=2018-06-30","mysas""
As per the docs:
For the ClientId field, use the deviceId.
So you need to set the Client ID with something like:
AT+UMQTT=0,"mydev"
I'm trying to set up TLS mutual authentication between client and IBM-MQ queue manager (using the ibmcom/mq Docker image). The certificates are self-signed and created according to this article. As stated in the docs, it should be possible to bake in the server's private key and both certificates into the image. My Dockerfile looks like this:
FROM ibmcom/mq
USER mqm
COPY --chown=mqm:mqm 20-config.mqsc /etc/mqm/ # creation of additional queues, no problems here
COPY --chown=mqm:mqm keys_mq1/key.key /etc/mqm/pki/keys/mykey/
COPY --chown=mqm:mqm keys_mq1/key.crt /etc/mqm/pki/keys/mykey/
COPY --chown=mqm:mqm keys_client/client.crt /etc/mqm/pki/trust/0/
The files can be found in the running container:
/etc/mqm/pki/keys/mykey
drwxr-xr-x 1 mqm mqm 4096 Feb 16 11:18 .
drwxr-xr-x 1 mqm mqm 4096 Feb 16 11:18 ..
-rwxr-xr-x 1 mqm mqm 1253 Feb 16 10:54 key.crt
-rwxr-xr-x 1 mqm mqm 1704 Feb 16 10:53 key.key
/etc/mqm/pki/trust/0
drwxr-xr-x 2 mqm mqm 4096 Feb 16 13:34 .
drwxr-xr-x 3 mqm mqm 4096 Feb 16 13:34 ..
-rwxr-xr-x 1 mqm mqm 1054 Feb 16 13:29 client.crt
One thing to notice is that, according to the docs, the channel details should now show the following entry: CERTLABL(mykey). In my case, it's just CERTLABL( ). However, I'm not sure if that's the problem here, authentication of the server without client authentication seems to be working (see below).
DISPLAY CHANNEL(DEV.APP.SVRCONN)
1 : DISPLAY CHANNEL(DEV.APP.SVRCONN)
AMQ8414I: Display Channel details.
CHANNEL(DEV.APP.SVRCONN) CHLTYPE(SVRCONN)
ALTDATE(2020-02-16) ALTTIME(13.34.47)
CERTLABL( ) COMPHDR(NONE)
COMPMSG(NONE) DESCR( )
DISCINT(0) HBINT(300)
KAINT(AUTO) MAXINST(999999999)
MAXINSTC(999999999) MAXMSGL(4194304)
MCAUSER(app) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCAUTH(OPTIONAL)
SSLCIPH(ANY_TLS12) SSLPEER( )
TRPTYPE(TCP)
On client side, I created two Java keystores (JKS), one with the server's certificate (truststore) and one with the client's keypair.
My connection attempts were as followed:
Connecting to the default queue manager QM1 using the provided app user (no password) and DEV.APP.SVRCONN channel. The client application is an existing tool that perfectly works with the existing MQ infrastructure, I just exchanged the keystores and connection details.
Client exception: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
MQ log:
AMQ5534E: User ID 'app' authentication failed
AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
Connecting using the provided admin user and DEV.ADMIN.SVRCONN channel via IBM MQ Explorer (in this scenario, I switched to admin because app has insufficient rights to be used with MQ Explorer, regardless of the authentication method). I checked the "no password" option, since I want to authenticate with the client's certificate.
MQ Explorer error message:
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.
MQ log:
AMQ5540E: Application 'MQ Explorer 8.0.0' did not supply a user ID and password
AMQ5541I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
AMQ9557E: Queue Manager User ID initialization failed for 'admin'.
Same as 2., but omitting the client's keystore and providing the password instead. Works. The idea here was to verify that at least the server's certificate is configured correctly (on the other hand, I'm not sure if MQ Explorer is enforcing the check of the server's certificate against the truststore in the first place).
What am I missing?
edit: my actual goal is to use mutual authentication for the app user and DEV.APP.SVRCONN channel.
CHANNEL attribute CERTLABL
This attribute does not need to be set, unless you require to present a different certificate over this SVRCONN than all the other channels on the queue manager. If you do not have this requirement, leave CHANNEL attribute CERTLABL blank and just use the overall queue manager wide certificate. This is either following the default pattern of a certificate named ibmWebSphereMQ<qm-name> or uses the certificate label that you set using the following MQSC command:
ALTER QMGR CERTLABL(my-certificate-label)
Connection Authentication (MQ built-in Password checking)
A brand new queue manager created at V8 or above will have the Connection Authentication feature enabled, which means the queue manager will check any passwords you provide, and more importantly in your scenario, will demand that any privileged user id must supply one. The error message you report in connection attempt 1:
AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
and connection attempt 2/3:
AMQ5540E: Application 'MQ Explorer 8.0.0' did not supply a user ID and password
AMQ5541I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
... are telling you that connection authentication is mandating that your user id, which it considers privileged (i.e. member of mqm group or similar), has not supplied a password.
If you do not require password checking for any remotely connecting privileged user id, then you can turn this off with the following commands on the queue manager.
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
Mutually Authenticated SSL/TLS
In order to ensure mutually authenticated SSL/TLS, you will eventually need to ensure that your CHANNEL attribute SSLCAUTH is set to REQUIRED. But the easiest way to achieve this is to start with it set to OPTIONAL, and get to the point where the client is authenticating the queue manager's certificate, and then get it sending it's own, and finally set SSLCAUTH(REQUIRED) to ensure that it will only work if the client continues to do so.
You will need to ensure that you have set SSLCIPH on both ends of the channel. You don't mention that in your question, but the instructions you reference use SSLCIPH(ANY_TLS12) so I assume you have done the same.
If you successfully make a connection and are not sure whether the client has sent a certificate to the queue manager, use the following MQSC command:-
DISPLAY CHSTATUS(DEV.ADMIN.SVRCONN) SSLPEER SSLCERTI
to see the Subject's DN and Issuer's DN of the certificate sent by the client. If blank, it did not sent a certificate.
I just set up an freeradius server (Version 2.2.5) on an Raspeberian PI with DaloRadius 0.99 web interface. OS = Debian Jessy. I do not use certificates for authentification.
Everythings working fine, I restricted the used authentification types to "PEAP" for 1st authentification and the inner-tunnel (second auth to MSCHAP(V2)).
Now I recognized when I configure a client using PEAP and no inner tunnel Auth method it's although possible to dial in.
I want to restrict the second auth to only accept MSCHAP/MSCHAPV2 and not "none" as auth metohd.
I am working on freeRADIUS v1.1.7-r0.0.2 with LDAP as backend for authenticating users.
I want to configure freeRADIUS server with certificates instead of using usernames and passwords.
How to configure RADIUS+LDAP using SASL/Certificate based binding ?
Please guide me how to achieve this,is there any help/doc how to configure LDAP SASL bind for RADIUS Server.
Support for SASL binding was recently added in v3.0.x, both for administrative binds, and user binds, it's not available in previous versions.
See the SASL sections in the config here
Certificated based binding has always been supported. It's configured with the certificate_file and private_key_file config items.
You cannot pass the SSL tunnel through from something like an EAP conversation.