On 11/16/06, aravind008_99 <aravind008_99@...> wrote:
> Hi
>
> When we upload the seed files of the tokens on the server, is there a
> chance that the existing seed files on the server are replaced. Which
> inturn could cause tokens to get unassigned from the user's accounts.
>

Reimporting seed records does not destroy associated data
relationships already established in the ACE data base.  My experience
is with ACE 5.x and have not heard of any change in this behavior.

-Len Lynch

Hi

When we upload the seed files of the tokens on the server, is there a
chance that the existing seed files on the server are replaced. Which
inturn could cause tokens to get unassigned from the user's accounts.

Any quick response in this matter will be much appreciated.


Thanks

Larry White recently sent us out a small batch of 30-second SID700
tokens, and I noticed that the display is infinitely better than the
LCD on the first batch of SID700 tokens we had received about a year
ago.

The only complaint we've had so far is that it is easy to misread a
"7" as a "1", more so than on the original fobs because of the new
lens design. Other than that, this is the most legible token I've
seen, RSA or otherwise.

Kevin

Hi,

The server was "corrupted"? Would you have a specific error? We're
planning to also install an agent on a Win 2003 server. Windows 2003
should be supported though.

I also had an instance wherein when I installed an agent on a DC
(AD), the server would not boot. This is on a Windows 2000 platform.

--- In securid-users@yahoogroups.com, rakesh mukherji
<india_n77@...> wrote:
>
> Hi,
>
> Can any one tell me whether RSA SecurID agent for windows
support Windows 2003 enterprise server?
> I am facing a problem while installing agent on my windows 2003
enterprise server the AD got corrupted.
>
> thanks & regds,
> rakesh
>
>
> ---------------------------------
> Here's a new way to find what you're looking for - Yahoo! Answers
> Send FREE SMS to your friend's mobile from Yahoo! Messenger
Version 8. Get it NOW
>

Hi,

The server was "corrupted"? Would you have a specific error? We're
planning to also install an agent on a Win 2003 server. Windows 2003
should be supported though.

I also had an instance wherein when I installed an agent on a DC
(AD), the server would not boot. This is on a Windows 2000 platform.


--- In securid-users@yahoogroups.com, rakesh mukherji
<india_n77@...> wrote:
>
> Hi,
>
>        Can any one tell me whether RSA SecurID agent for windows
support Windows 2003 enterprise server?
>   I am facing a problem while installing agent on my windows 2003
enterprise server the AD got corrupted.
>
>   thanks & regds,
>   rakesh
>
>
> ---------------------------------
>  Here's a new way to find what you're looking for - Yahoo! Answers
>  Send FREE SMS to your friend's mobile from Yahoo! Messenger
Version 8. Get it NOW
>

On IP, Bugtraq, Cryptography, and in several other security forums,
Hadmut Danisch <hadmut@...>, a respected German information
security analyst, recently published a harsh critique of one optional
feature in the SID800, one of the newest of the six SecurID
authentication tokens sold by RSA.

The subject of Mr. Danisch's post was: "RSA SecurID SID800 Token
vulnerable by design." It's raised quite a stir, and I thought this
list would like to see my response. It was written, of course, for a
vastly less informed audience.

A personal authentication token, by classical definition, must be
physical, personal, and difficult to counterfeit.  The most popular
implementations in computer security move the calculation of a
pseudo-random authentication code -- a so-called "One-Time Password,"
or OTP-- off an employee's PC and into a hand-held hardware fob,
small enough to be attached to a personal key chain.

RSA's mainstay token, the SID700 SecurID -- millions of which are
used in over 20,000 enterprise installations worldwide, including
many government agencies and financial institutions -- use AES (the
US cryptographic standard) to process Current Time and a 128-bit
token-specific secret to generate and continuously display a series
of 6-8 digit (or alphanumeric) OTP "token-codes" which change every
60-seconds, and remain valid only for a couple of minutes.

In practice, a RSA authentication server can then independently
calculate the token-code that is appearing on a specific SecurID at
this particular moment; compare that against an OTP submitted by a
pre-registered user, and validate a match.  RSA, which first
introduced the SecurID in 1987, has always insisted on the necessity
of "two-factor authentication" (2FA), where a remote RSA
authentication server must validate both a SecurID token-code
(evidence of "something held") and a user-memorized PIN or password
("something known.")

A stolen password can be reused indefinitely to masquerade as the
legitimate user, often with the victim wholly unaware. A
token-generated OTP, valid only briefly, is a far more robust
authenticator.  With 2FA, if a SecurID is stolen or lost, it still
can't be used to obtain illicit access to protected resources without
the second secret: the user's memorized PIN or password.

