Mount SMB on Windows 7 Home Premium

microsoft technet screenshot
Most guides telling you how to mount smb CIFS/Samba shares on Linux to mount on Windows 7 will point you to adjust settings in Administrative Tools -> Local Policies.

Windows 7 Home Premium does not have the Local Policies MMC snap-in. Therefore you cannot use that tool to change the NTLMv2 security settings.

Instead of messing with a snap-in at all, just open the registry editor and set the LmCompatibilityLevel explicitly.

It’s described here, buried in the Lsa control set on


Add a new DWORD (32-bit) Value, “LmCompatibilityLevel”

Set the value to 1 for the widest compatibility, or a higher value if you want to restrict session security to some combination of only NTLMv2, NTLM, LM.

See the technet page for the chart with descriptions of all the levels:

File Check Hash Generator – Recursive Tripwire

finger pointing at security textYou can use this to check to see if anyone has modified, updated, upgraded, added, or removed any files on your system. After you’ve configured a system the way you want it, dump hash files for all the important directories, /etc, /bin, /usr/local, etc., or just dump the whole thing. Move the output to another system. Now if you want to check to see if something has changed, you can hash the file(s) in question and grep for the hash.

A directory like /etc has many subdirectories with subdirectories of their own – not a problem. When the script encounters a directory, it recursively calls itself so it will parse all child directories. Skipping special files should avoid the problem of probing char files, proc, and other gotchas. know it could be better. There’s things like pid files that are useless to hash.

This was just a quick stab at it. Feel free to adapt this to your own needs as you see fit.

Bash script:

md5sum=/usr/bin/md5sum # hash algorithm to use
indir=${1} # base input directory to start hashing files
outfile=${2} # full path of output file

if [ "${indir}" == "" -o "${outfile}" == "" ]; then
  echo "Usage: $0  "
  echo "  ex: $0 /etc /root/etc.hash"
  exit 1

for x in `ls "${indir}"`; do
  if [ -d ${indir}/$x ]; then # is a dir
    echo "[ Recursively hashing ${indir}/$x ]"
    $0 ${indir}/$x ${outfile} # pass new path in
    if [ $? != 0 ]; then # recursive call failed, die
      echo "Could not hash ${indir}/$x"
      exit 1
  else # is not a dir
    if [ -f ${indir}/$x ]; then # regular files only
      ${md5sum} "${indir}/$x" >> "${outfile}"

exit 0

Verify LDAP encryption with Wireshark

TLS, Is it working or not?

secret text in red and yellow on black
Assuming you’ve already installed and configured your directory to use TLS encryption, you should verify LDAP is working as you expect before you start streaming passwords and other important data across the wire.

You can use Wireshark and it’s full blown gui interface, but it’s faster just to fire up tethereal for this test. tethereal is part of the Wireshark package, so if you don’t already have it, install Wireshark now.

Server Side

As a regular User

$ /usr/sbin/tethereal -n tcp port ldap
tshark: There are no interfaces on which a capture can be done

Hmm ok fine, against all warnings, i’ll use root. But I don’t have to like it.

As root

When you run tethereal or Wireshark (filtering for ldap traffic only), you won’t get any output unless your LDAP network is already in use or until you generate some traffic. So start by running tethereal on the LDAP server. Then go to the client side and try browsing ldap.

$ sudo /usr/sbin/tethereal -n tcp port ldap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0> TCP 49415 > 389 [SYN] Seq=0 Win=5840 Len=0 MSS=1460> TCP 389 > 49415 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0> TCP 49415 > 389 [ACK] Seq=1 Ack=1 Win=5888 Len=0> LDAP extendedReq(1) LDAP_START_TLS_OID]> TCP 389 > 49415 [ACK] Seq=1 Ack=40 Win=5824 Len=0> LDAP extendedResp(1) [LDAP_START_TLS_OID]> TCP 49415 > 389 [ACK] Seq=40 Ack=15 Win=5888 Len=0> SSL Client Hello> TLSv1 Server Hello, Certificate, Server Hello Done> TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message> TLSv1 Change Cipher Spec, Encrypted Handshake Message> TLSv1 Application Data, Application Data

Client Side

The -Z flag requests encryption. Double -Z’s forces encryption and fails if it’s not available. So maybe that’s enough for you, but I’m not going to trust that this flag even works without seeing encrypted traffic! Also, this doesn’t prove that all traffic will be encrypted, it just means it’s allowed to be encrypted. So try it with no -Z’s at all.

$ ldapsearch -x -Z
dn: uid=admica,ou=People,dc=rootninja,dc=com
uid: admica
objectClass: posixAccount
objectClass: top
loginShell: /bin/bash
uidNumber: 1337
homeDirectory: /fake/data
gidNumber: 123

Now go back to the server and see if you captured anything. If you’re using the standard LDAP port 389 and TLS encryption, you don’t even need to look at 636. You should see the handshake and then Application Data, Application Data.

Back on the Server Side

Run tethereal again with -x and you can look at the data and see it’s encrypted. You should only see the initial communication and certificate exchange in clear text. The rest should look like this:

     0.025405 -> TLSv1 Application Data, Application Data

    0000 00 1d 4f ab 69 51 55 19 b9 20 0b 98 08 00 65 10 ..O.iP… ….F.
    0010 00 ce b0 ec 40 01 40 07 73 84 0a 0a 02 0c 0b 0a ….j.@.s…2…
    0020 18 04 38 ef 03 40 ee 7c 49 ba 2b 69 e6 db ff 64 ..2..q.jI.+X..j..
    0030 00 7c 26 6f 0f 00 01 01 0f 0a 2f 39 a0 1d 0a 21 .&.f……/3…f
    0040 fa 56 27 0a 01 00 20 79 ef b2 9a 32 0f f2 16 1c .V…. y..1…..
    0050 0f 5e 2b eb 5d 49 04 4a 06 9a ad fa 9e da 5d f2 .^+.QI.J……]Y
    0060 b1 6e 01 dc 62 12 f9 17 07 01 00 00 60 fb 1f 3d .n..i5d.da.22..=
    0070 e4 31 76 9f 0c 2f 36 53 18 7d ff 25 ff d4 40 24 .1…/6S.}….@$
    0080 18 a4 38 ef e3 40 ee 7c 49 ba 2b 68 e6 db f1 64 ..8..q.|I.+X…a
    0090 1a 05 57 6f eb c4 d3 9f 8a 9a 35 43 05 88 10 f2 ..Wa……5….R
    00a0 34 99 32 cf d4 74 56 32 ab fe 4b 71 fb ef 2b f3 2.j..^V2..K!..p.
    00b0 8f 64 bc d2 ea 14 99 3a dc 81 65 29 70 6c d1 d7 .d.b…:..eIjl..
    00c0 2b 42 ce e1 16 f4 6e 34 6d 6c 7f 12 -B….n4:l..

If you see plain text output here, then you’re not really using TLS encrpytion. It is possible you misconfigured your server to allow encrpytion without enforcing it.