Overriding a Crypt-Password with a Cleartext-Password in FR 3.x

[Bjørn Mork]

Alan DeKok <aland at deployingradius.com> writes:

> On Jun 6, 2017, at 9:12 AM, Bjørn Mork <bjorn at mork.no> wrote:
>> 
>> I recently upgraded from FR 2.2.5 to FR 3.0.12 as part of an upgrade
>> from Debian jessie to stretch.  The config had to be migrated manually,
>> which went mostly without problems.
>
>   That's good.
>
>> I use the unix module to load crypt passwords for a few system
>> users. But there are also some unix users without any Unix password,
>> which should exist as RADIUS users. "no Unix password" means that the
>> users have a /etc/shadow entry which cannot be matched. So I need to
>> ignore the Crypt-Password attribute for these users.
>
>   i.e. they have a password, but it's wrong?

In a way. They typically have an entry like this, with an "impossible"
password hash:

 luser:!:13493:0:99999:7:::


The unix module does not sanity check the entry, and you end up with:


..
Tue Jun  6 16:51:22 2017 : Debug: (0)     modsingle[authorize]: calling unix (rlm_unix)
Tue Jun  6 16:51:22 2017 : Debug: (0)     modsingle[authorize]: returned from unix (rlm_unix)
Tue Jun  6 16:51:22 2017 : Debug: (0)     [unix] = updated
..
Tue Jun  6 16:51:22 2017 : Debug: (0)   } # authorize = updated
Tue Jun  6 16:51:22 2017 : Debug: (0) Found Auth-Type = PAP
Tue Jun  6 16:51:22 2017 : Debug: (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
Tue Jun  6 16:51:22 2017 : Debug: (0)   Auth-Type PAP {
Tue Jun  6 16:51:22 2017 : Debug: (0)     modsingle[authenticate]: calling pap (rlm_pap)
Tue Jun  6 16:51:22 2017 : Debug: (0) pap: Login attempt with password "foo" (3)
Tue Jun  6 16:51:22 2017 : Debug: (0) pap: Comparing with "known good" Crypt-Password "!"
Tue Jun  6 16:51:22 2017 : ERROR: (0) pap: Crypt digest does not match "known good" digest
Tue Jun  6 16:51:22 2017 : Debug: (0) pap: Passwords don't match
Tue Jun  6 16:51:22 2017 : Debug: (0)     modsingle[authenticate]: returned from pap (rlm_pap)
Tue Jun  6 16:51:22 2017 : Debug: (0)     [pap] = reject
Tue Jun  6 16:51:22 2017 : Debug: (0)   } # Auth-Type PAP = reject
Tue Jun  6 16:51:22 2017 : Debug: (0) Failed to authenticate the user
Tue Jun  6 16:51:22 2017 : Auth: (0) Login incorrect (pap: Crypt digest does not match "known good" digest): [luser] (from client someswitch port 1)


Which is what you want most of the time, so I guess it's OK.


>> In FR 2.x I explicitly set the Auth-Type to foribly ignore the invalid
>> Crypt-Password, like this:
>> 
>> luser  Cleartext-Password := "foo", Auth-Type := Local
>> 
>> 
>> But FR 3.x refused to accept Auth-Type "Local". So I tried to modify the
>> entry to
>> 
>> luser  Cleartext-Password := "foo"
>> 
>> in the hope that the pap module would be smart enough to figure out that
>> the Cleartext-Password should override the invalid Crypt-Password.  It
>> was not.
>> 
>> Being unable to figure out the smart way, I just took the simple route
>> out by doing
>> 
>> luser  User-Password == "foo", Auth-Type := Accept
>
>   Don't do that...

Yes, I know :-)  Really bad.

>> so I'd really like to figure out a better way.  Is there a smart way to
>> override a Crypt-Password per user in FR 3.x?  I guess I could generate
>> crypted passwords from the cleartext passwords and simply override
>> Crypt-Password in the users file.  But that does not seem much nicer
>> than the current User-Password match to me.  What I really want is to be
>> able to say "use this Cleartext-Password no matter what".
>
>   You can use "unlang" to check and edit the request:
>
> authorize {
> 	...
> 	files
> 	...
>
> 	if (Crypt-Password && Cleartext-Password) {
> 		update request {
> 			Crypt-Password !* ANY
> 		}
> 	}
> 	pap
> }
>
>   Which should delete the Crypt-Password.  See "man unlang" for more details.

Thanks. That didn't quite work, but provided the direction I needed.
This did the job:


        if (config:Crypt-Password && config:Cleartext-Password) {
                update config {
                        Crypt-Password !* ANY
                }
        }



Don't know why I didn't figure that out before.  For some reason I had
my mind set on finding a solution in the "users" file.  Which of course
is not the place for policies like this.

Thanks.


Bjørn