Re: 2.2.0 - Shared Secret is incorrect

2013-07-19 Thread Anja Ruckdaeschel
No. It didn´t inlcude a Message-Authneticator attrib...

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: 2.2.0 - Shared Secret is incorrect

2013-07-19 Thread Anja Ruckdaeschel
Dear Arran,

Sorry, about the typo with debug

I looked at the invalid packet counters. Only shows the requests with wrong
shared secrets  in rejects-Counter ... Same thing

stats client auth x.x.x.x
requests5
responses   5
accepts 1
rejects 4
challenges  0
dup 0
invalid 0
malformed   0
bad_signature   0
dropped 0
unknown_types   0

But thanks for the tipp

I´m aware of that log "formats" change, but I couldn´t get A.L.M.s
explanation, because of the unknown-Error appearing and the shared secret-Info
not "because of DoS prevention".

If you have a lot of radius-servers running and a lot of switches, you are
glad to do some syslog-collection and an automated-search for
any string or character in a log line showing that x.x.x.x has a wrong secret
or is not known to radius, so the problem can be fixed immediatly.

The only two types of "NAS-Misconfiguratin" I´m interested in are:
- The client is unknown o the RADIUS-Server (which is still logged).
- The shared secret is wrong (which is not in the log anymore).

So, I think I´ll  change the code.

Thanks for your time...



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Re: Re: 2.2.0 - Shared Secret is incorrect

2013-07-19 Thread Anja Ruckdaeschel
Sorry, but I only wanted to know why the behaviour has changed and if there is
any way to do it by configuration or access it with unlang...

BTW:
 If I remove the client completely, log in normal mode says):
Fri Jul 19 16:32:29 2013 : Error: Ignoring request to authentication address *
port 1812 from unknown client x.x.x.x port 45494
... which could be used for a DoS with a radius server running port 1812 open
for the world.

If I add the client  and use a wrong secret, log says: 
Fri Jul 19 16:33:09 2013 : Auth: Login incorrect: [radtestuser] (from client
 port 0)

It´s a kind of misleading information, because it has nothing do do with users
login, but with a wrong shared secret on the NAS.



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Re: 2.2.0 - Shared Secret is incorrect

2013-07-19 Thread Anja Ruckdaeschel
But it DID appear in earlier versions of freeradius with default settings for
logging.

And I don´t see the difference to something logging Erros like

 Error: Ignoring request to authentication address * port 1812 from unknown
client x.x.x.x port 1092

regarding the mentioned DoS problem. 

We´re using a logfile monitoring for years in order to find misconfigured NAS
of ours.
Seems we cannot do this with freeradius 2.2.0 anymore?

Anja
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

2.2.0 - Shared Secret is incorrect

2013-07-19 Thread Anja Ruckdaeschel
Hi, 

I´m wondering, if I miss something or why do Info-Messages about
Invalid-Message-Authenticator not appear
in the default radius.log anymore? Even can´t get it with

update control {
   Tmp-String-0 = "%{debug:7}"
}

in log section of radiusd.conf.

It´s only shown in debug mode with radiusd -X: 
 Info: Received packet from x.x.x.x with invalid Message-Authenticator! 
(Shared secret is incorrect.) Dropping packet without response.

Kind regards, Anja

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Antw: Re: Attr-Rewrite and Users File

2009-10-07 Thread Anja Ruckdaeschel
Dear Alan!

Thanks for your answer, but now it seems to work...

But it would be nice, if you can tell me, if there is a better way to do
this...

What I tried to do, was this:

I´m getting some profile-Information from a NAS embedded in some crytical
string in
the attribute Acct-Session-Id. To extract the profile name I do the
stripping

If the user is member of an ldap-group which cn matches with the profile-name
the users should be
accepted, else rejected... The groups are all in the same ou, so the whole
group-dn is not needed
If the profile name equals to "test_default" no ldap-group-check should be
done only the "normal" named bind...

The Auth-Request in this case is a simple one (no CHAP, MSCHAP, etc...)

So, what I tried in the first place was some kind of "variable" group cn in
the users file, but that didn´t work out as I posted earlier...


Now I did it with (in default, authorize section):

