Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


In Win2k | 24 comments | Create New Account
Click here to return to the 'In Win2k' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
In Win2k
Authored by: extra88 on Mar 08, '05 11:32:15AM

I don't have a Win2k Domain Controller but the following is true on a member server and Win2k Pro. Setting digital signatures to "always" is only really possible when you have a 100% Win2k or newer Active Directory domain.

Go to Start | Programs | Administrative Tools | Local Security Policy.

Local Policies | Security Options

"Digitally sign client communications (always)" [Disabled]
"Digitally sign client communications (when possible)" [Enabled]

"Digitally sign server communications (always)" [Disabled]
"Digitally sign server communications (when possible)" [Enabled]

While you're there, test the different configuration options for "LAN Manager Authentication Level." Ideally you set it to "Send NTLMv2 response only\refuse LM & NTLM." There should be no reason to set it lower than "Send NTLM response only." Even Win98 can use NTLM and it can use NTLMv2 if the ADclient software is installed. I haven't tested the version of Samba installed in OS X to see if it supports NTLMv2.

"LM" is short for LanManager and if your traffic is sniffed the password can be cracked like a walnut. "NTLM" is better but still flawed. NTLMv2 is *a lot* better, I think if you can stick to NTLMv2 you don't have to worry about network sniffing.



[ Reply to This | # ]
In Win2k
Authored by: s_groening on Mar 08, '05 03:05:13PM
A W2K server does not do this by default. W2K3 server expects to be used in a 'native environment' and thus acts this way per default. I think the implications of this 'hint' are to be overlooked, since a mailicious machine must be a Samba client of some sort or a Windows client bound to Active Directory and have access to a known AD user's login and password, or at least know the ip-address of your AD servers and have access to a known AD user's login and password in order to do much. Of course you will need to secure your subnet by turning off outside connections to your servers via ftp, telnet and smb. This all said, this is still a corner stone in getting Single Sign-On, SSO, working for Mac OS X and Windows clients alike with your W2K3 Active Directory. -At least when integrating Open Directory services with AD servers through the LDAPv3 plugin. I do not know if this is actually the case with the AD plugin but expect it to be. And yes: client ntlmv2 auth = yes works!! For more information on Kerberos SSO and Mac OS X with W2K3 AD

[ Reply to This | # ]
In Win2k
Authored by: raider on Mar 08, '05 05:13:16PM
This is a cool hint. Very helpful. We finally figured it out a while back - but it had us stumped for a LONG time.

But how do I make sure that our Macs are using NTLMv2 to connect? All running 10.3.8.

[ Reply to This | # ]
In Win2k
Authored by: s_groening on Mar 18, '05 05:56:29PM

in /etc/ssmb.conf ensure that :

client ntlmv2 auth = yes

is added.

that's it!



[ Reply to This | # ]
In Win2k
Authored by: smanzo on Mar 08, '05 03:19:33PM

Perfectly normal behavior. Apple's SMB client doesn't do signing, and their interoperation documentation goes into this. What you are doing is dropping the security requirements for the domain such that downlevel (pre-Windows 2000 clients) can still connect. As the other poster mentioned, it does do Very Bad Things whenever the downlevel client is connecting, as the transmissions of username and password via plain NTLM are trivial to decode.



[ Reply to This | # ]