Re: Cannot logon to "(local machine)"

From: Bruce Sanderson (Bruce.Sanderson_at_junk.junk)
Date: 12/02/04 

Date: Thu, 2 Dec 2004 13:39:10 -0800

Some additional information to add to what Ken B said:

1. by default, the "special folder" called "My Documents" is mapped to the
My Documents folder within the user's profile. This mapping can be changed,
either by code in a logon script or a Group Policy. A consideration with
Roaming Profiles is how large the profile is. The Roaming Profile has to be
synchronized with the local copy at each logon and logoff, so there is a
distinct advantage to keeping the profile small. Re-directing the My
Documents special folder outside of the profile assists in this endeavor.
Also, you can use a Group Policy to specify that certain sub-folders within
the profile are not made part of the network copy of the Roaming Profile.

2. it is a common practice in Windows environments to have a "Home
Directory" on a network share - this has been a feature in Windows for a
long time - it is not a UNIX specific feature. If desired, this Home
Directory can be automatically mapped to a drive letter; this mapping can be
specified for individual user accounts, via Group Policy or a logon script.
The special folder called "My Documents" can be re-directed to the Home
Directory, again either via Group Policy or a logon script.

3. when a computer is not network connected, naturally, the user's Home
Directory (network share) will unavailable. With WIndows XP clients, it is
possible to mark folders in the Home Directory or elsewhere as "available
offline". When this is done, the selected folders are copied to the local
harddrive and automatically synchronized with the network copy at logon and
logoff. Since only changes need to be synchronized, this reduces the
network traffic and elapsed time for logon/logoff, particularly as opposed
to keeping all of the user's files with a "Roaming Profile".

4. a logon script can be specified for the individual user accounts in
Active Directory, or via a Group Policy. The later is often easier since
then it is not necessary to add the setting to existing user accounts or new
user accounts when they are created.

As far as I'm concerned, Windows in a Domain environment is a "distributed
system". We treat all of workstations as interchangeable - users do not
store files on the local hard drives. For users with laptops, we encourage
them to use the Offline Folder feature rather than specifically copying
files to the laptop for use while not network connected.

If you want to go a step further, you can use Terminal Services (with or
without third party enhancements). Then, the workstations don't even need
to have applications installed on them and can be treated like "terminals" -
there are also manufactures of "special purpose" computers specifically for
this situation ("thin clients").

If you haven't already, take a look at the documentation at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/csc_and_shares.asp.

You may also find the spread*** at
http://www.microsoft.com/downloads/details.aspx?FamilyID=ef3a35c0-19b9-4acc-b5be-9b7dab13108e&DisplayLang=en.
It documents all of the Group Policy settings available via GPMC (or the
older Group Policy Editor). 

