Hello everyone. I am trying to join a Windows 2003 Enterprise server to a domain wherein the domain controller is running 2000 Advanced Server. Whenever I attempt to join, I specify the Admin name/password and promptly get an error message stating "The account is not authorized to log in from this station."

I've checked both servers and enabled "Send Unencrypted Password to Connect to third Party SMB Servers" and disabled the settings "digitally sign communications" (just to be sure I also disabled them in Domain Security Policy on the DC, in case they were propagating down to Local). Still nothing, I still get that error message.

I've done some Googling on the error, but most of the issues seem to be related to wanting to make the 2003 server the new domain controller; I'm not trying to do that (yet), I'm just trying to get it to join the domain so I can maintain it easier. Our LAN can see the server and access it (sometimes it denies access to files though), but it's part of "WORKGROUP" and not our domain.

Any help on this issue would be much appreciated, I'm out of ideas! :)

create another admin account, try to use it to join new server to domain

Thanks for the help. I tried to join using my domain user name (which has admin rights as I am the MIS Director) and got the same error.

2003 Enterprise can only join 2000 domains as a member server; if you want it to become an AD DC at any point then you MUST run the 2003 versions of both \forestprep and \domainprep on the primary 2000 DC before you join the domain.

In addition, Enterprise is very picky about its roles within a domain and is less than keen on sharing unless it's the dominant partner; in my experience the best way to add it to an extant domain is to do so immediately after the principal installation has been completed and before you start adding any of the Enterpise functionality - that includes DNS/DHCP/WINS etc. You want the system in as near barebones state as possible.

Principle diagnostics: examine ADU&C MMC on the 2000 DC and determine if the old domain has 'recognised' the new server as an AD member: if it has and your Enterprise join is still failing then

a] delete the member server on the 2000 DC and
b] examine the logs on both servers for relevant errors.

Its just authentication between domain controllers, try this to fix it, though a bit long winded. Please remember to back up the keys you change and make a note of the settings you change.

1. On the domain controller, click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
3. In the right pane, double-click enablesecuritysignature, type 1 in the Value data box, and then click OK.
4. Double-click requiresecuritysignature, type 1 in the Value data box, and then click OK.
5. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
6. In the right pane, double-click enablesecuritysignature, type 1 in the Value data box, and then click OK.
7. Double-click requiresecuritysignature, type 0 in the Value data box, and then click OK.
8. After you change these registry values, restart the Server and Workstation services. Do not restart the domain controller, because this action may cause Group Policy to change the registry values back to the earlier values.
9. Open the domain controller’s Sysvol share. To do this, click Start, click Run, type \\Server_Name\Sysvol, and then press ENTER. If the Sysvol share does not open, repeat steps 1 through 8.
10. Repeat steps 1 through 9 on each affected domain controller to make sure that each domain controller can access its own Sysvol share.
11. After you connect to the Sysvol share on each domain controller, open the Domain Controller Security Policy snap-in, and then configure the SMB signing policy settings. To do this, follow these steps:
a. Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.
b. In the left pane, expand Local Policies, and then click Security Options.
c. In the right pane, double-click Microsoft network server: Digitally sign communications (always).

Note: In Windows 2000 Server, the equivalent policy setting is Digitally sign server communication (always).

Important: If you have client computers on the network that do not support SMB signing, you must not enable the Microsoft network server: Digitally sign communications (always) policy setting. If you enable this setting, you require SMB signing for all client communication, and client computers that do not support SMB signing will not be able to connect to other computers. For example, clients that are running Apple Macintosh OS X or Microsoft Windows 95 do not support SMB signing. If your network includes clients that do not support SMB signing, set this policy to disabled.

d. Click to select the Define this policy setting check box, click Enabled, and then click OK.
e. Double-click Microsoft network server: Digitally sign communications (if client agrees).

Note: For Windows 2000 Server, the equivalent policy setting is Digitally sign server communication (when possible).

f. Click to select the Define this policy setting check box, and then click Enabled.
g. Click OK.
h. Double-click Microsoft network client: Digitally sign communications (always).
i. Click to clear the Define this policy setting check box, and then click OK.
j. Double-click Microsoft network client: Digitally sign communications (if server agrees).
k. Click to clear the Define this policy setting check box, and then click OK.
12. Run the Group Policy Update utility (Gpupdate.exe) with the force switch. To do this, follow these steps:
a. Click Start, click Run, type cmd, and then click OK.
b. At the command prompt, type gpupdate /force, and then press ENTER.

Policy Update utility

Note: The Group Policy Update utility does not exist in Windows 2000 Server. In Windows 2000, the equivalent command is secedit /refreshpolicy machine_policy /enforce.

13. After you run the Group Policy Update utility, check the application event log to make sure that the Group Policy settings were updated successfully. After a successful Group Policy update, the domain controller logs Event ID 1704. This event appears in the Application Log in Event Viewer. The source of the event is SceCli.
14. Check the registry values that you changed in steps 1 through 7 to make sure that the registry values have not changed.

Note: This step makes sure that a conflicting policy setting is not applied at another group or organizational unit (OU) level. For example, if the Microsoft network client: Digitally sign communications (if server agrees) policy is configured as "Not Defined" in Domain Controller Security Policy, but this same policy is configured as disabled in Domain Security Policy, SMB signing will be disabled for the Workstation service.
15. If the registry values have changed after you run the Group Policy Update utility, open the Resultant Set of Policy (RSoP) snap-in in Windows Server 2003. To start the RSoP snap-in, click Start, click Run, type rsop.msc in the Open box, and then click OK.

In the RSoP snap-in, the SMB signing settings are located in the following path:

Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options

Note: If you are running Windows 2000 Server, install the Group Policy Update utility from the Windows 2000 Resource Kit, and then type the following at the commmand prompt:

gpresult /scope computer /v

After you run this command, the Applied Group Policy Objects list appears. This list shows all Group Policy objects that are applied to the computer account. Check the SMB signing policy settings for all these Group Policy objects.

Hope this helps.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.