2017-07-19 07:32 AEST by Glen Starrett - Suppose there are 2 accounts, say "duser1" and "duser3".  If the following
statements are all true:

* Both have the same password (synchronized passwords, or reset by an admin to
the same default password, whatever)

* "duser3" is listed in passwd as an authorized CVS Suite user and "duser1" is not

* SystemAuth = No (thus setting up passwd as the authorized user list)

Then this will work:

	C:\Users\duser1>cvs -d :sspi:d-w2012x64-m:/myrepo ls
	cvs [ls aborted]: no such user duser1 in CVSROOT/passwd
		
	C:\Users\duser1>cvs -d :sspi:duser3@d-w2012x64-m:/myrepo logout
	Logging out of :sspi:duser3@d-w2012x64-m:2401:/myrepo
		
	C:\Users\duser1>cvs -d :sspi:duser3@d-w2012x64-m:/myrepo ls
	Listing modules on server
		
	abc

>> duser1 is granted access to CVS Suite by "spoofing" the account of duser1.  

Note that duser1 would have to have the same password as duser3 in order to get
this to work, which means they could just "login" as them anyway, so therefore I
think this is a fairly low priority issue.

It does lead to the question of "why is this possible" though.

2017-07-25 06:38 AEST by Arthur Barrett - Yes, this is windows default behaviour.  I think it's probably *NOT A BUG* from our POV, see:
https://superuser.com/questions/733312/2-users-that-have-the-same-passwords-on-windows-7-will-the-
hashes-in-the-sam-fi
and
https://superuser.com/questions/439268/why-does-this-work-windows-same-local-admin-username-and-
password-able-to-acce

The same password generates the same HASH and Windows only compares the hashed passwords for 'single 
sign on' (no it doesn't compare the account or domain names).  I vaguely remember some discussion about 
this finally being improved in some recent windows release or another - but I can't find any mention of it 
through a quick google search...

It may be possible for us to 'improve' this (in which case it's not 'NOT A BUG') - but I suspect it's not, or it's 
very very hard (after all microsoft don't do it themselves).  But maybe there is a way to 'force' SSPI to check 
the SID or something...
https://msdn.microsoft.com/en-us/library/bb742535.aspx


Before we close this bug need to do two things:
- check the same using 'net use' / SMB access
- check the behaviour on different windows releases (the AD server probably plays a part here)
- document what client/server/AD server/AD-level the bug was performed on

2017-07-29 02:32 AEST by Glen Starrett - I've demonstrated the username spoofing at the OS level.  This is the same
domain setup that I originally documented this behavior on.


Setup:
	• Duser1 and duser2 both have the password "Friend1-2"
	• Log into D-W7x64 as "duser2"
	• Using DELTA domain, which is Win server 2012 and Domain and Forest Functional
level 2012
	•
https://www.technipages.com/active-directory-how-to-check-domain-and-forest-functional-level

	• 

CLIENT:
	C:\Users\duser2>net use x: \\d-w2012x64\SharedFolder
	The command completed successfully.

SERVER:
	C:\Windows\system32>net session
	
	Computer               User name            Client Type       Opens Idle time
	
	-------------------------------------------------------------------------------
	\\192.168.248.203      duser2                                     0 00:02:32
	
	The command completed successfully.
	
CLIENT:
	C:\Users\duser2>net use x: /d
	x: was deleted successfully.
	
	
	C:\Users\duser2>net use x: \\d-w2012x64\SharedFolder /user:duser1
	The command completed successfully.
	
SERVER:
	C:\Windows\system32>net session
	
	Computer               User name            Client Type       Opens Idle time
	
	-------------------------------------------------------------------------------
	\\192.168.248.203      duser1                                     0 00:00:47
	
	The command completed successfully.

OK, so it's apparent that synchronized passwords are a problem at the OS level.

Try with duser3 (which has a different password):

CLIENT:
	C:\Users\duser2>net use x: /d
	x: was deleted successfully.
	
	
	C:\Users\duser2>net use x: \\d-w2012x64\SharedFolder /user:duser3
	The password or user name is invalid for \\d-w2012x64\SharedFolder.
	
	Enter the password for 'duser3' to connect to 'd-w2012x64':
	System error 1326 has occurred.
	
	Logon failure: unknown user name or bad password.
	
OK, so this is still a problem within Windows.

2017-08-08 13:11 AEST by Arthur Barrett - Probably would be nice to check Windows 2016 at some point.

We can get the current user SID using code example here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/6b23fff0-773b-4065-bc3f-d88ce6c81eb0/get-
user-sid-in-unmanaged-c?forum=vcgeneral

But whether there is an easy way to check that the SSPI token is for that same SID is the question.  We could 
start a thread that uses the SSPI token to impersonate (like cvsnt server does) and then do the whole SID 
thing again, but surely there is a cleaner way?

2017-08-17 09:39 AEST by Arthur Barrett - Created an attachment (id=3163)
Glen notes - server 2016

Tested on Windows Server 2016 - same error still occurs.

2017-08-17 09:47 AEST by Arthur Barrett - I found an article about windows and password hashing (in particular Lan Manager hashing):

Passwords Technical Overview (Applies To: Windows 7, Windows Server 2003, Windows Server 2008, 
Windows Server 2008 R2, Windows Vista)
https://technet.microsoft.com/en-us/library/hh994558(v=ws.10).aspx

At first I thought this was interesting, but later - not so much.  The problem Glen has demonstrated on Server 
2008 and later indicates this is an NTLM hash problem not an LM hash issue.

In particular:

Passphrases in Windows

There are several ways to ensure the LM hash is not stored; one of them is to use passwords or passphrases 
longer than 14 characters. You can also use the Network security: Do not store LAN Manager hash value on 
next password change Group Policy setting. 



More detail on the group policy setting is here:
https://technet.microsoft.com/en-us/library/jj852276(v=ws.11).aspx


This policy setting determines whether LAN Manager is prevented from storing hash values for the new 
password the next time the password is changed. Hash values are a representation of the password after the 
encryption algorithm is applied that corresponds to the format that is specified by the algorithm. To decrypt 
the hash value, the encryption algorithm must be determined and then reversed. The LAN Manager hash is 
relatively weak and prone to attack compared to the cryptographically stronger NTLM hash. Because the LM 
hash is stored on the local computer in the security database, the passwords can be compromised if the 
security database, Security Accounts Manager (SAM), is attacked.


Stand-Alone Server Default Settings: Enabled
DC Effective Default Settings: Enabled
Member Server Effective Default Settings: Enabled
Client Computer Effective Default Settings: Enabled

On Windows operating systems before Windows Server 2008 and Windows Vista, the default for this policy 
was Disabled.