XP Pro non-domain computers have trouble authenticating

I’ve seen two cases recently where a user couldn’t authenticate to our servers when they accessed our network from non-domain computer, unless they mapped a drive. They couldn’t do it through unc path shortcuts, although one reported that she did so as recently as two weeks ago.

In other words, most XP computers had no problem with a Start->Search->Search for Computers to bring up \\server.domain.edu They’d get prompted for a login screen, do the DOMAIN\user44 thing, and they’d be in.

But with these two users, they could only do it by mapping a drive to to our domain, and supplying credentials in the “connect as other user” screen.

Watching the logs on the servers the users were attaching to, it looks like the user attempting to attach was authenticated not with the credentials they entered, but with their local user account “nickname”

In this line from the logs, “Chingay” was the nickname of the user account. In XP, the user can have a friendly, real world name with a space, and I guess the nickname was equivalent to the real “username”.

[2004/03/18 10:42:16, 0] smbd/password.c:domain_client_validate(1620)
domain_client_validate: unable to validate password for user Chinggay in
domain KLJAYME to Domain controller pdc.domain.edu. Error was
NT_STATUS_NO_SUCH_USER.

I think what these computers have in common is that they were both XP Pro in fast-user-switching mode. It must have something to do with the “friendly” login names XP creates during the install. What is strange is that our server prompts with an authentication screen, but XP fails to use the credentials entered.

MS Office Files getting set to read-only when edited on a Samba share.

A problem cropped up this morning when some home directories were migrated to a new server. Two users reported problems with Excel and Word files crashing. We narrowed it down to files edited and saved by MS Office 2000. The same files edited in OpenOffice didn’t have the problem. After saving the files, the permission mask got set to -r——–.

It was odd, because the problem was easy to reproduce on this server, but not on the original host of the home directories, which had an identical smb.conf.

Turns out that the new server had an rpm isntalled of Samba 2.2.7 , where our other servers had a locally compiled version of 2.2.8

When running testparm on the two installations, the newer install offered this parameter-

 acl compatibility = 

…set to null, apprently, but it did make a difference. When I installed 2.2.8 on the problem server, it fixed the error.

This recent samba list thread seems to report a similar problem, though the workarounds are done by forcing the mask-

http://lists.samba.org/archive/samba/2004-March/081690.html

We don’t force many permissons on our shares. Here’s the config of the share that had the problem.

[home6]
        comment =  Home Folders
        path = /slot1/p1/nickhome6
        read only = No
        create mask = 0770
        profile acls = Yes