I am testing my current 1.1.7 config with version 2.0.0. I have 2 bits of config that are not quite right on 2.0.0 1) I have the line: filter = "(cn=%{Stripped-User-Name:-%{User-Name}})" I am not sure why, I inherited this setup and I am still trying to understand it. The LDAP server is eDirectory (FreeRADIUS compiled with -with-edir) The "-X" output says: WARNING: Deprecated conditional expansion ":-". See "man unlang" for details expand: (cn=%{Stripped-User-Name:-%{User-Name}}) -> (cn=user) expand: o=uol -> o=uol What is the replacement for ":-" given I don't know what it did in the first place for "man unlang" to be any help! 2) Rejecting a user I have a specific user account (call it "special") it was barred using: special Auth-Type := Reject Reply-Message = "Cannot use this user account" in the users file. Variants like " special", "Special" and "SPECIAL" etc get by this check, and out LDAP server allows them!, so I added: lower_user = before lower_pass = no nospace_user = before nospace_pass = no to radius.conf. These no longer seem to work. How do you achieve this with version 2.0.0? --------------- Barry Dean Networks Team Computing Services Department Tel: 0151 794 5641 (x45641)
Hi,
I am not sure why, I inherited this setup and I am still trying to understand it. The LDAP server is eDirectory (FreeRADIUS compiled with -with-edir)
The "-X" output says:
WARNING: Deprecated conditional expansion ":-". See "man unlang" for details expand: (cn=%{Stripped-User-Name:-%{User-Name}}) -> (cn=user) expand: o=uol -> o=uol
What is the replacement for ":-" given I don't know what it did in the first place for "man unlang" to be any help!
if Stripped-User-Name exists, then use that, otherwise use User-Name the :- operator is in unlang too - but the expansion check may need to be rewritten - eg %{%{Stripped-User-Name}:-%{User-Name}} its only deprecated right now - not too essential
2) Rejecting a user
I have a specific user account (call it "special") it was barred using:
special Auth-Type := Reject Reply-Message = "Cannot use this user account"
in the users file.
Variants like " special", "Special" and "SPECIAL" etc get by this check, and out LDAP server allows them!, so I added:
lower_user = before lower_pass = no nospace_user = before nospace_pass = no
to radius.conf. These no longer seem to work. How do you achieve this with version 2.0.0?
gosh. a lot of ways of doing this.... you could use the unlang method to check....eg if (%User-Name ~= /^special$/i ) etc etc etc or via the attrib filter rewrite alan
Dean, Barry wrote:
1) I have the line:
filter = "(cn=%{Stripped-User-Name:-%{User-Name}})"
I am not sure why, I inherited this setup and I am still trying to understand it. The LDAP server is eDirectory (FreeRADIUS compiled with -with-edir)
In 1.1.7, read doc/variables.txt
What is the replacement for ":-" given I don't know what it did in the first place for "man unlang" to be any help!
Look for ":-" in "man unlang. In this case, you want: filter = "(cn=%{%{Stripped-User-Name}:-%{User-Name}})" Which looks a lot like the example in the "man" page.
I have a specific user account (call it "special") it was barred using:
special Auth-Type := Reject Reply-Message = "Cannot use this user account"
in the users file.
Variants like " special", "Special" and "SPECIAL" etc get by this check, and out LDAP server allows them!, so I added:
lower_user = before lower_pass = no nospace_user = before nospace_pass = no
to radius.conf. These no longer seem to work. How do you achieve this with version 2.0.0?
"man unlang". Look for "case-insensitive". In this case, you would delete that "users" file entry, and use "unlang" authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ... That should work. Alan DeKok.
"man unlang". Look for "case-insensitive". In this case, you would delete that "users" file entry, and use "unlang" authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ... That should work.
I added this to the "authorize" section of radiusd.conf just after "preprocess" and before "auth_log" and it gives the error: radiusd.conf[1810]: ERROR: Unknown attribute reject radiusd.conf[1808]: Failed to parse "update" subsection. radiusd.conf[1788]: Errors parsing authorize section. Have I messed up here by misunderstanding you completely!
Dean, Barry wrote:
I added this to the "authorize" section of radiusd.conf just after "preprocess" and before "auth_log" and it gives the error:
radiusd.conf[1810]: ERROR: Unknown attribute reject radiusd.conf[1808]: Failed to parse "update" subsection. radiusd.conf[1788]: Errors parsing authorize section.
Have I messed up here by misunderstanding you completely!
Nope. It should be: if (...) { update reply { Reply-Message := ... } reject } Alan DeKok.
Back in January Alan DeKok kindly helped me out with some config I needed, see below. I have only just go back to reviewing RADIUS as I have been involved in loads of other projects... and now can't get this working! Typical... On Fri, 2008-01-18 at 16:23 +0100, Alan DeKok wrote:
authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ...
I added this to the authorize section of my config in sites-available/local-auth a file defining my policies for local users on our wireless etc and got the errors: "ERROR: Unknown attribute reject" "Failed to parse "update" subsection.". Can't fathom that as it seems perfectly OK to me having read the unlang man page. I am using version 2.0.2. Any ideas? -- Barry Dean Networks Team Computing Services Department Web: http://pcwww.liv.ac.uk/~bvd/ --- Nice boy, but about as sharp as a sack of wet mice. -- Foghorn Leghorn
Barry Dean wrote:
Back in January Alan DeKok kindly helped me out with some config I needed, see below. I have only just go back to reviewing RADIUS as I have been involved in loads of other projects... and now can't get this working! Typical...
On Fri, 2008-01-18 at 16:23 +0100, Alan DeKok wrote:
authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ...
I added this to the authorize section of my config in sites-available/local-auth a file defining my policies for local users on our wireless etc and got the errors:
"ERROR: Unknown attribute reject" "Failed to parse "update" subsection.".
Can't fathom that as it seems perfectly OK to me having read the unlang man page.
"""The only contents permitted in an "update" section are attributes and values""" ...from "man unlang" Move the reject to outside the "update" section (but inside the "if")
I am using version 2.0.2.
Any ideas?
Works of course! First class idiot for not spotting this... My head is full of DHCP configs and I am not thinking RADIUS! On Wed, 2008-11-19 at 11:20 +0000, Phil Mayers wrote:
Barry Dean wrote:
Back in January Alan DeKok kindly helped me out with some config I needed, see below. I have only just go back to reviewing RADIUS as I have been involved in loads of other projects... and now can't get this working! Typical...
On Fri, 2008-01-18 at 16:23 +0100, Alan DeKok wrote:
authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ...
I added this to the authorize section of my config in sites-available/local-auth a file defining my policies for local users on our wireless etc and got the errors:
"ERROR: Unknown attribute reject" "Failed to parse "update" subsection.".
Can't fathom that as it seems perfectly OK to me having read the unlang man page.
"""The only contents permitted in an "update" section are attributes and values"""
...from "man unlang"
Move the reject to outside the "update" section (but inside the "if")
I am using version 2.0.2.
Any ideas?
-- Barry Dean Networks Team Computing Services Department Tel: 45641, Web: http://pcwww.liv.ac.uk/~bvd/ --- Nice boy, but about as sharp as a sack of wet mice. -- Foghorn Leghorn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Mayers wrote:
Barry Dean wrote:
Back in January Alan DeKok kindly helped me out with some config I needed, see below. I have only just go back to reviewing RADIUS as I have been involved in loads of other projects... and now can't get this working! Typical...
On Fri, 2008-01-18 at 16:23 +0100, Alan DeKok wrote:
authorize { ... if ("%{User-Name}" =~ /special/i) { update reply { Reply-Message = "Cannot use this user account" reject } } ...
I added this to the authorize section of my config in sites-available/local-auth a file defining my policies for local users on our wireless etc and got the errors:
"ERROR: Unknown attribute reject" "Failed to parse "update" subsection.".
Can't fathom that as it seems perfectly OK to me having read the unlang man page.
"""The only contents permitted in an "update" section are attributes and values"""
That should read attribute value pairs ... and reject in the context that you're using it is not a value or an attribute, it's a module call.
...from "man unlang"
Move the reject to outside the "update" section (but inside the "if")
What you're doing when you list reject, is calling an instance of the 'always' module, which returns reject as it's return code. This percolates back up to the authorize stanza (reject has priority over most other return codes, unless you explicitly set it to be otherwise). authorize { } returns reject so server rejects the request... - --- I think you can achieve the same thing with: update control { Auth-Type := 'reject' } If you were really set on using update... In much the same way as you can do update control { Auth-Type := 'accept' } Regards, Arran - -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkkHPkACgkQcaklux5oVKLw4gCdEqIPOAEzY1QEcJA2JAfftxpG g5gAmgMOTI3AtJuQVeX1bwvhNEO8PJCJ =/pVb -----END PGP SIGNATURE-----
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Barry Dean -
Dean, Barry
-
Phil Mayers