(RADIATOR) Bug with LDAP or Config Issue?

Fri Jan 16 20:39:07 CST 2004

Hello Chris -

It is not clear to me how you want your configuration to work, but the 
usual approach is to use a "NoDefault" in the AuthBy clause.

regards

Hugh

On 17 Jan 2004, at 10:00, Chris Bissell wrote:

>
> I am reconfiguring our current radiator (version 3.8) and noticed some 
> odd behaviors.  Mainly when I send a request with radpwtest and either 
> the password is incorrect or the secret is incorrect, it seems 
> radiator gets into a loop condition constantly asking the LDAP server 
> information about this user.  radpwtest says it gets 'no reply' for 
> all 3 requests, but trace debug from the server as show here (this was 
> with a bad user password) show that it should just be failing 
> authentication, but instead seems to move on to another DEFAULT (We 
> only have two defaults):
>
> Fri Jan 16 15:30:39 2004: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got result for 
> uid=cisco,ou=people,dc=frii.com,o=FRII
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got gidNumber: 200
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got friiChapPassword: xxxxxx
> Fri Jan 16 15:30:39 2004: DEBUG: Radius::AuthLDAP2 looks for match 
> with DEFAULT36
> Fri Jan 16 15:30:39 2004: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got result for 
> uid=cisco,ou=people,dc=frii.com,o=FRII
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got gidNumber: 200
> Fri Jan 16 15:30:39 2004: DEBUG: LDAP got friiChapPassword: xxxxxx
> Fri Jan 16 15:30:39 2004: DEBUG: Radius::AuthLDAP2 looks for match 
> with DEFAULT37
> Fri Jan 16 15:30:39 2004: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
>
> This debug just keeps repeating until I kill the radiator process.
>
> Below are some slapd logs showing the repeated requests on the LDAP 
> side
>
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=28 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=29 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=30 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=31 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=32 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
> Jan 16 15:30:39 elara slapd[220]: conn=49 op=33 SRCH 
> base="uid=cisco,ou=people,dc=frii.com,o=FRII" scope=0 
> filter="(&(uid=cisco))"
>
> Following is my radiator config file:
>
> Foreground
> LogStdout       #THIS LINE IS FOR TESTING, OUTPUT GOES TO SCREEN
> LogDir          /u/frii/log/radacct/NEW/
> LogFile         /u/frii/log/radacct/NEW/%h.logfile
> DbDir           /etc/raddb/NEW
> PidFile         /var/run/NEW/radiusd.pid
> DictionaryFile  /etc/raddb/NEW/dictionary
> AuthPort        1814
> AcctPort        1815
> SnmpgetProg     /usr/local/bin/snmpget
> UsernameCharset a-zA-Z0-9\-\/@\.
> Trace           4
> <Client x.x.x.x>
>   Secret                xxxxxx
>   DefaultRealm          frii.com
>   AddToRequest FRII-Service-Type=DYNAMIC-DIALUP,FRII-Description=IPASS
> </Client>
> <AuthBy GROUP>
>   Identifier FRIIDynamicDialup
>   <AuthBy FILE>
>     Filename /etc/raddb/NEW/FRII-Users-POPOnly
>   </AuthBy>
>   <AuthBy FILE>
>     Filename /etc/raddb/NEW/FRII-Users-Dynamic-Dialup
>   </AuthBy>
> </AuthBy>
> include %D/FRII-PassFailLog.cfg
> <Handler FRII-Service-Type=DYNAMIC-DIALUP,Realm=/frii.com/i>
>   AuthBy FRIIDynamicDialup
>   AcctLogFileName /u/frii/log/radacct/NEW/%h.FRII-DYNAMIC-DIALUP.detail
>   AcctSummaryLogFileFormat %Y/%m/%d %H:%M:%S %{Acct-Status-Type} %n 
> %{NAS-IP-Address}:%{NAS-Port} %{Framed-IP-Address} %{NAS-Port-Type}
>   AcctSummaryLogFileName 
> /u/frii/log/radacct/NEW/%h.FRII-DYNAMIC-DIALUP.summary
>   AuthLog FRIIPassFailLog
> </Handler>
>
> The biggest change that has happened (this isn't a problem with our 
> current running setup) is that we have moved to handlers instead of 
> realms.  Has anyone else encountered this problem or is there an 
> obvious config error?
>
>
> --
> Chris Bissell - Senior Network Engineer
> Front Range Internet, Inc. / Vi Lata Communications
> cbissell at frii.com - 970.212.0723
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.