2021-06-11 09:00 AEST by Arthur Barrett - This is from an internal email on 2nd October 2018.  We haven't progressed this issue, so I'm writing it up as a 
bug so we don't lose track of it.  The email is about performing some testing as to what happens with 
authentication when the SPN is not created (eg: because CVSNT server was not installed from a domain 
admin account).  Based on the results of that testing, there may be some 'bugs' (or really 'features') we want 
to address.  In my original email I suggested putting notes for this in bug 6990: "eBook: 
Authentication/Authorization whitepaper/book (and add to eBook too)" - but now I'm creating this new bug 
and making it dependant on bug 6990, because it's related, but really its own topic too.
 




I’ve been reading up a little on SPN’s this morning just for interest sakes - and it may actually be worthwhile 
running a test internally.  Don’t do this during April - my budget is already up the creek - but maybe add this 
to your todo list for June or something…
 
You  have a domain test set - can you remind me of what it is?
- forest level (W2003/w2008?)
- domain level (W2003/w2008?)
- cvsnt server (W2003/w2008? non BDC/PDC? Domain Member?  Service user 
(SYSTEM/CVSMANAGER_USER)?
- cvsnt client (W7?) Domain Member?
 
So the specific test I would like to run is using SSPI with Kerberos.
 
There are two ways to do this:
 
cvs -d :sspi;force=Kerberos:localhost:/myrepo rls
 
and/or 
 
NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7
https://blogs.technet.microsoft.com/askds/2009/10/08/ntlm-blocking-and-you-application-analysis-and-
auditing-methodologies-in-windows-7/
 
Using security policies to restrict NTLM traffic 
https://docs.microsoft.com/en-us/previous-
versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865668(v=ws.10)?WT.mc_id=email
 
 
 
The problem is that as of AD DS 2008 and 2012,  Kerberos is the default protocol used for authentication on 
AD domain-joined machines; if NTLM is not disabled then tailback to NTLM is allowed if for some reason 
Kerberos authentication fails. So you can be using SSPI thinking you are getting Kerberos authentication - but 
you are actually relying on NTLM.
 
The reason we add the SPN for CVS is for use with Kerberos authentication.  Off the top of my head - I’ve 
only directly ran into problems with it when testing ‘gserver’.  So I started to wonder why it was that I hadn’t 
ran into problems with missing SPN more with SSPI - since that is Kerberos right?  Well the ‘fallback’ is 
possibly the reason why.  The SPN isn’t registered - Kerberos auth can’t proceed, so the AD reverts back to 
auth by NTLM.  I don’t think we are at fault here - it’s not a bug or anything - we bang on about needing to 
install the server as domain admin (which is the point of this whole thread now).  And there are technet 
articles that let admins audit NTLM usage (see above links).
 
But for our own peace of mind/understanding - it would be good to know what happens when people don’t 
follow the instructions.  If the result is they can’t login - all well and good.  But if the result is they get to log in 
with abysmal security, then maybe that’s not quite so good.  It could even be argued we should issue a 
warning or something "you’ve been logged in using insecure NTLM authentication”.
 
Here are some more useful links:
https://blogs.msdn.microsoft.com/autz_auth_stuff/
 
Service Principal Names:
https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx
 
In particular - Per Nygaard’s blog on 'Kerberos Delegation’ makes the link between the SPN and the user, 
which I frankly just don’t understand.  We always say that you must register the SPN as domain admin - and it 
makes sense to me that a domain admin has the authority to register the SPN in the forest.  But he is pointing 
out that SPN’s are related to users - which also makes sense because bug 6662 describes a situation where 
CVSMANAGER service must be ran as a member of the Domain Administrators group...
 
I’m starting to think we’ve conflated the ‘permissions required to set the SPN’ and the ‘user for whom the 
SPN should be set’ somewhere along the line.  What Tony wrote worked OK for Windows 2003 servers - but 
once you start to look at more recent servers like 2008R2 (which is after Tony left) the holes in the 
implementation start to appear.
 
There is potentially scope for one or two new ‘bugs’ to be created based on your test results:
- set SPN per user (CVSMANAGER_USER/SYSTEM)
- warn if NTLM is used for SSPI
 
I’ve written all this down in almost a ‘stream of consciousness’ fashion, so maybe it doesn’t make any sense 
at all...