[Samba] smbclient, kerberos, and EMC
Hi Everyone, I'm trying to get smbclient to cooperate with my new EMC Celerra (just got it a little while ago) using kerberos. My windows domain environment is win2000 + sp4, the EMC is joined to the domain. I am using samba 3.0, fresh sources, and MIT KRB5 1.3.4, all freshly built. I join the domain, etc. everything is happy. I use kinit [EMAIL PROTECTED] to get my initial tgt. then, i use smbclient //emc/share -k and I get this error: # ./smbclient //emc/share -k krb5_get_credentials failed for [EMAIL PROTECTED] (KDC reply did not match expectations) spnego_gen_negTokenTarg failed: KDC reply did not match expectations session setup failed: SUCCESS - 0 looking at an ethereal trace, I notice some funny things. first, the EMC returns the principal name in the NegProt response as [EMAIL PROTECTED] ... this is backwards, me thinks, as usually I have observed the principal (target host) in lowercase and the realm in all uppercase. You think this has anything to do with it? Looking at the TGS exchange, I see the realm(domain) in lowercase and the system name in upcase. The TGT-REP, however, has the Realm in the cleartext Ticket part in uppercase as well as the target system name. I have observed MIT KRB5 1.3.4 being a bit more picky about these things than earlier versions, and Micro$oft doesn't seem to give a hoot about case. Note, smbclient never actually tries to contact the EMC beyond the NegProt exchange. smbclient + kerberos (same binary as above) *is* happy going against my Windows2000 domain controller. In this situation, I notice the NetProt response has the server name in lowercase and the realmname in uppercase. Am I a victim of bad luck or is their an interop issue here? I know EMC's don't grow on trees, so it may be difficult to test this beast in the community. Any advice appreciated, I'm certainly willing to try things! all the best, Joey. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] Re: How to verify the domain secret is good or bad?
Gerald (Jerry) Carter wrote: [snip] Also, sometimes I saw problems like wbinfo -t just says secret is bad, when all the daemons were running. It sure was good at some point before. Samba periodially changes the password on the server. secrets.tdb should be in sync with this. Hi, Why does Samba do this? Does the secret expire after a certain period of time or is this done as a safety precaution? thanks, Joey. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: How to verify the domain secret is good or bad?
Gerald (Jerry) Carter wrote: [snip] Also, sometimes I saw problems like wbinfo -t just says secret is bad, when all the daemons were running. It sure was good at some point before. Samba periodially changes the password on the server. secrets.tdb should be in sync with this. Hi, Why does Samba do this? Does the secret expire after a certain period of time or is this done as a safety precaution? thanks, Joey.
SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
Good evening ladies and gents, The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO does not appear to be correct. Furthermore, Ethereal's interpretation does not seem right, either. Here's what SNIA says: TIME CreationTime; TIME LastAccessTime; TIME LastWriteTime; TIME ChangeTime; ULONG Attributes; // SNIA says USHORT; Ethereal says ULONG LARGE_INTEGER AllocationSize; LARGE_INTEGER EndOfFile; ULONG NumberOfLinks; UCHAR DeletePending; UCHAR Directory; LARGE_INTEGER IndexNumber; ULONG EaSize; ULONG AccessFlags; LARGE_INTEGER IndexNumber1; // mistake in SNIA spec? LARGE_INTEGER CurrentByteOffset; ULONG Mode; ULONG AlignmentRequirement; ULONG FileNameLength; STRING FileName[]; After poking around with a sniffer, here is what I think it looks like: TIMECreationTime; TIMELastAccessTime; TIMELastWriteTime; TIMEChangeTime; ULONG Attributes; ULONG Pad1; // assumed LARGE_INTEGER AllocationSize; LARGE_INTEGER EndOfFile; ULONG NumberOfLinks; UCHAR DeletePending; UCHAR Directory; USHORT Pad2; // assumed ULONG EaSize; ULONG FileNameLength; STRING FileName[]; This is simply the concatenation of Basic Info, Standard Info (plus padding, Pad2, which is not in the SNIA spec), EA Info, and File Name Info. There is no sign of the rest of the information (internal file system index numbers, open-file information) being present. In my test I used a Win 2000 client, a Win 2000 server, and used SMB_COM_QUERY_FILE_INFORMATION (by fid, not by path). My questions: 1) Can anyone else confirm my interpretation? 2) Are there server-dependent variations on the format? thanks all for your time and best regards, Joey.
NTLMv2 Response (Only) yields Unicode password length of 78
Good evening folks, I have a WIN2K system and I am failing to authenticate to a Samba 2.2 installation, which I suspect is due to the weird length of Unicode password length in the SessionSetupAndX message. Here is my circumstance. On my W2K machine: -Run the secpol.msc management plug-in thingie. -Click Local Policies -Click Security Options -In the right pain, look for LAN Manager Authentication Level -Double click on this. -In the pull-down, set it to Send NTLMv2 response only -Commit that change. -Now, connect to the Samba machine. The ANSI password length in the SessionSetupAndX is 24, but in my case the Unicode Password Length is 78 (this is according to the latest greatest ethereal built from sources yesterday). When I change the setting in LAN Manager Authentication Level back to the default, I can connect to Samba 2.2 using the same creds. I tried this on a W2K - W2K setup (not active directory) and the same trace occurs, but this time, the Unicode password length was 66 (it was a different account/password)! Anyone else see this? Does anyone know how the binary response of 78 bytes is created? Lots of zeros, it does not appear to be ASN.1 Have a great night, Joey.
[Samba] Error in SNIA spec wrt. SessionSetupAndX response when dialect is NT LM0.12
Good evening, On the bottom of page 53, section 4.1.2.2 in the SNIA spec (http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf), it states if the dialect is NT LM 0.12 and extended security is off (I.e., use traditional NTLMv2/NTLMv2 authentication w/o SecurityBlobs), the SessionSetupAndX response is as shown in section 4.1.2.2 with a word count = 4. However, what I have noticed is this is not the case, but rather, if you are doing NTLMv2 or NTLMv1 authentication w/o extended security, the SessionSetupAndX is really the one shown in 4.1.2.1 with a word count = 3. I tried this a few times, using NT4.0 + SP 6a client against NT4.0 + SP 6a, and Win2k + SP 3 against the NT4.0 + SP 6a server and all resulted in the same SessionSetupAndX response--the one shown in section 4.1.2.1 with a wc = 3. Am I doing something funky to get this result or is this in fact an issue in the spec? thank you and enjoy the evening. Joey. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
