Need access to Windows SBS 2003 from DOS client

We are trying to support an old network that has a number of DOS clients
that are required to access a server for manufacturing data. We would like
to replace the existing server with at least Windows SBS 2003. However, in
testing, we are unable to access the new domain from DOS clients.

The client and server can communicate, but the client gets an "Error 5:
Access has been denied" error on logon. The server's event log shows a logon
request from the client, a successful logon, and an immediate logoff. No
error or other data is given in the log; all three events have a Successful
status. The client has no problem logging on to a Windows 2000 Server
domain.

We have read numerous support articles and tried numerous settings without
changing the result. Many others claim success in getting this to work, but
we cannot. We do understand that lowering the required security settings
exposes the network to some risk, but we have no choice. We have tried
modifying various group policy settings such as secure channel signing, SMB
signing, LDAP signing, SID translation, LM and NTLM responses, SAM password
hashes, etc. We are still unable to find a combination that allows DOS
clients on the domain.

For testing, we are using a freshly installed copy of Windows SBS 2003 SP1
and a freshly installed copy of DOS V6.22 with the Networking Client for
MS-DOS V3.0. The domain controller and client can ping each other by name
and, as mentioned above, the server event log does see the logon attempt and
identifies the client and user by name. The logon event (540) has a success
status, but is immediately followed by a logoff event (538). The client
only sees the error message listed above.

Can anyone help? Thanks!

Hello Tim,

You have to change the Default domain controllers policy and LOWER the security
level to allow DOS authentication with server 2003. The question is, will
you allow this?

Then change following policy:
Default domain controllers policy,Security settings,local policies, Security,
Digitally sign Server communication (always) to DISABLED

Also look here about SMB signing:
http://support.microsoft.com/kb/839499/EN-US/

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> We are trying to support an old network that has a number of DOS
> clients that are required to access a server for manufacturing data.
> We would like to replace the existing server with at least Windows SBS
> 2003. However, in testing, we are unable to access the new domain from
> DOS clients.
>
> The client and server can communicate, but the client gets an "Error
> 5: Access has been denied" error on logon. The server's event log
> shows a logon request from the client, a successful logon, and an
> immediate logoff. No error or other data is given in the log; all
> three events have a Successful status. The client has no problem
> logging on to a Windows 2000 Server domain.
>
> We have read numerous support articles and tried numerous settings
> without changing the result. Many others claim success in getting this
> to work, but we cannot. We do understand that lowering the required
> security settings exposes the network to some risk, but we have no
> choice. We have tried modifying various group policy settings such as
> secure channel signing, SMB signing, LDAP signing, SID translation, LM
> and NTLM responses, SAM password hashes, etc. We are still unable to
> find a combination that allows DOS clients on the domain.
>
> For testing, we are using a freshly installed copy of Windows SBS 2003
> SP1 and a freshly installed copy of DOS V6.22 with the Networking
> Client for MS-DOS V3.0. The domain controller and client can ping
> each other by name and, as mentioned above, the server event log does
> see the logon attempt and identifies the client and user by name. The
> logon event (540) has a success status, but is immediately followed by
> a logoff event (538). The client only sees the error message listed
> above.
>
> Can anyone help? Thanks!
>

Meinolf:

Thank you for your reply. In my original post where I mentioned SMB
signing, I meant to imply that the policy you described was already
disabled. Sorry for not being more clear. So, we already have that policy
disabled, but we still cannot access the server from DOS clients.

Since we are seeing a successful logon in the event log, although followed
by immediate logoff, does this show that we have already gotten past the SMB
signing issue and that our problem stems from something else?

Thanks!
Tim

Hello Tim,

Check also that these are also set:
Microsoft network client always
enabled
if server agrees
enabled
Send unencrypted passwords........
disabled
Microsoft network server always
disabled
if client agrees
enabled
Disconnect clients when
logon ...... enabled
Network security: Do not store LAN Manager HASH value......
disabled
Network security: LAN Manager authentication level
Sent NTLM response only

For existing accounts you have to reset the password for the policy "Network
security: Do not store LAN Manager HASH value......" to recreate the HASH
Value.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> Meinolf:
>
> Thank you for your reply. In my original post where I mentioned SMB
> signing, I meant to imply that the policy you described was already
> disabled. Sorry for not being more clear. So, we already have that
> policy disabled, but we still cannot access the server from DOS
> clients.
>
> Since we are seeing a successful logon in the event log, although
> followed by immediate logoff, does this show that we have already
> gotten past the SMB signing issue and that our problem stems from
> something else?
>
> Thanks!
> Tim

Meinolf:

Thank you for your continued support! We did have most of the policies
defined as you stated in your previous post, including server (always),
client (always), and hash value. However, we had left a few of the other
policies as undefined, so we changed them as you suggested. We had LM
authentication set to LM or NTLM, but changed it to NTLM only at your
suggestion. We had already reset the password when we changed the hash
policy. Finally, we forced the group policy update.

