Very Computer

Hello,

        has anyone heard of problems for a SUNOS 4.1.4 3 to be a client of an
ACE server (Security Dynamics)? My SUNOS is pretty heavily patched for
security reasons but refuses to have a correct dialog with the ACE/server.

Thats what happens : the username and PASSCODE are correctly sent to the APIs
but these mis-encrypt the PASSCODE and so send an incorrect PASSCODE to the
server which refuses the authentication.

BTW there's no problem with SUNOS 4.1.4 2

TIA

Quote:>         has anyone heard of problems for a SUNOS 4.1.4 3 to be a client of an
> ACE server (Security Dynamics)? My SUNOS is pretty heavily patched for
> security reasons but refuses to have a correct dialog with the ACE/server.

        I think it _will_ be supported, at least for the client (and maybe
the ACE/Server too,) under ACE 2.2 -- which is due to be released any day
(probably within a week.)

   ACE 2.1 had a function which referred back to the kernel for
validation.  If the 4.1.4 3 SunOS (or your patches) rearranged the kernel
layout vis a vis 4.1.4 (2), it might have caused a problem.  ACE 2.2 has a
workaround that should henceforth make it relatively OS-independent...
within supported Unix families, at least.

   Check with SDTI in Paris.  They've got a good tech support guy there.

Quote:

> Thats what happens : the username and PASSCODE are correctly sent to the APIs
> but these mis-encrypt the PASSCODE and so send an incorrect PASSCODE to the
> server which refuses the authentication.

Quote:> ...there's no problem with SUNOS 4.1.4 2

Ohh. Poor suckers.

I stay with supported Open Code. Like Digipass, like snk.

The reason is that i have tried secureid - and rejected it.
Once you leave this propetary *binary-only* world you'll
never go back!

Feel Free!

:  
: >         has anyone heard of problems for a SUNOS 4.1.4 3 to be a client of an
: > ACE server (Security Dynamics)? My SUNOS is pretty heavily patched for
: > security reasons but refuses to have a correct dialog with the ACE/server.

:    SunOS 4.1.4 is supported for the ACE/Server and ACE/Client under ACE
: 1.3 (the C/S code without the Progress RDBS) and later versions.  

:         I think it _will_ be supported, at least for the client (and maybe
: the ACE/Server too,) under ACE 2.2 -- which is due to be released any day
: (probably within a week.)

:    ACE 2.1 had a function which referred back to the kernel for
: validation.  If the 4.1.4 3 SunOS (or your patches) rearranged the kernel
: layout vis a vis 4.1.4 (2), it might have caused a problem.  ACE 2.2 has a
: workaround that should henceforth make it relatively OS-independent...
: within supported Unix families, at least.

:    Check with SDTI in Paris.  They've got a good tech support guy there.

: >
: > Thats what happens : the username and PASSCODE are correctly sent to the APIs
: > but these mis-encrypt the PASSCODE and so send an incorrect PASSCODE to the
: > server which refuses the authentication.

:    This seems unlikely.  The encrypted exchange between an ACE/Client and
: the ACE/Server is more complex than simply passing on the Passcode, but if
: there were a problem with the encrypting process (corrupted code, or bad
: node (client) secret) it wouldn't work with either 4.1.4 (3) or 4.1.4
: (2).  And, as you said:

: > ...there's no problem with SUNOS 4.1.4 2

:    Suerte,
:                   _Vin
: --

:    53 Nichols St., Chelsea, MA. O2150 USA Tel.(617) 884-5548

--
--
Peter Hakanson  VolvoData Dep 2580 phone +46 31 66 74 27