Windows authentication problems

Windows authentication problems /
Windows users unable to log in

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:

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.
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.

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.

Explanation: There are two security modes in Windows. Samba calls them "share" mode and "user" mode. This is what I discovered about the process by experimentation.

Share mode This was the default mode in earlier versions of Windows. In Share mode, Windows sends your Windows Account Name (that is, the name you're logged in as), along with the password that Windows associates with the network share. If the password or username is rejected, Windows tries logging in as "guest" with no password. The Windows Account Name must be the same as the username on the server. If it's not, the user must click on User Accounts in the Control Panel and change the name of their Windows account so they match.

User mode In User mode, Windows sends a username and password to the server. The server matches this information with its passwd and smbpasswd files and grants access to everything the user is entitled to. Windows has used this model since about 2000. Unix has used it since about 1969. The Windows implementation causes endless problems because Windows hides what is going on.

Suppose you have two accounts, named "chuck" and "dave" on the server.

In Samba, the username and password for Chuck and Dave must be in the smbpasswd file (smbpasswd -a chuck).
The usernames and password in smbpasswd must match the ones in the server's passwd file.
The Windows password (used for logging in to the Windows machine) is totally separate, and does not have to match anything.
To access Chuck's home directory, type \\servername\chuck in the Address Bar in Windows Explorer, or click on "Add a Network Place" and browse for it.
If the server (Samba) is using User Mode Security, it is not necessary for the Account Name to match the username on the server.
If the server is in User mode: Once you're logged in under chuck, if you decide to log in under dave, you must first reboot the Windows machine. After rebooting, Windows continues to send Chuck's password the first four times you click on the /homes/dave icon. Each time, it displays a message saying "You might not have permission to use this network resource." After the fourth time, Windows then pops up a password dialog box, which allows you to finally enter the password for Dave.

I don't know whether it takes four times in all versions of Windows, or whether four is a parameter that is configurable somewhere.
If the server is in Share mode: In Share mode, once a Wrong Password error is received, Windows reverts to attempting to log in as Guest. Even if you somehow manage to get a password prompt, the username will be grayed out if Windows thinks it has a good password. As far as I can tell, there is no easy way to convince it otherwise.
Once a correct username/password combination is accepted, Windows continues to send it automatically without asking for authentication.
The behavior after a reboot depends on whether "Do not store credentials" is enabled in Local Security Policy in Windows. Windows always sends the Windows Account name when it boots up, or when it first tries to connect. If "Do not store credentials" is disabled (the default), Windows also remembers and sends the password. If "Do not store credentials" is enabled, Windows sends something else (possibly a blank password, I'm not sure what) and invariably gets a Wrong_Password error. After four failures, Windows opens a password dialog box. Windows then sends the new username and password and forgets the old one.

Solution: There are some other things that may cause this problem.

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.
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.
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.

If that doesn't work, try the following:

net use * /delete
Disable guest access on the Samba server
Re-enter the user's samba password using smbpasswd or smbpasswd -a

If it still doesn't work, check the logs. If they use an incorrect password or an incorrect username, Windows automatically tries logging them on as guest.

Windows users can't access home directory

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.

Windows not asking for a password

Frequently, a user will be unable to access their home directory because Windows doesn't display a password dialog box. This happens because Windows thinks it already knows the password. It happens when a user has two different accounts on the same computer--for example, a shared directory with a shared username guest access, and their home directory with their regular password. Or they may have to log into two different accounts--for example, a secretary who needs to log into the boss's account. Windows cannot imagine that a user might have two different accounts on the same server. The general strategy is to work around Windows's password caching "feature".

Symptom: Can't access home directory. Windows not asking for password.

Solution 1: Disable storage of network passwords In XP go to Control Panel Administrative Tools, double click on Local Security Policy MMC Snap-in Shortcut.

In Local Security Policy Management Console, open Local Policies Security Options on the left.

The policy list is on the right. Browse to the policy "Network access | Do not allow storage of credentials or .NET passports for network authentication" and double click it, select Enabled, click Apply and then OK. Reboot your computer.

After this, passwords will only be remembered until you logoff or reboot.

Solution 2: Delete your cached current password

In Control Panel | User Accounts, highlight your name from the list and click the Advanced tab. Click Manage Passwords. There should be a list of network shares that Windows has the password for. Click on the one that you can't log in to, and click Remove. The next time you browse to this computer, it should ask for your password. Later, if you want to browse to a shared directory or access a different account, you will have to go through this step again.

Solution 3: Set a new password from a cmd box

Start - Run - type 'cmd' (without quotes) to open a cmd box. A black box will appear titled "Command Prompt". Type the following:
net user myusername *
Then type your password to assign a new password to this account. Type it again to confirm.