0
votes

Can someone please assist with the following question

I want to be able to force either an NTLM logon or Kerberos logon to an Active Directory Domain controller as a separate user principle

Initially, I simply tried the Windows NET command as follows

net use \DCName\Sharename /user:DomainName\Username password01 and net use \10.10.10.10\Sharename /user:DomainName\Username password01

the first one for Kerberos as the SPN (service principal name) can be obtained and therefore the hash to use with Kerbberos ticket encryption

The second one for NTLM as no SPN can be retrieved based on IP address and therefore fall back to NTLM

I have had very mixed results with the above, therefore I want to look for an alternative method (as I need to feed in lots or username and password to create lots of logons at the DC e.g. Kerberos or NTLM at will)

So next I tried

[system.reflection.assembly]::LoadWithPartialName('System.DirectoryServices.AccountManagement')
$D = [system.DirectoryServices.AccountManagement.ContextType]::Domain
$PC = [system.DirectoryServices.AccountManagement.PrincipalContext]$D
$M = [system.DirectoryServices.AccountManagement.ContextOptions]::Negotiate

$PC.ValidateCredentials('User01','Password01',$m)

However as one might imagine this only validated the username password combination it did not create a Kerberos TGT for the user for example (which is what I want to do when forcing a kerberos logon)

So my question is please, if there a .NET namespace when given a know username and password you can force the issuance of a TGT (for Kerberos authentication) or NTLM token, logon ?

Thanks very much in advance EB

1

1 Answers

0
votes

Why exactly are you wanting to do this?

Windows really doesn't want you to specify what protocol to use and instead just wants you to use Negotiate so it can safely move to better and more secure protocols without impacting apps.

That philosophy has mostly bubbled up through the major frameworks, so you're not going to get dedicated API's for each protocol.

That said, you can call directly in to SSPI specifically passing in "Kerberos" or "NTLM".

The gist of this is:

Client:

AcquireCredentialsHandle(..."Kerberos"...) -> 
InitiateSecurityContext(..."spn/kerb.host"...) => server

Server:

AcquireCredentialsHandle(..."Kerberos"...) -> 
AcceptSecurityContext(...iscTicket...)