OT: change NT login procedure

Toomas Soome tsoome at ut.ee
Wed Jan 31 09:41:48 GMT 2001


Osama Abu-Aish wrote:
> 
> Am 31 Jan 2001, um 9:23 Uhr schrieb Toomas Soome zum Thema Re: OT: change NT login procedure:
> Dazu meine Meinung:
> 
> > we have currently blocked passwd change from windows and all passwords
> > are changed from unix (Solaris). I have written PAM module for this
> > task, stacked below pam_unix. pam_unix will take care of unix passwords
> > and pam_smb will write password into smbpasswd NIS+ table. this is unix
> > -> windows direction. this works well in our case.
> I know that PAM enables us to authenticate a unix box against windows.
> What I'm looking for is the other way round: windows->unix.

yes, but I do not authenticate unix against windows, I'm useing pam as
interface to change all configured authentication tokens. my unix boxes
still autenticate users with unix password database. the idea is not to
force different systems to use one specific algorithm, but let every
system to use it's native interface.

> 
> > windows-> unix is a problem, because we do not get cleartext old
> > password from windows client (am I wrong?). if so, we must save
> The GINA is the part of the authentication system that receives the
> password from the user. So there we have the plaintext passwd and
> can do anything with it (like crypt()ing and updation in the unix-fashion).

yes I know, it's possible to have such schemas. iPlanet ldap server does
have some sort of password sync etc. but this will requre changes in
client or in local (native mode) authentication server - in NT domain
controller for example.

> 
> > plaintext passwords into the safe place (crypted with some internal
> > key). it is generally bad idea to have plaintext passwords around, but
> > in university environment it is not totally unacceptable. I mean, such
> > database must be protected with some sort of encryption and if someone
> > wants passwords, well it is possible to use sniffers from pc classes,
> > one can do dictionary attack against password hashes etc.
> Off course the implementation must match the local requierements
> concerning security. In many environments NIS is used which sends
> the passwd-hashes (which are cleartext equivalent) over the wire. And

yes and no - you can't use password hash in unix login prompt - you need
cleartext for this.

> AFAIK LDAP authentication sends also the passwd in cleartext.

you can use ldap over ssl.

> The charme of an open implementation of a NT authentication package
> would be that it could be easily modified (IMHO that's what makes PAM
> so powerful). I.e.one could integrate SSL to protect the login-process.
> 
> Apart from this it's not only password synchronisation I'm thinking of
> (but off course it's the most important aspect), but I'd like to have a central
> user database containing _all_ account information. The best thing
> for me would be a LDAP directory containing an object for each user with
> _all_ information needed by windows, unix, etc...

this is my goal as well. and I'm already on a half a way, because I have
unix passwd.org_dir and smbpasswd.org_dir for windows. translating then
to ldap is relatively easy task, BUT. But I do not use windows native
domain controllers - only samba. and I can teach samba to store and
retrieve information from ldap, and even more important, I can teach it
to use pam to use pam to change ALL authentication tokens in system.

You have to keep in mind, this solution is specific and limited - you
can't use native NT server to control password change (unless you have
built some sort of mechanism to send old and new authentication token to
unix box). 

> 
> > so, if safe sorage for old (or current) passwords is implemented, next
> > task is to rewrite current samba interface for password change to use
> > standard pam interface (with old password from internal storage and new
> > password from client) and it's done. nice and clean.
> But this doesn't solve the problem that samba never sees the cleartext
> passwd because on standard NT authentication only the MD4'ed passwd
> is available to samba. Therefore it can't change the user's unix passwd.

samba will get user new password in cleartext, so I can store (and use)
it for next password change. and so I can take full advantage of pam.

> 
> > of course, there are but's. how to handle username maps, what happens if
> > we are going to have domain trust or kerberos environment etc...
> which could perhaps be handled easier on the NT side...
> 

If you have it. and if you have resources to "hack" it - to implement
syncronization. I do not have them, as samba does not support bdc. but I
do have different samba pdc's sharing the same smbpasswd.org_dir NIS+
table:)

toomas
-- 
Save a little money each month and at the end of the year you'll be
surprised at how little you have.
		-- Ernest Haskins




More information about the samba-technical mailing list