Samba

[Mark Parsons]

Hi All,

I have two HP-UX servers - one called Prod11 running HP11.11 with Samba 3.0.7 and the other called Zarwin running HP11.00 with Samba 2.0.6. My username is a16609.

On Prod11 when connecting it comes back as "Prod11\a16609" and I can successfully get onto the share. However when connecting on Zarwin it comes back as "UK\a16609" and the connection fails unless I physically delete the "UK" bit and replace with "Zarwin".

How can I get the "Zarwin" bit to appear automatically just like the "Prod11" one does.

The smb.conf files on both Prod11 and Zarwin are the same (as much as they can be between the two releases).

Kind Regards - Mark Parsons.

[Rita C Workman]

Here's a couple thoughts that may help...

1. It is possible that your smb.conf you are reading is NOT what is running. The file could have been edited, but if SAMBA was not stopped and restared on Zarwin it would be running the old info.
>>>Get a time when you can run stopsmb; confirm all is clear; then restart it with startsmb. This will prove what SAMBA is actually running.

2. I'd ask myself, where is it getting UK? What in your environment is named "UK"? If you have something named that, then it's a resolution issue. Check hostfile, check DNS, do reverse lookups to track down what the connection is getting resolved to.

Hope this helps, until others pipe in as well.
Rgrds,
Rita

[Steven E. Protter]

Shalom,

You can hard code the authentication information to the HP-UX 11.00 server.

You may want to think about replacing HP-UX 11.00 with 11.11 so you can run the same version of Samba on both.

SEP

[Mark Parsons]

Hi,

Thanks for that. Unfortunately we cannot upgrade our HP-UX11.00 machine due to an application and oracle version currently on it. Can we use Samba 3.0.7 on HP-UX11.00 though? It all seems to work nicely on that version.

How do you hardcode the authentication information?

Cheers - Mark P.

[Matti_Kurkela]

I'm getting the feeling something is missing here. You've identified two servers you are connecting *to*, but what is the client you are using to connect?

If it is a Windows workstation, it may remember the connection to Prod11 as a _client-side_ feature.

But a persistent connection (the "Remember this connection..." checkbox in the connect dialog) would connect automatically, without asking username & password at all.

Hmm... Do you have any other connections to Prod11, but not tho Zarwin? I seem to recall that a client must use the same identity in all simultaneous connections to the same server, and thus any previous connections will force the username on the later ones.

Or maybe you have your Samba configured to use plaintext passwords? In this case, you are following old advice that was already obsolete back in 2001 - but somehow seems to keep popping up in Samba circles.

The problem with plaintext passwords is, with WinNT4 SP3 and Win95 OSR1, Windows stopped accepting plain-text passwords by default. The ability to use plain-text passwords can still be enabled with a registry setting - but further Windows security updates have since removed the facility to *cache* passwords in their plain-text form.

This would make a persistent connection using plaintext passwords an odd beast: it remembers the target server, share and username, but not the password. Maybe this is what is happening here?

From the Samba-3 HOWTO document:
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/ServerType.html#id2560564
---------
MS Windows 95 pre-service pack 1 and MS Windows NT versions 3.x and version 4.0 pre-service pack 3 will use either mode of password authentication. All versions of MS Windows that follow these versions no longer support plain-text passwords by default.

MS Windows clients have a habit of dropping network mappings that have been idle for 10 minutes or longer. When the user attempts to use the mapped drive connection that has been dropped, the client re-establishes the connection using a cached copy of the password.

When Microsoft changed the default password mode, support was dropped for caching of the plaintext password. This means that when the registry parameter is changed to re-enable use of plaintext passwords, it appears to work, but when a dropped service connection mapping attempts to revalidate, this will fail if the remote authentication server does not support encrypted passwords. It is definitely not a good idea to re-enable plaintext password support in such clients.
-----------

MK