[RADIATOR] Radiator + LDAP tries to use "(?uid=)" as search filter...

[Heikki Vatiainen]

On 09/12/2011 09:52 PM, Isaac Freeman wrote:

Hello Isaac

> I'm trying to set up Radiator's evaluation software to use my OpenLDAP
> server as a back-end. On the LDAP server I see it trying to query with:
> 
> Sep 12 14:41:58 ldap1 slapd[5590]: conn=9813 op=9 SRCH
> base="ou=People,dc=<my-domain>" scope=2 deref=2 filter="(?uid=)"
> 
> This does not seem to be a valid search to me. I am testing with:

I agree. That does not look correct. I tested with Radiator and it looks
like when Radiator hands filter "(uid=)" to Perl LDAP library, it shows
as "(?uid=)" in OpenLDAP logs.

I am not sure why this happens. Is it how OpenLDAP flags a bad filter or
does Perl LDAP library do this?

> radpwtst -user testuser -password qwer1234
>
> radiusd with -foreground options says:

Your log indicates something has happened to the username. For example:

Mon Sep 12 14:35:57 2011: DEBUG: Radius::AuthLDAP2 looks for match with  []

This should be something like when the username is present:
Mon Sep 12 14:35:57 2011: DEBUG: Radius::AuthLDAP2 looks for match with
hvn [hvn at testing]

The username in square brackets is the original username and the
username just before the brackets is the one Radiator will use for the
LDAP lookup.

In your log both are empty and I suspect this is the problem. There is
no username to pass to the LDAP search.

Your configuration looks correct, but I would still investigate why
User-Name seems to be missing. You did not include the incoming packet
dump. That should show what Radiator actually receives and if the
User-Name is there.

Thanks!
Heikki


> Mon Sep 12 14:35:57 2011: DEBUG: Handling request with Handler
> 'Realm=DEFAULT', Identifier ''
> Mon Sep 12 14:35:57 2011: DEBUG:  Deleting session for , 127.0.0.1,
> Mon Sep 12 14:35:57 2011: DEBUG: Handling with Radius::AuthLDAP2:
> Mon Sep 12 14:35:57 2011: INFO: Connecting to localhost:389
> Mon Sep 12 14:35:57 2011: INFO: Attempting to bind to LDAP server
> localhost:389
> Mon Sep 12 14:35:57 2011: DEBUG: No entries for  found in LDAP database
> Mon Sep 12 14:35:57 2011: DEBUG: Radius::AuthLDAP2 looks for match with  []
> Mon Sep 12 14:35:57 2011: DEBUG: Radius::AuthLDAP2 REJECT: No such user:
> []
> Mon Sep 12 14:35:57 2011: DEBUG: No entries for DEFAULT found in LDAP
> database
> Mon Sep 12 14:35:57 2011: DEBUG: AuthBy LDAP2 result: REJECT, No such user
> Mon Sep 12 14:35:57 2011: INFO: Access rejected for : No such user
> 
> I've tried varying the "SearchFilter" parameter in the config, but it
> always tries searching with "(?uid=)". The openLDAP logs should show the
> actual filter used. An example from a working LDAP client:
> 
> Sep 12 14:37:52 ldap1 slapd[5590]: conn=9825 op=2 SRCH
> base="ou=People,dc=<my-domain>" scope=1 deref=0
> filter="(&(objectClass=posixAccount)(uid=nsm))"
> 
> Here are the non-blank/non-comment lines from my config (slightly edited
> from the example config):
> 
> LogStdout
> LogDir		/var/log
> DbDir		/var/radiator
> Trace		4
> <Client DEFAULT>
> 	Secret	<secret>
> 	DupInterval 0
> </Client>
> <Realm DEFAULT>
> 	<AuthBy LDAP2>
> 		Host		localhost
> 		AuthDN		cn=admin,dc=<my-domain>
> 		AuthPassword	<admin-password>
> 		BaseDN		ou=People,dc=<my-domain>
> 		SearchFilter (uid=%1)
> 		ServerChecksPassword
>                 # LDAP to keep the connection to the server up for as
> 		HoldServerConnection
> 
> 		AddToReply Framed-Protocol = PPP,\
>         		Framed-IP-Netmask = 255.255.255.255,\
>         		Framed-Routing = None,\
>         		Framed-MTU = 1500,\
> 			Framed-Compression = Van-Jacobson-TCP-IP
> 		Version 3
> 	        # that match the search that will be used for
> 	</AuthBy>
> </Realm>
> 
> If I change the SearchFilter to something like "(cn=%1)" it just sends
> "(?cn=)".
> 
> Radiator seems to understand the right syntax for a search when looking for
> the default user, however:
> 
> Sep 12 14:49:04 ldap1 slapd[5590]: conn=9835 op=2 SRCH
> base="ou=People,dc=<my-domain>" scope=2 deref=2 filter="(cn=default)", but
> no such user exists. Also, it successfully binds as the cn=admin user.
> 
> Any ideas would be greatly appreciated.
> 
> Thanks,
> --
> Isaac Freeman - Systems Administrator
> IBM Information Protection Services
> isaac at us.ibm.com
> 919-254-0245
> 
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.