[Samba] user won't "log in" to share

[Xen]

I have a very peculiar issue.

On my Synology NAS I have a bunch of LDAP users and SMB is configured by 
Synology to accept LDAP logins. So far so good. I log in through an LDAP 
user by specifying my "base dn" as the domain name, which is "ds" in my 
case, nice and short.

I have 2 users. One user is present on my system with the same name, the 
other isn't.

When I mount a certain share with the other user, she is able to log in. 
The share gets mounted.

When I mount this with my own user (but it is a remote user) I am not 
able to mount the share.

When I use smbclient to log in to that share, I get in.

$ smbclient //diskstation/hub -U xen -W ds
WARNING: The "syslog" option is deprecated
Enter xen's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.9]
smb: \> ls
   .                                  DA        0  Tue Oct  4 12:05:13 
2016
   ..                                  D        0  Tue Oct  4 10:33:38 
2016

                 1930607900 blocks of size 1024. 1404974712 blocks 
available
smb: \>

Well, there is just nothing to see :p. But I'm in the right place.

Now when I mount the thing using sudo and all, I get:

$ sudo mount //diskstation/hub /nas/hub -t cifs -o 
"username=xen,domain=ds,workgroup=ds,noforceuid,noforcegid,soft,noperm"
Password for xen@//diskstation/hub:  *********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

When I use the other user, I get:

$ sudo mount //diskstation/hub /nas/hub -t cifs -o 
"username=paola,domain=ds,workgroup=ds,noforceuid,noforcegid,soft,noperm"
Password for paola@//diskstation/hub:  ********
$

Mounted.

The "xen at ds" user is part of 2 groups that have read access to the 
share. They have this group membership on the server.
The "paola at ds" user is part of one of these groups that have read access 
to the share. She has this group membership on the server.

Both users have their loginShell in LDAP set to /bin/false to ensure 
that these users don't show up as login accounts on GUI login managers.

They are nearly identical for the rest; actually completely so apart 
from that one group.

Wiping that difference does not create a difference at first go, at 
least.

In the shell (tty) errors are visible:

[79460.389536] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
[79460.389565] CIFS VFS: Send error in SessSetup = -13
[79460.389800] CIFS VFS: cifs_mount failed w/return code = -13

I really have not an inkling of a clue as to why this is happening now.

And then I do some random hunting on the interwebs and this solves my 
issue:

sec=ntlmssp

Does it have to do with the password being identical to that of the 
other user?

We shall find out.

Yes, it is because the password hash of my @ds user is the same as that 
of my regular user on that system????

Changing the password immediately solves it. There is a hash collision.

The reality is that I cannot mount 2 shares using two different users 
that each have the same password and the same name, excluding domain.

The moment I umount the last of the first user (local user) I can mount 
the 2nd of the 2nd user (ldap user).

Turns out it works as long as I use a /different/ sec= algorithm for the 
2 sets of shares.

If I turn them /both/ to ntlmssp they will collide again :p.