samba - Dec 2004 - authenticate Samba users with RSA SecureID or Safeword

Hi,

=20

I=92m looking for inspiration on how to get Samba (setup as a Domain
controller)=20

To authenticate its users by AAA products like Safeword from securecomputing
(HYPERLINK "http://www.safeword.com/"www.safeword.com) or

RSA SecureID =96 HYPERLINK "http://www.rsa.com/"www.rsa.com=20

=20

Would appreciate responses from you kind folks

=20

Rgds

Gopal


--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 12/26/2004
=20

Gopal,

How much inspiration do you need? I can spare you a little of mine, but you=20
can't have it all! :)

=2D John T.

On Monday 27 December 2004 06:55, Gopal Krishna C J
wrote:
> Hi,
>
>
>
> I=92m looking for inspiration on how to get Samba (setup as a Domain
> controller)
>
> To authenticate its users by AAA products like Safeword from
> securecomputing (HYPERLINK
"http://www.safeword.com/"www.safeword.com) or
>
> RSA SecureID =96 HYPERLINK "http://www.rsa.com/"www.rsa.com
>
>
>
> Would appreciate responses from you kind folks
>
>
>
> Rgds
>
> Gopal
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 12/26/2004
=2D-=20
John H Terpstra
Samba-Team Member
Phone: +1 (650) 580-8668

Author:
The Official Samba-3 HOWTO & Reference Guide, ISBN: 0131453556
Samba-3 by Example, ISBN: 0131472216
Hardening Linux, ISBN: 0072254971
Other books in production.

On Mon, 2004-12-27 at 19:25 +0530, Gopal Krishna C J wrote:
> Hi,
> 
>  
> 
> I?m looking for inspiration on how to get Samba (setup as a Domain
> controller) 
> 
> To authenticate its users by AAA products like Safeword from
securecomputing
> (HYPERLINK "http://www.safeword.com/"www.safeword.com) or
> 
> RSA SecureID ? HYPERLINK "http://www.rsa.com/"www.rsa.com 
Replacing passwords in an NT domain environment is a tricky problem,
because unlike Active Directory, we don't have kerberos.  Kerberos
allows the exchange between the fob and the central server to be
customised, and nobody else in the chain needs to care what's going on.

Once you use passwords, and in the 'cached password' NT Domain Logon
environment that we have, there is a presumption that that password does
not change, after the user logs in.  This is used to give the illusion
of 'single sign on'.  If the password does change, and a server is
contacted (say a new file-server), then the user will be prompted for a
password.  This is fine (well, a right royal pain, but functional)
*most* of the time, but we loose the auto-reconnect feature, and can
loose data.   (See discussion about plaintext passwords and Samba,
because I think it's the same problem).

However, I think it is still possible to construct a system that has the
benifit of the 'fob', but with sufficient 'memory' such that
once a
workstation has cached a password for a login session, the password can
still be used.  Provided the one-time passwords are kept secret for the
reasonable life of the session, this should still be a security
improvement over the constant passwords, because user's can't choose
them.

This would require the algorithm for the generation of the one-time
passwords to be public, and Samba as the server would need access to
those passwords.  It could then 'remember' passwords successfully used
for an interactive logon request, and allow that password to be used via
file-servers, proxy servers and the like for the reasonable duration of
the session.   BDC operation would be interesting, but I suppose
possible.

Yes, this is very easily spoofed, but the passwords are not clear-text
on the network in the first place, so it is practical to consider them
confidential.

Hmm, perhaps it's just easier to finish Samba4, and use Kerberos :-)

Andrew Bartlett

-- 
Andrew Bartlett <abartlet@samba.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20050102/31ddc807/attachment.bin

On Mon, 2004-12-27 at 19:25 +0530, Gopal Krishna C J wrote:
> Hi,
> 
>  
> 
> I?m looking for inspiration on how to get Samba (setup as a Domain
> controller) 
> 
> To authenticate its users by AAA products like Safeword from
securecomputing
> (HYPERLINK "http://www.safeword.com/"www.safeword.com) or
> 
> RSA SecureID ? HYPERLINK "http://www.rsa.com/"www.rsa.com 
Replacing passwords in an NT domain environment is a tricky problem,
because unlike Active Directory, we don't have kerberos.  Kerberos
allows the exchange between the fob and the central server to be
customised, and nobody else in the chain needs to care what's going on.

Once you use passwords, and in the 'cached password' NT Domain Logon
environment that we have, there is a presumption that that password does
not change, after the user logs in.  This is used to give the illusion
of 'single sign on'.  If the password does change, and a server is
contacted (say a new file-server), then the user will be prompted for a
password.  This is fine (well, a right royal pain, but functional)
*most* of the time, but we loose the auto-reconnect feature, and can
loose data.   (See discussion about plaintext passwords and Samba,
because I think it's the same problem).

However, I think it is still possible to construct a system that has the
benifit of the 'fob', but with sufficient 'memory' such that
once a
workstation has cached a password for a login session, the password can
still be used.  Provided the one-time passwords are kept secret for the
reasonable life of the session, this should still be a security
improvement over the constant passwords, because user's can't choose
them.

This would require the algorithm for the generation of the one-time
passwords to be public, and Samba as the server would need access to
those passwords.  It could then 'remember' passwords successfully used
for an interactive logon request, and allow that password to be used via
file-servers, proxy servers and the like for the reasonable duration of
the session.   BDC operation would be interesting, but I suppose
possible.

Yes, this is very easily spoofed, but the passwords are not clear-text
on the network in the first place, so it is practical to consider them
confidential.

Hmm, perhaps it's just easier to finish Samba4, and use Kerberos :-)

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@samba.org
Authentication Developer, Samba Team            http://samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20050108/6992e89c/attachment.bin