[Full-disclosure] Re: SecurID with Active Directory ?

2006-01-10 Thread vin

Steven steven at lovebug.org wrote:

 RSA  for Windows authenticates against the RSA Authentication Manager
 and if successful allows the client to then send the Windows password to
 the Domain Controller.  This kind of defeats the purpose of two-factor as
 they could just login with their normal Windows password from a machine
 that doesn't have the RSA software on it.

Hi Steven,

You might want to review your assumptions here.

RSA's SecurID for Windows solution in Authentication Manager  v6.x will
enforce a two-factor authentication policy for domain resources -
including logon to domain accounts. If you're not using the RSA
Authentication Agent for Windows (or RSA's SSO option, SOM 4.5), you will
not be able to log in to a PC as a domain user in the protected group.

All resources protected by a SecurID for Windows (S4W) protected domain
require a session certificate for access. Just providing a windows
password satisfies windows domain authentication, but the
sub-authentication filters installed as a part of the S4W Domain
Controller (DC) component will deny access until a two-factor
authentication has occurred.

There are, of course, some environment for which RSA does not have a
S4W-enabled agent. In these environments the user will need to perform a
SecurID authentication from an agent that creates verifiable
authentications, and then provide their domain password (to OWA for
example). Even here, direct access -- without having performed a
verifiable authentication -- will be denied by the 'subauth' components on
the DC.

Courtney's First Law reminds us that it is impossible to say anything
meaningful about the security of any system without a clear
understanding of the context: the environment in which it is used, and the
specific application.

If you need something the standard S4W doesn't provide, you really should
sort through the implications of your application and your
environment with your RSA SSE or the gurus at RSA Customer Support. They
may even have suggestions if you really need tighter integration between
the SecurID authentication and AD.

[If, for instance, you really need to completely eliminate access via
passwords, you could use some programmatic method (i.e., Visual Basic) to
set your users' Windows passwords to very long, random passwords that
never expire. The password change would be captured on the DC and sent to
the ACE/Server. The long, random passwords would then be
provided with each authentication (and recovered when offline), but the
users will never know their Windows password. Since the passwords would
never expire, the users are also never allowed to select a smaller, less
secure passwords.

[These shadow passwords can be manually expired using the same process
executed on a regular basis (e.g., yearly), but that process is maybe a
little touchy for a production environment. The users would have make sure
their ACE/Server is up (and the connection is
operational) before running the process (or else they will have to run the
process again when the connection is available). The DC services will
queue these changes if a large number occur at once, so you would also
want to make sure all the password changes have been processed before
shutting down either the ACE/Server or DC.]

As always, the world is simpler if you stay with the standard product, but
customization is possible, sometimes with RSA support.

I hope this is helpful. I've been a consultant to RSA for many years, and
I figure that any authentication problem can have a SecurID
solution. YMMV. ;-)

Suerte,
 _Vin

References:

RSA SecurID for Windows (S4W) Infrastructure:
http://www.rsasecurity.com/node.asp?id=1173
RSA's Sign-On Manager:
http://www.rsasecurity.com/node.asp?id=2541

RSA's Security Vulnerability Reporting Policy:
http://www.rsasecurity.com/node.asp?id=2928

--- * * * * ---

On 1/10/06, Steven at lovebug.org queried the Listocracy:

 Does anyone know of a product that will tie-in RSA's SecurID with
 Microsoft Windows Active Directory?  I want to require certain users to
 use their pin+current token in order to authenticate to the Domain.
 However, the main solution from RSA does not appear to provide a very good
 solution at all. RSA for Windows authenticates against the RSA
 Authentication Manager and if successful allows the client to then send
 the Windows password to the Domain Controller.  This kind of defeats the
 purpose of two-factor as they could just login with their normal Windows
 password from a machine that doesn't have the RSA software on it.
 Additionally, what if they want two-factor across the board.. to include
 NetBIOS/SMB Shares/Webmail?  Is there a product that will tie into Active
 Directory and *only* and *always* accept RSA SecurID pin+tokens for
 authentication?

 This can easily be done *nix boxes, but I am having some trouble finding
 something that will work on Windows.

 Any ideas?

 Thanks,

 Steven



Re: [Full-disclosure] Re: SecurID with Active Directory ?

2006-01-10 Thread Morning Wood
 [If, for instance, you really need to completely eliminate access via
 passwords, you could use some programmatic method (i.e., Visual Basic) to
 set your users' Windows passwords to very long, random passwords that
 never expire. The password change would be captured on the DC and sent to
 the ACE/Server. The long, random passwords would then be
 provided with each authentication (and recovered when offline), but the

 I belive you are meaning a custom VB login.exe at every user station?

 users will never know their Windows password.

unless of course they take to time to look in the custom vb login.exe
application,
where the user/pass is stored in clear text. This would also be a point of
attack
if the exe were ever to escape outside infrastructure controls. ( I bring
this up as
this exact vector was used successfully in a pentest, the exe asked for a
user/pass,
the application then allowed access to the ftp server and its credentials
were stored cleartext
in the exe. The developer belived he could hide the actual ftp process from
the end user so
they did not need to set up user accounts on the ftp server and using the
exe to validate
against an asp server, thus allowing the application to validate and run. )

although not quite the scenario you describe, i believe the implications
would be the same.
of course, I could be completely off base

MW
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/