SAMBA issue reading smb.conf file on CIFS Server 02.04.04

[John Jimenez]

I am having issues with some Window XP clients logging into CIFS (Samba) shares.   These users should be using  /var/opt/samba/private/smbpasswd file to authenticate.   I set them up through swat years ago.     

Several months ago I put a new windows 2008 server client and had to  upgrade HP-UX 11.11 server to A02.04.04.    But after upgrade these windows XP clients continued to work.     Since I istarted using SAMBA 3 years ago I have always had some users who would have issues the map dirves not connecting right after their domain passwords expired and they had to change.  In the past it was no big deal, I would just log them off and re-map their PC's back to the SAMBA shares.      But now I have having issue connecting them back the UNIX share.  It looks like it wants to use the windows domain  to authenticate instead of /var/opt/samba/private/smbpasswd.     

Can anyone give me some insite on how to get thse clients authenticated using smbpasswd?

thanks again,

[John Jimenez]

F.Y.I. When I upgraded to 02.04.04, I also installd LDAP-UX Integration B.04.20, on this HPUX 11.11 server

[John Jimenez]

hmmm.   I have a test server that is configured exactly the same way and production server.   Windows XP PC connect to the test server CIFS okay, but when I connect to production CIFS, it shows our domain.    I still cannot figure out why the PC is trying to access the AD.     I remove the domain out of "User name" field, but it just comes back.    It should just show "user name"  not "domain\username".       I am worried that little by little all samba clients will acquire this issue and not be able to log in. 

[Matti_Kurkela]

So... your PC clients are domain members, and the SAMBA/CIFS server is configured as a standalone server, as opposed to a domain member, right?

In the SMB/CIFS protocol, I understand the domain part must always be specified: it is not possible to specify a username without a domain part. The authentication credential always consists of the domain+username+password triplet. If the system is not a member of a domain, then the domain part should be equal of the hostname of the system the credential is associated with.

However, Microsoft clients "helpfully" hide the domain part in some situations, to make it "easier" for the users...and because in some situations there can be many possible domain parts, I think some versions of Windows may attempt to be even more helpful by trying to guess the domain part. If a domain account is not found, a Windows system might assume the user meant a local user account of the client system instead.

But sometimes this strategy fails, and you will have to be explicit in order to make the system work as you want.

When a client is a member of a domain, it will assume all unqualified usernames refer to domain user accounts. If you want to specify a non-domain user account, you must specify the hostname of the system that contains the account as the domain part. If you want to remotely change the password of the local Administrator account of a Windows server, you will need to specify it as windowsserver\Administrator: if you specify just "Administrator", you may end up changing the administrator account of your local Windows workstation instead.

The same applies to logging in to standalone servers: if the client is a domain member, you should be connecting explicitly as StandaloneServerName\username, otherwise the client will take the unqualified username and attempt to login as domainname\username, which is not what you want.

If the user has previously successfully connected to the standalone server, some versions of Windows may use their credential cache to produce further guesses if the domainname\username version fails, so using the unqualified username may work in some situations... but the users should be aware that the explicit form is the only one that is guaranteed to work in all situations.

Disclaimer: I am not a Windows administrator, so the following may be seriously outdated or misunderstood:

I think the user-specific credential cache is stored locally, but protected using the user's login password. If the user's password is changed by the domain administrator (or in any other way so that the user's local workstation is not involved in the password change procedure), the credential cache may become invalid, requiring the user to re-specify the login credentials to all network connections that are not using the user's default domain credentials. That would mean re-specifying the domain+username+password triplets for all connections to standalone servers.

[John Jimenez]

I Matti,

    It sounds like you are 100% correct      Last night I got one of the two issues resolved.    Instead of mapping, from "My Computer" I tried to connect \\hostname (unix server), but again it changed to domaind\hostname.   I then tried \\ip-address and it worked.     The login did not change to the domain, and it let me use the password.         So I logged off and back on and mapped to IP address. (which by the way I am sure I tried before and it failed).   But this it worked.   I am going to work on the other client this morning.