Re: Questions regarding authentication systems and protocols to password types compatibility

2007-04-20 Thread Alan DeKok
Reimer Karlsen-Masur, DFN-CERT wrote:
> Which freeradius modules can be used for the *simple password store*?
>   files (the users file)
>   unix
>   pam
>   ldap
>   sql (?)

  Not PAM.

> Could you please complete this list? Are these entries ending up in the
> authenticate or authorize or both sections of the freeradius config?

  Databases don't do authentication.  They do not get listed in the
"authenticate" section.

  As for completing the list, it really depends.  You can configure many
modules to add a clear-text password for the user.  Please read
radiusd.conf, and the documentation for examples.  I'm not going to
re-type all that here.

> How do I differ within the ldap module configuration if I do an ldap
> authentication via the *oracle* or if I *retrieve* (additional) attributes
> for a user like e.g. his password?

  See the documentation for the LDAP module.

> Is the difference that the 'ldap' entry shows up in the 'authenticate'
> section for attribute retrieval use  (plain password store) which I have
> configured here and believe to be working and in the 'authorize' section for
> oracle use?

  You have that completely backwards.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Questions regarding authentication systems and protocols to password types compatibility

2007-04-20 Thread Reimer Karlsen-Masur, DFN-CERT
Thanks Alan!

Your answer is raising some more questions though:

Alan DeKok wrote:
> Reimer Karlsen-Masur, DFN-CERT wrote:
>> I appreciate the tables explaining the compatibility of authentication
>> systems / protocols to password type compatibility from:
> 
>> But I am still confused about the relationship of these two tables to each
>> other and how to use them.
>>
>> Is the following considered correct?
>>
>> 1. If I am using the back end DB (e.g. ldap or users file, etc.) as a simple
>> *password store*, only [table 1] if of interest.
> 
>   Yes.

Which freeradius modules can be used for the *simple password store*?
  files (the users file)
  unix
  pam
  ldap
  sql (?)

Could you please complete this list? Are these entries ending up in the
authenticate or authorize or both sections of the freeradius config?

...
>> 2. If I am using the back end DB (e.g. ldap etc.) as an *authentication
>> oracle*, [table 2] tells me which authentication oracle system I can use
>> (depending on the authentication protocol that the supplicant/client/user is
>> using)
> 
>   Yes.
> 
>> and [table 1] tells me in which format the passwords need to be
>> stored in the authentication oracle.
> 
>   Yes.  Except that PAP is compatible with all password formats.  Also,
> ntlm_auth is used on Windows, which stores passwords in cleartext or
> NT-Hash format, and nothing else.
> 
>   So after reading the "oracle" page, there's no need to go back to the
> other page to see how to store the passwords.
> 
>> And freeradius is able to connect to
>> the back end (if there is a rlm_ module available), to
>> authenticate *with the user provided* credentials (username/password) and to
>> optionally retrieve some attribute values if the *user* authenticated
>> successfully against the authN oracle.
> 
>   No.  Authentication has nothing to do with retrieving other
> information.  When an authentication oracle is used, FreeRADIUS takes
> the username && password, and hands them to the oracle.  The oracle
> returns yes/no, and nothing else.

How do I differ within the ldap module configuration if I do an ldap
authentication via the *oracle* or if I *retrieve* (additional) attributes
for a user like e.g. his password?

Is the difference that the 'ldap' entry shows up in the 'authenticate'
section for attribute retrieval use  (plain password store) which I have
configured here and believe to be working and in the 'authorize' section for
oracle use?

Thanks again for more insight on this!

-- 
Kind Regards

Reimer Karlsen-Masur

DFN-PKI FAQ: https://www.pki.dfn.de/faqpki
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737


smime.p7s
Description: S/MIME Cryptographic Signature
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Questions regarding authentication systems and protocols to password types compatibility

2007-04-20 Thread Alan DeKok
Reimer Karlsen-Masur, DFN-CERT wrote:
> I appreciate the tables explaining the compatibility of authentication
> systems / protocols to password type compatibility from:

> But I am still confused about the relationship of these two tables to each
> other and how to use them.
> 
> Is the following considered correct?
> 
> 1. If I am using the back end DB (e.g. ldap or users file, etc.) as a simple
> *password store*, only [table 1] if of interest.

  Yes.

> And freeradius is able to
> connect to the back end (if there is a rlm_ module available),
> authenticate itself with a special radius server account/user credential and
> to retrieve the password plus optionally some other attribute values if the
> radius server *itself* authenticates successfully with the back end DB. The
> radius server itself is then performing the user name/password check to
> accept or reject the authentication request of the user trying to connect.

  Yes.

> 2. If I am using the back end DB (e.g. ldap etc.) as an *authentication
> oracle*, [table 2] tells me which authentication oracle system I can use
> (depending on the authentication protocol that the supplicant/client/user is
> using)

  Yes.

> and [table 1] tells me in which format the passwords need to be
> stored in the authentication oracle.

  Yes.  Except that PAP is compatible with all password formats.  Also,
ntlm_auth is used on Windows, which stores passwords in cleartext or
NT-Hash format, and nothing else.

  So after reading the "oracle" page, there's no need to go back to the
other page to see how to store the passwords.

> And freeradius is able to connect to
> the back end (if there is a rlm_ module available), to
> authenticate *with the user provided* credentials (username/password) and to
> optionally retrieve some attribute values if the *user* authenticated
> successfully against the authN oracle.

  No.  Authentication has nothing to do with retrieving other
information.  When an authentication oracle is used, FreeRADIUS takes
the username && password, and hands them to the oracle.  The oracle
returns yes/no, and nothing else.

> ps: There is probably a small typo in the column heading of [table 1]:
> 'SSHA1 hash' should be 'SHA1 hash' and 'Salted SSHA1 hash' should be 'Salted
> SHA1 hash (SSHA1)'

  Fixed, thanks.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html