Windows authentication problems

If users can't log into their home directory - Windows 98 / ME

Symptom: Windows 98 or Windows ME users are unable to access files in their home directory (access is denied).

Solution:

  1. Make sure they log onto their Windows machine using the same login name as they use for their Unix account. The password need not be the same. Unfortunately, there is no easy way to specify a username when connecting to another computer in Windows 98, so if you have a shared computer (e.g., attached to a common-use scanner) the users will have to create shared folders on their personal computers in order to store their files. This may seem awkward to Unix users, but it does have a certain weird Redmondian logic, because it avoids the security risks of typing your password on a shared computer (although it adds other risks). Windows 2000 does allow users to specify a different username, but this feature seems not to always work.
  2. Check to make sure 
       writeable = yes
   browseable = yes
   guest ok = no
   public = no
   read only = no
    is present in the "[homes]" section in /etc/smb.conf. If "guest ok" access is permitted, Windows will preferentially connect as the user specified in the global "guest account" option (typically 'ftp'). This causes users to be blocked from accessing their home directories (unless, of course, your permissions are set incorrectly).

Samba authentication problems - Windows 2000

Symptom: Samba reports messages like the following when Windows 2000 users try to connect, even though smb.comf is correct: 
  smbd/password.c:pass_check_smb(575)
  pass_check_smb failed - invalid password for user [tjn]
  smbd/password.c:pass_check_smb(575)
  smbd/service.c:make_connection(331)
  Invalid username/password for tjn [tjn]

Windows users see a message such as "\\Servername\homes is not accessible. Access is denied." or "The share name was not found. Make sure you typed it correctly".

Solution: the actual problem may have nothing to do with passwords or with the network path. Under some circumstances, samba does not allow users to connect unless everyone has read permission in the user's directory, even if samba is running as root. Changing the permissions to drwxr-xr-x (755) instead of the usual 711 solves the problem. Of course, this is undesirable. On other computers, permissions of 711 or 700 work fine. Samba must have execute permission in every step of the path leading to the directory. If you have a /home/samba directory, it must be 711. I haven't yet discovered why different permissions are needed on different servers.

Another possible cause is the line "security = user" in smb.conf. Occasionally, Samba gets out of whack for no discernable reason and suddenly prevents anyone from connecting. This does not happen if the line is changed to "security = share".

Connecting to a second account on the server:
Another problem that frequently crops up is that users who have two accounts on the same server can only access one of them. For example, User A gets the password from User B in order to copy some of User B's files, but finds that it is only possible to login as User A.

This is a Windows problem. Once the user has successfully authenticated, the password is sent automatically and the username/password window doesn't reappear again. To login to a second account with a different username, delete the connection by typing one of the following in a DOS box: 
  net use \\machine\some_share_name /d
  net use * /delete
  net use \\machineA\another_share /user:user2
If this doesn't work, click on "Tools .. Map Network drive" in Explorer, select the desired directory, and click on "Connect as a different user".

The "net use * /delete" command also frequently fixes the "Access denied" problems that occur when Windows becomes befuddled about your "network password". Rebooting the Windows machine or (at least in Windows XP) logging off from the Windows machine has the same effect.

See also Printing from Windows 2000 through Samba.

Windows XP users unable to login

Symptom: When Windows XP users try to connect, they receive a grayed-out login dialog box with the username set to "Guest". It is impossible to change the username, and no password works. Only files owned by the guest account are accessible.

Solution: There are three things that may cause this.

  1. User logged in more than once If the user has already logged onto the Samba server from one computer, all attempts to login as the same user from any other computer are automatically changed to "Guest". Users are therefore prevented from accessing their home directories from more than one computer at a time.

    In some cases, changing the name of your user profile to something else has been known to work. XP then thinks you are someone else, and provides a dialog that allows the user to enter both the username and the password.
  2. Simple File Sharing turned on in XP machine According to Microsoft, with Simple File Sharing in force, all incoming connections authenticate as Guest, regardless of whether they have a valid user account or not. There are no passwords or access restrictions. Simple File Sharing is the only type of sharing available in Windows XP Home Edition. Open Windows Explorer and go to Tools->Folder Options->View and uncheck ``Use Simple File Sharing''. Turning the guest account off in the control panel does not disable it.
  3. No guest account on XP machine If Simple File Sharing ( and hence ForceGuest ) is in force, but the Guest account has been disabled, then users will not be able to connect. Connections from an XP box will get prompted to supply credentials: 
    A Password is required:
Username: XP-Box\Guest ( Greyed out);
Password:
    No password will work, because Guest is disabled.

Symptom: Another problem that sometimes occurs in XP is when a user tries to use two different resources on the server, such as a shared printer and their home directory. Sometimes the connection works, but it is intermittent. Other times, the username is automatically set to "guest" and access to their home directory is denied. Users get some or all of the following error messages: 
Could not reconnect all network drives
Disconnected Drive
\\server\homes is not accessible. You might not have
permission to use this network resource. Contact the 
administrator of this server to find out if you have
access permissions. Access is denied

Solution: Needless to say, the problem has nothing to do with permissions. It is merely Windows goofing up the passwords again. The solution is to change to from "security=share" to "security=user". In Samba, change /etc/samba/smb.conf as follows: 
   security = user
;    announce as = NTServer (this is commented out)
   domain logons = yes
   mangle case = yes
   revalidate = yes

The last two options are said to help for Windows XP users, but I have never noticed any difference from these two options. While changing security to "user" allows XP users to connect effortlessly, it messes things up for Windows NT and 2000. W2K will now insist that the user supply a password, while NT will be unable to print. The solution is to add a dummy password/username combination such as staff/staff in Samba, using the commands 
useradd staff
smbpasswd -a staff

This will allow W2K to satisfy its craving for a password, while the other Samba access controls prevent unauthorized access. Although the new user "staff" has to be present in /etc/passwd, the password should only be set in Samba, not on the system. You must leave the "staff" account locked (i.e., don't type 'passwd staff', and make sure their shell is set to /bin/false). But you already knew that.

Back