authorize {
...

 if (Acct-Session-Id) {
if (Acct-Session-Id =~  /^[^\(]+([\(])([^\)]+).+$/ ) {
update request {
Acct-Session-Id := "%{2}"
}
   }
   }

...


 if (User-Name =~  /^(\.*)([a-zA-Z]{3}[0-9]{5})/ && Huntgroup-Name == "test" )
 {
if (Acct-Session-Id != "test_default") {
 if (ldapgroups1-Ldap-Group ==
"cn=%{Acct-Session-Id},o=test,c=de" ) {
 update control {
   
Auth-Type := LDAP
}
   ok
}
   else {
 reject
}
   }

 #if it´s test_default, ignore ldap-group an do only the named bind
else {
  
  update control {
   
Auth-Type := LDAP
}
}
 
   } 


 if (Huntgroup-Name != "test" ) {
files 
   }

...
}


I have a lot of things in the users file, so it should be left out only in
this special case...

Thank you very much...

Anja







>>> Alan DeKok  02.10.2009 20:33 >>>
Anja Ruckdaeschel wrote:
> Now I did it with unlang in the authorize section before the files
module
> 
>  if (Acct-Session-Id) {
> if (Acct-Session-Id =~  /^[^\(]+([\(])([^\)]+).+$/ ) {
>
> update request {
> ldapgroups1-Ldap-Group :=
"cn=%{2},ou=vpn,ou=test,o=test,c=de"

  The "ldapgroups1-Ldap-Group" attribute can *only* do comparisons.
Assigning to it is not supported.

  And even if assigning to it was supported, the LDAP-Group attribute
checks group *names*.  It doesn't support LDAP queries like "cn=...,ou=..."

  Perhaps you could try to describe what you are trying to do.  Describe
it in terms of ideas, not pieces of configuration files.  The
configuration pieces you posted are wrong, and won't work.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Antw: Re: Attr-Rewrite and Users File

2009-10-02 Thread Anja Ruckdaeschel
Now I did it with unlang in the authorize section before the files module

 if (Acct-Session-Id) {
if (Acct-Session-Id =~  /^[^\(]+([\(])([^\)]+).+$/ ) {
   
update request {
ldapgroups1-Ldap-Group := "cn=%{2},ou=vpn,ou=test,o=test,c=de"
 
}
 update request  {
ldapgroups2-Ldap-Group :=
"cn=%{2},ou=vpn,ou=test,o=test,c=de"
}

   }
   }

and in the users file now:

 DEFAULT User-Name =~ "^(\.*)([a-zA-Z]{3}[0-9]{5})", Huntgroup-Name == "test",
 ldapgroups1-Ldap-Group=="%{ldapgroups1-Ldap-Group}"

Same result. Stripping works. But expansion of %{ldapgroups1-Ldap-Group}
happens only the first time after starting the server...
On the second request it´s again the value of the first one.

Any idea? Or did you mean something else???

Thanks for your help.

Anja







>>> "Ivan Kalik"  01.10.2009 00:21 >>>
> DEFAULT User-Name =~ "^(\.*)([a-zA-Z]{3}[0-9]{5})", Huntgroup-Name ==
> "test",
> ldapgroups1-Ldap-Group=="cn=%{Acct-Session-Id},o=test,c=de"

Use unlang instead.

Ivan Kalik
Kalik Informatika ISP

-
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: Attr-Rewrite and Users File

2009-10-02 Thread Anja Ruckdaeschel
Do you mean the stripping part?






-
Anja Ruckdäschel M.A.; Rechenzentrum der Universität Regensburg;
Universitätsstr.31; 93 053 Regensburg
Telefon: +49 941 943 4826
-
>>> "Ivan Kalik"  01.10.2009 00:21 >>>
> DEFAULT User-Name =~ "^(\.*)([a-zA-Z]{3}[0-9]{5})", Huntgroup-Name ==
> "test",
> ldapgroups1-Ldap-Group=="cn=%{Acct-Session-Id},o=test,c=de"

Use unlang instead.

Ivan Kalik
Kalik Informatika ISP

-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Attr-Rewrite and Users File

2009-09-30 Thread Anja Ruckdaeschel
Hi there!

Please help


I´m doing a attr_rewrite with an attribute in the request:

attr_rewrite strip-vpn {
attribute = Acct-Session-Id
searchin = packet 
searchfor = "^[^\(]+([\(])([^\)]+).+$"
replacewith = %{2}
new_attribute = no 
max_matches = 1
append = no 

}

Radius doing the rewrite seems okay to me...

[strip-vpn] expand: ^[^(]+([(])([^)]+).+$ -> ^[^(]+([(])([^)]+).+$
[strip-vpn] expand: %{2} -> test1
strip-vpn: Changed value for attribute Acct-Session-Id from
'abc0(test1)"Mon Sep 28 13:34:40 2009"9XMBQBrh' to 'test1'
strip-vpn: Could not find value pair for attribute Acct-Session-Id
++[strip-vpn] returns ok

Later in the files modules I´d like to use the stripped value for checking
against an ldap-group:

DEFAULT User-Name =~ "^(\.*)([a-zA-Z]{3}[0-9]{5})", Huntgroup-Name == "test",
ldapgroups1-Ldap-Group=="cn=%{Acct-Session-Id},o=test,c=de"
   
So, if the user is a member of the group cn=test1,o=test,c=de he should get an
access-accept, else he should be rejected.

The FIRST request after RADIUS started it looks like this:

 expand: cn=%{Acct-Session-Id},o=test,c=de -> cn=test1,o=test,c=de 
rlm_ldap: Entering ldap_groupcmp()
...
rlm_ldap: performing search in cn=test1,o=test,c=de, with filter 

and it´s working as it should be.

The next request from the same user but with test2 instead of test1 in the
request:

[strip-vpn] expand: ^[^(]+([(])([^)]+).+$ -> ^[^(]+([(])([^)]+).+$
[strip-vpn] expand: %{2} -> test2
strip-vpn: Changed value for attribute Acct-Session-Id from
'abc0(test2)"Mon Sep 28 13:34:40 2009"9XMBQBrh' to 'test2'
strip-vpn: Could not find value pair for attribute Acct-Session-Id
++[strip-vpn] returns ok

Now radius doesn´t do the expansion like it did for the first request, but the
search in the group with the value used in the request before:

rlm_ldap: Entering ldap_groupcmp()
...
rlm_ldap: performing search in cn=test1,o=test,c=de, with filter 

Is there some kind of caching or do I miss something?

Thank you very much
Anja










-
Anja Ruckdäschel M.A.; Rechenzentrum der Universität Regensburg;
Universitätsstr.31; 93 053 Regensburg
Telefon: +49 941 943 4826
-

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Use LDAP-Groups for rejecting a user

2009-08-07 Thread Anja Ruckdaeschel
Hello there!

I´m using freeradius 2.1.6 and use a ldap-group to reject some users. The
problem is, when the ldap-servers are
not responding when doing the search for the ldap-dn or when doing the search
for the dn in the group 
the files-Module returns ok because the user abc matches for the next entry.
So a correct named bind is triggered
and the user gets access-accept even though he´s in the reject-group. 

How can I get something like 
"[files] returns failed"
in that case???

I´m doing the module loading for the groups in radiusd.conf:
instantiate {
...
ldagroups1
ldagroups2
}

Here´s the users-File. I hope anyone can help ...

DEFAULT Auth-Type :=REJECT, User-Name =~ "^(\.*)([a-zA-Z]{3})",
ldapgroups1-Ldap-Group == 'cn
=rejectgroup,ou=public,o=mycompany,c=de'
DEFAULT Auth-Type :=REJECT, User-Name =~ "^(\.*)([a-zA-Z]{3})",
ldapgroups2-Ldap-Group == 'cn
=rejectgroup,ou=public,o=mycompany,c=de'

... 
DEFAULT User-Name =~ "^(\.*)([a-zA-Z]{3})", FreeRADIUS-Proxied-To !*
127.0.0.1, Auth-Type :=LDAP
... 
DEFAULT Auth-Type :=reject

Thanks a lot
Anja





-
Anja Ruckdäschel M.A.; Rechenzentrum der Universität Regensburg;
Universitätsstr.31; 93 053 Regensburg
Telefon: +49 941 943 4826
-

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Freeradius 2.1.6: LDAP connect

2009-07-08 Thread Anja Ruckdaeschel
Hello there!
 
Hope you can help.
I´m running freeradius 2.1.6 on sles 11 and do LDAP-Authentificaiton on
Radius.
EAP/TTLS with cleartext-password against ldap works fine.
PEAP/MSCHAP with universal password retrieval works fine.
Ldap-Groups work fine.
Load-Balancing with multiple ldap-servers also work fine.
 
The only problem is: From time to time! the radius-debug fpr rlm_ldap says:
 
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in c=de, with filter
(&(objectClass=inetOrgPerson)(uid=abc12345))
rlm_ldap: object not found
 
So, radius doesn´t know the dn and can´t go on. The difference between other
ldap searches and the one with this error
is, that there is no new connect to the ldap-server and no new bind. Also,
this never happens with the first access-request.
Besides: A trace on my ldap servers shows no communication in that case
(looks
like radius doesntt ask after all) ... and: same problem appears with
freeradius 2.1.1.
 
Any ideas...???
Thank you very much...
 
Kind regards
Anja
 
 
 
 
 
 

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html