The elegant simplicity of the traditional SecurID -- and patents on
the mechanism by which the "drift" in each individual SecurID's
internal clock is tracked by the RSA authentication server -- has
allowed RSA's "time-synched" SecurID to dominate the market niche for
hand-held OTP authentication devices for 20 years.

In a typical installation, anyone seeking to log on to a protected PC
or network, or to access restricted online resources, must manually
type in the OTP currently displayed on the SecurID -- as well as his
memorized PIN or password -- to have his identity and access
privileges validated. Network applications handle the combined
SecurID "pass-code" like any long traditional password. The link
between the user and the RSA infrastructure is often, but not always,
an encrypted VPN channel. That's a local decision. Data exchanges
between the RSA agent  and RSA authentication server -- which
typically means between one of the 350-odd "SecurID-aware" network
applications and the RSA Authentication Manager, using RSA's own
protocol -- are always fully encrypted.

Mr. Danisch is an admirer of the classic SecurID (SID700), RSA's
traditional hand-held token. His ire is directed at one of the two
new hybrid SecurID designs that RSA has recently offered in an
attempt to respond to new requirements in the boisterous and
rapidly-evolving market for what's called "strong authentication."

With the nascent prospect of a new billion-dollar market in consumer
authentication for financial services boosted by US federal
regulatory initiatives, RSA announced the SecurID Signing Token, the
SID900. The SecurID Signing Token still has a time-synched OTP, but
RSA added a keypad and a challenge/response function which
successively authenticates the user, the remote server, and a
specific financial transaction, before the transaction (e.g., a funds
transfer) is executed.

On the other side of the market -- where again US laws and federal
regulatory initiatives have boosted demand for internal controls and
more accountability measures in enterprise IT -- RSA has introduced
the SID800, another hybrid SecurID, to meet the requirements of
organizations that want to move into a full public key infrastructure (PKI.)

The SID800 SecurID is a multi-function authentication and
cryptographic device that combines, in a single DPA-resistant token,
the mobility and availability of the classic hand-held SecurID, as
well as a "smart chip" that implements v2.1.1 Java tech (essentially
a "virtual smart card") in a USB format. It looks like a slightly
smaller version of the classic SecurID key fob, with a USB plug
jutting out at one end. It can carry up to seven X.509 digital
certificates for PKI, as well as account information and complex
passwords for up to three Windows accounts. The SID800's lithium
battery allows it to continuously generate and display 60-second
SecurID OTPs for up to five years.

The SID800 "smart chip" has the typical load of standards-compliant
smart card functionality: ANSI X9.31 PRNG, client-side PKI support
including key generation for DES/3DES and 1024-bit RSA Public Key
Cryptography, SHA-1 hashing, and 1024-bit RSA digital signatures.To
access its local cryptographic services (key generation,
authentication, file encryption, digital signatures, etc.) and its
X.509 certificates -- complex resources that require a
circuit-to-circuit connection and interactive data exchanges --  the
SID800 SecurID can be plugged directly into a PC's USB port.

None of these features -- none of the SID800's cryptographic
resources -- were of apparent interest to Mr. Danisch. He ignored
them all when he denounced the SID800 as "vulnerable by design."

The classic SecurID, declared Mr. Danisch on the Cryptography mailing
list, "is a smart device which provides a reasonable level of
security in a very simple and almost foolproof way...."

"It's a pity," he added, "to see it weakened without need..." The
traditional SecurID has the advantages (and disadvantages) of an "air
gap." With no direct circuit connection to the user's PC or client
terminal, it has no direct vulnerability to the various classes of
malicious or larcenous malware which -- Mr. Danisch warns -- can
potentially overwhelm and totally corrupt PCs, and particularly Windows PCs.

What particularly disturbs Mr. D is one option among in the SID800
SecurID features which allows RSA's local client software to poll and
retrieve a single OTP from the token when the SID800 is plugged into
the PC's USB port.  Given the potential for malicious malware to
invade and take control of any Windows PC -- malware that can seize
and misuse both the user's PIN and an OTP fresh from the USB bus --
it was irresponsible, Danisch suggests, for RSA to make such a option
available to its customers.

There are actually two versions of the SID800 sold by RSA.  In one
version, there is none of the fancy new OTP functionality that
worries Mr. D.  In this model, the only way to use the SecurID's OTP
is the old-fashioned way: to read the LCD and type it (and the user's
PIN) at the keyboard.

In the second version of the SID800 -- an option selectable by local
management pre-purchase, and burnt into the token's USB firmware by
RSA -- the user can select a menu in which he instructs the SecurID
to load one OTP token-code directly into the paste buffer, presumably
for immediate use. Since internal access to the SecurID's OTP via the
USB bus makes it a potential target for "malware or intruders on the
computer," claimed Mr. Danisch, "This is weak by design."  I beg to
differ. Effective IT security is about an appropriate balance, not
walls of iron or stone.

