(RADIATOR) Problems with Vasco Digipass application names

[Mike McCauley]

Hello Bosse,

Thanks again for reporting this and for the DPX file.
We have now fixed this problem so that tokens with long application names can 
now be imported.  Also, when importing tokens, there is
no need to specify the application name unless there is more than one
application in the imported DPX file.
The fixes are now in the Radmin patches area.

We apologise for any inconvenience.

Cheers.

On Tuesday 14 June 2005 20:46, Bosse Klykken wrote:
> I have been evaluating Radiator and RAdmin for a client that wants a
> Linux-based AAA solution as a replacement for their existing and EOL Shiva
> RADIUS implementation. I have concluded that Radiator meets their demands
> almost perfectly, but the most important demand of the client was that the
> system should have support for Vasco Digipass. It seemed to be perfect for
> this case.
>
> During implementation, I created a MySQL database of the client's digipass
> keys by scripting a bulk import using digipass.pl in the Radiator goodies,
> and assigning the users to Digipasses by using some shellscript magic on
> the exported Shiva data. When I discovered that RAdmin used a different
> schema, I exported the data from the "old" radiator database to adapt to
> this "new" radmin schema, as the datafields were identical but in another
> order. So far so good.
>
> I also tried importing some old Vasco DPX files through RAdmin, and got
> trouble with importing it due to the fact that the "application name" form
> didn't hold enough characters to contain it. I didn't find this to be a big
> issue, as this only applied to older keys (newer keys worked fine, as they
> had shorter application names), and I had alread "sneaked in" the old keys.
>
> The problem now is that while I can see all Digipass keys in the "list
> digipass tokens" selection in RAdmin, I get an error message when I try to
> click on one of the "old" tokens containing the beforementioned longer
> application names. Their serial numbers look something like
> "0012345678I_APPLI. #01", and the error message I get is:
>
>   Error
>   A serious error has occurred:
>   No Digipass with serial 0012345678I_APPLI. present in the database
>
> As you can see, the systems seem to cut the last four characters " #01"
> from the application name (as in the form during import), causing the
> lookup to fail. I suspect this also can apply to RADIUS requests in
> Radiator, but as I don't have any such "old" digipass tokens inhouse to
> test against Radiator, I can't confirm it. A good percentage of the
> client's token calculators have this application name, and as such these
> tokens might need to be replaced if this issue isn't solved.
>
> I am uncertain to what component that are having a problem with this issue,
> Radiator or RAdmin. As digipass.pl didn't report any problems during the
> initial import, I suspect that the problem might be in RAdmin.
>
> I appreciate any suggestions.
>
> .../Bosse

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

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 etc on Unix, Windows, MacOS etc.

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