Forgive me if this seems too stupid to ask but I must be 100% sure of this - if Cleartext-Password is set to NULL in radcheck then this is equivalent to disabling the account?
On Aug 31, 2018, at 12:12 PM, Dom Latter <freeradius-users@latter.org> wrote:
Forgive me if this seems too stupid to ask but I must be 100% sure of this - if Cleartext-Password is set to NULL in radcheck then this is equivalent to disabling the account?
It will let them log in using "NULL" as the password. It's better to just remove the Cleartext-Password attribute from the database. Alan DeKok.
On 31/08/18 17:37, Alan DeKok wrote:
On Aug 31, 2018, at 12:12 PM, Dom Latter <freeradius-users@latter.org> wrote:
Forgive me if this seems too stupid to ask but I must be 100% sure of this - if Cleartext-Password is set to NULL in radcheck then this is equivalent to disabling the account?
It will let them log in using "NULL" as the password.
Really? That's a database NULL not a string containing those four letters.. The query returns a Cleartext-Password value of NULL. Debug output subsequently returns: (115) Tue Sep 4 12:54:21 2018: Debug: sql: User found in radcheck table (115) Tue Sep 4 12:54:21 2018: Debug: sql: Conditional check items matched, merging assignment check items (115) Tue Sep 4 12:54:21 2018: Debug: sql: Cleartext-Password := "" Is it possible to authenticate with an empty password string in any way? MSCHAPv2 is the backend. I have been trying to test this both with a real device and with tools, and although it seems a blank password gets rejected I would like to know...
It's better to just remove the Cleartext-Password attribute from the database.
Not really an option. We are using encrypted passwords [1] which are decrypted before being passed to freeradius. When new users are created they are sent a link which enables them to set a new password. Before this is used we'd like to have a placeholder value something like "not set yet". As this is not decryptable the query returns a NULL value. [1] So that it can be said that passwords are encrypted.
On Sep 4, 2018, at 8:10 AM, Dom Latter <freeradius-users@latter.org> wrote:
Really? That's a database NULL not a string containing those four letters..
Well then say that. I can't read your mind.
The query returns a Cleartext-Password value of NULL. Debug output subsequently returns:
(115) Tue Sep 4 12:54:21 2018: Debug: sql: User found in radcheck table (115) Tue Sep 4 12:54:21 2018: Debug: sql: Conditional check items matched, merging assignment check items (115) Tue Sep 4 12:54:21 2018: Debug: sql: Cleartext-Password := ""
Is it possible to authenticate with an empty password string in any way?
MSCHAPv2 is the backend.
Yes. If they enter an empty password.
I have been trying to test this both with a real device and with tools, and although it seems a blank password gets rejected I would like to know...
It depends on the client.
It's better to just remove the Cleartext-Password attribute from the database.
Not really an option.
It's a database... you can put different things in it. Or, delete things from it.
We are using encrypted passwords [1] which are decrypted before being passed to freeradius. When new users are created they are sent a link which enables them to set a new password. Before this is used we'd like to have a placeholder value something like "not set yet". As this is not decryptable the query returns a NULL value.
If you want to put garbage into the database, then you will get garbage results. If you want the system to behave properly, then put good data into the database. Alan DeKok.
On Tue, 2018-09-04 at 13:10 +0100, Dom Latter wrote:
When new users are created they are sent a link which enables them to set a new password. Before this is used we'd like to have a placeholder value something like "not set yet". As this is not decryptable the query returns a NULL value.
Be explicit about it in unlang? Along the lines of if (&Cleartext-Password == "") { reject } Seems like the safest way to me, whatever the default behaviour. -- Matthew
On 04/09/18 13:33, Matthew Newton wrote:
On Tue, 2018-09-04 at 13:10 +0100, Dom Latter wrote:
When new users are created they are sent a link which enables them to set a new password. Before this is used we'd like to have a placeholder value something like "not set yet". As this is not decryptable the query returns a NULL value.
Be explicit about it in unlang? Along the lines of
if (&Cleartext-Password == "") { reject }
Seems like the safest way to me, whatever the default behaviour.
That is a very helpful suggestion, thank you Matthew!
participants (3)
-
Alan DeKok -
Dom Latter -
Matthew Newton