When we first tried these new settings, it again failed as it did earlier.
However, in checking the setiings, we noticed someone on our team must have
changed the Default Domain Controller Policy while other settings were made
in the Default Domain Policy. We changed all settings in the Default Domain
Controller Policy back to their defaults, leaving only the Default Domain
Policy with the changes, and then the DOS clients could log on. I'm not
exactly sure which combination of things made the difference here. Can you
recommend whether these changes more properly belong at the Domain or Domain
Controller level?

Thanks!
Tim

Hello Tim,

Normally it should belong to the Default Domain Controllers policy, because
the DC is used for the authentication.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> Meinolf:
>
> Thank you for your continued support! We did have most of the
> policies defined as you stated in your previous post, including server
> (always), client (always), and hash value. However, we had left a few
> of the other policies as undefined, so we changed them as you
> suggested. We had LM authentication set to LM or NTLM, but changed it
> to NTLM only at your suggestion. We had already reset the password
> when we changed the hash policy. Finally, we forced the group policy
> update.
>
> When we first tried these new settings, it again failed as it did
> earlier. However, in checking the setiings, we noticed someone on our
> team must have changed the Default Domain Controller Policy while
> other settings were made in the Default Domain Policy. We changed all
> settings in the Default Domain Controller Policy back to their
> defaults, leaving only the Default Domain Policy with the changes, and
> then the DOS clients could log on. I'm not exactly sure which
> combination of things made the difference here. Can you recommend
> whether these changes more properly belong at the Domain or Domain
> Controller level?
>
> Thanks!
> Tim

Meinolf:

Thanks, again. Just as a follow-up, I did a post mortem on this issue and
think I found the root cause. We tried all these settings in various
combinations during testing, but were not able to get the DOS clients to
authenticate. In earlier testing, we did not use the gpupdate command to
force the changes immediately. We had other things we were working on, so
we simply waited 15 minutes or more between tests. We even restarted the
server many times for various reasons. The domain controller refresh rate
was 5 minutes and after restarts, surely the policies should be updated.
Not.

When I tested your latest suggested settings, I wanted to check the results
immediately, so I used the gpupdate command. That's when the settings
started working. Several times before using gpupdate, I had reset the
account password to its same value whenever I changed the LM hash value
setting. After using the gpupdate command, I could no longer set the
password to its same value due to the default domain password policy. The
only way that could have happened is if the default domain group policy had
not been applied until I first used the gpupdate command.

I'm not sure what the issue is/was, but I'm sure the policies were not being
applied until I finally used the gpupdate command. This was a fresh install
of Windows Small Business Server 2003 R2 Premium. Does a fresh install not
apply/refresh group policies until after you use the gpupdate command? I
could not locate any discussion about this issue.

Thanks, again!
Tim

Hello Tim,

For DC's the default refresh intervall is 5 minutes. So shouldn't be a problem.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> Meinolf:
>
> Thanks, again. Just as a follow-up, I did a post mortem on this issue
> and think I found the root cause. We tried all these settings in
> various combinations during testing, but were not able to get the DOS
> clients to authenticate. In earlier testing, we did not use the
> gpupdate command to force the changes immediately. We had other
> things we were working on, so we simply waited 15 minutes or more
> between tests. We even restarted the server many times for various
> reasons. The domain controller refresh rate was 5 minutes and after
> restarts, surely the policies should be updated. Not.
>
> When I tested your latest suggested settings, I wanted to check the
> results immediately, so I used the gpupdate command. That's when the
> settings started working. Several times before using gpupdate, I had
> reset the account password to its same value whenever I changed the LM
> hash value setting. After using the gpupdate command, I could no
> longer set the password to its same value due to the default domain
> password policy. The only way that could have happened is if the
> default domain group policy had not been applied until I first used
> the gpupdate command.
>
> I'm not sure what the issue is/was, but I'm sure the policies were not
> being applied until I finally used the gpupdate command. This was a
> fresh install of Windows Small Business Server 2003 R2 Premium. Does
> a fresh install not apply/refresh group policies until after you use
> the gpupdate command? I could not locate any discussion about this
> issue.
>
> Thanks, again!
> Tim

Meinolf:

Yes, the documentation states the default refresh rate is 5 minutes.
However, the default domain password policy was not enforced during the
three weeks after SBS was installed. That policy only became effective
after I ran the manual group policy update. So, for some reason, group
policy was not being refreshed as expected, including at logon and restart.
Since using the gpupdate command, group policy is now happily freshing on
its own. The refresh rate setting was not modified at any time. Weird.
We'll test this behavior again next time we install SBS 2003 R2. Thanks for
all your help!

Tim

Hello Tim,

Nice to hear that it is working now. You're welcome.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> Meinolf:
>
> Yes, the documentation states the default refresh rate is 5 minutes.
> However, the default domain password policy was not enforced during
> the three weeks after SBS was installed. That policy only became
> effective after I ran the manual group policy update. So, for some
> reason, group policy was not being refreshed as expected, including at
> logon and restart. Since using the gpupdate command, group policy is
> now happily freshing on its own. The refresh rate setting was not
> modified at any time. Weird. We'll test this behavior again next time
> we install SBS 2003 R2. Thanks for all your help!
>
> Tim
>