TR Forums

I just posted a topic on ServerFault on an issue I'm having getting a Windows 7 PC that's attached to a domain to connect to any Samba share.

It's quite ridiculous too and infuriating because it can connect to shares that it owns under Active Directory just fine. Anybody have any bright ideas? Additional info and stuff is available in the SF link (like the smb.conf file).

Thanks.

Try adding
client ntlmv2 auth = yes
to your SMB.conf and that might resolve it. Window 7 does have much tighter default security.

Will do tomorrow, thanks.

Couple of notes and basic questions.

First, set "log level=4" and try the connection again. It will likely tell you exactly why the connection isn't proceeding. You just have to interpret the log entries.

Now, for the basic stuff. You aren't specifying a security mode so it is going to default to "security = user". This means that the user must have and account defined in the smbpasswd file, and that account must match exactly the Unix account for the user. Assuming all these are verified, the next step would be the log files from a connection attempt with the log level raised. I'm certainly not a Samba expert, but I oversee about 100 or so Samba servers in my day job, so I might be able to give you some hints.

--SS

Found out the problem thanks to a co-worker looking into it.

The problem is that within our environment, by default, Windows 7 required all SMB packets to be signed. Samba servers, however, do not. So there are two ways to fix this: turn off client signing in Win7 or add a flag to the smb.conf file in the global section as this: 'server signing = auto'. (we were using Samba 3.5.2).

For Windows 7, you can 'fix' this policy by making it more lenient -- going from requiring digital signatures to optionally using it if the server agrees.

Here's how you can use it:

The local windows security policy changes are as follows:
Start menu
type GPEdit.msc
Browse to Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options
Look for "Microsoft network client: Digitally sign communications (always)" and change it to Disabled

You may also need to do the same for "Microsoft network client: Digitally sign communications (if server agrees)". In theory this should be negotiated during the negotiate/challenge phase of NTLM but it may fail; NTLM doesn't explicitly demand any real negotiation.

Your option to have Samba do the signing would be a more perferable outcome. An extra defense against man in the middle attacks would be worth it. Even if it is internal only traffic, let us not forget our own employees are our greatest security threat.

Absolutely. That's what we're doing.