pegasy / python-ntlm

Automatically exported from code.google.com/p/python-ntlm
0 stars 0 forks source link

Local (none Domain Accounts) can not be used #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I noticed I could not use python-ntml for user accounts which existed on the 
server but not in 
active directory. 

Line #72 in HTTPNtlmAuthHandler.py tries to access the second item in the 
user_parts list. 
However, in my situation the list only had one item since there was no domain 
to be specified. 

The fix appears to be pretty simple and in testing on my own system is working 
really well. 

Change line #72 from:
UserName =  user_parts[1]
to:
UserName =  len(user_parts) > 1 and user_parts[1] or user_parts[0]

Original issue reported on code.google.com by scottwa...@gmail.com on 29 Oct 2009 at 1:48

GoogleCodeExporter commented 9 years ago
That worked for me. I attached a patch that does what that said, because that 
makes it feel more real to me, and to show that someone cares /that/ much.

Original comment by quodlibe...@gmail.com on 30 Jan 2011 at 6:52

Attachments:

GoogleCodeExporter commented 9 years ago
As a workaround, I simply specified the user as '\\username'. However, the 
server I am connecting to would not simply accept a blank domain. I also had to 
turn off the NTLM_NegotiateOemDomainSupplied flag. This library doesn't have an 
option for changing flags, but I was able to monkey patch it:

from ntlm import ntlm
ntlm.NTLM_TYPE1_FLAGS = ntlm.NTLM_TYPE1_FLAGS & 
~ntlm.NTLM_NegotiateOemDomainSupplied

Original comment by CollinMA...@gmail.com on 29 Aug 2011 at 5:46

GoogleCodeExporter commented 9 years ago
I can confirm that CollinMA's workaround and monkeypatch work wonderfully — 
thank you, without this hint I would have had no idea how to get this working 
against my Windows server!

Original comment by brandon....@gmail.com on 22 Dec 2011 at 3:12

GoogleCodeExporter commented 9 years ago
I've committed a fix for issue #26 (r82) that probably fixes the first part if 
this issue (setting UserName and DomainName).

Could you check if that's true?

The ntlm.NTLM_TYPE1_FLAGS is something that could be set when the domain is 
empty, correct?

Original comment by cornelis...@gmail.com on 18 Apr 2012 at 8:00

GoogleCodeExporter commented 9 years ago
I've changed ntlm.create_NTLM_NEGOTIATE_MESSAGE(). It now takes optionally 
type1_flags. These are normal (ntlm.NTLM_TYPE1_FLAGS) when DomainName is not 
empty or otherwise set to ntlm.NTLM_TYPE1_FLAGS & 
~ntlm.NTLM_NegotiateOemDomainSupplied

See r83

It would be nice if someone could verify that this is correct/working.

Original comment by cornelis...@gmail.com on 18 Apr 2012 at 8:27

GoogleCodeExporter commented 9 years ago
Very interesting. I have since written my own HTTPNtlmAuthHandler, calling 
ntlm.create_NTLM_NEGOTIATE_MESSAGE() directly. So, I can't test your 
HTTPNtlmAuthHandler but I can test NTLM_NEGOTIATE_MESSAGE.

Actually, I have found while testing this: it turns out both in 1.0.1 and r83, 
I can simply pass in 'user' instead of '\\user' and my server accepts it, 
without needing to change default the flags.

After r83, I can confirm that this also works:
ntlm.create_NTLM_NEGOTIATE_MESSAGE('\\user', ntlm.NTLM_TYPE1_FLAGS & 
~ntlm.NTLM_NegotiateOemDomainSupplied)

However, I think I will stick with the cleaner code that works in the current 
version 1.0.1:
ntlm.create_NTLM_NEGOTIATE_MESSAGE('user')

Thanks so much for all of your work on this.

Original comment by CollinMA...@gmail.com on 18 Apr 2012 at 2:26

GoogleCodeExporter commented 9 years ago
Thanks for the response. Changing status to fixed.

Original comment by cornelis...@gmail.com on 18 Apr 2012 at 3:17