> Ok I understand you don't want to have MD5/SHA1, but with the PAP > solution, you don't have to. Unless you are telling me that the > documentation or rlm_pap is wrong: > > https://freeradius.org/radiusd/man/rlm_pap.txt > > which is entirely plausible. Even if I am thinking that i miss > some pieces because i don't understand why you want to replicate > the user DB, once you have a RADIUS server. > > > I don't think the documentation is wrong. > > See the following table in that documentation: > Header Attribute Description > ------ --------- ----------- > {clear} Cleartext-Password clear-text passwords > {cleartext} Cleartext-Password clear-text passwords > {crypt} Crypt-Password Unix-style "crypt"ed passwords > {md5} MD5-Password MD5 hashed passwords > {base64_md5} MD5-Password MD5 hashed passwords > {smd5} SMD5-Password MD5 hashed passwords, with a salt > {sha} SHA-Password SHA1 hashed passwords > SHA1-Password SHA1 hashed passwords > {ssha} SSHA-Password SHA1 hashed passwords, with a > salt > SSHA1-Password SHA1 hashed passwords, with a > salt > {ssh2} SHA2-Password SHA2 hashed passwords > {ssh256} SHA2-Password SHA2 hashed passwords > {ssh512} SHA2-Password SHA2 hashed passwords > {nt} NT-Password Windows NT hashed passwords > {nthash} NT-Password Windows NT hashed passwords > {x-nthash} NT-Password Windows NT hashed passwords > {ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords > {x- orcllmv} LM-Password Windows LANMAN hashed passwords > {X- orclntv} LM-Password Windows LANMAN hashed passwords > When receiving a password with the PAP module, we have to choose > either one of those algorithms or cleartext. Se we are choosing > cleartext (over an encrypted tunnel if necessary), but delegating the > authorization, that is the check of the password stored with a > stronger hashing algorithm (and possibly more complex checks) to an > external application.
Exactly, my point is I have read that you can convince LDAP to do that, without doing it yourself. What is not entirely clear to me is if you can actually convince the module to do it for you, with one of the more secure hashes in the list and then use any other DB. > let's try again: what is the architecture you have in mind? given > the following scheme: > > > SU --- AU -------------- Radius ---- DB > > what are the components you control and what are the external > components you only plan to connect to? > > > In public wifi or university wifi settings, we control everything. > captive portal, VPNs, freeradius, openwisp2. > > In other settings like Eduroam or other 802.1x settings we may not > have control of access points that talk to freeradius, in that case we > would need to properly setup the TTLS tunnel between freeradius and > the parts we don't control. > > Let me offer a bit more context about django-freeradius > <https://github.com/openwisp/django-freeradius> because maybe you are > not aware of it. We are working to renovate an existing application > called OpenWISP User Management System > <https://github.com/openwisp/OpenWISP-User-Management-System>, which > is basically a freeradius management interface which creates a (very > weird) MySQL database that is then used by freeradius (usually > deployed with freeradius 2). This application has been used for many > years by many companies and municipalities to offer public wifi. OWUMS > has many important limitations and shortcomings which we are trying to > solve with this renovation. > So with django-freeradius we are trying to create the base openwisp2 > module that will take care of AAA in openwisp2, but in a cleaner way > which we aim will be simpler to extend and less costly to mantain and > evolve over time. > > I hope is clearer now. Thank you Federico, now everything is clear and I also understand your solution. best, leonardo. > > Federico > -- > You received this message because you are subscribed to the Google > Groups "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- Leonardo Maccari, Assistant Professor @DISI, University of Trento Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7 -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
