R: winbindd UPN problem
fules
fules at balabit.hu
Tue Jan 27 14:49:24 GMT 2009
Diego Zuccato wrote:
> Seems UPN logins are the "trouble of the day" :-)
> I'm having a problem that could be related, but I'm only trying to login.
> Does your system accept upn logins?
Over RDP it does. However, I must use a full qualified name like
'user at TEST1DOMAIN.COMPANY', the short one ('user at TEST1DOMAIN') doesn't work,
indeed. (As far as I remember, last week the short one worked, too, so either an
automatic update has changed some code or one of my fellow colleagues some
setting on the server :)...)
Besides, while trying this approach I found another phenomenon, namely that
while I pass an empty domain name to wbcAuthenticateUserEx() as this is what I
got from the client, for some reason winbind tries to fix it anyway and replaces
it by the short domain name:
netr_LogonSamLogonEx: struct netr_LogonSamLogonEx
in: struct netr_LogonSamLogonEx
server_name : *
server_name : '\\test1.test1domain.balabit'
computer_name : *
computer_name : 'CHAOS'
logon_level : NET_LOGON_TYPE (2)
logon : *
logon : union netr_LogonInfo(case 2)
network : *
network: struct netr_NetworkInfo
identity_info: struct netr_IdentityInfo
domain_name: struct lsa_String
length : 0x0016 (22)
size : 0x0016 (22)
string : *
string : 'TEST1DOMAIN'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here the domain name should be empty
parameter_control : 0x00000820 (2080)
0: MSV1_0_CLEARTEXT_PASSWORD_ALLOWED
0: MSV1_0_UPDATE_LOGON_STATISTICS
0: MSV1_0_RETURN_USER_PARAMETERS
1: MSV1_0_ALLOW_SERVER_TRUST_ACCOUNT
0: MSV1_0_RETURN_PROFILE_PATH
1: MSV1_0_ALLOW_WORKSTATION_TRUST_ACCOUNT
logon_id_low : 0x0000dead (57005)
logon_id_high : 0x0000beef (48879)
account_name: struct lsa_String
length : 0x0032 (50)
size : 0x0032 (50)
string : *
string :
'fules at test1domain.balabit'
workstation: struct lsa_String
length : 0x000e (14)
size : 0x000e (14)
string : *
string : '\\CHAOS'
challenge : 8a1018542a7c6c64
nt: struct netr_ChallengeResponse
length : 0x0132 (306)
size : 0x0132 (306)
data : *
data :
0bf019387117f03c6c5ae3493253f36a0101000000000000680b2c5a8b80c9010fe4322431cb68a100000000020016005400450053005400310044004f004d00410049004e0001000a004300480041004f005300040026007400650073007400310064006f006d00610069006e002e00620061006c006100620069007400030032006300680061006f0073002e007400650073007400310064006f006d00610069006e002e00620061006c006100620069007400050026007400650073007400310064006f006d00610069006e002e00620061006c00610062006900740007000800680b2c5a8b80c9010600040002000000080030003000000000000000000000000030000075a230e559db3da0fa49d619c88f2ec2913712ee6ce2d6fbeafdab03e48aee01000000000000000000000000
lm: struct netr_ChallengeResponse
length : 0x0000 (0)
size : 0x0000 (0)
data : NULL
validation_level : 0x0003 (3)
flags : *
flags : 0x00000000 (0)
Since this way the domain name is not the one used by the client, it's no wonder
that the calculated nt hashes don't match and so the authentication fails.
I think I'm going to try to locate where the domain name gets this value
assigned to, comment it out and try that way. I don't have too much faith in
this kind of hacking, but it's better than just staring at the log anyway :).
Gabor
More information about the samba-technical
mailing list