Logon local to W2k workstation using domain account

  • Thread starter Thread starter Ratmoler Hamstak
  • Start date Start date
R

Ratmoler Hamstak

I have a win2k workstation which is a member of a domain on a home
network (set up as a domain for development/academic purposes). I am
receiving a "system was unable to log on..." message when I attempt to
use a domain account to log on locally (logging into the domain works
fine). The account policy is set to allow local logon; this is
established in the local, domain, and domain controller levels.
Opening the account policy in the workstation's local security policy
manager reveals that the effective security policy is opeartive for
the domain account in question. The domain account is not a member of
any groups affected by the "deny local login" policy, which I suspect
would override the "Log on locally" policy.

The reason I need to log on locally is that I recently purchased a
Tritton NAS device for centralized file storage/ftp capabilities; I
chose an appliance over building a file server for low power, always
on, and small footprint benefits. I can only connect to it as a drive
from the workstation when logged in to the daomin if my win2k server
is on (I leave this off most of the time, and would prefer to); the
error is "no logon server avaialable to service the request". Logging
on locally using the domain account would clear up the problem, I
suspect. Creating a local user account is a possibility of course, but
I'd prefer to use a single account.

One last thing: when logging in locally using a domain account, is
it necessary to prefix the account name with the domain name, as in
DOMAIN\Username? I tried this, but the dropdown for selecting the
login context grayed out, so I assumed that prefixing in this manner
performs domain login even if you have the local machine selected.

Thanks in advance.

Tom
 
I'm a little confused by what you are asking....

To logon locally with a domain account, you type the name, password and
select the domain from the list (or type DOMAIN\ACCOUNT which causes the
third box to get greyed out.) You can do it either way.

I'm confused by what you are calling a "local logon" vs a "domain logon" ...
a local logon means it is occuring at the console of the workstation (as
opposed to connecting over the network to the workstation) and does not
relate to whether the account is local to the machine or is from a domain.

If you are typing at the keyboard, it's a local logon no matter where the
account comes from. Also called an "interactive" logon in Microsoft-speak.

If you don't want to logon using a domain account (for example-- because you
plan on shutting your server down most of the time) then you should make a
local account. [Although Windows will usually allow a domain logon to occur
if the server is unavailable because it will cache your credentials.]

The term "logging on locally" is also sometimes used to refer to logging on
to a machine using a local machine account (for example, the computer's
local Administrator account.) Maybe that's where the confusion is...
 
Domain user accounts such as those listed in AD Users and computers can only logon to
the domain or a trusted domain only. To logon to a local computer, you must use local
user account. By default there are two - built in administrator and guest [which is
disabled by default]. You can however choose the same username and password for a
local computer account if you want. --- Steve
 
There is a setting in group policy under Windows Settings->Security
Settings->Local Policies->User Rights Assignment named 'Log on Locally'. I
wonder if the group 'everyone' is added there? or atleast the domain user in
question...
 
Steven said:
Domain user accounts such as those listed in AD Users and computers
can only logon to the domain or a trusted domain only. To logon to
a local computer, you must use local user account.
Click to expand...
Hi

But you can use your domain account/password to log on to the computer
even if the domain is not available (a.k.a. cached credentials).

A prerequisite for this to work is that you must do at least one
successful logon to the domain before taking the computer offline.
 
True, but I did not get the impressions that is what he was trying to do. --- Steve
 
Thanks for your responses. If anyone was (is) confused, that would be
me. I misunderstood the notion of using a domain account to "logon
locally" (selecting "this computer" from the "log on to" menu of the
logon screen), believing that this would cause the account to emulate
a local account therefore bypassing domain authentication and treating
the workstation essentially as a standalone computer. Let me approach
the problem from the opposite direction.

I have a Tritton NAS-120 network attached storage appliance. It was
designed to operate readily with Windows workgroups but not domains.
Accounts and groups are established on the device through an embedded
http interface and do not appear to be integrable with Active
Directory.

My server is Win2k, serves as a DC and has Active Directory installed.
When I initially set up the NAS device, I was able to connect to it
and map it to a drive letter on the server in the manner specified
(\\{ip address}). Incidentally, a name can be specifed for the
device using its web interface, and this name appears in the Active
Directory Users and Computers manager under the compouters node.)
While the server was in operation, I made the same mapping on my
workstation and was able to access it without any problems. The
problem occurs if the server is off and I try to access the drive
through the workstation using either the mapping or the URN. The
error which occurs reads "no logon servers available to service the
logon request". My impression is that the device is considered to be
a member of the domain and is registered in Active directory, that
this information stored is maintained in the instance of win2k pro on
the workstation, and that it requires the dc to be operating in order
to service the "logon" request.

By the way, the credentials for the domain accounts I have used are
cached, as I am able to "logon to the domain" even when the server is
unavailable.

Finally, if I use a local computer account and logon to the computer,
I am able to access the drive with no problem.

Ultimately, the issue is that I would like to be able to use a domain
account to logon and be able to access the drive without the server
being available rather than having to maintain a separate local
account. For those of you who might suggest I keep the server on all
the time, the reason I got the NAS device was so I wouldn't have to do
that; it is a compact, low-power unit -- and I do live in SoCal.

Thanks again for any comments/suggestion you might have.

Tom -- aka hamstak
 
You can create a local computer account that has the same username/password as a
domain account and access resources in the domain as a domain user as long as the
domain controller is running. If the domain controller is down you can not access the
resource as a domain user because the domain controller must be contacted to
authenticate the user since the domain resource computer has no way of knowing if the
request is from a legitimate domain account. That is the nature of domain
authentication.

The only way to access a resource on a domain computer without the domain controller
running is to add users to local user database via lusrmgr.msc on that domain member.
That will allow a user to access the resource as a local user and not as a domain
member. Though confusing, you could have the same username/password in the local user
sam of the domain computer offering the share. You should be able to connect then by
using computername\user as the user trying to gain access when prompted for
credentials. Hope that helps. --- Steve
 
Thanks Steve, but I think I am out of luck -- at least from the
perspective of my ideal solution. I was hoping to be able to use a
single account so that I could also use a single profile; correct me
if I am mistaken, but I am under the impression that a domain account
and a local account, even with identical credentials, maintain
distinct profiles. Your solution might be the closest to ideal that I
have. So it goes.
 
That is true. About the best you could do is to copy one profile over to the
other when needed. --- Steve
 
Back
Top