Can this token-code in the paste buffer be misused? Not likely, even
if it is immediately stolen by malware and immediately used for some
nefarious purpose.  A SecurID token-code can only be used once; no
replay is allowed.  As a defense against race attacks, the RSA
Authentication Manager will also automatically reject both of two
identical token-codes submitted roughly simultaneously -- even if
both are accompanied by the proper PIN -- and log it for
investigation by the security manager. If the legitimate user can use
the token-code, he effectively preempts any misuse of that OTP by a
hostile party or malware.

Could hostile malware independently execute the menu request for a
new token-code -- essentially instruct a token plugged into the USB
port to produce a new token-code, without the knowledge of the user
-- and then swipe it, directly or from the paste buffer? Could
malware collect the PIN and logon data of any authentication process
with a keyboard logger? Unfortunately, it could.  Mr. Danisch raises
a valid concern.

The cryptographic functionality of any smart card -- which typically
includes authentication, encryption, digital signatures, etc. -- can
be initialized and misused by a powerful hostile agent which took
control of the user's PC and snatched the user's password.  Just as
-- although Mr. Danisch didn't mention this -- the "virtual smart
card" in the SID800, or any similar UBB device, could be initialized
and misused.

The level of malware penetration that Mr. D presumes could corrupt
the client authentication and cryptographic functions in any
contemporary PKI environment, certainly any Windows-based client-side
SSL. (See: "Keyjacking: the surprising insecurity of client-side
SSL," by Marchesini, Smith, and Zhao at
<http://www.cs.dartmouth.edu/~sws/pubs/msz05.pdf>.)

Mr. Danisch denounces RSA for implementing an optional ease-of-use
feature, just because it effectively reduces the implicit security of
OTP authentication to no more than what is provided by any PKI smart
card environment. Some -- but not necessarily me -- might suggest
that this is carrying an appreciation of the unique and sterling
qualities of the classic SecurID's OTP a bit far.

This has been an ongoing debate within the RSA user community for the
past year, where some of the language used in declaring opinions is
not always as civil or restrained as that used by Mr. Danisch.  It is
not yet clear how the market's choices and concerns will affect the
next version of the SID800's firmware, expected later this year --
but it seems unlikely that either of the two SID800 versions will be
removed from RSA's sales list.

In security, ease-of-use (which usually implies internal complexity)
is often the enemy of security. Yet, any enhancement in ease-of-use
which will have little or no impact on overall system security is
something of a Holy Grail for both InfoSec vendors and local IT managers.

Some organizations choose to use SID800 SecurIDs which offer RSA's
"OTP paste" feature, others do not. Those who don't are presumably
acting on the basis of a risk analysis of their environment that
determines that the advantages of enhanced usability do not justify
the risks it entails.  Many of those, I presume, have concerns
similar to those of Mr. Danisch.

If the hostile malware can wait and capture the initiation password
off the keyboard, it can ask for anything the password can authorize.
  From the SID800. From any smart card. From any application. From any
network resource. This is not a new insight.  (Ironically, the
SID800's OTP output to the USB bus is relatively more difficult to
misuse, since it is time-constrained, while stolen smart card
functionality typically is not.)

Obviously, if a hostile enemy can load malware that "owns" your PCs,
untrustworthy user authentication is only the beginning of your problems.

If the enemy "owns" your Windows box today -- or any other computer,
for that matter -- he probably totally controls everything that
passes through it, and all devices connected to it.  Although the
firmware in a smart card -- or in USB plugs like the SID800 which
offer "virtual smart cards" -- supposedly won't allow the PC to
directly access the token's internal secrets, a computer under the
control of a hostile party can doubtless gain illicit access to the
cryptographic services provided by those devices.

Assuming imperfect defenses in any given technical context --
certainly true with the current Microsoft Windows OS, the leading
browsers, and the protocols now in use for both secure data transfer
and authentication -- the industry consensus calls for multiple
defensive layers. Where one defensive layer leaves a gap, another
will often overlap to cover it. The logic of such an approach is
based on gritty experience: there is no such thing a perfect security!

Mr. Danisch bemoans -- as do other fretful traditionalists like
myself, including many who work for RSA -- the loss of the "air gap,"
the isolation of the SecurID's OTP generation from the potentially
corrupted PC and network.  (A networked device will never be as
transparent as the classic OTP token, where everybody knows exactly
what the SecurID is doing, and can be certain that it is doing no
more than it is expected to do. The elegance of simplicity.)

Others -- including many fretful traditionalists -- celebrate
(despite imperfect implementations, despite many inherently
untrustworthy operational environments) the powerful security
utilities which become available with interactive PKI, which RSA
pioneered with its work on the seminal Public Key Crypto Standards
(PKCS) and the revolutionary RSA public key cipher which is critical
to so much of today's network security services.

The two hardest things to do in computer security are (A) to create a
perfectly secure technical infrastructure, and (B) to second-guess
the CIO, CISO, or local system administrator who has the
responsibility to identify his assets, understand his risks, and
select where and how to balance his investments in usable
functionality and information security.

Since no one today argues that perfect security is attainable,
security mavens like Mr. Danisch (and myself) are forever occupied
with the second task. Yet, as Courtney's First Law -- codified 40
years ago by IBM's Bob Courtney, one of the pioneers in computer
security -- puts it: "Nothing useful can be said about the security
of a mechanism except in the context of a specific application and a
specific environment."

Information security vendors like RSA attempt to respond to the
perceived market requirements, juggling concerns about risk,
liability, and cost against demands for functionality, flexibility,
and accessibility.  When relative security is slightly compromised
for a perhaps critical enhancement in ease-of-use, it seems smart to
at least give the buyers the option.  That leaves the critical
judgment to the professionals who know their environment, their real
risks, and their people, best.

Lecturing CIOs about the relative importance of security threats --
when they have to get real work done in an imperfect universe -- is
as presumptuous as it is almost surely ill-informed.  Hectoring
vendors who respond to demands from their customers for alternative
ways to address security issues -- some admittedly more or less
robust than others -- is far more appropriate. In that sense, debates
that arise when critics like Mr. Danisch forcefully state their case
are useful, even necessary.

It is no secret that Windows and the browsers have design
flaws.  Client-side SSL still has some major architectural issues,
particularly in Windows. It is no secret that PC users today need a
safer place -- some sort of restricted input environment,
inaccessible to all but the local user -- by which they can submit
authentication calls to an application over a trusted path. It is no
secret that network protocols require new IETF initiatives to better
secure them against attempts to corrupt them for illicit gain. It is
no secret that simple authentication protocols must today often be
supplemented by some form of mutual authentication, or that
high-value transactions may require supplementary authentication, or
that unusual transactions or access claims may trigger direct
oversight or adaptive authentication requirements.

Simple user authentication, simple web server authentication, simple
client-side SSL, basic PKI, is no longer enough when malware is now
usually the sophisticated product of a criminal enterprise. Forensic
audit logs have never been more important. The good news is that --
thanks to concerns raised by outspoken techies like Hadmut Danisch --
there is public debate and significant developments in all these
areas, and solutions (probably imperfect, but better) are on the horizon.

Suerte,
             _Vin

PS. I have been a consultant to RSA for nearly 20 years and my bias
is overt. I beg the indulgence of the List for the length of my comments.

You need to install an agent on the remote pc. Otherwise, if you have
remote users, you could opt to use SSL VPN and then use the SSL VPN
NAS to prompt for passcodes. We have tested this using firepass
through RSA Radius and works well

--- In securid-users@yahoogroups.com, "speedy_1s" <speedy_1s@...> wrote:
>
> Thanks for the reply Didier, I am pretty sure the last time i was
> troubleshooting this problem i could login through a vpn with my
> windows -password but not with the passcode, even though the user is
> in the challenge group, perhaps its something between the ad server
> and the ace server. do you know of any good installation guides for
> securid with domain authenication? the only one i found was a nasa one
> but that was very flawed, i am not finding much info on securid at all..
>

Hi room,
  can we use MicroSoft CA already installed in a corporation instead of
using CA utility of RSA?

Brgds,
Kamyar

From: <securcare_note@...>
Subject: Update on Heightened Security and Air Travel with RSA SecurID
Authenticators
Date: Fri, 11 Aug 2006 14:54:48 -0400

** Please do not reply to this email. To change or cancel your
subscription to RSA SecurCare Notes & Alerts, please log on to RSA
SecurCare Online at https://knowledge.rsasecurity.com, click "Notes &
Alerts" > "Subscription" in the left navigation menu, and follow the
instructions on the page to unsubscribe from this service.


Dear RSA SecurCare Online Customer:

In response to heightened security due to recent events, RSA Security
has provided the following answers for customers concerned about
carrying an RSA SecurID Authenticator aboard an aircraft:


Q: Are RSA SecurID Authenticators and other electronic devices banned
from aircraft?

A: As of Friday, August 11, 2006, the U.S. Transportation Security
Administration (TSA) has reported key information directly to RSA
Security regarding RSA SecurID tokens and the current security
measures affecting air travel.

All electronic items, even ones that do not emit radio signals such as
RSA SecurID tokens and digital watches, are banned from carry-on
luggage on all RED Alert flights only. RED Alert flights are currently
those only between the U.S. and the U.K., as well as those that depart
from the U.K. or transfer flights at a U.K. airport.

More specifically, RED Alert Flights include an electronic key fob
ban. If traveling on a RED Alert Flight, RSA Security strongly advises
that you pack your RSA SecurID Authenticator in your check-in baggage.
If you do not do this, and you proceed to the boarding area with it in
hand, you might be asked to dispose of it before departure.

In the case of RED Alert Flights, if you do not have your laptop on
board, you will also not need your RSA SecurID token with you on the
aircraft.

For Orange Alert Flights � which are currently those that cover all
other U.S. flights � RSA SecurID tokens are not prohibited from
carry-on luggage. In other words, the company is currently being
advised that it is acceptable to place your RSA SecurID token in your
carry-on baggage if you are traveling on an Orange Alert Flight.


Q: What are considered electronic devices?

A: In the U.S., laptop computers, cell phones, and iPods are currently
considered electronic items. The U.K. authorities are also including
electronic key fob devices, such as those that lock and unlock your
automobile.


Q: Are RSA SecurID Authenticators different from electronic key fobs
for automobiles?

A: Yes, electronic key fobs for automobiles contain an RFI (Radio
Frequency Interface), and RSA SecurID Authenticators do not. However,
U.K. officials will not make the distinction between the two devices.
The concern is that any electronic device with an RFI could be used to
trigger an explosive device.


Q: How do I know if these rules and regulations have changed?

A: RSA Security is continuously monitoring the situation, is in
contact with the TSA and will provide updates as they become available.

The company also advises that you contact your airline or corporate
travel agency for information about any new or additional security
measures or precautions that might be required before you pack for
your trip and leave for the airport. If your travel plans do not
involve U.S. or U.K. flights, you may want to check with your national
transportation authority for the latest information.

You may also want to visit the website for the U.S. Transportation
Security Administration (http://www.tsa.gov) or the U.S. Department of
Homeland Security (http://www.dhs.gov/dhspublic/) for up-to-date
information.


Getting Support and Service:

For customers with current maintenance contracts, please contact your
local RSA Security Customer Support center with any additional
questions regarding this RSA SecurCare Alert. Contact phone numbers
and email addresses can be found by logging on to RSA SecurCare Online
at https://knowledge.rsasecurity.com and clicking "Contact & Help" >
"Contact Us - Phone" or "Contact Us - Email" in the left navigation menu.


General Customer Support Information:
http://www.rsasecurity.com/node.asp?id=1067


RSA SecurCare Online:
https://knowledge.rsasecurity.com


About RSA SecurCare Notes & Alerts Subscription:

RSA SecurCare Notes & Alerts are targeted email messages RSA Security
sends you based on the RSA Security product family you currently use.
If you'd like to stop receiving RSA SecurCare Notes & Alerts, or if
you'd like to change which RSA Security product family's Notes &
Alerts you currently receive, log on to RSA SecurCare Online at
https://knowledge.rsasecurity.com and click "Notes & Alerts" >
"Subscription" in the left navigation menu. Following the instructions
on the page, remove the check mark next to the RSA Security product
family whose Notes & Alerts you no longer wish to receive. Then click
the "Submit" button to save your selection.


Sincerely,


RSA Security Customer Support

Didier,

If you "sanitized" your documentation (i.e., changed hostnames and IP
addresses) would your employer permit you to share?

I would love to see your docs.

JP

--- In securid-users@yahoogroups.com, "Didier Arenzana"
<darenzana@...> wrote:
>
> Hi,
> I am using pam_radius from freeradius.org under RH Linux 2.1, to
> authenticate SSH users. It works perfectly.
>

> I have written a documentation on this, but I can't send it, since
> it's property of my employer. However feel free to ask details on the
> implementation.

Hi,
First, double-check that the VAR_ACE variable is exported and points
to the directory where sdconf.rec is (typically /var/ace/data).

I would advise to do the following, to diagnose where the problem is:
before runing sudo, set the following environment variables:
RSATRACELEVEL=15
RSATRACEDEST=/tmp/AceAPI.log
export RSATRACELEVEL RSATRACEDEST

after having launched sudo, look in /tmp/AceAPI.log file.

Regards,
Didier.

2006/7/27, Kevin <kkadow@...>:
> From the sudo-users mailing list, anybody seen this problem before?
>
> It's been years since I've used the SecurID module with sudo directly.
>
> Kevin

From the sudo-users mailing list, anybody seen this problem before?

It's been years since I've used the SecurID module with sudo directly.

Kevin


---------- Forwarded message ----------
From: Mike Nguyen <moozoo+sudo@...>
Date: Jul 26, 2006 4:48 PM
Subject: [sudo-users] Make fails when configured with --with-SecurID
and --with-pam
To: sudo-users@...

. . .

Additionally, I had alot of trouble getting the --with-SecurID option to
work and had to do a bit of mucking around, at least based on the provided
instructions in the README (Or maybe I was just tired).

If anyone needs to get it compiling (Using SecurID Version 5):

- Make sure to grab the ACEAgentSDK5032.zip file from RSA's site (Login
required).

- Once uncompressed, copy all the header files from the inc/ directory to a
location of your choice (say, /tmp/rsa/).  There should be 8 files.

acclnt.h    acexport.h  sd_types.h  sdacmvls.h  sdi_athd.h  sdi_defs.h
sdi_size.h  sdi_type.h

- Also copy the library files from the platform of your choice, lib/sol/, to
this same directory (say, /tmp/rsa/)  There should be 2 files.

libaceclnt.a   libaceclnt.so

- Once that is done, a ./configure --with-SecurID=/tmp/rsa should work
accordingly, find all the files it needs, and also detect that the SecurID
version you're using is 5, and not any previous one.

- Near the end of the ./configure output, if you get:

checking for SD_Init in -laceclnt... yes

...then SecurID version 5 has been correctly detected.

-----

But, although the compile seems to work fine using --with-SecurID...

It still seems as though something isn't working properly.

As I try a:

# sudo -s

I get:

sudo: failed to initialise the ACE API library

And in /var/adm/messages, appears:

sudo[7091]: [ID 940004 user.error] ACEAGENT: The message entry does not
exist for Message ID: 1001

The VAR_ACE variable has been defined in /etc/profile and the username
trying to sudo has it defined.

Might this be because we are using RSA 5.2, and not 5.0?

-----

OS:  Solaris 8
GCC:  3.3.2
Sudo:  1.6.8p12
RSA:  5.2

. . .

Hi All,

I want to protect RedHat Linux Advanced Server 2.1 using RSA SecurID.
Since this verson is not supported by RSA, so I'm planning to use
pam_radius or free_radius agent but have difficulties when configure it.

Can anyone share to me any experience, links or documents about
configuring this agent so it can communicate with RSA Authentication
Manager or RSA RADIUS server ?  Thanks for your time...

Hi,
I am using pam_radius from freeradius.org under RH Linux 2.1, to
authenticate SSH users. It works perfectly.

There is nothing realy special about the configuration, except that if
ou want to support New  PIN and next tokencode messages, you need to
configure the SSH daemon to allow this particular feature in the pam
module. I don't remember exactly which setting it was, I can look
further if you're interested.

I have written a documentation on this, but I can't send it, since
it's property of my employer. However feel free to ask details on the
implementation.

By the way, I have been asked to do the same thing with HP-UX on
Itanium, if anyone has been successful in compiling the pam_raidus
module in this environment, any information would be appreciated.

Regards,
Didier.


2006/7/25, Hendry <wirawijaya@...>:
> Hi all,
>
> I want to protect RedHat Linux Advanced Server 2.1 using RSA SecurID.
> Since it is not supported by RSA, so I'm planning to use pam_radius or
> free_radus module.
>
> Can anyone share to me link or documents how to configure this
> pam_radius or free_radius so it can communicate to RSA Authentication
> Manager or RSA RADIUS server ?
>

Hi all,

I want to protect RedHat Linux Advanced Server 2.1 using RSA SecurID.
Since it is not supported by RSA, so I'm planning to use pam_radius or
free_radus module.

Can anyone share to me link or documents how to configure this
pam_radius or free_radius so it can communicate to RSA Authentication
Manager or RSA RADIUS server ?

Hi thanks for the reply,

Well at the moment, i have an ldap query running to pull the users out
of AD (and that works).. the main problem here is auth manager is
rejecting my authentication requests, I am running a separate RADIUS
server and have that added as a agent host comm server. The request
doesnt seem to be making it to auth manager because their are no logs
but using a windows password accepts access (no logs on auth manager
either).

Domain controller is set to challenge all users in a particular group,
user is in that group.. token assigned.. any documentation you have on
setup would be great too.. havent found any decent guides on google.


--- In securid-users@yahoogroups.com, Bhagat Panwar
<bhagat_panwar@...> wrote:
>
> Hello
>   I have implemented such a solution for a major oil company .
>   and i totally disagree with Didier Arenzana .
>   First You dont need to create local users with Auth manager. You
can import your users from active Directory to your Auth Manager.
>   Yes the RSA agent EAP should be installed on the remote clients,
and this is more secure.The purpose of using a RSA SecurID is to only
be sure that who are logging remotely are who they really are and that
is why you have to use 2 factor authentication for the remote users.
They have to be authenticated by Auth manager before they can login in
to the network.
>   If you need more details you can always email me
>
>   Regards
>   Bhagat Panwar
>   ISS, CISSP , RSA SecurID , CCIE
>
>
> Didier Arenzana <darenzana@...> wrote:
>           Hi,
>
> 2006/7/5, speedy_1s <speedy_1s@...>:
> > Hi has anyone used securid for remote logins to an active directory?,
> > most of my users will dialin via adsl, here are some questions i have:
>
> I haven't used such a feature, but I think I can help anyway :
>
> > 1) should user accounts (within auth manager) be local or remote (i
> > really would like to avoid having to use realms unless completely
> > neccesary)
>
> Your user accounts within auth manager will be local. Remote accounts
> is only used when you want users from another realm to be able to
> authenticate through yours. If all your users are within your
> resposability, meaning you are the only one to provide them SecurID
> cards, then you don't need to use remote accounts.
>
> > 2) does the client software need to be installed on the remote pc
> > (keeping in mind that the user will be entering their passscode in the
> > dialup networking screen not the windows gina).
>
> I don't think so. That would mean the remote PC itself is contacting
> your auth manager to check the passcode, which would be a very bad
> idea, since that would mean you trust the remote PC's security.
>
> Regards,
> Didier.
>

