Guide: Troubleshoot XP File and Printer Sharing Access Errors
Part 3 of 3
Windows File and Printer Sharing (FPS) must be configured for a “mix-and-match” set of machines/components/options. This guide troubleshoots FPS in 3 parts
- Part 1 is on network visibiltiy problems which prevent workstations from seeing one another
- Part 2 explains Computer Browser Service and how it can add to visibily problems
- Part 3, this document, focuses on the computer access errors which may occur
NOTE: Visibility problems should be fixed before tackling access errors. Shared network workstations should be listing other shared workstations in My Network Places.
Windows FPS access may “simply work” but, if not, there can be many variables / options involved. This is my best shot at pulling (what I know of) them together but “your results may vary”
The system instructions herein are specific to XP Pro and XP Home running SP2 or SP3. You can still apply this guide as general “things to look for” on other versions. Just not apply specific instructions
1 XP File Sharing Methods
- Simple File Sharing (SFS) has the simpler user interface. A shared resource in Simple File Sharing is equally available to all network users. It doesn’t require passwords nor allow you to differentiate access by user
- Classic File Sharing (CFS) is traditional Windows file sharing. It provides greater security and control. Resource access restrictions can be defined at a more granular level.
XP Pro allows choice of either. XP Home only supports SFS
2 Terms
- Client / Server – Server is the workstation offering a shared resource. Client is the workstation accessing the resource
- Policies – rules stored on the workstation which define the behavior and allowed actions for the computer and its users
- Share – a share refers to a shared resource
- Share permission – Only applied when accessed from a network. Applied to the entire share
- NTFS Permission –
- Applies to any request for a resource on an NTFS formatted disk
- More complicated and granular then share permissions. Can control access to files, folders, and disk
3 Simplified view of XP authentication
Authentication validates user credentials. CFS always does Local Authentication. On failure, it may also do Guest Authentication. SFS only does Guest Authentication
3a Guest authentication
Requests validated against server Guest account. Guest permissions are applied to all requests. Administrators can’t be differentiated and get same permissions as others. See MS doc on Guest accountGuest fails if
=> Not allowed server access: Account disabled, guest network login or anonymous users restricted, passwords mismatch
=> Account doesn’t have permissions to access the shareSimplified logic
IF guest account active AND allowed remote login/access THEN
….IF request password EQUAL account password: Success
ELSE: Fail3b. Local Authentication
Requests validated against server’s account data. Result affected if policy set to “Deny net login for users without an account password”
=> Permissions of the authenticated server account are mapped to client requests
=> Permissions can be differentiated by user id, user group membership, etc.Local authentication/access fail if
=> Not allowed server access: User account doesn’t exist or denied network login, passwords mismatch or user’s server password violates policy
=> Account doesn’t have permission to access the resourceSimplified logic
IF request userid NOT in server’s account database: GO guest authentication
IF request userid EQUAL Guest: GO guest authentication
IF request password EQUAL account password THEN
…IF account password is blank BUT policy denies blank passwords THEN
……GO guest authentication
…….ELSE: Success
ELSE: Fail
4 Checklist
Check Policy Settings
- ntrights tool assigns user rights. Works on all versions XP and Vista. Download Win2003 Resource Kit. Commands are case sensitive. See attachment ntrights.txt for commands you can use to copy/paste
- Or to edit registry: Start->Run, enter: regedit
- Policy Editors are available on XP Pro and some Vista versionsUser Rights
Access this computer from the network
=> Grant rights to: Guest and Everyone
=> Use ntrights +r
Deny access to this computer from the network
=> Revoke denials of: Guest and Everyone
=> Use ntrights –rSecurity (note: RestrictAnon or Null may affect other programs)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\limitblankpassworduse
Accounts: Limit local account use of blank passwords
= 0 (Disable): guest and non-guest can login without server account passwords
= 1 (Enable): Only guest can login without server account passwordRestrictAnonymous
Network access: Do not allow anonymous enumeration of SAM accounts and shares
= 0 (Disable): Guest or non-guest can access server
= 1 (Enable): Only non-guest accessHKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
RestrictNullSessAccess
= 0 (Disable): Guest or non-guest can access server
= 1 (Enable): Only non-guest accessAccounts activated, passwords match, net logon enabled
On client and server:
- Verify userids match
- Enter: net user xxxx /active:yes where xxxx is userid
- Set identical passwords: Enter control userpasswords2. Select user, click Reset Password. Enter identical passwords. Hit enter for no password
5 Suggestions / fyi’s
Start testing with NO Guest password. ALLOW account logon with blank password
Explorer prompts you to logon when
- Your logon id not on server or
- Your logon password not equal server password
Explorer displays error message when userid/password is correct but doesn’t have logon rights or access permissionWindows may reuse an earlier client session to a share (and the connection’s logon) if its status is Open or Disconnected (dormant)
If this occurs when you’re trying a new test, the test result may seem to make no sense or confuse!
> On client, net use * /d /y deletes all connections
> On server, net session /d /y
With no args they display current usage.=> Reusing Explorer window after its connection is deleted will result in access errors for a share that was working. Open new Explorer window
Understand security issues of SFS and CFC using Guest AuthenticationSee here
6. Troubleshooting
Trace logon events using Windows Event Log. On XP Pro, set policy to audit Account Logon and Logon/Logoff events for Success,Fail. Then reboot. XP Home set by default
Event category Account Logon logs logon attempt, userid and success/fail
If you see userid joe fail then Guest succeed: the client sent userid joe but it failed. Server uses local authentication so it next tries Guest logon which worksEvent category Logon/Logoff logs reason for success/fail
See if logon fails due to bad userid/password or was denied (implies policy issue). I found Windows may log fail reason for its last validation. In such case, use ntrights to revoke Guest network access then reboot to disable Guest validations. See attachment ntrights.txtFind your session id. Verify it authenticated as expected
Use Shared Folder console for status of shares and sessions Start->Run, enter: fsmgmt.msc. In Sessions:
- Userid: userid in client request
- Guest: Y if Userid authenticated as Guest
If Guest=Y then Guest is the session id otherwise it’s the client Userid displayed.
Rt click to close sessionsCheck your session userid’s permission to resources
Effective Permissions Tool displays user or group access permission for a selected file or folder
- In Explorer, select file or folder. Open Properties
- On Security tab click Advanced then Effective Permissions
- Click Select->Advanced->Find Now. Select your session userid, hit OK and OK again to see its permissions to the resource. See also hereAccesschk lists accounts with access to a file/folder (e.g. accesschk “C:\Program Files”) or lists an account’s permissions for each object in a file/folder (e.g. accesschk joe “C:\Program Files”) Download to Windows\system32. Use “” around the path







