(RADIATOR) Digipass+password checking

[Bosse Klykken]

In the implementation process I'm currently in, I've discovered that there
are several routers and other equipment that needs to authenticate to RADIUS
through static passwords. As the Digipass module rejects requests where it
can't find the username in the RADDIGIPASS database, I've looked at using
Handlers to check the password field so that the request can be handled by
the correct chain. Unfortunately, as the passwords are MD5, I believe
that this might be somewhat problematic.

But as AuthBy EXTERNAL allows me to decrypt the password before sending it
to an external program, I thought I might try that as a workaround. The
script looks like this:

---8<--- radchkpwd.sh
#!/bin/sh

if echo $1 | grep -q ^[0-9][0-9][0-9][0-9][0-9][0-9]$
then
    echo "REJECT"
    exit 1 # This is probably a digipass token
else
    echo "ACCEPT"
    exit 0 # This is something else
fi
---8<---

When I call this script from the commandline with some test parameter,
the output looks okay, and if it contains six digits, it responds with
"REJECT", as it (probably) should. I also verified through the log that
the $1 parameter is correct.

Here's the relevant parts of radius.cfg that calls the script:

---8<--- radius.cfg
<Realm DEFAULT>
<AuthBy GROUP>
AuthByPolicy ContiniueWhileAccept
        <AuthBy EXTERNAL>
        # If exit 0 then password is NOT Digipass, and the chain should continiue
        # If exit 1 then password is Digipass, and the chain should be broken
	# and hopefully pass on to the next AuthBy GROUP.
        DecryptPassword
        Command /usr/bin/radchkpwd.sh %P
        # ResultInOutput
	</AuthBy>

	<AuthBy RADMIN>
	# Standard AuthBy RADMIN information here, but removed NoCheckPassword
	</AuthBy>
</AuthBy>
<AuthBy GROUP>
AuthByPolicy ContiniueWhileAccept
	<AuthBy DIGIPASS>
	# Standard DIGIPASS stuff here
	</AuthBy>
	<AuthBy RADMIN>
	# Standard RADMIN stuff here
	</AuthBy>
</AuthBy>
# Some AuthLog stuff here
</Realm>
---8<---

The following log snippet is from an attempt logging on with digipass. It
runs the radchkpwd.sh script with a correct six-digit parameter, and should
give a REJECT so that the AuthBy should stop traversing downwards, according
to the AuthByPolicy ContiniueWhileAccept - but as you see from the log, it
gets handled by Radius::AuthRADMIN.

---8<--- logfile
Tue Jun 21 14:19:23 2005: DEBUG: Handling request with Handler 'Realm=DEFAULT'
Tue Jun 21 14:19:23 2005: DEBUG:  Deleting session for sttest, 127.0.0.1,
Tue Jun 21 14:19:23 2005: DEBUG: do query is: 'delete from RADONLINE where NASIDENTIFIER='127.0.0.1' and NASPORT=0':
Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthGROUP
Tue Jun 21 14:19:23 2005: DEBUG: Running command: /usr/bin/radchkpwd.sh 444872
Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthRADMIN
Tue Jun 21 14:19:23 2005: DEBUG: Handling with Radius::AuthRADMIN:
---8<---

Now, as this is now, it works with password auth, but not digipass. I guess
that it would work with digipass again if I reordered the radmin.cfg a bit,
so from what I can tell, I might have misunderstood the concept of AuthBy
GROUP and AuthByPolicy.

Could anyone here help me by pointing me in the right direction, considering
my objective of having both digipass and password authentication? I believe
I could use Handlers with triggers on NAS-identifiers in order to set up
static password handling in radmin.cfg for requests from certain NASes or
User-IDs, but this really isn't what I had in mind.

.../Bosse
-- 
Bosse Klykken, operations consultant
Linpro AS - http://www.linpro.no

--
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.