Thanks for the reply Didier, I am pretty sure the last time i was
troubleshooting this problem i could login through a vpn with my
windows -password but not with the passcode, even though the user is
in the challenge group, perhaps its something between the ad server
and the ace server. do you know of any good installation guides for
securid with domain authenication? the only one i found was a nasa one
but that was very flawed, i am not finding much info on securid at all..

Hello
   I have implemented such a solution for a major oil company .
   and i totally disagree with Didier Arenzana .
   First You dont need to create local users with Auth manager. You can import
your users from active Directory to your Auth Manager.
   Yes the RSA agent EAP should be installed on the remote clients, and this is
more secure.The purpose of using a RSA SecurID is to only be sure that who are
logging remotely are who they really are and that is why you have to use 2
factor authentication for the remote users. They have to be authenticated by
Auth manager before they can login in to the network.
   If you need more details you can always email me

   Regards
   Bhagat Panwar
   ISS, CISSP , RSA SecurID , CCIE


Didier Arenzana <darenzana@...> wrote:
           Hi,

2006/7/5, speedy_1s <speedy_1s@...>:
> Hi has anyone used securid for remote logins to an active directory?,
> most of my users will dialin via adsl, here are some questions i have:

I haven't used such a feature, but I think I can help anyway :

> 1) should user accounts (within auth manager) be local or remote (i
> really would like to avoid having to use realms unless completely
> neccesary)

