NT Domain logon
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Fri Oct 31 12:19:04 GMT 1997
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?
> Is the cleartext password supoprt in NT limited to the mounting of
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
> 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>
More information about the samba