NT Domain logon

[Luke Kenneth Casson Leighton]

On Thu, 30 Oct 1997, Nathan Neulinger wrote:

> On Thu, Oct 30, 1997 at 11:31:35PM +0000, Luke Kenneth Casson Leighton wrote:
> > On Fri, 31 Oct 1997, Nathan Neulinger wrote:
> > 
> > > First, a couple of questions - are encrypted passwords absolutely necessary?
> > 
> > the only way is to find out if the SAM database can support clear-text 
> > passwords or not.  we're mirroring SAM databases, which are based on 
> > encrypted passwords.
> > 
> > effectively what we are implementing is NT's "Local Security Authority"
> > SAM Service - LSASS.EXE.
> 
> So basically what you're saying is that smbd never receives a cleartext 
> version of the password, or never has enough data in it's posession to 
> calculate the cleartext? 

correct.
 
> Is the cleartext password supoprt in NT limited to the mounting of 
> shares?

yes, and worse: only for the "user-interactive" stage of the logins, 
which is when you get the "enter password for cached share" dialogs.

for security reasons, NT does not support clear-text passwords in the 
non-interactive stages (i.e the bits run by WINLOGON.EXE).


> (i.e. Does the domain controller interface not support cleartext 
> at all?)

no it does not, to the best of my knowledge.
 
> Most unfortunate.

about the only way i can think of to do this is to treat the 16 byte 
hashes as the clear-text passwords, for use by your kerberos server!

> > if you can get hold of an alternative login system, for example Novell's 
> > Local Security Authority, and ask them to provide full documentation on 
> > their over-the-wire protocol, then we will implement this.
> 
> The problem is, I thought this didn't log you into NT unless your NT 
> password was the same.

ah ha - the Novell system _replaces_ the NT login system as the "Primary
Login".  because you have the clear-text password at the login time, you
can _also_ generate the 16-byte hash, and log in to an NT Domain as _well_
as to a Novell Server. 

this is quite involved, technically, and microsoft doesn't publish
sufficient [implementation] details about it, deliberately. 

> We were hoping to do all this without replacing the GINA module. We've 
> got the source and such for a couple example GINA modules that we'd be 
> able to use if we had to.

GINA's won't help you, here: you need an LSA behind the GINA.  the GINA 
is just the graphical bit: the LSA is the actual authenticator that 
allows the login (local _or_ remote _or_ multi-user).
 
> If we have to replace the GINA module, we'll just authenticate directly 
> to AFS and not bother with SAMBA at all (sorry :), 

hey, that's no big deal: solve the problem any way you can that doesn't 
lock you in to a single solution.

> since at that point 
> we'd have direct AFS access on the station. Or, if we wanted to go 
> the cheap route, just authenticate to any central auth server 
> (tacacs/etc.). 
> 
> The big thing we're trying to gain is:
> 	1. 1 step logon
> 	2. Centralized SINGLE password database
> 	3. All users everywhere (not having to define a local NT userid for
> ever user we want to allow to log in.)
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                  Univ. of Missouri - Rolla
> EMail: nneul at umr.edu                    Computer Center
> WWW: http://www.umr.edu/~nneul      SysAdmin: rollanet.org
> 

<a href="mailto:lkcl at switchboard.net"  > Luke Kenneth Casson Leighton </a>
<a href="http://mailhost.cb1.com/~lkcl"> Lynx2.7-friendly Home Page   </a>
<br><b> "Apply the Laws of Nature to your environment because your
         environment applies the Laws of Nature to you"               </b>