Your user accounts within auth manager will be local. Remote accounts
is only used when you want users from another realm to be able to
authenticate through yours. If all your users are within your
resposability, meaning you are the only one to provide them SecurID
cards, then you don't need to use remote accounts.

> 2) does the client software need to be installed on the remote pc
> (keeping in mind that the user will be entering their passscode in the
> dialup networking screen not the windows gina).

I don't think so. That would mean the remote PC itself is contacting
your auth manager to check the passcode, which would be a very bad
idea, since that would mean you trust the remote PC's security.

Regards,
Didier.

Hi,

2006/7/5, speedy_1s <speedy_1s@...>:
> Hi has anyone used securid for remote logins to an active directory?,
> most of my users will dialin via adsl, here are some questions i have:

I haven't used such a feature, but I think I can help anyway :

> 1) should user accounts (within auth manager) be local or remote (i
> really would like to avoid having to use realms unless completely
> neccesary)

Your user accounts within auth manager will be local. Remote accounts
is only used when you want users from another realm to be able to
authenticate through yours. If all your users are within your
resposability, meaning you are the only one to provide them SecurID
cards, then you don't need to use remote accounts.

> 2) does the client software need to be installed on the remote pc
> (keeping in mind that the user will be entering their passscode in the
> dialup networking screen not the windows gina).

