Re: LDAP attribute mapping
On Tue, Oct 30, 2012 at 07:02:02PM +, Phil Mayers wrote:
> +1
>
> Personally I'd rather the latter format everywhere, even unlang:
>
> update {
> request:foo = 1
> }
Agreed - having that option would make things much tidier when
several things in different lists are being updated at once.
update {
config:Auth-Type = Reject
reply:Reply-Message = "Go away"
}
On the other hand, the current form is nicer when updating a few
attributes all in one list, so maybe both...? :)
or...
update [] {
...
}
update reply {
config:Auth-Type = Reject
Reply-Message = "Go away"
}
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
+1
Personally I'd rather the latter format everywhere, even unlang:
update {
request:foo = 1
}
John Dennis wrote:
>
>What I'd like to see is the individual modules converging on common
>behavior so there is a consistent model.
>
>I suspect a number of the modules were written independently and
>contributed, their diverse heritage makes for some awkwardness when
>viewing the totality of FreeRADIUS.
>
>If rlm_rest and rlm_cache have attribute models that are elegant and
>well thought out then let's move everything to that model. On the other
>
>hand if ulang is conceptually cleaner then lets move rlm_rest and
>rlm_cache to a ulang solution. Pick one idea and make everything follow
>
>those rules. Consistency is a virtue and should be a goal of 3.0 IMHO,
>it will make using FreeRADIUS easier. A major version upgrade is one of
>
>the very few opportunities available to clean up.
--
Sent from my mobile device, please excuse brevity and typos.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
> >> If rlm_rest and rlm_cache have attribute models that are elegant and well >> thought out then let's move everything to that model. On the other hand if >> ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a >> ulang solution. Pick one idea and make everything follow those rules. > > With 2.0 there was an effort to maintain configuration compatibility, which > limited standardisation efforts. Maintaining config compatiblity with 3.0 we > don't have that constraint. * Were not maintaining config compatibility with 3.0 so we don't have that constraint. Just talking with Alan, apparently whole subsections can be referenced. This is especially useful for things like TLS, where you're using the same certs in multiple places, and you can define a global TLS section and then reference it from the various module configuration. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: User authorize with Perl-Script
On Tue, Oct 30, 2012 at 02:40:35PM +0100, Oliver Werner wrote:
> I would configure my Switch-Ports Mac-Based. When a Computer
> wired a Perl-Script should check the Username and gives VLAN
> back.
You can probably do this without a perl script, however -
> exec {
> wait = yes
> program = "/usr/bin/perl /usr/local/test.pl %{User-Name}"
> input_pairs = request
> output = reply
output = config
Currently you're trying to send the cleartext password back to the
NAS...
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
On 30 Oct 2012, at 13:00, John Dennis wrote: > On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote: >> Quick poll. >> >> For 3.0 the ldap module will be moving away from using the >> ldap.attrmap file and instead use a config based mapping. >> >> There are a few ways we are considering for organising the mapping. >> >> We can use something like the existing unlang: >> >> Or something like rlm_rest and rlm_cache: >> >> It really depends on whether people are actually using the full >> ldap.attrmap, or whether they're just pulling out one or two >> attributes. Each approach is as efficient as the other performance >> wise, so it comes down to which one people prefer. >> >> Any thoughts? > > What I'd like to see is the individual modules converging on common behavior > so there is a consistent model. This is what's happening. We now have a common API for connections which means that managing connection pools is done in a consistant and easy to understand way. TLS configuration is also being standardised as much as possible, though there will probably be some minor differences where libraries only expose a subset of OpenSSL configuration parameters. > I suspect a number of the modules were written independently and contributed, > their diverse heritage makes for some awkwardness when viewing the totality > of FreeRADIUS. Yes. > If rlm_rest and rlm_cache have attribute models that are elegant and well > thought out then let's move everything to that model. On the other hand if > ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a > ulang solution. Pick one idea and make everything follow those rules. With 2.0 there was an effort to maintain configuration compatibility, which limited standardisation efforts. Maintaining config compatiblity with 3.0 we don't have that constraint. That said, discuss whether using exactly the same syntax is useful. People may get more confused and try to use other unlang statements within module configs. > Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using > FreeRADIUS easier. A major version upgrade is one of the very few > opportunities available to clean up. Yes. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Regarding pam_radius_auth to be integrated with busybox
On 30 Oct 2012, at 14:13, Deep Shah wrote: > Sorry for inconvenience. > > I have enabled flag of mips in md5.c file of pam_radius_auth and my issue is > resolved now. Ahhh. https://github.com/FreeRADIUS/pam_radius/commit/c61a218efb2a0ec4f493bcc9fa735306f779ea64 -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: User authorize with Perl-Script
We use more then two VLANs. The PCs authorize with the MAC-Address. So i would check the Database for this MAC and read the defined VLAN. Am 30.10.2012 um 14:55 schrieb Michael Schwartzkopff : >> Hello, >> >> I'm useing FreeRADIUS in Version 2.1.10. >> >> I would configure my Switch-Ports Mac-Based. When a Computer wired a >> Perl-Script should check the Username and gives VLAN back. > > Why so complicated? > > FreeRADIUS can do this out of the box, provided the NAS (switch) can do this. > > -- > Dr. Michael Schwartzkopff > Guardinistr. 63 > 81375 München > > Tel: (0163) 172 50 98 > Fax: (089) 620 304 13 > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Regarding pam_radius_auth to be integrated with busybox
Sorry for inconvenience. I have enabled flag of mips in md5.c file of pam_radius_auth and my issue is resolved now. Regards, Deep On Tue, Oct 30, 2012 at 11:20 AM, Fajar A. Nugraha wrote: > On Tue, Oct 30, 2012 at 12:42 PM, Deep Shah > wrote: > > Hi, > > > > Thank you for your reply. > > > > Here, radius server is at /usr/local/etc/raddb/ (which is on pc side) > and I > > have configured and put my client which is at /etc/raddb/server. > > > > When I am getting " pam_radius_auth: packet from RADIUS server > > 192.168.100.27 fails verification: The shared secret is probably > incorrect." > > on my radius client. > > > If you're not going to listen to suggestion then I wont bother > answering your mail anymore. > > I just tested it on Ubuntu 12.04. The package is libpam-radius-auth, > and (despite the comment in the config file), pam_radius_auth.conf > must be in /etc. It works. > > Again, my advice is start with known good config, and work from there. > If you decide to ignore that advice, it's your choice, but please stop > wasting everyone's time. > > -- > Fajar > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: User authorize with Perl-Script
> Hello, > > I'm useing FreeRADIUS in Version 2.1.10. > > I would configure my Switch-Ports Mac-Based. When a Computer wired a > Perl-Script should check the Username and gives VLAN back. Why so complicated? FreeRADIUS can do this out of the box, provided the NAS (switch) can do this. -- Dr. Michael Schwartzkopff Guardinistr. 63 81375 München Tel: (0163) 172 50 98 Fax: (089) 620 304 13 signature.asc Description: This is a digitally signed message part. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
User authorize with Perl-Script
Hello,
I'm useing FreeRADIUS in Version 2.1.10.
I would configure my Switch-Ports Mac-Based. When a Computer wired a
Perl-Script should check the Username and gives VLAN back.
For a simple Test i don't have some conditions in the Script only outputs:
use strict;
use warnings;
use DBI;
### SwitchUser ###
my $pass= $ARGV[0];
print 'Access-Accept';
print 'Cleartext-Password := "'.$pass.'"';
exit 0;
my modules/exec looks here:
exec {
wait = yes
program = "/usr/bin/perl /usr/local/test.pl %{User-Name}"
input_pairs = request
output = reply
shell_escape = yes
}
and my sites-enabled/switch its this:
authorize {
exec
expiration
chap
}
authenticate {
chap
}
post-auth {
exec
}
When i wired with my PC Log Says following:
# Executing section authorize from file /etc/freeradius/sites-enabled/switchport
+- entering group authorize {...}
[php] expand: %{User-Name} -> aa:bb:cc:dd:ee:ff
Exec-Program output: Access-AcceptCleartext-Password := "aa:bb:cc:dd:ee:ff"
Exec-Program-Wait: plaintext: Access-AcceptCleartext-Password :=
"aa:bb:cc:dd:ee:ff"
Exec-Program: returned: 0
++[php] returns ok
++[expiration] returns noop
[chap] Setting 'Auth-Type := CHAP'
++[chap] returns ok
Found Auth-Type = CHAP
# Executing group from file /etc/freeradius/sites-enabled/switchport
+- entering group authenticate {...}
[chap] login attempt by "aa:bb:cc:dd:ee:ff" with CHAP password
[chap] Cleartext-Password is required for authentication
++[chap] returns invalid
Failed to authenticate the user.
} # server switchport
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Anyone knows what is wrong in my Configuration?-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote: Quick poll. For 3.0 the ldap module will be moving away from using the ldap.attrmap file and instead use a config based mapping. There are a few ways we are considering for organising the mapping. We can use something like the existing unlang: Or something like rlm_rest and rlm_cache: It really depends on whether people are actually using the full ldap.attrmap, or whether they're just pulling out one or two attributes. Each approach is as efficient as the other performance wise, so it comes down to which one people prefer. Any thoughts? What I'd like to see is the individual modules converging on common behavior so there is a consistent model. I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS. If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules. Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of the very few opportunities available to clean up. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CentOS 6.3 and FreeRadius - can't authenticate to Unix
On 10/30/2012 03:23 AM, Alan DeKok wrote: Fajar A. Nugraha wrote: What's the recommended method for authenticating against Linux system users? I thought pam was the better one? Maybe. getpwent() or getspwent() should work. Also, is the "big warning" still valid? Likely, yes. I've been avoiding PAM for nearly a decade now. It's not as bad as libtool, but it's pretty crazy. FWIW pam is used extensively on Red Hat systems. I'm not aware of any glaring problems deserving the recommendation not to use it. That said I'm no lover of pam, it's not designed well and if it ever got replaced I don't think there would be many tears shed. Be that as it may it's still central to most system authentication. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
I pull out only the attributes I need and change ldap.attrmap to match my
schema. Personally, I can live with either config method.
Arran Cudbard-Bell wrote:
>Quick poll.
>
>For 3.0 the ldap module will be moving away from using the ldap.attrmap file
>and instead use a config based mapping.
>
>There are a few ways we are considering for organising the mapping.
>
>We can use something like the existing unlang:
>
>update control {
> Cleartext-Password := userpassword
>}
>
>update reply {
> User-Name = radiusUserName
>}
>
>update outer.reply {
> Reply-Message = radiusReplyMessage
>}
>
>Or something like rlm_rest and rlm_cache:
>
>update {
> control:Cleartext-Password := userpassword
> reply:User-Name = radiusUserName
> reply.outer:User-Name = radiusUserName
>}
>
>It really depends on whether people are actually using the full ldap.attrmap,
>or whether they're just pulling out one or two attributes. Each approach is as
>efficient as the other performance wise, so it comes down to which one people
>prefer.
>
>Any thoughts?
>
>-Arran
>
>
>
>
>
>
>-
>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
Oh my, any linux/bsd system with 128MB of RAM or you can even try a http://www.raspberrypi.org/ :) - Original Message - From: "fknet" To: freeradius-users@lists.freeradius.org Sent: Tuesday, October 30, 2012 12:31:54 PM Subject: Re: Ideal SO and hardware for FreeRadius+MySQL What virtual machine does you recommend Alan? thanks Em 30/10/2012 07:49, Alan DeKok escreveu: > Bjørn Mork wrote: >> You're right. Time to save some power replacing all those idling x86 >> CPUs with last years phones :-) > Most people with small RADIUS systems should really be running them in > a VM. There are few reasons to run dedicated hardware for ~10K users. > > Alan DeKol. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
fknet wrote: > What virtual machine does you recommend Alan? It doesn't matter. I've used all of them. A VM with ~1G of RAM, one CPU, and ~10G of disk space is tiny by todays standards. It should be enough to handle 20K users. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP attribute mapping
Quick poll.
For 3.0 the ldap module will be moving away from using the ldap.attrmap file
and instead use a config based mapping.
There are a few ways we are considering for organising the mapping.
We can use something like the existing unlang:
update control {
Cleartext-Password := userpassword
}
update reply {
User-Name = radiusUserName
}
update outer.reply {
Reply-Message = radiusReplyMessage
}
Or something like rlm_rest and rlm_cache:
update {
control:Cleartext-Password := userpassword
reply:User-Name = radiusUserName
reply.outer:User-Name = radiusUserName
}
It really depends on whether people are actually using the full ldap.attrmap,
or whether they're just pulling out one or two attributes. Each approach is as
efficient as the other performance wise, so it comes down to which one people
prefer.
Any thoughts?
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
What virtual machine does you recommend Alan? thanks Em 30/10/2012 07:49, Alan DeKok escreveu: Bjørn Mork wrote: You're right. Time to save some power replacing all those idling x86 CPUs with last years phones :-) Most people with small RADIUS systems should really be running them in a VM. There are few reasons to run dedicated hardware for ~10K users. Alan DeKol. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
Bjørn Mork wrote: > You're right. Time to save some power replacing all those idling x86 > CPUs with last years phones :-) Most people with small RADIUS systems should really be running them in a VM. There are few reasons to run dedicated hardware for ~10K users. Alan DeKol. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
Arran Cudbard-Bell writes: > On 30 Oct 2012, at 07:57, Bjørn Mork wrote: >> Alan DeKok writes: >>> fknet wrote: Hello people! What's the ideal Hardware (processor+memory) to run FreeRadius+MySQL for authentication of 3000 PPPoE users? >>> >>> Any iPhone 4 could handle that traffic. >> >> Yes, but how do I build FR for an iphone? > > Hmm pretty sure gcc and others are available in Cydia? You're right. Time to save some power replacing all those idling x86 CPUs with last years phones :-) Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
On 30 Oct 2012, at 07:57, Bjørn Mork wrote: > Alan DeKok writes: >> fknet wrote: >>> Hello people! >>> >>> What's the ideal Hardware (processor+memory) to run FreeRadius+MySQL for >>> authentication of 3000 PPPoE users? >> >> Any iPhone 4 could handle that traffic. > > Yes, but how do I build FR for an iphone? Hmm pretty sure gcc and others are available in Cydia? -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ideal SO and hardware for FreeRadius+MySQL
Alan DeKok writes: > fknet wrote: >> Hello people! >> >> What's the ideal Hardware (processor+memory) to run FreeRadius+MySQL for >> authentication of 3000 PPPoE users? > > Any iPhone 4 could handle that traffic. Yes, but how do I build FR for an iphone? Bjørn :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CentOS 6.3 and FreeRadius - can't authenticate to Unix
Fajar A. Nugraha wrote: > What's the recommended method for authenticating against Linux system > users? I thought pam was the better one? Maybe. getpwent() or getspwent() should work. > Also, is the "big warning" still valid? Likely, yes. I've been avoiding PAM for nearly a decade now. It's not as bad as libtool, but it's pretty crazy. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CentOS 6.3 and FreeRadius - can't authenticate to Unix
On Tue, Oct 30, 2012 at 2:04 PM, Alan DeKok wrote: >> ++[unix] returns notfound > > That's pretty definitive. The user isn't in /etc/passwd, or > /etc/shadow. Or, the server can't read it. What's the recommended method for authenticating against Linux system users? I thought pam was the better one? Also, is the "big warning" still valid? " # WARNING: On many systems, the system PAM libraries have # memory leaks! We STRONGLY SUGGEST that you do not # use PAM for authentication, due to those memory leaks. " -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CentOS 6.3 and FreeRadius - can't authenticate to Unix
Jacobs, Joseph wrote: > I’m trying to set up Freeradius to authenticate against the local Linux > user accounts. .. > joe2 Auth-Type := System (I’ve tried this with both := and =) Don't do that. > bob Cleartext-Password := "hello" OK. Then: > [files] users: Matched entry bob at line 8 That makes sense. > Sending Access-Accept of id 124 to 127.0.0.1 port 54241 So that works. > When I run “radtest joe2 secret localhost 0 testing1234” ... > ++[unix] returns notfound That's pretty definitive. The user isn't in /etc/passwd, or /etc/shadow. Or, the server can't read it. > [files] users: Matched entry joe2 at line 6 That entry is wrong, delete it. > One of the steps involved putting the group for freeradius to be > “shadow” but there is no “shadow” group in the group file in CentOS 6.3. That's fine. If you're running the server as root, that isn't necessary. > I also did confirm that I can log into my server using joe2 / secret > password. Well, FreeRADIUS asks the system for "joe2"s password. It says "not found". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
