Re: Windows NT domain login

From: Brian Fulmer [231282] (briantf@hotmail.com)
Date: 02/04/03


From: "Brian Fulmer [231282]" <briantf@hotmail.com>
Date: Tue, 4 Feb 2003 10:07:03 -0800


Good questions.

1) User logon to a domain via a workstation that has membership in a domain
is NOT the same as authenticating from an untrusted machine and mapping a
drive. The biggie for NT boxes has always been that you can auth as a
different user than the one logged on locally, where the Win9X boxes only
give you the password dialog. The great leap forward from Win9x to XP Pro is
going to knock the socks off your users; you'll be happy and they'll be
happy.

2, 3) Given that you've read the editorial below:

For your environment, it sounds to me that the primary benefit of domain
membership for your NT/XP workstations would be user portability and logon
scripts. NT4 has pretty limited client management in comparison to
ActiveDirectory/IntelliMirror or NDS/ZenWorks.

I dunno when you started with NetWare, but imagine that every NT/XP
workstation is like a NetWare 3.x server - the bindery information for all
users/password/group membership is unique to each server. The equivalent for
NT is the Security Accounts Manager database (SAM). This means that for five
workstations, each user account would have to be created 5 times (and
password manually synchronized) for a single user to logon to any given
workstation at any given time. Also, any drive mappings would have to be
manually created at least once for each user profile. This was a screaming
PITA in NW3.x, and Novell bit off more than they could chew when they
"solved" it with NDS (took 3 tries to get a working version of NDS on the
market).

One of the purposes of the NT/Lan Manager Domain model is to allow a single
user account to be valid anywhere on the network (Novell had a product
called Domain Manager that did this for NW3 before NDS came out). This is a
more limited model than what NDS or AD does, but it is more than sufficient
for what you're doing.

The Primary Domain Controller on an NT4 domain uses its own SAM as the
read-write user/group repository for any workstation or server that is a
member (BDC's keep a read-only copy for load balancing and fault tolerance).
This means that the user accounts are not localized to the individual
workstation's stand-alone SAM's, but are centrally authenticated by the
domain (hence the "logon to <DOMAIN>" vs. "logon to <MACHINE>"). If a
workstation (machine) is not a member of a domain, you'll not see the domain
logon option.

For your Notes users, this would allow them to logon to any workstation in
your domain with a single user account and password, and have universally
available drive mappings (via logon scripts). So, someone's workstation
bombs out Monday AM, they move to the next cubicle where someone is out
sick, and go on the network as if nothing happened.

The last time I had to deal with Notes was on 4.6a (blech!) so I'm not sure
how the userid mapping for the Notes client works in the more recent 5.x
versions, but it should also make Notes administration easier if your domain
user accounts are authenticated as themselves from member workstations. It
will also make auditing your security logs a lot simpler (you'll get a lot
of garbage traffic from untrusted clients).

4) I don't know of any.

>>>>> Editorial >>>>>

The only reason I can imagine your having an NT Domain right now instead of
having your NT servers integrated into NDS/eDirectory is that you're
planning to eventually migrate to Win2K and ActiveDirectory. If this is NOT
the case, then you ought not have a mixed environment (NT Domains and NDS).
You're using your NT servers as app servers for Notes, so bring them under
management of NDS and don't screw around with Domains at ALL.

Around here, about the only place NetWare still has a user base is in
municipal government and education. The lower inertia organizations (private
sector excepting accounting offices) have all moved to Win2K. This is NOT to
say that Novell has not worked very hard to bring NetWare and NDS up to the
competitive challenge; they have a great product line that suffers mainly
from the kind of client base they've managed to retain. The same inertia
that keeps them on NetWare slows adoption and integration of the really
excellent technology Novell has deployed in the last five years.

IF you're staying with Novell/NetWare/NDS, I would urge you to concentrate
on using NDS for *everything* you possibly can. The tools are there. You
will be sad if you don't.

Regards,
Brian in CA

"Howard Hartman" <postmaster@neteast.com> wrote in message
news:#iLEbIGzCHA.2564@TK2MSFTNGP12...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello.
>
> I have a mixed network environment running Novell Netware and Windows NT.
> Currently our workstations are
> Windows 98 which log into both the NetWare servers and the Windows NT
> domain. Some of our Lotus Notes
> data is mapped to a drive in the Windows NT domain.
>
> We are planning an upgrade of our workstations to Windows XP Pro in the
near
> future. In testing we have found
> that Windows XP has many more options for connecting to a Windows NT
domain
> than Windows 98 does.
>
> One of the things we've discovered is that we can still map a drive to the
> Windows NT domain by supplying
> username and password without creating a domain account on the Windows XP
> workstation.
>
> We do not use our NT domain for user policy, profile or roaming user
> management.
>
> My questions are:
>
> Is logging into a Windows NT domain from XP by mapping a drive the same
> thing as being a member of the NT domain?
> If not, what are the benefits of making the XP workstations members of the
> NT domain?
> What are the benefits of creating domain login accounts on the XP
> workstations over local accounts?
> Is the a technical document or tutorial on managing logins and memberships
> to a Windows NT domain when using XP?
>
> Direct replies are appreciated.
>
> Thanks.
>
> - --
> Howard Hartman, Network Engineer
> United States District Court for the District of Columbia
> United States Courthouse - Washington, DC
> - --
> ICQ UIN: 1469550
> AOL IM: howard1h
> Web: http://neteast.com
> PGP Key: http://neteast.com/hhkeys.html
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0
> Comment: Digital signature guarantees authenticity
>
> iQA/AwUBPj/cNd/hBQ7O4WklEQIIOgCgrR0bo/J6aYWVBIzNQA8sOABdfi8AoM5H
> 3bMrnuTALMxEG2UFJj00JQ3s
> =WtN6
> -----END PGP SIGNATURE-----
>
>



Relevant Pages

  • network error 1331
    ... We have a mixed mode Windows 2000 AD Domain. ... The workstation is not joined to our domain but it should ... The client can connect to the Windows 2003 shares but the NT shares are ... I tried the user account also from one ...
    (microsoft.public.win2000.networking)
  • Re: Windows Update Failing - Error 0x800A0046
    ... here is what I did to resolve my issue in Windows 2000 SP4. ... I went to the Local User Account settings and went to the 'Member Of' ... So I decided to restart the workstation and voila Windows Update worked ... automatically downloaded critcal updates. ...
    (microsoft.public.win2000.windows_update)
  • Re: NT 4.0 PDC to 2000 SERVER AD admt question
    ... windows 2000 domain cant be renamed, then the workstations still be the member of the old domain ??? ... One of the most overlooked ADMT features is the Computer Migration Wizard. ... Remember that logging on to a Windows NT 4.0 or Windows 2000 workstation with a new user account, even with the same login name, creates a new user profile on the machine. ...
    (microsoft.public.win2000.active_directory)
  • RE: Adding a NT 4 stand alone server
    ... The W2K workstation is more efficient than NT. ... The average system uptime of Windows 2000 Professional ... account is disabled on NT or the passwords of the user account on both PCs ... please run Network Setup Wizard on both the ...
    (microsoft.public.windows.server.sbs)
  • Re: Unable To Delegate Add Workstation To Domain
    ... The domain controllers are 2000 and the member servers ... >I have created various OU admin groups for our different department and made ... >Group Policy at the domain level (added the Add Workstation group to the ... >of the GPO under User Account Rights) and 3) editing the Domain security ...
    (microsoft.public.win2000.active_directory)