I don't think so. That would mean the remote PC itself is contacting
your auth manager to check the passcode, which would be a very bad
idea, since that would mean you trust the remote PC's security.

Regards,
Didier.

Hi has anyone used securid for remote logins to an active directory?,
most of my users will dialin via adsl, here are some questions i have:

1) should user accounts (within auth manager) be local or remote (i
really would like to avoid having to use realms unless completely
neccesary)
2) does the client software need to be installed on the remote pc
(keeping in mind that the user will be entering their passscode in the
dialup networking screen not the windows gina).
3) anything else i should take in consideration..??

Hi

  Well, my problem is ,i want to restrict each user to be able to log
to domain via certain client pc .
i know that i must do this from "Edit Agent" in RSA server,then
adding the "activate user",and disabling "open to all locally
known.." at the same time.
i did this but it does not work.
the question is:certain user must be added to "DC Agent host" or
"client agent host"?

Rgds,
Kamyar



> Hi,
>
> I think when you are using domain authentication agent, then we
cannot
> register each ws as agent host. All the ws will login through
active
> directory. This might be your problem is.
>
> Have you ever try to configure it on active directory instead of
> Authentication Manager ??
>
> Or else, you might use local authentication agent to protect domain
> client.
>
>
>
> --- In securid-users@yahoogroups.com, "kamyarbeigi" <kamyarbeigi@>
> wrote:
> >
> >  Hi room,
> >
> >  newbie to RSA,just implemented Authentication Manager 6.0 for
domain
> > clients,i want to assign just one user to log on from each Agent
> > Host,but it does not work.any user exists in active directory
may log
> > on from any ws.
> > any tricks or tips or something else?
> >
> > Thank you in advance,
> > Rgds,
> > Kamyar
> >
>

