DFS Clients keep prompting for logon - should be anonymous access

[Jeff]

I have a standalone Windows Server 2003 R2 SP2. I added the File
Server role and set up a DFS namespace, to be hosted on that server,
which we'll call Windows. So my namespace is:

\\Windows\Shares

I set up a folder pointing to an existing share location. I want
anonymous access...so that anyone can access the shares without
needing a local account on the server. Originally, nothing could
connect to it without asking for a password, but after tweaking the
following Local Security Policies:

Network access: Do not allow anonymous enumeration of SAM accounts
(set to Disabled)
Network access: Do not allow anonymous enumeration of SAM accounts and
shares (set to Disabled)
Network access: Let Everyone permissions apply to anonymous users (set
to Enabled)
Network access: Restrict anonymous access to Named Pipes and Shares
(set to Disabled)

and ensuring that Everyone had share and NTFS read/execute permissions
on the Shares folder (plus a reboot), Windows clients *still* won't
connect to it. I've tried allowing NETWORK, NETWORK SERVICE and
ANONYMOUS LOGON to have permission (both kinds) to the share...no
luck. I've even tried giving Everyone access to C:\DFSRoots...no luck
(after reboots after every configuration change).

I've tried accessing the server through its IP address and FQDN...no
change. Tried mounting with net use...still asks for a password.

Even weirder, every time that I try to log on from a Windows box, on
the client I get the prompt for a username/password, but on the DFS
server, in the Secury log in Event Viewer, I get a Successful Network
Logon entry with the user NT AUTHORITY\ANONYMOUS LOGON, showing the
correct workstation name (matching the client I tried to connect
from). These events, although always successful, generally take one
of two forms. The Logon Type is 3 in both cases, and the Logon ID
matches, but in the case of the Windows client, the User Name and
Domain are both blank; in the case of the Linux client, the User Name
is ANONYMOUS LOGON and the Domain is NT AUTHORITY.

I have tried with a different standalone Windows Server 2003 R2 SP2
box, and a Windows XP SP1, and a Windows XP SP2 box. All prompt for
passwords. So does CIFS and SMB from a Mac.

I have no idea what is going on here. Hellllllllllllllpppppp

[DaveMills]

Everyone Group Does Not Include Anonymous Security Identifier

http://support.microsoft.com/kb/278259

Post by Jeff
I have a standalone Windows Server 2003 R2 SP2. I added the File
Server role and set up a DFS namespace, to be hosted on that server,
\\Windows\Shares
I set up a folder pointing to an existing share location. I want
anonymous access...so that anyone can access the shares without
needing a local account on the server. Originally, nothing could
connect to it without asking for a password, but after tweaking the
Network access: Do not allow anonymous enumeration of SAM accounts
(set to Disabled)
Network access: Do not allow anonymous enumeration of SAM accounts and
shares (set to Disabled)
Network access: Let Everyone permissions apply to anonymous users (set
to Enabled)
Network access: Restrict anonymous access to Named Pipes and Shares
(set to Disabled)
and ensuring that Everyone had share and NTFS read/execute permissions
on the Shares folder (plus a reboot), Windows clients *still* won't
connect to it. I've tried allowing NETWORK, NETWORK SERVICE and
ANONYMOUS LOGON to have permission (both kinds) to the share...no
luck. I've even tried giving Everyone access to C:\DFSRoots...no luck
(after reboots after every configuration change).
I've tried accessing the server through its IP address and FQDN...no
change. Tried mounting with net use...still asks for a password.
Even weirder, every time that I try to log on from a Windows box, on
the client I get the prompt for a username/password, but on the DFS
server, in the Secury log in Event Viewer, I get a Successful Network
Logon entry with the user NT AUTHORITY\ANONYMOUS LOGON, showing the
correct workstation name (matching the client I tried to connect
from). These events, although always successful, generally take one
of two forms. The Logon Type is 3 in both cases, and the Logon ID
matches, but in the case of the Windows client, the User Name and
Domain are both blank; in the case of the Linux client, the User Name
is ANONYMOUS LOGON and the Domain is NT AUTHORITY.
I have tried with a different standalone Windows Server 2003 R2 SP2
box, and a Windows XP SP1, and a Windows XP SP2 box. All prompt for
passwords. So does CIFS and SMB from a Mac.
I have no idea what is going on here. Hellllllllllllllpppppp

