CIFS HPUX B11.00 and file sharing with a windows 2003 server

[Jay Bietz]

Hi:
I have an HPL1000 with HPUX B.11.00 and CIFS Client A.01.09.03, CIFS server and Development A.01.11.05 installed.

I can successfully share folders/directories on the HP with Windows 2000 and XP clients with Active Domain.

I have been unable to successfully follow the directions to mount a shared hidden folder on my Windows 2003 server (sp1 domain controller with all current patches) on the HP server.

When I read the documentation and config files for CIFS -- I don't see any reference to Windows 2003 -- only Windows 2000 and lower.

Is my goal of mounting on the HP the shared folder on a Windows 2003 server even possible?

[Thomas Elsäßer]

Hello Jay,

i think the problem is the auth protocol in win2003, this is kerberos and this isnt
supported in CIFS.

Regards

Thomas

[Jay Bietz]

Hi Thomas:
As I understand your reply, the version of CIFS for HPUX 11.00 is NOT kerberos ready and therefor will fail.

Thanks for the reply.

Jay

[Eric Raeburn]

Hello, Jay,

This is Eric in HP's CIFS Client software lab. The version of the CIFS Client you are using DOES support Kerberos. It is supported in all versions A.01.09 and beyond. But that is not the issue: in the CIFS protocol, no server insists on use of Kerberos; the client decides whether to use Kerberos if the server supports it.

So now to solve your issue...

How are you attempting to access the Windows share from the HPUX system? The typical sequence is (1) root mounts the share, using either "cifsmount" or "mount -F cifs ...", and then(2) non-root users authenticate themselves to the server in order to access the mounted share; this is done with the "cifslogin" command.

Detailed procedures are given in chapters 2, 3, and 4 of the CIFS Client Administrator's Guide, here: http://www.docs.hp.com/en/B8724-90044/B8724-90044.pdf

Note also that the fact of your share being hidden should not be a problem. I just tried that with the A.01.09.03 CIFS Client and was able to mount and access the share.

Please post your results so we can resolve this for you.

Good luck,
-Eric

[Steven E. Protter]

Shalom,

To succesfully mount Windows 2003 shares two things are needed and one would help:

1) Kerebos 5 client or downgrade Windows 2003 with a patch to permit Kerveros v4 authentication.
2) A user on the windows machine that is permitted to access the share. I normally add a root account to the Windows box with admin privs unless someone pitches a fit.

helpful:
1) A more modern version of CIFS/9000 You options are limited on 11.00 but it would be helpful to have something based on Samba 3.0

SEP

[Eric Raeburn]

Steven,

Regarding your suggestions:

> Kerebos 5 client or downgrade Windows 2003
> with a patch to permit Kerveros v4
> authentication.

Kerberos is not necesarily an issue here, so syncing up the versions is not required. Any CIFS client can do authentication against any Windows server without using Kerberos (otherwise, backwards compatability with older clients, like NT, would be impossible). In fact, the default configuration for authentication in the HP CIFS Client is NTLM, not Kerberos. That works fine with all Windows 200x servers. Kerberos is just a configurable option.

> A more modern version of CIFS/9000 You
> options are limited on 11.00 but it would
> be helpful to have something based on Samba
> 3.0

First, this is not Samba (on which the HP CIFS Server is based); it is the the HP CIFS Client, a completely different product. And second, yes, a later version of the software would be nice (A.02.xx versions support NTLMv2, for example), but unfortunately, Jay's system is HP-UX 11.0, for which the end of support is approaching; A.01.09.03 version of the CIFS Client is the most current and last version to be supported on that HP-UX version.

Regards,
Eric

[Jay Bietz]

Thanks for the reply:

Yes I expect to retire this HPL1000 in a year or so -- so no plans to install an OS update at this time.

I have created a mount point /x/engdrw on the HP.

I use the following script as root:

cifsmount //p20/engdrw$ /x/engdrw -f -U admXXp20 -P XXXXXX -I 172.16.1.20 -s

w/o changing login as root, I go to /x and ls -l show no /x/engdrw folder. On a non root user -- same issue.

if I cd to /x and then cd to engdrw I get the error:
NFS access failed for server 172.16.1.20: RPC: Remote system error sh: engdrw: The specified directory is not valid.

as user bietz I login

cifslogin p20 bietz
enter my password and returns to the $ prompt w/o error but ls -l of /x engdrw is still hidden.

umount /x/engdrw and the directory is visible.

Hope this helps.
Jay

umount /x/engdrw

[Eric Raeburn]

Jay,

I suggest you remove the "-f" option from cifsmount. This options tells the cifsclient to do the mount in so-called "force mode", which means only to set up internal data structures as if the mount had been done, but not to actually do the mount. This is explained on p.60 of the Admin Guide.

If you try this with ethereal or some other network trace utility running, you will see that with cifsmount -f there is no network traffic; with -f removed, the client and server talk.

I do not know why your explicit cifslogin for non-root did not work. That did not fail for me. I suspect a permission problem on the server. What does "cifslist" tell your after you do cifslogin?

