Tcl

NTLM Client and Server Code

See more NTLM Examples

Demonstrates the NTLM authentication algorithm for both client and server. Tcl

load ./chilkat.dll

set success 0

# This example assumes the Chilkat API to have been previously unlocked.
# See Global Unlock Sample for sample code.

set ntlmClient [new_CkNtlm]

set ntlmServer [new_CkNtlm]

# The NTLM protocol begins by the client sending the server
# a Type1 message. 

CkNtlm_put_Workstation $ntlmClient "MyWorkstation"
set type1Msg [CkNtlm_genType1 $ntlmClient]

puts "Type1 message from client to server:"
puts "$type1Msg"

# If the server wishes to examine the information embedded within the
# Type1 message, it may call ParseType1. 
# This step is not necessary, it is only for informational purposes..
set type1Info [CkNtlm_parseType1 $ntlmServer $type1Msg]

puts "---"
puts "$type1Info"

# The server now generates a Type2 message to be sent to the client.
# The Type2 message requires a TargetName.  A TargetName is
# the authentication realm in which the authenticating account
# has membership (a domain name for domain accounts, or server name
# for local machine accounts).
CkNtlm_put_TargetName $ntlmServer "myAuthRealm"

set type2Msg [CkNtlm_genType2 $ntlmServer $type1Msg]
if {[CkNtlm_get_LastMethodSuccess $ntlmServer] != 1} then {
    puts [CkNtlm_lastErrorText $ntlmServer]
    delete_CkNtlm $ntlmClient
    delete_CkNtlm $ntlmServer
    exit
}

puts "Type2 message from server to client:"
puts "$type2Msg"

# The client may examine the information embedded in the Type2 message 
# by calling ParseType2, which returns XML.  This is only for informational purposes
# and is not required.
set type2Info [CkNtlm_parseType2 $ntlmClient $type2Msg]

puts "---"
puts "$type2Info"

# The client will now generate the final Type3 message to be sent to the server.
# This requires the Username and Password:
CkNtlm_put_UserName $ntlmClient "test123"
CkNtlm_put_Password $ntlmClient "myPassword"

set type3Msg [CkNtlm_genType3 $ntlmClient $type2Msg]
if {[CkNtlm_get_LastMethodSuccess $ntlmClient] != 1} then {
    puts [CkNtlm_lastErrorText $ntlmClient]
    delete_CkNtlm $ntlmClient
    delete_CkNtlm $ntlmServer
    exit
}

puts "Type3 message from client to server:"
puts "$type3Msg"

# The server may verify the response by first "loading" the Type3 message.
# This sets the various properties such as Username, Domain, Workstation,
# and ClientChallenge to the values embedded within theType3 message.
# The server may then use the Username to lookup the password.  
# Looking up the password is dependent on your infrastructure.  Perhaps your
# usernames/passwords are stored in a secure database.  If that's the case, you would
# write code to issue a query to get the password string for the given username.
# Once the password is obtained, set the Password property and then 
# generate the Type3 response again.  If the server's Type3 response matches
# the client's Type3 response, then the client's password is correct.

set success [CkNtlm_LoadType3 $ntlmServer $type3Msg]
if {$success != 1} then {
    puts [CkNtlm_lastErrorText $ntlmServer]
    delete_CkNtlm $ntlmClient
    delete_CkNtlm $ntlmServer
    exit
}

# The Username property now contains the username that was embedded within
# the Type3 message.  It can be used to lookup the password.
set clientUsername [CkNtlm_userName $ntlmServer]

# For this example, we'll simply set the password to a literal string:
CkNtlm_put_Password $ntlmServer "myPassword"

# The server may generate the Type3 message again, using the client's correct
# password:
set expectedType3Msg [CkNtlm_genType3 $ntlmServer $type2Msg]

puts "Expected Type3 Message:"
puts "$expectedType3Msg"

# If the Type3 message received from the client is exactly the same as the
# expected Type3 message, then the client must've used the same password,
# and authentication is successful

delete_CkNtlm $ntlmClient
delete_CkNtlm $ntlmServer