Thomas Linden <[EMAIL PROTECTED]> wrote:
> As I said in some earlier posting: I am using FreeBSD (4.7),
> which uses by default MD5-hashed passwords, which FreeRadius
> does not support.
Exactly. FreeRADIUS (or rlm_unix, in this case) knows nothing about
MD5-hashed passwords. It doesn't NEED to know.
What happens is that it calls getpwent() to get the password, and
then crypt() to encrypt the password. If password returned by
getpwent() is MD5'd, and the crypt() password is DES'd, then it won't
work.
Look at the 'man' page for crypt(). It requires a salt, which
FreeRADIUS gets from the password in getpwent(). Most (sane?) systems
implement crypt() so that if it sees an MD5 salted password, it
outputs an MD5 encrypted password string. The NetBSD'man' page
(I don't have access to a FreeBSD machine) says:
...
DESCRIPTION
The crypt() function performs password encryption. The
encryption scheme used by crypt() is dependent upon the contents
of the NUL-terminated string setting. If setting begins with the
``$'' character, a non-DES encryption scheme is selected
(currently MD5 hashing only). If setting begins with the ``_''
character, DES encryption with a user specified number of
perturbations is selected. If setting begins with any other
character, DES encryption with a fixed number of perturbations is
selected.
...
That makes a whole lot of sense to me.
How do you propose that FreeRADIUS work around the fact that your
system doesn't do this? The Unix module uses standard system calls to
get the passwords. There is little that the module can do if your
system gives MD5 passwords via one method, and DES passwords via
another.
> But you could be nice to FreeBSD users coming
> after me and telling them, what to do if they want to use
> Auth-Type=System:
>
> 1. either turn usage of MD5 off (/etc/auth.conf+/etc/login.conf)
> 2. or use DES (crypt(3)) encrypted passwords for Radius users
> 3. use "/etc/master.passwd" as "passwd" in radiusd.conf.
>
> OR:
> add MD5-Support to freeradius. It's time, we are in the 3rd
> year-thousand :-)
See the PAP module. It's there already, to a certain extent.
But FreeRADIUS doesn't HAVE /etc/passwd and getpwent() support. It
doesn't have crypt() support, either. Those calls are supplied by
your local system. e.g. select(), fopen(), and everything else.
Should FreeRADIUS ship with a socket library, too? After all, maybe
your OS doesn't support UDP packets...
> I did not complain (if you meant me). But, let me complain now:
> It *was* not documented. The guys here on the list helped me,
> not the docs. Read them yourself and you'll see.
Please look through your FreeBSD docs. If you can find anything
related to this issue, I would be happy to know.
> Well - configuring radius is a complicated task, that's why
> some people need help, which they get here (thanks again!),
> so why are you frustrated about this?
Some problems don't bother me. Others do.
The problems that bother me are ones where local configuration
issues are blamed on FreeRADIUS, and where people refuse to fix their
local systems, and instead expect FreeRADIUS (and often me) to do the
work for them.
e.g. Not having development libraries/headers for FOO in place, and
expecting rlm_FOO to build.
e.g. Putting the development libraries for FOO in a place where the
linker can't find them, and then blaming FreeRADIUS for the failed
compile/link.
e.g. Systems which have a function (e.g. pthread_create, MD5Init,
des_encrypt, sem_init, crypt) in libc, but which doesn't do what
it's supposed to do (often it does nothing at all)
Can you supply a patch to rlm_unix to make it work on FreeBSD? What
magic FreeBSD function does it have to call to get crypt() working in
a non-idiot manner? Why the heck would the FreeBSD people break
crypt() like this?
Does it really make sense to ship rlm_unix with 20 different pieces
of conditional code, for 20 different platforms? What the heck ever
happened to standard libraries?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
