KB2001.728
Problem: '[Control] Access Denied' using Domain Time II Manager, Client, Server, Update Server, or Audit Server
This article applies to Domain Time Domain Time II Manager,
Domain Time II Update Server, and
Domain Time II Audit Server
Last updated: 4 November 2021
Problem
When you try to control a remote machine using Domain Time II Manager, you get "Control Access Denied" or "Access Denied" errors, and, on Manager Version 4.1 and earlier, all (or most) of the buttons on the Connected to... dialog window are grayed out.
Or you receive "Access Denied" messages when using Domain Time II Update Server or Domain Time II Audit Server.
Symptoms
Domain Time II Manager
Domain Time II Manager uses standard Microsoft Networking access to provide remote control
of other machines on your network. If Manager cannot obtain sufficient access, it will
display "Access Denied" or "Logon Failure" errors, and on some versions, all (or most) of the control buttons will be
grayed out.
If Manager can determine that Domain Time II Client or Server is installed on the remote machine,
but doesn't have sufficient permission to provide full remote control it will only enable the Sync Now,
Reset Stats, and Refresh functions. These functions only require port 9909 UDP access, not full
remote control permission.
Domain Time II Update Server
The Update Server service works very similarly to Manager in performing remote installs and upgrades using
Microsoft Networking. If it is unable to obtain sufficient network access to a remote system, installs
and upgrades will fail and "Access Denied" errors will be written to the service log.
Domain Time II Client or Server
The "Connect to another computer" function of the Domain Time applet also uses Microsoft Networking to provide
display of settings on remote Domain Time Clients or Servers. As above, access will fail with insufficient permissions.
Domain Time II Audit Server
Standard features such as collecting audit data and synchronization records are available using port 9909 UDP and/or TCP.
Some features of Audit Server such as automatically updating the Audit List with
machines that have synchronized with Domain Time II Servers require remote file and registry access in the same manner as
Manager and Update Server. If the Audit Server service cannot obtain sufficient network access, these features will fail and
"Access Denied" errors will be written to the service log.
Details
Domain Time II components use four tests to verify remote access permission:
- Ping
The remote machine must respond to an ICMP echo request. If you are accessing
by IP number, then failure usually means the remote host is offline or that
ICMP has been blocked by a router between you and the remote machine. If you
are accessing by DNS or NetBIOS name, then you may not have proper DNS and/or WINS (or other)
NetBIOS-name-to-IP-address resolution set up on your network.
- File System
The remote machine must allow you to connect to its ADMIN$ share and read/write
files. The ADMIN$ and drive shares exists by default on machines joined to a domain as long as File and Print Sharing is
installed and enabled. On newer versions of Windows, machines in workgroups need to have this capability
enabled by a registry change (see #7 below).
- Remote Registry
The remote machine must allow you to connect to and read/write from its registry using the Remote Registry service.
Failure usually means that that you do not have administrative permissions to the remote machine or that the Remote
Registry service is not running there. Remote Registry is installed (but not always set to run by
default) on Windows XP and later systems. Remote Registry must be manually installed on Win9x machines.
See Microsoft's Q141460
for information about obtaining and installing the Remote Registry Service on Win9x.
- LSA RPC
The remote machine must allow you to start/stop Domain Time services. RPC uses default dynamic port ranges, which
vary depending on the version of the OS. See Microsoft's
Service overview and network port requirements for Windows for details on permitting RPC.
Solution
Follow each of these steps and verify that each item is working correctly:
- Use the right version for your processor architecture
As of version 5.1, Domain Time Manager is capable of upgrading both 32-bit and 64-bit versions of Windows from a single installation.
These considerations only apply to version 4.1 and earlier:
Be sure the machine you're using for Manager and/or Update Server has the same processor architecture as your target machines.
32-bit x86 versions of Manager can only fully remote control or install/upgrade/configure other 32-bit x86 systems.
64-bit systems can only remote control/install/upgrade/configure to other 64-bit systems.
If you have a mixture of architecture types, you will need to use a separate machine running
Domain Time II Manager and/or Update Server for each machine type. However, please note that Manager is able to perform some basic functions
such as trigger synchronization on or view the stats from Domain Time components on other architectures.
Domain Time II Audit Server is not affected by this restriction. It will interoperate with Domain Time II components on any architecture type.
- Rule out any firewall issues
Verify that your network access is not being blocked by any firewalls, including personal firewalls. In particular, traffic over UDP port 9909
and TCP ports 137-139, 445, and RPC default dynamic ports must be enabled between the Manager, Update Server, and/or Audit Server machine and the remote systems.
See Firewall and Router Issues for more details.
Manager contains a very useful tool for verifying remote control and firewall access. Find your machine in one of the access lists (Domains & Workgroups, DT2 Nodes, NTP Nodes, PTP Nodes, etc.)
and right-click it. Choose Test Connection from the context menu. Manager will attempt to remotely connect to the target machine and will display the
results (and any error messages) it encounters.
- Enable Network Discovery
Windows operating systems running Vista or later have a network function called Network Discovery,
which controls whether or not machines on the network are visible to each other for making network connections.
Network Discovery is actually a specific combination of services and firewall settings which are enabled or
disabled by settings in the Network and Sharing Center. If present on any system running Domain Time II
components, Network Discovery must be enabled so that the Domain Time II Manager, Update Server service, and/or Audit Server service
can ping the remote systems, connect to their administrative shares, and connect to their registry as necessary.
You must have at least the Network Discovery and File Sharing options enabled in Network and Sharing Center.
See Microsoft's
What is network discovery? page for more info.
- Verify Ping works correctly
Make sure you can ping the remote machine from the Domain Time Manager, Update Server, and/or Audit Server machine. Ask your
network administrator for assistance if you cannot ping the remote machine -- your firewall(s) may be preventing
ICMP traffic. Test by typing
ping machinename
at the command prompt (substituting the machine's DNS name, NetBIOS name, or IP address for machinename).
Log in with the right account
Domain Time II Manager, Client, and Server initially use the credentials of the logged-in user to make remote network connections.
If connection cannot be made using those credentials, you will be prompted to enter correct credentials. Use of logon credentials
is controlled entirely by Windows; any errors are those provided by Windows in attempting the connection.
Update Server and Audit Server run
as background services using the credentials specified in the Services database. Each program
must run under credentials with rights sufficient to make changes through connections to administrative shares and Remote Registry.
For Manager, be sure you are logged on or connecting as a user who has administrative rights on the remote machine. For Update Server and Audit Server,
verify that their service is set to start Automatically and set to Log On using an account with administrative rights to the remote machine(s).
Within a domain, members of the Domain Admins
group have administrative rights by default on all machines that are members of the domain. If the remote machine is
in a different domain, you must have an inter-domain trust in place, or be logged in using a username and password
that matches a username and password on the other domain that does have adminstrative rights.
If the target machine is not a domain member, you must make sure the machine's workgroup name matches the domain/workgroup name of your
Manager and/or Audit Server (Update Server will not work against target machines that are not domain members).
Then, use the local users administration function in Control Panel (or MMC snap-in, depending
on your OS version) to make sure that the account name being used on the machine running Domain Time
II Manager and or Audit Server is listed as being a remote adminstrator for the local machine, either by name or by inclusion in a named
group, such as Domain Admins. Note that Win9x machines must have user-level security enabled for this to work properly.
Enable NetBT
As of version 5.1, discovery uses Active Directory and/or broadcasts/multicasts
to discover machines. NetBT is still useful on workgroup members, but not normally required on domains.
Some machine discovery functions of Manager, Update Server and Audit Server can also use the Windows Network Browse list to discover machines.
This function typically requires that NetBIOS over TCP (NetBT) be enabled. Check the WINS tab of your Network TCP/IP v4 properties to be sure NetBT is enabled.
Also, more recent version of Windows (i.e. Windows 10) may need to have the SMB 1.0/CIFS File Sharing Support feature added for
computer browsing to work.
Be sure you can connect to and read/write through administrative file shares
Domain Time II components must be able to read and write files on remote target machines using Windows Networking. They do this
via UNC paths such as \\machinename\admin$\system32\.
Perform the following test to be sure the account you're using can access administrative shares. This example assumes you have a target
machine named FRED with an IP address of 10.1.1.23. Substitute your own test machine's name and IP address, of course.
- Log in to the machine where Manager, Client, Server, Update Server, and/or Audit Server will run using the administrative account that will be used to
run the program or service.
- Using Notepad, try to open \\FRED\Admin$\win.ini or \\10.1.1.23\Admin$\win.ini,
and, if you can open it, save the file.
- If you cannot open or save the win.ini file, you either do not have sufficient rights, file sharing isn't enabled,
or the special Admin$ share has been deleted. Check with your network administrator to
correct the problem.
Note: If your machine is not a member of a domain (in a workgroup), you need to disable Simple File Sharing. This is usually found
on the list of Folder Options in Explorer (This option may be called Public File Sharing and controlled from the Network Sharing Center on newer versions).
Also, if your workgroup machine
is running Vista or later, network access to your administrative shares (i.e. admin$) is blocked by default.
Create the following registry entry to permit this:
Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Type: (REG_DWORD) LocalAccountTokenFilterPolicy
Data: 1
You may also need to use Group Policy Editor (gpedit.msc) to verify the following policy setting:
Location: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Network access: Sharing and security model for local accounts
Data: Classic - local users authenticate as themselves
See File and Printer Sharing in Windows Vista or
Configure File and Printer Sharing for Microsoft Networks for more info.
Make sure the Registry is accessible remotely on the target machines.
Check the Services database on your remote systems to be sure the Remote Registry service is set to Automatic and is started.
The Remote Registry Service is not installed by default on Win9x machines, and is turned off by default on many newer
operating systems so you will need to explicitly verify that this is operational.
Do the following test to be sure you can access the registry on your remote machines. As above, this example assumes you have a target
machine named FRED:
- Log in to the machine where Manager, Update Server, and/or Audit Server will run using the administrative account that will be used to
run the program or service.
- Start Regedt32.exe and use the Connect Remote Registry function to connect to \\FRED.
If you can connect successfully, try creating and then deleting a test key or value in HKEY_LOCAL_MACHINE on the remote system.
If you are unable to create a test key, check your registry's permissions to be sure there are sufficient rights for your account.
If you cannot connect successfully to the remote registry, then check the policies and/or WinReg permissions. (See Microsoft's
KB314837 or
KB186433 for information on WinReg options.)
Note: If you're testing a connection from an earlier version of Windows to a more recent version, you may not be able to
actually create/delete a registry key due to regedt32 incompatibilities between versions. However, you should at least be
able verify that you can make the connection using RegEdt32, even if you can't open or write any keys.
|
|