[Jeff]

You clearly missed the part of my original post:

"after tweaking the
following Local Security Policies:......Network access: Let Everyone
permissions apply to anonymous users (set
to Enabled)"

So, the anonymous security identifier does include Everyone
permissions.

In addition, you also missed the part where I stated that I have
explicitly given permission for NETWORK SERVICE, NETWORK, and
ANONYMOUS LOGON everywhere that I could find that was related to the
DFS shares, with no luck.

I would definitely appreciate advice on how to fix this.

Thanks,
Jeff

Post by DaveMills
Everyone Group Does Not Include Anonymous Security Identifier
http://support.microsoft.com/kb/278259

Post by Jeff
I have a standalone Windows Server 2003 R2 SP2. I added the File
Server role and set up a DFS namespace, to be hosted on that server,
\\Windows\Shares
I set up a folder pointing to an existing share location. I want
anonymous access...so that anyone can access the shares without
needing a local account on the server. Originally, nothing could
connect to it without asking for a password, but after tweaking the
Network access: Do not allow anonymous enumeration of SAM accounts
(set to Disabled)
Network access: Do not allow anonymous enumeration of SAM accounts and
shares (set to Disabled)
Network access: Let Everyone permissions apply to anonymous users (set
to Enabled)
Network access: Restrict anonymous access to Named Pipes and Shares
(set to Disabled)
and ensuring that Everyone had share and NTFS read/execute permissions
on the Shares folder (plus a reboot), Windows clients *still* won't
connect to it. I've tried allowing NETWORK, NETWORK SERVICE and
ANONYMOUS LOGON to have permission (both kinds) to the share...no
luck. I've even tried giving Everyone access to C:\DFSRoots...no luck
(after reboots after every configuration change).
I've tried accessing the server through its IP address and FQDN...no
change. Tried mounting with net use...still asks for a password.
Even weirder, every time that I try to log on from a Windows box, on
the client I get the prompt for a username/password, but on the DFS
server, in the Secury log in Event Viewer, I get a Successful Network
Logon entry with the user NT AUTHORITY\ANONYMOUS LOGON, showing the
correct workstation name (matching the client I tried to connect
from). These events, although always successful, generally take one
of two forms. The Logon Type is 3 in both cases, and the Logon ID
matches, but in the case of the Windows client, the User Name and
Domain are both blank; in the case of the Linux client, the User Name
is ANONYMOUS LOGON and the Domain is NT AUTHORITY.
I have tried with a different standalone Windows Server 2003 R2 SP2
box, and a Windows XP SP1, and a Windows XP SP2 box. All prompt for
passwords. So does CIFS and SMB from a Mac.
I have no idea what is going on here. Hellllllllllllllpppppp

--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.

[Jeff]

There's also the weirdness that everytime someone tries to connect, I
get a "Successful Network Logon" event in the Security event log.
User shows up as

NT AUTHORITY\ANONYMOUS LOGON

with the following data:

Successful Network Logon:

User Name:

Domain:

Logon ID: (0x0,0xA1E979)

Logon Type: 3

Logon Process: NtLmSsp

Authentication Package: NTLM

Workstation Name: [correct computer name]

Logon GUID: -

Caller User Name: -

Caller Domain: -

Caller Logon ID: -

Caller Process ID: -

Transited Services: -

Source Network Address: [correct ip address]

Source Port: 0

But even though the server shows a successful network logon, the
client computer still prompts for a username and password, and I can
never get through.