On 6/22/06, Hendry <wirawijaya@...> wrote:
> I'm planning to implement RSA SecurID to protect user when login to
> Bastian Host. The Bastian Host is running in Linux 2.1. My concern is
> RSA didn't support Linux 2.1 OS anymore.

Welcome to my world.  RSA never did support OpenBSD.


> Is there any suggestion how to implement this ??

Run your ACE/Server on a supported platform inside the network with
RADIUS services enabled, and configure user authentication on the
Bastion host to use RADIUS authentication to the internal ACE/Sever.
This same solution will work with any OS or device which can handle
RADIUS, with a couple of minor caveats (e.g. the client must not try
to reuse the "password").

In the long run OATH (http://www.openauthentication.org/) should
resolve all of the "my OS isn't supported by my strong authentication
vendor" problems, but don't hold your breath.

Kevin

Hi,

I think when you are using domain authentication agent, then we cannot
register each ws as agent host. All the ws will login through active
directory. This might be your problem is.

Have you ever try to configure it on active directory instead of
Authentication Manager ??

Or else, you might use local authentication agent to protect domain
client.



--- In securid-users@yahoogroups.com, "kamyarbeigi" <kamyarbeigi@...>
wrote:
>
>  Hi room,
>
>  newbie to RSA,just implemented Authentication Manager 6.0 for domain
> clients,i want to assign just one user to log on from each Agent
> Host,but it does not work.any user exists in active directory may log
> on from any ws.
> any tricks or tips or something else?
>
> Thank you in advance,
> Rgds,
> Kamyar
>

Hi all,

I'm planning to implement RSA SecurID to protect user when login to
Bastian Host. The Bastian Host is running in Linux 2.1. My concern is
RSA didn't support Linux 2.1 OS anymore.

Is there any suggestion how to implement this ??

Hi room,

  newbie to RSA,just implemented Authentication Manager 6.0 for domain
clients,i want to assign just one user to log on from each Agent
Host,but it does not work.any user exists in active directory may log
on from any ws.
any tricks or tips or something else?

Thank you in advance,
Rgds,
Kamyar

Does anyone have any experience with RSA SecureID & WSS?

I have my WSS Intranet setup, but there is a constant security issue
because of RSASecureID.

If a user tries to access the WSS Intranet, 30 mins + after login,
they are prompted with a RSA Authentication window (which is
expected) and a Windows Authentication pop-up.

Since our users don't use a Windows password, the only quick fix is
to have a user Authenticate with RSA, cancel the windows pop-up and
then refresh the screen to access the WSS Intranet.

It just seems like there has to be an easier way.

I've been looking into RSA ClearTrust as a solution, but before I
make a proposal, I have to find the best option.

Any suggestions?  Can anyone through some insight my way?

Thanks in advance,
Dave
Core Systems Analyst
Novi, MI

--- In securid-users@yahoogroups.com, "nooosanis" <nooosanis@...>
wrote:
>
> Hi everybody
> Since RSA SD600 tokens are at "end of life" (isn't it?), I want to
make
> sure about compatibility of SID700 with the RSA ACE/SERVER 5.2.
> Does it work properly or do I need some upgrade for the server?
> Thanks.
>

We use many of the SID700 with ACE 5.2. Works just fine.