Bug 869 - Unable to authorize user correctly using ntlm_auth in native ADS for plain-text auth
Unable to authorize user correctly using ntlm_auth in native ADS for plain-te...
Status: RESOLVED INVALID
Product: Samba 3.0
Classification: Unclassified
Component: ntlm_auth tool
3.0.0
All Linux
: P3 major
: none
Assigned To: Andrew Bartlett
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-09 07:23 UTC by Alexander Bokovoy
Modified: 2003-12-23 02:46 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bokovoy 2003-12-09 07:23:06 UTC
In a native and mixed ADS both wbinfo -a and ntlm_auth --diagnostics report
errors when running with plain-text auth.

Follow is the session transcript:
# ntlm_auth --username=USERNAME --password=PASSWORD
NT_STATUS_OK: Success (0x0)

# ntlm_auth --username=USERNAME --password=PASSWORD --diagnostics
Wrong Password (0xc000006a)
[2003/12/09 16:28:03, 1] utils/ntlm_auth.c:diagnose_ntlm_auth(1932)
  Test NTLM and LM, NTLM broken failed!

# wbinfo -a USERNAME%PASSWORD
plaintext password authentication failed
error code was NT_STATUS_INVALID_PARAMETER (0xc000000d)
error messsage was: Unexpected information received
Could not authenticate user USERNAME%PASSWORD with plaintext password
challenge/response password authentication succeeded

Setup: 
# net ads info
LDAP server: 192.168.111.213
LDAP server name: finist
Realm: MIXED.117.X
Bind Path: dc=MIXED,dc=117,dc=X
LDAP port: 389
Server time: Tue, 09 Dec 2003 17:20:09 GMT
KDC server: 192.168.111.213
Server time offset: 7

wbinfo -u and -g work fine -- lists of users are returned correctly.
Comment 1 Gerald (Jerry) Carter 2003-12-10 06:56:11 UTC
For wbinfo -a you have to specify the username as 'DOMAIN\foo'.
I just checked this again 3.0.1rc2 and it works correctly 
(tested using a mixed & native mode AD domain).  I'll let andrew 
fill in the gaps for the ntlm_auth report.
Comment 2 Andrew Bartlett 2003-12-23 02:46:44 UTC
Looks like 'not a bug' to me.  I can't see anything wrong with that output,
except that our diagnostics code might have picked up a change in how MS treats
a particular werid case of invalid input.  (It looks like they might have
tightened things up).

If you want 'winbind use default domain' then specify it, or wait until I fix
bug #569