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

[Jeremy Begg]

Further testing ...

With or without "require strongkey = yes" in SMB.CONF, the domain policy must be set as described in the KB article for CIFS to join the domain.

Once the join has been done, the domain policy can be reset to the defaults and CIFS will continue to work as a member server in the domain.

We also found that changing the "require strongkey" setting in CIFS after CIFS has joined the domain will break it: the join must be done again. (But perhaps this is expected behaviour.)

Regards,
Jeremy Begg

[Paul Nunez]

Hi Jeremy,

I didn't have the same problem - with the Windows Server 2008 policy disabled and with "require strongkey = yes" in smb.conf, I was able to join the domain.

Deleted the machine account from Active Directory, delete all .tdb files in samba$root:[private] and [var.locks], commented out the "require strongkey" and tried to join again - no luck:

[2009/05/01 08:59:14, 0] SAMBA$SRC:[SOURCE.UTILS]NET_RPC_JOIN.C;1:(359)
Error in domain join verification (credential setup failed): NT code 0xc0000388

Uncommented the "require strongkey = yes" line and was able to join again...

Regards,

Paul

[Robert Atkinson]

For what it's worth, I can confirm Paul's solution worked fine for me under CIFS v1.2 Patch 001.

Rob.

[Jeremy Begg]

Thanks Robert. The customer concerned is making less use of CIFS than they used to, but they are now talking about implementing external authentication so I want to look into upgrading them to the latest CIFS. Which means your recent experience might come in handy :-)

Regards,
Jeremy Begg

[Paul Nunez]

Jeremy,

CIFS is not required for external authentication and doesn't provide any extauth capability (there is no
ACME module provided).

Use the ACME LDAP module to provide external authentication.

Paul

[Jeremy Begg]

Paul,

Thanks for the comments. I worded my note badly. What I meant to imply was that up until recently we didn't want to upgrade CIFS because it seemed that every time we touched it, something broke. We had arrived at a patch level which solved most problems and were happy to leave it there.

Now that CIFS is less critical and the new IT manager wants to authenticate everything against the Active Directory domain, it's probably time to look at upgrading CIFS to 1.2.

Regards,
Jeremy Begg