-- 
Bruce Sanderson MVP
It's perfectly useless to know the right answer to the wrong question.
"nhlpens66" <nhlpens66@discussions.microsoft.com> wrote in message 
news:19C1DC1F-5B03-4142-A059-8097C391CFDF@microsoft.com...
> Ahhh.  That's it!  Thank you so much.  That's the solution to my problem.
>
> Boy, how simple it is -- the best kind of solution -- where you don't have
> to do anything.  It was there all along.  That feature is not documented, 
> at
> least that I could see when perusing hundreds and hundreds of web pages 
> and
> windows books over the past several months.  I can't tell you how releived 
> I
> am that I've finally got this problem solved.
>
> Boy was I down the wrong path.  Everything pointed to the "logon locally"
> group policy.
>
> For all the newbies out there, there is a subtle but disctinct difference
> between local user profiles and roaming profiles; and local user accounts 
> and
> domain accounts.
>
> Profiles DO NOT equal accounts.
>
> Profiles are only a set of files settings.  User accounts however are
> "authenticated" either locally or on the network's SAM, or Security Access
> Manager.  My mistake was thinking that because I logged onto the domain
> account , which created the local profile on my machine, that I could just
> logon to the local machine.  My local SAM had no idea who I was when 
> trying
> to logon to the "(local machine)".  Authentication failed everytime.  As 
> soon
> as I added myself to the local users, the local SAM, and logged on 
> locally, a
> new local profile was created -- different than the roaming profile with
> different settings (whatever the defaults are for that machine).
>
> One last subtlety, domain accounts create different and independent local
> profiles on each computer that one logs onto.  Roaming profiles use the 
> same
> profile from a centralized server.  However, they do create a CACHED 
> profile.
>
> Bruce has the right answer to the right question.  Disconnecting from the
> network and then logging on is how one logs onto the locally cached copy 
> of
> their roaming profile.
>
> It's a lot to keep straight, but I don't think that I'll ever forget it.
>
> Pardon my naiveness.  UNIX and Linux are distributed systems.  One just
> "logs on" to any machine and all their files and settings are stored in 
> their
> "home directory".  But it really sucks when the network goes down. 
> Everybody
> at work has to go home because they can't logon.  That justifies the 
> locally
> cached complexity as a win for me.  I just wish it was documented.  :)
>
> Thanks again Bruce.
>
> jim sadlek
>
> "Bruce Sanderson" wrote:
>
>> If a user has logged on with a domain account, the credentials 
>> (usernmame,
>> password and domain name) are cached locally.
>>
>> Then, when the computer is NOT network connected, the user can still 
>> logon
>> with their domain user account.  Just leave the "Domain:" box on the 
>> logon
>> panel with the domain name - don't change it to the local computer name.
>> Key the user's normal (Domain) username and password.
>>
>> Naturally, since there is no network connection, the locally cached copy 
>> of
>> the roaming profile will also be used.
>>
>> By default, Windows will cache the logon credentials locally for up to 10
>> domain user accounts.
>>
>> -- 
>> Bruce Sanderson MVP
>>
>> It's perfectly useless to know the right answer to the wrong question.
>
> "nhlpens66" <nhlpens66@discussions.microsoft.com> wrote in message
> news:73A0A99D-45C1-4059-91F8-CF519061462E@microsoft.com...
>> Steven,
>>
>> Maybe all I'm missing is to actually create the user account in the local
>> sam database.  That's where the authentication is failing.  The profile
>> may
>> be cached locally, but the user account doesn't exist in the sam.  I'll
>> try
>> that.
>>
>> "Steven L Umbach" wrote:
>>
>>> That is by design. You can only logon to the local computer with 
>>> accounts
>>> that exist in the local user database as shown by lusrmgr.msc because
>>> when
>>> you logon to the local computer you are authenticating with the local
>>> sam.
>>> Domain users must select the domain name when they logon - not the local
>>> machine  --- Steve
>>>
>>>
>>> "nhlpens66" <nhlpens66@discussions.microsoft.com> wrote in message
>>> news:8B22C6FB-40FF-492B-9004-0F222E2BEBE5@microsoft.com...
>>> >I am able to logon with local accounts (locally only, of course); and
>>> >with
>>> > domain accounts through domain authentication only.  I CANNOT logon to
>>> > any
>>> > domain accounts locally (local machine).
>>> >
>>> > "Steven L Umbach" wrote:
>>> >
>>> >> So you are not able to logon at all as that user?? If that is the 
>>> >> case
>>> >> enable auditing of logon events on the computer in question and
>>> >> account
>>> >> logon events in Domain Controller Security Policy to see if any logon
>>> >> failures are recorded and the reason for such. The error seems to
>>> >> indicate
>>> >> unknown user account or bad password. By default all domain users can
>>> >> logon
>>> >> to all domain computers except domain controllers. Make sure you are
>>> >> logging
>>> >> onto the correct domain or not the local machine on the computer in
>>> >> question. Also check that the user has permissions to their local
>>> >> profile
>>> >> which by default would be full control and also be owner.  --- Steve
>>> >>
>>> >>
>>> >> "nhlpens66" <nhlpens66@discussions.microsoft.com> wrote in message
>>> >> news:7C8963B1-F2CE-43E4-B3E0-8985E3D2B93B@microsoft.com...
>>> >> >I setup roaming profiles and can logon to my domain for each user.
>>> >> >However,
>>> >> > when I try to compare the original local profile with the new
>>> >> > roaming
>>> >> > profile side-by-side, I get this error message:
>>> >> >
>>> >> > "The system could not log you on.  Make sure your User name and
>>> >> > Domain
>>> >> > are
>>> >> > correct..."
>>> >> >
>>> >> > I get this when attempting to log on locally to the machine with 
>>> >> > the
>>> >> > original, local profile.
>>> >> >
>>> >> > I tried setting the "Allow log on locally" policy under Computer
>>> >> > Configuration/Windows Settings/Security Settings/Local 
>>> >> > Policies/User
>>> >> > Rights
>>> >> > Assignment".
>>> >> >
>>> >> > I added the users group.  I even added the user explicitly.
>>> >> >
>>> >> > Am I missing a step when applying this policy?  I can email my
>>> >> > gpresults
>>> >> > if
>>> >> > you'd like.  Everything appears to be in order.
>>> >> >
>>> >> > --
>>> >> > Jim