-Eric

[Jay Bietz]

Eric:
removing the -f and rerunning the script throws an error

Remote user root's password: {xxxx}
Connection Share: DOS: Access denied

I have made the root user in active directory a member of domain admins, and checked the folders to be sure that root has full access and reentered the root users password. All seems OK on the AD side.

"I do not know why your explicit cifslogin for non-root did not work. That did not fail for me. I suspect a permission problem on the server. What does "cifslist" tell your after you do cifslogin?"

Until I get the cifsmount to work the cifslogin fails and cifslist = now servers connected.

Jay

[Eric Raeburn]

Jay,

Sorry, but this may be getting too complex to handle in this forum, and if you need AD support, I'm definitely not your guy. You'd be better served to file an official call with HP Support. If they determine there's a problem with the CIFS Client, they will contact us.

Some recommendations:

1. Check whether SMB packet signing is set to "required" on the Windows server. Signing is not supported on the CIFS Client until version A.02.01, so, although "access denied" usually means a bad password, it can be the consequence of other problems. If this is the case, try setting signing to "if client agrees".

2. If you have a standalone Windows server, you could start with the simple case (eliminating AD from the equation). Set up a share and a user and try to mount and access the share as that user. This would at least validate your procedures (though it does seem you are doing everything correctly).

3. Try setting the "domain" parameter in the configuration file, /etc/opt/cifsclient/cifsclient.cfg . The server may need that value. Be sure to unmount all shares on the server after changing the config and before trying this.

4. Try doing authentication via Kerberos. To do this, set "authenicationLevel = kerberos" in the config file, and again unmount the server after changing the config, and then repeat the cifsmount. Note that Kerberos authentication will work only if the server is a domain controller or domain member; standalone Windows servers to not do Kerberos. In addition, beware that there were some Kerberos version compatibility issues around the hp-ux 11.0 vs. windows 2003 era.

Let me know what happens.

-Eric

[Eric Raeburn]

One more suggestion:

5. Try to map the share from an independent Windows client, using the same user and password that you are using on the HPUX system. In fact, I would try this before any of the other suggestions; it's a good way to localize the problem to AD or cifsclient.

-Eric

[Jay Bietz]

Eric-
Jay,

Some recommendations:

1. Check whether SMB packet signing is set to "required" on the Windows server. Signing is not supported on the CIFS Client until version A.02.01, so, although "access denied" usually means a bad password, it can be the consequence of other problems. If this is the case, try setting signing to "if client agrees".
>> I'll have to research this setting with my consultant.

3. Try setting the "domain" parameter in the configuration file, /etc/opt/cifsclient/cifsclient.cfg . The server may need that value. Be sure to unmount all shares on the server after changing the config and before trying this.

>> already done before we started talking.

4. Try doing authentication via Kerberos. To do this, set "authenicationLevel = kerberos" in the config file, and again unmount the server after changing the config, and then repeat the cifsmount. Note that Kerberos authentication will work only if the server is a domain controller or domain member; standalone Windows servers to not do Kerberos. In addition, beware that there were some Kerberos version compatibility issues around the hp-ux 11.0 vs. windows 2003 era.

>> I looked in cifsclient.cfg and smb.conf for this setting but can't seem to find the entry to change. Do I need a different file or add it to which file?

5. (try PC mapping with root login to share etc.)
>>I used an xp computer to login to AD with the root user name and I was able to map the share as expected.

[Eric Raeburn]

Jay,

My apologies. In my effort to give you a quick reply, in item 4, I inadvertently overlooked the fact that doing Kerberos with the CIFS Client requires more than just setting the parameter, but requires some setup globally on the hp-ux system, in particular, /etc/krb5.conf must be configured to talk to the Windows DC. I refer you to the Admin Guide for this; it is straightforward but not a trivial task.

If you do not see the parameter "authenticationLevel" in cifsclient.cfg, that means the file was modified before any A.01.09.xx version was installed; SD installations do not overwrite any existing version in that case. Check cifsclient.cfg.default and /opt/cifsclient/newconfig/etc/opt/cifsclient/cifsclient.cfg to see if either of those are newer versions (see "ver_id" near the top of the file). Otherwise, you can add the parameter to the "defaultServer" section of your existing cifsclient.cfg .

--------------

3. Try setting the "domain" parameter in the configuration file, /etc/opt/cifsclient/cifsclient.cfg . The server may need that value. Be sure to unmount all shares on the server after changing the config and before trying this.

>> already done before we started talking.

Did you try with the default setting as well ("domain" commented out)? Windows servers can be exceedingly sensitive about these settings.

---------------------

Our next steps, if you are sure everything is consistent (sounds like it is), and once you eliminate SMB packet signing as the possilbe culprit, would be to configure additional log levels for the cifsclient logfile, and possibly get a network trace. For this, I refer you to hp support. They will probably ask for a copy of your config file, and we can take it from there.

Let me know about the signing issue, and if you've placed a support call.

Thanks,
-Eric