By default when I access some computer's share ( typing \\hostname in Windows Explorer ) Windows passes credential of my current user. It prompts for credentials only when current user's credentials are incorrect.
Is there some way to force Windows not to pass current user's credentails, but prompt for them ? I thought about making use of net view command, but it doesn't grab 'user' and 'password' parameters.
I just tried to access a folder like so:
\\somecomputeronmynetwork\somelocation$
When going to this location I'm prompted for a user name and password.
I put one in, and it let me in fine.
Now I need to remove that login, so I can try a different user name and password.
What's the easiest way to do this?
Local System : Completely trusted account, moreso than the administrator account. There is nothing on a single box that this account can not do and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)"
http://msdn.microsoft.com/en-us/library/aa274606(SQL.80).aspx (Preparing to install SQL Server 2000(64 bit) - Creating Windows Service Accounts) tells:
"The local system account does not require a password, does not have network access rights, and restricts your SQL Server installation from interacting with other servers."
http://msdn.microsoft.com/en-us/library/ms684190(v=VS.85).aspx (LocalSystem Account, Build date: 8/5/2010) tells:
"The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService function, any password information you provide is ignored"
http://technet.microsoft.com/en-us/library/ms143504.aspx (Setting Up Windows Service Accounts) tells:
Local System is a very high-privileged built-in account. It has extensive privileges on the local system and acts as the computer on the network. > The actual name of the account is "NT AUTHORITY\SYSTEM".
Well-known security identifiers in Windows operating systems ( http://support.microsoft.com/kb/243330 ) does not have any SYSTEM at all (but only "LOCAL SYSTEM")
My Windows XP Pro SP3 (with MS SQL Server setup, developing machine in workgroup) does have SYSTEM but not LocalSystem or "Local System".
QUESTIONS:
Can somebody clear out this mess?
It is possible to burn hours after hours, day after day reading MS docs just to collect more and more contradictions and misunderstandings...
1) Has LocalSystem rights to access the network or not? What is the mechanism?
2) Are the SYSTEM and the LocalSystem (and the "Local System") synonyms?
Why they have been introduced?
What are the differences between SYSTEM and Local System
Update1:
Hi, sysamin1138!
Your answers add even more confusion if to compare them to observed reality, for ex., to the fact that Fresh installed or workgroup Windows XP Pro SP3 has only SYSTEM (but not LocalSystem).
Sysadmin138 wrote:
Does this phrase mean that LocalSystem is added upon joining computer to domain?
Should it be understood that SYSTEM is for "local"/internal and workgroup access (computer identification) and LocalSystem for identification of computer in domain?
Update2: same workgroup Windows XP Pro SP3 if not specified otherwise
Hi, Sysadmin1138, In your Edit
"It's just that in that case SYSTEM and NT Authority/SYSTEM are equivalent in ability",
how are they (NT Authority/SYSTEM and SYSTEM) related to LocalSystem? Did not you err one of them with LocalSystem?
Greg Askew,
"Note that if you configure a service to logon as .\LocalSystem, it will still appear as logged on as NT AUTHORITY\SYSTEM in Process Explorer or System in Task Manager"
This is a little be closer. I cannot choose LocalSystem in either NTFS/share premissions, RunAs list. But in services.msc the service "SQL Server (MS SQL SERVER)" --> double-click or rc --> Properties ---> tab "Logo on as:" has radiobuttom "Local System account". This service then appears in Windows Task Manager as SYSTEM
Greg Askew and sysadmin1138,
"NT AUTHORITY" or any "xxx\" does not appear anywhere. All account names are single-labeled. Note it is Windows XP workgroup computer. Though I run an instance of ADAM (Active Directory Application Mode).
I guess "NT AUTHORITY" is from that famous "security subsystem" which is absent in workgroup(?) Would "NT Authority" appear if I join computer to a domain?
NTFS/share permission list has 2 columns:
The former ones have also synonyms for coding as "MyCompName\xxxx" or ".\xxx" (i.e.
Can you synchronize your answers in context of http://blogs.msdn.com/aaron_margosis/archive/2009/11/05/machine-sids-and-domain-sids.aspx (Machine SIDs and Domain SIDs)?
Update3: same workgroup Windows XP Pro SP3 if not specified otherwise
Hi, Sysadmin1138,
And how to see edit-history? and dereference SID?
Breakthrough! cacls shows "NT Authority\SYSTEM"...
Though for services it is all vice versa: all services show under "Log On" tab
Sorry for your time, but I couldn't get yet to any LocalSystem in Windows XP! LocalSystem does not show up anywhere in XP! but the problem that all MS docs dwell only on LocalSystem...
BTW, http://support.microsoft.com/kb/120929 ("How the System account is used in Windows") tells that SYSTEM is for internal to computer logging of services, and surprise-surprise "APPLIES TO" all Windows from NT Workstation 3.1 to Windows Server 2003 except Windows XP(?!).
Is Windows XP some anomaly in Windows line?
Update4: same workgroup Windows XP Pro SP3 if not specified otherwise
I couldn't detect any LocalSystem (only "local system" mentioned in text to radiobutton of services LogOn)in Windows XP though all MS docs usually dwell on LocalSystem only but not SYSTEM. I marked this question as answered having understood for me that Windows XP is anomaly/exception in Windows OS-es having some GUI usability bug and I should guess how a scenario would have appeared in other Windows (with the help of answer(s) here)
Update5: same workgroup Windows XP Pro SP3 if not specified otherwise
Venceremos!
I found "Local System" in Windows XP! It is shown in "Log On As" column in services.msc!
We've recently migrated our Windows network to use DFS for shared files. DFS is working well, except for one annoying problem: users experience a significant delay when they try to access a DFS namespace that they have not accessed for some time. I have tried to troubleshoot the issue but have not had any success so far, and I was hoping someone here may have some pointers to help resolve the problem.
Firstly, some background on our network:
The network uses a Windows 2008 functional level Active Directory domain with two Windows 2008 DCs and two DNS servers (one on each of the DCs). The network is DNS only - no WINS. All computers are located at the same site and connected by Gigabit Ethernet. We have approximately 20 Domain-based DFS namespaces in Windows 2008 mode, and each DFS namespace has two Windows 2008 DFS namespace servers (the same two servers for all namespaces). All namespace servers are in FQDN mode and all folder targets are specified using their FQDN. All computers are up-to-date with Service Packs and patches.
The actual folder targets (i.e. the SMB shares our DFS folders point to) are scattered across several file and application servers, all running Windows 2008 bar two application servers which run Windows 2003 R2, with no replication setup at all (e.g. all DFS folders currently only have one folder target).
Some more detail on the problem:
The namespace access delay is generally 1 - 10 seconds long and seems to occur when a particular computer has not accessed the requested namespace for approximately five minutes or more.
For example, if the user has not accessed \\domain.name\namespace1\ for more than five minutes and attempts to access \\domain.name\namespace1\ via Windows Explorer, the Explorer window will freeze for 1 - 10 seconds before finally resuming and displaying the folders that exist in \\domain.name\namespace1. If they then close the Explorer window and attempt to access \\domain.name\namespace1\ again within five minutes the contents will be displayed almost instantly - if they wait longer than five minutes it will go through the 1 - 10 second pause again.
Once "inside" the namespace everything is nice and snappy, it's just the initial connection to the namespace that is slow.
The browsing delays seem to affect all variants of Windows that we use (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - it is possibly a bit worse in Windows XP / 2003 than in Windows 2008, but I'm not sure if the difference isn't just psychological.
Accessing the underlying folder targets directly exhibits no delay at all - i.e. if the SMB shares pointed to by DFS are accessed directly (bypassing DFS) then there is no pause.
During trouble-shooting I noticed that the "Cache duration" for all of our DFS roots is set to 300 seconds - 5 minutes. Given that this is the same amount of time required to trigger the pause I assume that this caching is somehow related, although I am unsure exactly what is cached on the client and hence what needs to be looked up again after 5 minutes have elapsed.
In trying to resolve the problem I have already tried / checked the following (without success):
So that's where I'm up to - and I'm out of ideas. Can anyone suggest what may be causing the delays and/or what I should be trying next?
I have a simple scenario. There's an application on ServerA that runs under the built-in Network Service account. It needs to read and write files on a folder share on ServerB. What permissions do I need to set on the folder share on ServerB?
I can get it to work by opening the security dialog of the share, adding a new security user, clicking "Object Types" and making sure "Computers" is checked, and then adding ServerA with read/write access. By doing this, what accounts are gaining access to the share? Only Network Service? All local accounts on ServerA? What should I be doing to grant ServerA's Network Service account access to ServerB's share?
Note:
I know this is similar to this question. However, in my scenario ServerA and ServerB are in the same domain.