Cannot logon to "(local machine)"

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
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
 
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).
 
nhlpens66 said:
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).
Click to expand...
 
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
 
But I'm using roaming profiles with folder redirection and offline files. I
want to logon to the locally cached copy when, say, my laptop is mobile and
on the road.

I should be able to logon to the locally cached profile. The documentation
for roaming profiles states that all changes to the profile and offline files
will be merged/copied back to the server when I next logon to the network.

Jim
 
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.
 
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.
 
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
 
Well, along those lines, you /could/ make Windows a distributed system where
your "home directory" is mapped and you can relatively easily log onto any
workstation and your files appear (via redirected folders).

But glad you got the solution :)

Ken
 
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/.../enterprise/proddocs/en-us/csc_and_shares.asp.

You may also find the spreadsheet at
http://www.microsoft.com/downloads/...c0-19b9-4acc-b5be-9b7dab13108e&DisplayLang=en.
It documents all of the Group Policy settings available via GPMC (or the
older Group Policy Editor).
 
Thanks for the tips Bruce and Ken. I am testing the holy grail in windows
data and user settings before rolling this out. That is I'm implementing
"roaming profiles with folder redirecting and offline files" as described in:

Guide to User Data and User Setting
http://www.microsoft.com/technet/pr...ctory/activedirectory/stepbystep/usrdata.mspx

So far, even as you have pointed out, the dependancy is not mission
critical. Each PC can operate without the network. The synchronization
"just happens" when the network returns. I give the Redmond boys credit.
Try that on a UNIX box. Huh, everybody will go home.

Later,

jim
 
Back
Top