AFS uses a different passwords scheme than Samba. That means you'll need two 
sets of password files in order to have Samba and AFS on the same network. 
Otherwise, you need to use plain text passwords. Isn't there a way to make AFS 
and Samba more transparent than it is? I know you didn't write AFS, but Samba 
is now deployed on a lot of AFS-run networks, and perhaps there is something 
that can be done to solve this issue even if it means working with AFS 
developers to do it on their end.

Instead of providing a summary beyond that simple one, I'll give a copy of an 
email available at the URL above that will explain things better. I imagine 
you have heard about this a million times, but I couldn't find a bug on it 
(probably because the server is so new):

Sent: Monday, December 18, 2000 

==========

Question from student named Nate

 

I can understand the motivation for a decent computing department to require 
the use of ssh instead of straight telnet for all connections.  You are 
planning on implementing REQUIRED ssh even when students are ON campus, but it 
isn't even OPTIONAL to check one's email securely, or even connect to sambasrv 
securely, when it is the SAME PASSWORD!!!  Can you please explain the logic 
behind this?

===========

 

Response from Alan Powell

 

 

Date: Mon, 11 Dec 2000 

From: Alan Powell <powela AT NOSPAM rpi DOT E DEE U>

Subject: Remote Access Servers, Sambasrv, Mail, etc...

 

Hi Nate,

 

I read your comments to consult and thought I'd answer you since I'm in a 
better position to offer comments than the consultants are. I maintain 
sambasrv and I am also a member of the CIS security team. 

 

I can readily understand why you might think that it's absurd for us to 
require ssh on the Remote Access Servers and yet allow the exposure of user 
passwords with other services. The reality, however, is that we do care about 
protecting user passwords (and data) but that this is not always an easy thing 
to do. Just because there is a difficulty with protecting passwords in one 
service, doesn't mean it's irrational to protect passwords in services where 
we can do this easily. Each service we protect is one less potential exposure 
of someone's password. I also believe that good networking architecture could 
go a long way towards making passwords and data more secure and that 
encryption by itself it not the complete answer.

 

 

At any rate, you mentioned several services and here are some comments on each 
of them:

 

--------------------------------------------------------------------------

sambasrv

 

I have maintained sambasrv for the last four years and I *am* concerned about 
sambasrv requiring plain text passwords. If the solution were simply a matter 
of turning on encryption in samba, I would have done it years ago. The 
complication is that sambasrv is really a gateway to AFS space and for a user 
to end up with a token which gives them access to AFS, samba needs their plain 
text password.

When a user connects to sambasrv, samba first authenticates them to a 
kaserver  (a kerberos server that is part of AFS); this gives them access to 
the samba share itself. In addition to simply authenticating the user, this 
process also gives the user a token which gains them access to their AFS 
space. If I turned on encrypted passwords on the sambasrv side, 1) sambasrv 
would need to have a password file containing the NT hash of all users, which 
is *really* ugly from a security point of view, or would need to authenticate 
to an external NT server (messy) and 2) samba would be unable to authenticate 
that user to AFS, because all it would have would be the (Windows) encrypted 
password.

 

Long-term solutions:

 

Despite the general problem I explain above, I (and others) have come up with 
possible ways to turn on encryption and still allow users access to AFS space. 
At some point in the future, I do hope to be able to go to encrypted 
passwords.  But the reality is, that there is not a simple solution to this 
problem. I would also like to point out that turning on encryption in samba is 
not a large step forward security wise from using plain text passwords. The 
L0pht group has a program that can grab encrypted passwords from the network 
and use a dictionary attack against them with a very high success rate. 
Encrypted passwords would be a step forward, but are not the complete answer 
to a more secure environment...

 

---------------------------------------------------------------------------

 

The Remote Access Servers

 

I personally would have enforced SSH only on the Remote Access servers years 
ago, but Academic Computing had concerns about the availability of ssh clients.

One thing that is important to remember is that our primary job is to enable 
people to use RPI services, not get in their way. There is always a trade off 
between user needs and security. In the past, the decision was made that the 
trade off for enforcing ssh versus telnet was too great. Now that SSH clients 
are readily available and the RPI laptops all have SSH clients (and security 
incidents are getting worse), the decision was made to enforce SSH as the user 
burden would not be as great as it would have been in the past.

 

---------------------------------------------------------------------------

 

Email

 

Email clients are a good example of why we just can't turn on encryption and 
be done with it.

 

There are really no standards for encrypting passwords via email clients. Yes, 
some clients support some mechanisms but there is no overall standard and this 
makes it difficult to ensure that everyone can check email securely. What you 
may not know is that we do offer some ways of securely checking email (at 
least in terms of not exposing passwords) and have tested several others but 
found them very cumbersome or insecure in a different way.

 

kpop - Mail pop'ed to your RCS accounts using kpop has used kerberos 
authentication since I started here more than four years ago. Your passwords 
are not exposed via this process.

 

Eudora on PC's & Macs - Eudora users have been able to check email using 
kerberos for almost two years. Some crude instructions on doing this are at:

 

http://www.rpi.edu/dept/new-media-ctr/emailworkshop/emailkerberos.htm

 

I have been using this mechanism for a year and a half.

 

 

SSL tunneling, APOP - We have also tried other mechanisms for protecting user 
passwords but SSL tunneling was cumbersome and slow and APOP was a security 
risk in other ways.

 

--------------------------------------------------------------------------

 

 

CIS has not always moved as quickly as I like towards better security and

I personally would probably enforce greater security measures (like SSH on

Remote Access servers a long time ago) even if they were painful to users, but 
from the inside. I don't see this as a result of not caring or laziness, etc. 
I see it largely as 

1) a lack of real concern on the part of companies like Microsoft with regards 
to security combined with encryption laws which make providing secure services 
difficult and 

2) a consequence of an environment (things like AFS) which can make some 
things we might otherwise do difficult...

 

 

alan

 

----------------------------------------------------------------

 Alan Powell, Sr. Systems Programmer     e-mail: powela AT NOSPAM rpi DOT E 
DEE U

 Server Support Serv., RPI, 110 8th St.   Voice: (518) 276-2204

 Troy, New York 12180-3590                  FAX: (518) 276-2809