CIFS V1.1-ECO1 and Windows Server 2008

[Jeremy Begg]

Hi,

A customer site is running CIFS V1.1-ECO1 on OpenVMS V8.3-1H1 in "Standalone" mode (because they have no Windows domain on site). They are now looking at putting in a "proper" Windows Domain PDC with Active Directory. They would prefer to run Windows Server 2008.

So we've been trying to test this setup in my office. We have installed CIFS V1.1-ECO1 on an Integrity server here runnng OpenVMS V8.3-1H1 and we have installed Windows Server 2008 with Active Directory on a PC.

We are unable to get CIFS to join the Windows domain:

CLIVE» net rpc join --user administrator

Password:

[2009/04/28 13:17:08, 0] SAMBA$SRC:[SOURCE.UTILS]NET_RPC_JOIN.C;1:(359)

Error in domain join verification (credential setup failed): NT code 0xc0000388

Unable to join domain AD.

CLIVE»

The above error message appears in several postings to various newsgroups and forums discussing SAMBA 3.0.28 on which OpenVMS CIFS is based.

The OpenVMS CIFS Version 1.1 Administrators Guide says "HP CIFS Server supports the NTLMv1/NTLMv2 security used for NT domain membership, so HP CIFS Servers can be managed in any Windows 2000/2003 ADS, Windows 200x mixed mode, or NT environment." But I wonder about the significance of the "x" in "Windows 200x".

Can HP OpenVMS CIFS be a member server in a Windows 2008 domain? If so, are any special policies required in the Windows server setup?

Thanks,
Jeremy Begg

[Ian Miller.]

Ask HP. I believe there are updates for CIFS V1.1-ECO1

[Verne Britton]

Just finished a five day course on Server 2008 a few weeks ago ...

but do not have any 2008 servers at my office ...

the term that sticks in my mind from the course is

domain functional level

of your Active Directory environment ... and there is one setting for

2008 (all machines being 2008 servers)

and another (maybe several other settings) when having a mixture of servers (older O/S machines, perhaps including CIFS) in the domain ...

Perhaps this is an area for you to look into ...

again, I do not have the resources here to try any of this, sorry.


Verne

[Jeremy Begg]

My Windows 2008 guy tells me that we can't "downgrade" the "domain functional level" once the server is up and running. So we might try buildng a new one with it set to operate in 2003 mode.

I think I'll log a service call with HP as well. It looks a lot like CIFS can't be a member in an AD2008 domain.

Thanks,
Jeremy Begg

[John Gillings]

Jeremy,

> It looks a lot like CIFS can't be a
> member in an AD2008 domain.

But of course! Isn't that the primary reason the guys in Redmond bring out new versions? To break anything running old versions, or software from other vendors, thus forcing another round of license fees.

Compatibility? Not good for the shareholders...

[Jeremy Begg]

Hmm, is that worth 0 points or 10 points? :-)

[Paul Nunez · Accepted solution]

Hi Jeremy,

With "security = domain", CIFS is configured as an NT v4 style member server and as such the Windows Server 2008 DCs will need a policy change - see:

http://support.microsoft.com/kb/942564

(I'll request engineering add something to the release notes.)

Regards,

Paul

[Jeremy Begg]

Hi Paul,

That's exactly what we needed! Big thanks!

I'm leaving the thread open just in case we run into more issues.

Regards,
Jeremy Begg

[Paul Nunez]

Hi,

Oops - lesson time - RT!M.

According to the CIFS Administrator's Guide, there's an smb.conf paramater that allows CIFS to join a domain wth Windows Server 2008 domain controllers (no change required on DCs):

require strongkey = yes

Paul
(feel free to assign negative points :O)

[Jeremy Begg]

Hi Paul,

Thanks for the suggestion but it appears not to work.

We turned off the policy described in the KB article, added "require strongkey = yes" to our SMB.CONF, and tried to join the domain.

The result was that the join appeared to succeed (but it didn't prompt for a password).
However we couldn't access any shares.

So we re-enabled the policy and joined the domain again, and now it works again.

Summary: "require strongkey = yes" may be correct, but it's not sufficient -- you still need the domain policy described in the MS KB article.

Regards,
Jeremy Begg