Re: Calling station ID
On 12.07.2012 12:57, madal 30 wrote: >> From: sav...@savage.za.org >> To: freeradius-users@lists.freeradius.org >> On Thu, Jul 12, 2012 at 12:29 PM, madal 30 wrote: >> > Calling-Station-Id = ".031" >> >> > How do I or where do i adjust this parameter sothat full IP address is >> > logged in calling-station-ID ? I looked at detail file in modules/detail >> > but could not find the parameter >> >> The radius server can only process on what the NAS sends it. Look at >> the NAS and configure the NAS to send the correct/full >> Calling-Station-Id. >> > Where I can Configure this (in which file ?) In Freeradius? Nowhere. You have to alter the configuration of the device you are logging in to. "192.168.1.1" in your case. Freeradius only processes the data sent from the device. If this data is wrong or incomplete, Freeradius can do nothing about it. Grüße, Sven. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WPA Enterprise Certificate renewal for FreeRadius
Mike Diggins wrote: > Do the certificates need to be listed in any particular order in the > certificate_file? I have had the best experience with the following order: Server-Cert frist then Intermedite-Cert [ then additional Intermedite-Certs ] then Root-Cert The Root-Cert can be omitted, but its presence made no difference in my environment. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WPA Enterprise Certificate renewal for FreeRadius
Mike Diggins wrote:
> I use a Thawte Premium Server CA for my WPA2 Enterprise freeradius
> authentication certificate currently. My eap.conf 'certificate file'
> contains the certificate only, not the root and/or intermediates. That
> seems to be ok, since most clients already have the Thawte Root
> certificate installed.
> I renewed the new certificate just recently and discovered that Thawte
> is no longer issuing certificates under the old root so my clients
> will likely be asked to trust the new certificate when I install it.
> All my documentation changes as well but that's another story.
> My question is, what is the value of adding the roots/intermediates to
> the certificate file i.e certificate_file =
> ${certdir}/certificate.crt? Does it really allow a client without the
> Root already installed to verify this certificate?
No, if the client does not know/trust the root certificate, it will not
work/ask the user.
But it will help if the client only includes the root but not any
intermediate certificates.
So it is a good idea to append intermediate and root certificates (i.e.
the whole chain to the root) to your server certificate.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Change of network adapters in radius server
Roland Pinches wrote: > We've run into a problem with our freeradius server virtual machine. > It's a RHEL5.5 VM running on ESXi 4.1 and it talks to a cisco NAS. It > currently works but we have performance issues, which I have partly > tracked down to a very specific VMware issue - if running linux with > more than 1 vCPU, vmxnet3 NIC connected to a distributed vSwitch. The > work around is to change the network adapters to something other than > a vmxnet3 adapter. > However, this is where my radius problem comes in. When I change the > NICs, the MAC address changes, which means I need to setup the static > IP addresses again. Not a problem and I can then ping the cisco device > and the cisco device can ping the radius server. The problem is, no > radius traffic flows between them. You can override the generated MAC. Try putting in the one fromt the vmxnet3 NIC and see what happens. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS/EAP-TLS with freeRADIUS
Mr Dash Four wrote: >> Addition: The first FreeRADIUS version to include native RADsec >> support will be 3.0. To use it with a version below that, you usually >> proxy your normal RADIUS request through a software like radsecproxy. > Very interesting indeed. How about tunnelling (via ssh for example) - > is that a similar technique? Very unusual. Normally, you only control one of two RADIUS servers, one being the one in your network and the other one being located in some other organization. Of course you can create a tunnel between the two servers, but this would be custom, non-standard setup. >> But again: this is normally only used between RADIUS servers across a >> insecure network and not betweens a client (meaning an AP or a >> modem-server, etc.) and its RADIUS server. > If there is something I learned about such things, it is that when it > comes to security issues one can *never* be too careful! Well, if you cannot trust your own internal network, then you have other problems than securing your RADIUS authentication. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS/EAP-TLS with freeRADIUS
Mr Dash Four wrote: >>> In other words, EAP-TTLS/EAP-TLS isn't actually supported in >>> freeRADIUS? >> It is. I believe you misunderstood how RADIUS works. >> > Maybe, considering I've been reading about RADIUS for just over 2 days... >> The connection between the AP (called NAS in RADIUS) and the >> RADIUS-Server is only protected by the shared secret configured in >> clients.conf. >> >> Yes, this is kind of weak. > It is *very* weak, not least because connections can be intercepted as, > I presume is the case here, this "shared secret" is transmitted in the > clear over the wire. If that is not the case and it is hashed, then, > that's another story. No, the shared secret is not transmitted over the wire. For additinal information see RFC2865, §2: "When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. (see RFC131). >> And because of this weakness a protocol like RADsec has been >> developed, which is essentially RADIUS-with-SSL-over-TCP, thus >> providing strong encryption of the whole RADIUS session. > Interesting, noted. It would be nice if this works in a similar way as > the SSL handshake works - this is very secure, tested and already > established in the real world. RadSec works this way, yes. Think of it like HTTPS for RADIUS. >> Back to EAP-(T)TLS: >> >> The connection between a connecting device such as a laptop, which >> connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol >> transported via RADIUS packets. >> >> This of course is supported by FreeRADIUS since ages. > OK, my understanding of EAP-TTLS/EAP-TLS is that the authentication > happens in two distinct stages: the first stage (EAP-TTLS) is the outer > authentication where the server presents its credentials/certificate to > the client and then the secure channel is established. Phase two > (EAP-TLS in my case) is where the client - via its client certificate - > is actually authenticated to the RADIUS server. Now, I was hoping that > the AP does this in a similar sort of way when authenticating itself to > the RADIUS server, but it seems that is not the case and this is indeed > a weak point. No, the AP does not authenticate itself to the RADIUS server via TLS, just via the shared secret configured in clients.conf. > My question still remains though - since this is a two-phase > authentication, two distinct sets of (ca, server, client) certificates > can be used. How do I specify these in RADIUS? Which distinct set of certificates? The server certificate and key is configured via eap.conf. Which client certificates the RADIUS server trusts is configured via CA_file, also in eap.conf. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS/EAP-TLS with freeRADIUS
Sven Hartge wrote: > Yes, this is kind of weak. And because of this weakness a protocol like > RADsec has been developed, which is essentially > RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole > RADIUS session. Addition: The first FreeRADIUS version to include native RADsec support will be 3.0. To use it with a version below that, you usually proxy your normal RADIUS request through a software like radsecproxy. But again: this is normally only used between RADIUS servers across a insecure network and not betweens a client (meaning an AP or a modem-server, etc.) and its RADIUS server. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS/EAP-TLS with freeRADIUS
Mr Dash Four wrote: >>> After reading various howto's and documentation as well as looking >>> at numerous sources on the Internet, I can't see a way in which the >>> AP is authenticated to the RADIUS server by using only its >>> certificate attributes (CN, Subject, Issuer etc) - it seems that >>> freeRADIUS always needs some sort of "password" or "shared secret" >>> specified. >> so it is, you can only protect your AP client with the shared secret >> key. > In other words, EAP-TTLS/EAP-TLS isn't actually supported in > freeRADIUS? It is. I believe you misunderstood how RADIUS works. The connection between the AP (called NAS in RADIUS) and the RADIUS-Server is only protected by the shared secret configured in clients.conf. Yes, this is kind of weak. And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session. So far I have not seen any devices like APs, Dial-in-Servers, etc. support RADsec. But this is normally no problem, since those devices are usually located in a safe network with the RADIUS server. RADsec for example is used in the Deutsche Forschungsnetz (DFN), to secure inter-university RADIUS connections over the Internet to authenticate Eduroam users. Back to EAP-(T)TLS: The connection between a connecting device such as a laptop, which connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol transported via RADIUS packets. This of course is supported by FreeRADIUS since ages. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Keeping plain-text shared secret and user passwords in sql
asdf zxcv wrote: > I'm attempting to use freeradius to authenticate wireless network in > my organisation, using self-signed certificates. I have installed > freeradius 2.1.10 from debian 6 repository, set up basic configuration > according to instructions on freeradius.org site, finally I've > configured freeradius to use mysql. > It seems to work properly, but i wonder if it is safe to keep user > password and client secret in plaintext? I searched the lists and > googled a bit, but I can't find any information regarding this case. > So: > 1 - is there a way (or sense) to hash shared secret in my database? Not if you have to support challange handshake authentication. If you only use MSCHAPv2 or PAP, then you can store the password as an NT-Hash. This is somewhat safer than clear text, but should still be secured, because both the NT-Hash and the LM-Hash are quite easily broken (l0pthcrack etc.) > 2 - Can I hash user passwords if I'm using eap-tls? > 2a - if I'm using certificates for authentication, do I actually need to > keep user passwords? Cause it seems that they aren't used during > authentication (or I didn't find that part during debuging) If 2a, then no, as the certificate is the only needed credential of a user/system, no username/password involved. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP/MSCHAP
Andreas Rudat wrote: > Am 12.11.2011 23:00, schrieb Sven Hartge: >> This also means you have to protect those Hashes inside your database >> like a raw cleartext password, as you can authenticate to any Windows >> box with the knowledge of the NT/LM-Hash. >> >> This has been exploitet by several Windows trojan horses, which >> grabbed to NT-Hash from the Administrator user to login into other >> boxes on the network using the same password (or worse: the domain >> controller). > Ah much thanks for that clearing, so both is bad no matter which > mechnism is used. Yes. Storing the NT-Hash has the advantage of not completley exposing the cleartext password to a possible intruder. Storing the LM-Hash is just dumb, because a) it limits the the length of the password to 16 characters and b) LM-Hash is easily broken in seconds by todays computers. Storing the raw cleartext password is as bad, but it enables one to use other challange-handshake auths, if needed. I chose to store the raw cleartext password in LDAP, but in a different attribute than the normal userPassword. This way, if my LDAP servers ever get compromised (or I mess up with an ACL, enabling anyone to read the cleartext password), just the WLAN/Dialup-Password of a user is revealed and not the master password for the account, which is used for mail, login in to computers, etc. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP/MSCHAP
Sven Hartge wrote: > Andreas Rudat wrote: >> Am 11.11.2011 03:56, schrieb Fajar A. Nugraha: >>> On Fri, Nov 11, 2011 at 8:29 AM, Gary Gatten wrote: >>>> I agree with Jake, in that I *think* it would be possible to have a >>>> plugin or whatever interface with LDAP/AD in the same manner >>>> ntlm_auth does. I don't think one *needs* a cleartext password, >>>> but does need some way to compare apples-to-apples. >>> That's exactly what Alan is saying: " store your passwords in the >>> LDAP as NT-Password or LM-Password " >> But if that works, why then all are saying that you can just work >> with plaintext? Its realy confusing. > NT/LM-Password is "special". This is why it works with MSCHAPv2, both > being a MicroSoft "invention". To be precise: MSCHAPv2 works with the NT/LM-Password as input to the Challenge-Handshake and not the "raw" cleartext password. This is why this works. FreeRADIUS converts a cleartext password into the needed NT-Hash and then applies this to the MSCHAPv2 handshake. Or it uses a pre-existing NT-Hash from LDAP/MySQL/whatever. Quote from http://en.wikipedia.org/wiki/NTLM , | The NTLM protocol uses one or both of two hashed password values, both | of which are also stored on the server (or domain controller), and which | are password equivalent, meaning that if you grab the hash value from | the server, you can authenticate without knowing the actual password. ` This also means you have to protect those Hashes inside your database like a raw cleartext password, as you can authenticate to any Windows box with the knowledge of the NT/LM-Hash. This has been exploitet by several Windows trojan horses, which grabbed to NT-Hash from the Administrator user to login into other boxes on the network using the same password (or worse: the domain controller). Grüße, S° -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP/MSCHAP
Andreas Rudat wrote: > Am 11.11.2011 03:56, schrieb Fajar A. Nugraha: >> On Fri, Nov 11, 2011 at 8:29 AM, Gary Gatten wrote: >>> I agree with Jake, in that I *think* it would be possible to have a >>> plugin or whatever interface with LDAP/AD in the same manner >>> ntlm_auth does. I don't think one *needs* a cleartext password, but >>> does need some way to compare apples-to-apples. >> That's exactly what Alan is saying: " store your passwords in the >> LDAP as NT-Password or LM-Password " > But if that works, why then all are saying that you can just work with > plaintext? Its realy confusing. NT/LM-Password is "special". This is why it works with MSCHAPv2, both being a MicroSoft "invention". S° -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP/MSCHAP
"Sallee, Stephen (Jake)" wrote: > Please forgive the interjection, but does anyone know of a helper > module like ntlm_auth that would work with LDAP, seems like such a > tool would make questions like this a non-issue. No, will not work. You can't transform the normally used hashes back into a cleartext password. (This is kind of the whole point of a hash.) As long you don't have any means to provide FreeRADIUS with a cleartext password or the NT/LM-Hash, you are doomed. ntlm_auth just offloads the whole Challenge-Response exchange from the RADIUS server to the ActiveDirectory (as far as I understand it) using the ntlm_auth binary from Samba. Again: the AD will have to know the cleartext password in some way (either encrypted or somehow "pre-hashed") to make this work. (Don't know the specifics, I am a Unix guy, the only Windows near me is on my gaming computer.) Grüße, S° -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP/MSCHAP
Whitlow, Michael wrote:
> I am really close to a successful Freeradius implementation for 802.1X
> wireless using LDAP authentication on the back end.
Nope, you are not very close.
You _cannot_ use any LDAP authentication (via binding with a DN to the
LDAP server) with any CHAP authentication. This will never work.
You cannot use LDAP as an authentication oracle here, you have to use it
more like a database.
See http://deployingradius.com/documents/protocols/oracles.html, quote:
"An authentication oracle is a system where the RADIUS server does not
perform the authentication itself, but instead passes the users
authentication credentials to another system. "
This does NOT work with MSCHAP, since the RADIUS server _does not have_
the complete authentication credentials in this case, it is missing the
password. The only thing it has, is the hashed version, the so called
"challenge".
> Here is what I have:
> - RADTEST / clear text Freeradius password from "users" file /
> WORKS GREAT
Works because of the cleartext password.
> - Windows XP 802.1X PEAP/MS-CHAPv2 wireless client / clear text
> Freeradius password from "users" file / WORKS GREAT
Works because of the cleartext password.
> - RADTEST / LDAP credentials / WORKS GREAT
Works, because this uses PAP, which does _not_ need a cleartext password
on the RADIUS server, because radtest supplies a cleartext password
itself in the RADIUS packet (inside attribute User-Password) and the
servers ldap modules then can use this information to bind to the LDAP
server using the username and the supplied password from radtest.
CHAP does _not_ work like this.
> - Windows XP 802.1X PEAP/MS-CHAPv2 wireless client / LDAP
> credentials / NO GO
Does not work, because you don't have any cleartext password in the
RADIUS server, because your LDAP setup does not provide one.
And before you ask: no, just reading userPassword from the LDAP server
will not help, because in 99.9% this is a crypted password, mostly
hashed using SHA1.
> Here is the debug output. I have read others online with these symptoms
> but nothing I have found yet will help me.
This is untrue. This comes up every fscking time any one tries to use
LDAP and MSCHAP. It is a common error.
> [mschapv2] +- entering group MS-CHAP {...}
> [mschap] No Cleartext-Password configured. Cannot create LM-Password.
> [mschap] No Cleartext-Password configured. Cannot create NT-Password.
You will need to do the following:
a) setup a special user inside your LDAP tree for freeradius. This
special user needs to have the correct permissions to read an attribute
with the cleartext password of any user.
b) configure this special user in {confdir}/modules/ldap, search
for "identity"
c) change password_attribute to the cleartext-password attribute you
are using if it is not userPassword. (I strongly recommend using a
different password attribute for your users, but the default is OK too,
if you don't mind having the main password for a user being in cleartext
inside your LDAP tree.)
This way FreeRADIUS logs into the LDAP server using its own credentials,
searches for the username, reads the cleartext password and _THEN_ the
mschapv2 module is able to work.
This is the _only_ way to get MSCHAPv2 to work with LDAP.
And this has been discussed in this list every time anyone tried to tie
LDAP and FreeRADIUS.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authentication issues with Win7 and WPA/WPA2 Enterprise
Phil Mayers wrote: > On 18/05/11 17:10, Gary Gatten wrote: >> I would LOVE if W7 just worked! People here are blaming FR and I'm >> trying to convince them it has nothing to do with it, but since the >> MSCHAP challenges / responses are hashed I can't PROVE it to them. > Are you / have you been able to: > 1. stop terminating the PEAP on the Aruba > 2. upgrade to FreeRADIUS 2.1.10 I can at least confirm the following from my Aruba setup here: a) _not_ terminating the outer EAP-PEAP in the Aruba and b) passing the whole thing to FR 2.1.10 works with any Windows I have so far encountered. (as far as the other things like server certificate chain, etc. are correct.) So the setup Win7->Aruba->FR _will_ work, if you don't let the Aruba gear fiddle with your EAP. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius + EAP-TLS + LDAP
Phil Mayers wrote: > On 19/04/11 15:24, Sven Hartge wrote: >> Alexandros Gougousoudis wrote: >>> The users should be checked by uid and the password should be >>> checked, but I have of course no cleartext-password in my LDAP, they >>> are all crypt or MD5 (depends on tree). >> >>> Is this possible or not? >> >> No, impossible. >> >> If you want to use LDAP to authenticate your users, you _need_ a >> cleartext password somewhere. > Hang on - the OP said he wanted to do EAP-TLS. > For EAP-TLS there is no inner-auth, and no passwords. Ah, yes. But he also wrote about checking the password. EAP-TLS uses client certificates, no user password involved. Grüße, S° -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius + EAP-TLS + LDAP
Alexandros Gougousoudis wrote: > The users should be checked by uid and the password should be checked, > but I have of course no cleartext-password in my LDAP, they are all > crypt or MD5 (depends on tree). > Is this possible or not? No, impossible. If you want to use LDAP to authenticate your users, you _need_ a cleartext password somewhere. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius Ldap
Usuário do Sistema wrote:
> Hello everyone, I'm dificult with freeradius and LDAP.
> the user autheticate only it's work when I put in the user file
> User-Password clear text as follow.
> "maicon.pereira"Cleartext-Password := "meleca"
>Reply-Message = "Hello, %{User-Name}"
> however, my integration between Freeradius and Ldap it isn't working.
> My question is: there is possible to make the intragation?? because
> I've read that freeradius needs supply to ldap User-Password clear
> text.
> it's true ??
That depends. If you want to use _any_ Challenge-Handshake auth method
like MSCHAPv2 for wireless LAN you need to supply a cleartext password.
If you only want to use PAP, you can keep using ldap_bind() and an
encrypted/hashed password.
>[-- text/html, encoding quoted-printable, charset: ISO-8859-1, 30 lines --]
Ugh.
Grüße,
Sven.
--
Sig lost. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Load Balancing FreeRADIUS with CLUSTERIP
Alan DeKok wrote: > Randy Wilson wrote: >> I'm considering assigning a CLUSTERIP to the servers so we can make >> full use of the resources. Does anyone see any potential issues of >> using this with FreeRADIUS or know of any caveats I should be aware >> of? > EAP won't work. It requires multi-packet round trips between one > client and one server. If the hashing is stable (which it is, if I understand the CLUSTERIP feature of netfilter right) and thus one IP always connects to the same cluster server, EAP should work as well. And if one server goes down, EAP sessions in progress at that moment will fail anyway and need to be restarted with a new target server, no matter if one uses a classic primary/secondary setup or the clusterip variant. Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: revision control
Phil Mayers wrote: > On 16/02/11 14:54, Raymond Norton wrote: >> Is there any way to use some sort of revision control for .deb >> installs, outside of snapshots on a VM? > I assume this relates to your other posts. > You don't need to version-control the binaries. > You only need to version-control the config directory /etc/raddb, and > you can do this with any version control system. One of the new DVCSes > are is a good choice for this (e.g. git, bzr, hg) I use etckeeper for this task. It keeps /etc in git (or hg or bzr) and is automagically updated whenever the package system is run. Or manually by the admin, if he chooses to do so. Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.1.10 Certificate Compatibility Warning
Ben Wiechman wrote: > I've been testing EAP-TTLS/MSCHAPv2 authentication with a network > device. FreeRADIUS keeps complaining about EAP sessions not finishing > with the link to the certificate compatibility wiki link, however the > authentication process completes successfully. Looking at the packet > exchanges more carefully it appears that the supplicant is not > incrementing the Packet Identifier. Every EAP packet sent by the > device uses an packet identifier of 0. I have seen the same, using wpasupplicant-0.6.10-2.1 from Debian Unstable with a Linksys WAP54G (latest german firmware) and FreeRADIUS 2.1.10. Authentication succeeds but FR complains about never finishing sessions nevertheless. Unfortunately I cannot test right now if the packet identifier is always same in my case as well. Grüße, Sven -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Query
karnik jain wrote: > But as per RFC 2865, what is the meaning of then "UTF-8 encoded 10646 > [7] characters", the [7]? 7 stands for what over here? Footnote 7: [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ldap and (automagic) xlat
Alan DeKok wrote: > Sven Hartge wrote: >> Just out of curiosity: is there an easy way to see the whole contents >> of all lists while debugging? > Not really. It's a *lot* of data. Yeah, I thought so. Another thought: Are those lists fully available to the perl module? Maybe then I could just dump the %hashes to disk to examine them. > It's possible to patch the server to do this. If you do it, send us > the patch. :) Nah, my C-fu is just too bad to do this ;) I will have to live with the situation as is. Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ldap and (automagic) xlat
Alan DeKok wrote:
> Sven Hartge wrote:
> ...
>> | update request {
>> | GIFB-NetzAccStatus :=
>> "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-NetzAccStatus?sub?uid=%u}";
>> | GIFB-Status :=
>> "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-Status?sub?uid=%u}";
> ...
>> Now, for my rather simple question:
>>
>> Why can't I just add the following to ldap.attrmap and have the ldap
>> module add those two attributes automagically. Why do I have to use two
>> separate ldap_xlat queries:
>>
>> checkItem GIFB-NetzAccStatus GIFB-NetzAccStatus
>> checkItem GIFB-Status GIFB-Status
> That doesn't seem to be consistent. "update request" versus "checkItem" ?
Correct. This was my configuration _before_ I used the "update request"
method to get this information. As I said: this was just a
misunderstanding of the involved mechanisms on my side.
>> I also tried this with "replyItem" instead of checkItem and also
>> tried adding ":=" as the operator, but without the separate ldap_xlat
>> queries both RADIUS-Attributes are not available after the normal
>> ldap module ran.
>>
>> It seems I am missing some crucial part of information here or just
>> lack the understanding of this part of Freeradius.
> They attributes *are* added, to the list that you specified. If you
> want to refer to them in a particular list, see "man unlang".
> Referring to them a "GIFB-NetzAccStatus" means referring to that
> attribute in the *request*, not the *control* list, and not the
> *reply* list.
Ah! I need to use "%{control:GIFB-NetzAccStatus}".
Thank you, this was just the little nudge, I needed.
Just out of curiosity: is there an easy way to see the whole contents of
all lists while debugging? This would have saved me this question, as I
could have easily spottet my data in the output.
Grüße,
S°
--
Sig lost. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: duplicate users + Free Radius
Tyler Nally wrote: > Curious... assuming FreeRadius is configured to allow people to use > the NAS via a username/password combination... would that allow > johndoe to use both laptop computer and iPhone (and other wifi enabled > devices) concurrently? or does FreeRadius boot the oldest > authenticated login off of duplicate uses? The depends on your configuration. Normally freeradius just sends another Access-Accept and is done with it. If you want to disable duplicate logins, you have to keep the state of active logins somewhere (SQL database) and check for an existing session if a new requests comes in. This will disallow the second login to happen. If you want to boot the first login from the device and allow the second one, this gets a bit more complicated, as you have to actively tell the device to disconnect the first session. I think the correct search term here may be "CoA" or "Change of Authorization". Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_ldap and (automagic) xlat
Hi all!
I am using freeradius 2.1.10 (from backports) on a Debian Lenny server
to authenticate wireless users using EAP and normal users (from Ascend
NAS and ASA5510) with CHAP and PAP and so on.
My backend is a LDAP directory (OpenLDAP).
So far, everything is fine and working great.
My question is more about fine tuning some aspects and some
understanding issues with the way rlm_ldap adds (or doesn't add)
attributes to the query/reply.
I need to explain a bit about my environment:
I have two LDAP attributes, which control the state of the account of a
user:
a) gifb-Status ("1" means enabled)
b) gifb-NetzAccStatus ("1" again means enabled)
- gifb-status gets set to "0" if the password expires or the account gets
disabled because of other reasons.
- gifb-NetzAccStatus gets set to "0" if the networking account has to be
disabled
If any of the two attributes is != 1, then the user has to be rejected.
To achieve this, until recently I had a filter like the following for
the ldap module:
filter =
"(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(objectclass=gifb-NetzAccount)((gifb-status=1)(gifb-NetzAccStatus=1))"
This worked OK, ie. the user was rejected if his account was disabled,
because he wasn't even found by the ldap module. But this also resulted
in somewhat ugly log entries:
Sun Oct 3 20:38:18 2010 : Auth: Login incorrect ( [ldap] User not found):
[123] (from client alb13 port 5 cli 00236CDEADBF via TLS tunnel)
Sun Oct 3 20:38:18 2010 : Auth: Login incorrect: [123] (from client alb13
port 5 cli 00236CDEADBF)
So, using unlang I created the following, adjusting my filter first ...
filter =
"(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(objectclass=gifb-NetzAccount))"
... adding to the dictionary ...
ATTRIBUTE GIFB-NetzAccStatus 3000integer
ATTRIBUTE GIFB-Status 3001integer
and then in the inner-tunnel:
,[sites-enabled/inner-tunnel
| ldap
|
| if ( !notfound ) {
| update request {
| GIFB-NetzAccStatus :=
"%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-NetzAccStatus?sub?uid=%u}";
| GIFB-Status :=
"%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-Status?sub?uid=%u}";
| }
| if ( GIFB-NetzAccStatus != 1 ) {
| update reply {
| Reply-Message = "User denied by GIFB-NetzAccStatus"
| }
| reject
| }
| if ( GIFB-Status != 1 ) {
| update reply {
| Reply-Message = "User denied by GIFB-Status"
| }
| reject
| }
| }
`
This also works great, I get meaningful log-entries and everything is
OK.
Now, for my rather simple question:
Why can't I just add the following to ldap.attrmap and have the ldap
module add those two attributes automagically. Why do I have to use two
separate ldap_xlat queries:
checkItem GIFB-NetzAccStatus GIFB-NetzAccStatus
checkItem GIFB-Status GIFB-Status
I also tried this with "replyItem" instead of checkItem and also tried
adding ":=" as the operator, but without the separate ldap_xlat queries both
RADIUS-Attributes are not available after the normal ldap module ran.
It seems I am missing some crucial part of information here or just lack the
understanding of this part of Freeradius.
Please enlighten me.
Grüße,
Sven.
--
Sig lost. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
Phil Mayers wrote: > On 28/10/10 12:34, Sven Hartge wrote: >> Phil Mayers wrote: >>> On 28/10/10 11:48, Maurice James wrote: >>>> OK here are the logs from the latest test. As you will see the >>>> password is stored in cleartext, but still no dice >> >>> The "ldap" module isn't running at all in the "inner-tunnel" virtual >>> server AFACIT. >> >>> You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel >> >> And it looks like the old "Windows does not respond to >> Access-Challenge" problem, also documented in the FAQ. > Erm... no it doesn't. Yes, you are (of course) right. Must be the lack of coffee on my side. Grüße, S! -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
Phil Mayers wrote: > On 28/10/10 11:48, Maurice James wrote: >> OK here are the logs from the latest test. As you will see the >> password is stored in cleartext, but still no dice > The "ldap" module isn't running at all in the "inner-tunnel" virtual > server AFACIT. > You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel And it looks like the old "Windows does not respond to Access-Challenge" problem, also documented in the FAQ. Grüße, S° -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
Sven Hartge wrote: > slapcat (and a simple base64 decoder) is your friend. If you are using OpenLDAP or one of its derivate implementations, of course. Grüße, S° -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
John Dennis wrote: > On 10/27/2010 07:11 PM, Sven Hartge wrote: >> You need a password in the clear in your LDAP directory, not hashed. I use a >> different (self defined) attribute in my LDAP directory to do this and >> use ldap.attrmap to map this attribute (called gifb-NetzPassword in my >> schema) to the required RADIUS-Attribute-Name: >> >> checkItem Cleartext-Password gifb-NetzPassword > Sven knows this but probably just forgot to mention this. No matter > which ldap attribute you choose to store the clear text password in > make sure it is absolutely locked down with LDAP ACI's (Access > Controls). Consult your LDAP documentation for the exact syntax since > it tends to vary with different servers. The ACI should permit only > the LDAP administrator and the radius user (the special user account > assigned exclusively to the radius *server*) to access the password > attribute. Yes, of course. Every attribute which contains anything used as a password or -phrase should be locked down strictly. While SSHA hashes are rather safe if exposed (unless the password is something like "bunny123"), other hashes are not. Be careful with lmpassword or ntpassword, as those hashes are used directly within windows and should be treated the same as a cleartext password. > You may additionally provide an extra level of protection if some one > gets access to the actual disk files (or backup's) of the LDAP store by > asking your ldap server to reversibly encrypt the attribute used to > store the cleartext password. Not all LDAP servers have this feature but > many do. While nice to have, my argument would be: if anyone gets direct access to the backend database of your LDAP server, you are hosed anyway. > Finally, many people would argue it's never a good idea to store > cleartext passwords under any circumstance. There is much validity to > that argument and you should give it careful consideration. Correct. Because of this and the overall lower security of any permanently stored credentials in any of the subsystems of Windows, the password management web-tool used by "my" users to change their passwords enforces a different NetPassword than the normal password (or master password). > Another option besides storing cleartext is to use a multivalued LDAP > attribute with different hashes, including the nt hash. But whether > you go the cleartext route or the multivalued password attribute route > you'll have to get your users to renter their passwords so you can > generate the hashes. Consult your LDAP documentation, many LDAP > servers can be configured when storing a password to generate a > variety of hashes and then throw the cleartext away leaving only the > specified hashes in LDAP. Unfortunately not every LDAP implementation allows a multi-valued UserPassword attribute. But the correct solution, whether to use a different attribute or a multi-valued one is clearly outside of the scope of this mailinglist. Last statement: beware of magic! Some implementations (LDAP servers _and_ client libraries) tend to do something magic with values of some attributes. slapcat (and a simple base64 decoder) is your friend. Grüße, S° -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
Maurice James wrote: > How do I do it? You need a password in the clear in your LDAP directory, not hashed. I use a different (self defined) attribute in my LDAP directory to do this and use ldap.attrmap to map this attribute (called gifb-NetzPassword in my schema) to the required RADIUS-Attribute-Name: checkItem Cleartext-Password gifb-NetzPassword And no, there is _no_ way to use _any_ CHAP method using an encrypted or hashed password. > Radius to ldap works no problem Yes, because this most definitely uses PAP as authentication method, which works with hashed/encrypted passwords. > Wireless to radius to ldap does not This is because the windows wireless supplicant can only use MSCHAPv2 (or ans SSL cert) to authenticate. This is a FAQ item, I suggest you to read the documentation on the website again. http://wiki.freeradius.org/index.php/FAQ#PAP_authentication_works_but_CHAP_fails Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless WPA2 enterprise Radius authentication
Maurice James wrote:
> [ldap] looking for check items in directory...
> [ldap] userpassword -> User-Password ==
> "{SSHA}5wzxRoUPX/rLkS9hY1HztczPN8u5m/dGDzKvdg=="
This will not work. You need a cleartext password. This SSHA-Hash is
only good for PAP, any challenge response method like MSCHAPv2 won't
function with this.
> [mschap] No Cleartext-Password configured. Cannot create LM-Password.
> [mschap] No Cleartext-Password configured. Cannot create NT-Password.
> [mschap] Told to do MS-CHAPv2 for MJames with NT-Password
> [mschap] FAILED: No NT/LM-Password. Cannot perform authentication.
> [mschap] FAILED: MS-CHAP2-Response is incorrect
> ++[mschap] returns reject
And this is the result --> reject.
Grüße,
Sven.
--
Sig lost. Core dumped.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ACL on LDAP
Um 04:27 Uhr am 15.05.05 schrieb Chan Min Wai: > I'm working with freeradius that running EAP auth, the account info is > with LDAP server. > Just want to know what kind of Right did the freeradius need to have on > the LDAP server so that the ACL on the LDAP server can be control. > > Also, I'm abit confused on the Password on LDAP, did we need to "READ" > it or we just have to AUTH with it? If you want to use any CHAP-like authentication method, Freeradius needs a) READ access (through some sort of proxy user) and b) clear text passwords. If you want to use EAP-TTLS, you just need AUTH, but cannot use MSCHAPv2, but are forced to do something else, like PAP (which is no problem inside a TTLS "tunnel".) Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://sven.formvision.de/blog/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
