[cifs-protocol] New case: SRX080910600015: [MS-ADA3]: 2.44 Elaborate on objectSid definition
Good morning Andrew. I have created the new case as noted in the Subject line. I expect you will be happy to know that we are initiating a strong recommendation that the objectSid definition in [MS-ADA3] be modified as shown below. Thank you for your persistence on this topic. I will keep you advised of progress! Change: 2.44 Attribute objectSid This attribute specifies a binary value that specifies the security identifier (SID) of the user. The SID is a unique value used to identify the user as a security principal. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. To: 2.44 Attribute objectSid This attribute specifies a variable-length byte array value that specifies the security identifier (SID) of the user. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. It also may be represented as a UTF-8 string that is a valid SDDL SID string beginning with "S-" (see [MS-DTYP] sections 2.4.2 and 2.5.1, and [MS-ADTS] 3.1.1.3.1.2.5). The SID is a unique value used to identify the user as a security principal. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
Good afternoon Mr. Simpkins. We have completed our investigations concerning your request for correction assistance regarding NTLM authentication using SPNEGO (in [MS-NLMP]), and have provided the document changes shown below. These changes will be available in a future document refresh. Please note that your other comments (shown in 'Remaining Issues' below are still under investigation. I will keep you updated as developments occur. == Original Comment: When NTLM authentication is negotiated over SPNEGO, Windows clients do not properly wrap the initial NTLM token inside a GSS-API InitialContextToken (described in RFC 2743 section 3.1). [MS-NLMP] Document Change: <#> Section 3.2.5.2: This behavior is present on Windows Vista, Windows Server 2003, Windows XP, and Windows 2000. For backward compatibility and historical reasons, the Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the Universal Receiver behavior. == Remaining Issues: [MS-SPNG] Inside the actual note <5> in Appendix A, it would be nice to also mention that the inner mechToken/responseToken always contains the standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2. Windows servers do not accept the "truncated" OID in the thisMech field. Another related point that should probably be documented is that Windows servers do not seem to accept well-formed GSS InitialContextTokens containing NTLMSSP. I have attached a trace of that, too (gss_ntlmssp.cap frame 7). (The server is the same Windows Server 2003 system as in the other traces.) Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Re: New case: SRX080910600015: [MS-ADA3]: 2.44 Elaborate on objectSid definition
On Wed, 2008-09-10 at 03:34 -0700, Bill Wesse wrote: > Good morning Andrew. I have created the new case as noted in the > Subject line. I expect you will be happy to know that we are > initiating a strong recommendation that the objectSid definition in > [MS-ADA3] be modified as shown below. Thank you for your persistence > on this topic. No worries. > I will keep you advised of progress! > > > Change: > > 2.44 Attribute objectSid > This attribute specifies a binary value that specifies the security > identifier (SID) of the user. The SID is a unique value used to > identify the user as a security principal. For more information on the > SID data type, refer to [MS-DTYP] section 2.4.2. SID usage is also > discussed in [MS-ADTS], in particular in section 3.1.1.1.3. > > To: > > 2.44 Attribute objectSid > This attribute specifies a variable-length byte array value that > specifies the security identifier (SID) of the user. For more > information on the SID data type, refer to [MS-DTYP] section 2.4.2. It > also may be represented as a UTF-8 string that is a valid SDDL SID > string beginning with "S-" (see [MS-DTYP] sections 2.4.2 and 2.5.1, > and [MS-ADTS] 3.1.1.3.1.2.5). The SID is a unique value used to > identify the user as a security principal. SID usage is also discussed > in [MS-ADTS], in particular in section 3.1.1.1.3. That looks good. Let me know how you go - I had understood from the call that we were at a stalemate, so I'm particularly glad to see this (potentially) moving forward. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: Subject: [cifs-protocol] CAR - NTCreateX options
Hello Tridge, I wanted to follow up with you to make sure that my last response resolved this issue. Please let me know as soon as you can. Thanks John From: John Dunning Sent: Friday, September 05, 2008 1:57 PM To: John Dunning; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Subject: [cifs-protocol] CAR - NTCreateX options Importance: High Hello Tridge, I have answers for two of your questions and I would like clarification for question number 1. Please let me know if the answers for questions 2 and 3 are satisfactory. Also would you please clarify what data you are using to support the behavior you are seeing in #1. Question 1: MS-SMB section 2.2.8 says that FILE_OPEN_BY_FILE_ID should return STATUS_NOT_SUPPORTED. We have found that win2008 returns STATUS_OK for this bit. Can you please tell us how this bit works? I analyzed the capture that you sent, raw-open. I do not see the behavior that you are describing. Frame 1091 is the frame which contains the client request Create with CreateOptions = 0x2000, FILE_OPEN_BY_FILE_ID. The following frame, 1092 is the server response. The NTStatus returned by the server in that frame is: 0xC0BB, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_ERROR, Code = (187) STATUS_NOT_SUPPORTED. These frames would support :MS-SMB section 2.2.8 which says that FILE_OPEN_BY_FILE_ID should return STATUS_NOT_SUPPORTED. Question 2: We similarly noticed that w2008 returns the NT_STATUS_OK for each of the following bits: 0x0001 0x0002 0x0004 0x0008 all of which are not documented in the current WSPP docs. Please clarify this behaviour, and if w2008 is not just ignoring these bits then please document what they mean. Question 3: Please also tell us what the differences are for handling these bits between the SMB and SMB2 protocols. We have noticed (for example) that the w2008 SMB2 server returns STATUS_NOT_SUPPORTED for bit 0x0010 in the create options, whereas the same server using the SMB protocol returns STATUS_OK, and the SMB2 documentation says it should return STATUS_INVALID_PARAMETER. For questions # 2 and # 3 the SMB document and the SMB2 document will be updated in a future release of these documents. The updates will be similar if not exactly as follows: MS-SMB: CreateOptions (4 bytes): The options to use if creating the file or directory. This field MUST be set to 0 or a combination of the following possible values. Unused bit fields SHOULD be set to 0 by the client when sending a request and SHOULD be ignored when received by the server.<49> Windows server implementations reserve all bits not specified in the following table<50>. WB Notes <49> Windows-based SMB servers force off the following options when receiving this request: o FILE_SYNCHRONOUS_IO_ALERT o FILE_SYNCHRONOUS_IO_NONALERT o FILE_CREATE_TREE_CONNECTION Windows-based SMB servers fail requests with the FILE_OPEN_BY_FILE_ID option set and return STATUS_NOT_SUPPORTED in the Status field of the SMB header in the server response. Windows-based SMB servers fail requests when both the FILE_DIRECTORY_FILE and FILE_NON_DIRECTORY_FILE options are set and return STATUS_NOT_SUPPORTED in the Status field of the SMB header in the server response. Windows-based SMB servers allow only a combination of the following options on a named pipe or a mailslot: o FILE_WRITE_THROUGH o FILE_SYNCHRONOUS_IO_ALERT o FILE_SYNCHRONOUS_IO_NONALERT <50>If any of the reserved bits are set, Windows server implementations return NT_STATUS_OK. Thanks John Dunning Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM Email: [EMAIL PROTECTED] Tele: (469)775-7008 We're hiring From: John Dunning Sent: Thursday, August 14, 2008 6:10 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Subject: [cifs-protocol] CAR - NTCreateX options Hello, I failed to indicate what this request is regarding. The request I am working on is for your question: "MS-SMB section 2.2.8 says that FILE_OPEN_BY_FILE_ID should return STATUS_NOT_SUPPORTED. We have found that win2008 returns STATUS_OK for this bit. Can you please tell us how this bit works? We similarly noticed that w2008 returns the NT_STATUS_OK for each of the following bits: 0x0001 0x0002 0x0004 0x0008 all of which are not documented in the current WSPP docs. Please clarify this behaviour, and if w2008 is not just ignoring these bits then please document what they mean. Please also tell us what the differences are for handling these bits between the SMB and SMB2 protocols. We have noticed (for example) that the w2008 SMB2 server returns STATUS_NOT_SUPPORTED for bit 0x0010 in the create options, whereas the same server using the SMB protocol returns STATUS_OK, and the SMB2 documentation says it should return STATUS_INVAL
[cifs-protocol] RE: What are the 'Service' levels in SamLogonEx?
Hi Andrew:
My name is Obaid Farooqi and I'll be helping you with case.
I looked at [MS-NRPC] and in section 2.2.1.4.16, all the levels are documented
with the situations in which they are used. Please provide specifics as to what
is missing from this info that you are looking for.
Also, are you asking about all the levels in the enum or only about
NetlogonServiceInformation and NetlogonServiceTransitiveInformation?
Regards,
Obaid Farooqi
Sr. SEE, DSC Protocol Team, Microsoft
-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2008 7:13 AM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: What are the 'Service' levels in SamLogonEx?
In MS-NRPC 3.5.4.4.1 NetrLogonSamLogonEx command uses 2.2.1.4.6 NETLOGON_LEVEL
typedef enum _NETLOGON_LOGON_INFO_CLASS{
NetlogonInteractiveInformation = 1,
NetlogonNetworkInformation = 2,
NetlogonServiceInformation = 3,
NetlogonGenericInformation = 4,
NetlogonInteractiveTransitiveInformation = 5,
NetlogonNetworkTransitiveInformation = 6,
NetlogonServiceTransitiveInformation = 7 } NETLOGON_LOGON_INFO_CLASS;
What I'm wondering is: What are the Service levels for? Neither MS-NRPC or
MS-APDS seems to define their use.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] Other types of Kerberos messages on SamLogon Generic
Andrew,
We still have problem with the test. The following is we did during our test.
Please give us some advice.
Here's the output:
[EMAIL PROTECTED] source]# bin/smbtorture -k yes --realm=test.net
//W2K3SRV.test.net/public RPC-PAC -UTESTDOM/[EMAIL PROTECTED]
Using seed 1221036728
Running PAC
Domain join failed - Connection to SAMR pipe of DC W2K3SRV.test.net failed:
Connection to DC W2K3SRV.test.net failed: NT_STATUS_INVALID_PARAMETER
Setup failed: torture/rpc/rpc.c:144: Failed to join as BDC
PAC took 0.194445 secs
This is my krb5.conf file:
[EMAIL PROTECTED] source]# cat /etc/krb5.conf
[libdefaults]
default_realm = TEST.NET
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
TEST.NET = {
kdc = W2K3SRV.test.net:88
admin_server = W2K3SRV.test.net:749
default_domain = test.net
}
[domain_realm]
.test.net = TEST.NET
test.net = TEST.NET
Note: A netstat -an does not show any processes listening on port 749 on the
W2K3SRV machine.
Also, as a reference, here are the steps I followed on the Linux side:
1. Pulled down the current Samba source tree using rsync
2. ./configure
3. make
4. make install
5. setup/provision --realm=test.net --domain=TESTDOM [EMAIL PROTECTED]
--server-role=dc
6. Copied /usr/local/samba/private/krb5.conf to /etc/
7. Edited /etc/krb5.conf to look as shown above.
Changed following entries:
dns_lookup_realm
dns_lookup_kdc
kdc
admin_server
8. Run smbtorture
Linux is configured to use W2K3SRV as its DNS server.
Thanks !
Hongwei
-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2008 8:37 PM
To: Hongwei Sun
Cc: Stefan (metze) Metzmacher; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Pfif] Other types of Kerberos messages on SamLogon Generic
On Tue, 2008-09-09 at 07:46 -0700, Hongwei Sun wrote:
> Metze,
>
>
>
> After we set time correctly, we got the following output. The error
> doesn't look like related to verify PAC message. Maybe we didn't go
> further enough. Any suggestion?
>
>
>
> Thanks!
>
>
>
> Hongwei
>
>
>
> --- After setting time
>
> [EMAIL PROTECTED] source]# bin/smbtorture //VM-W2K8.test.net/public RPC-PAC
> -UTESTDOM/[EMAIL PROTECTED]
Add -k yes --realm=test.net
> TEST verify FAILED! - torture/rpc/remote_pac.c:101: status was
> NT_STATUS_INVALID_PARAMETER, expected NT_STATUS_OK:
It failed to connect using kerberos (which was strictly required for this test)
because it did not find the KDC (or some other pre-requisite).
Also ensure your krb5.conf points the kerberos libs to your KDC with:
[libdefaults]
default_realm = S4.NAOMI.ABARTLET.NET
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: What are the 'Service' levels in SamLogonEx?
On Wed, 2008-09-10 at 14:20 -0700, Obaid Farooqi wrote: > Hi Andrew: > My name is Obaid Farooqi and I'll be helping you with case. > > I looked at [MS-NRPC] and in section 2.2.1.4.16, all the levels are > documented with the situations in which they are used. Please provide > specifics as to what is missing from this info that you are looking > for. I can't provide specifics, because what I'm missing is the general information. To restate the question: What I'm wondering is: What are the Service levels for? Neither MS-NRPC or MS-APDS seems to define their use. What is the role and purpose of these levels. Perhaps compare and contrast them with the other levels in this enum. > Also, are you asking about all the levels in the enum or only about > NetlogonServiceInformation and NetlogonServiceTransitiveInformation? I am enquiring about these levels. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] Other types of Kerberos messages on SamLogon Generic
On Wed, 2008-09-10 at 15:00 -0700, Hongwei Sun wrote: > Andrew, > > We still have problem with the test. The following is we did during our > test. Please give us some advice. Turn up the debug level (-d10 for example to the command line) and see what the underlying error is. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] What happened to SamLogon validation level 4?
Hi Andrew,
I'd like to provide you with both a confirmation on your finding and an answer
to your question:
1) Level #4 corresponds to NetlogonValidationGenericInfo and IS defined
in the _NETLOGON_VALIDATION_INFO_CLASS. In fact, it has the same behavior as
NetlogonValidationGenericInfo2 = 5.
We'll update our documentation accordingly in future releases.
2) With regards to the question about the restrictions in the
validationlevel for the different logonlevels:
These logonlevels:
NetlogonInteractiveInformation:
NetlogonInteractiveTransitiveInformation:
NetlogonNetworkInformation:
NetlogonNetworkTransitiveInformation:
NetlogonServiceInformation:
NetlogonServiceTransitiveInformation:
Accept these ValidationLevels
NetlogonValidationSamInfo:
NetlogonValidationSamInfo2:
NetlogonValidationSamInfo4:
AND NetlogonGenericInformation accepts:
NetlogonValidationGenericInfo:
NetlogonValidationGenericInfo2:
Please let me know if I can be of further assistance.
Thanks and regards,
Sebastian Canevari
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: [EMAIL PROTECTED]
We're hiring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett
Sent: Wednesday, August 27, 2008 6:10 AM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [cifs-protocol] What happened to SamLogon validation level 4?
In MS-NRPC 2.2.1.4.17 NETLOGON_VALIDATION_INFO_CLASS it states:
The NETLOGON_VALIDATION_INFO_CLASS enumeration selects the type of logon
information
block being used.
typedef enum _NETLOGON_VALIDATION_INFO_CLASS
{
NetlogonValidationUasInfo = 1,
NetlogonValidationSamInfo = 2,
NetlogonValidationSamInfo2 = 3,
NetlogonValidationGenericInfo2 = 5,
NetlogonValidationSamInfo4 = 6
} NETLOGON_VALIDATION_INFO_CLASS;
However, level 4 is missing. It appears however in the wireshark dissector
(and therefore in our IDL). What is the history here?
Also, what restrictions are there on choice of validation level for the
different logon levels available into a SamLogon* call?
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] FW: SAMBA4 Test suite interoperability testing in preparation for the upcoming event.
Andrew: As we discussed, you recommended that Stefan review the RPC issue below identified during initial test results from a few test scenarios.As noted by the test suite developer below, this required the test suite to bind w/o the UUID. -Original Message- From: Darryl Welch Sent: Monday, September 08, 2008 4:02 PM To: 'Andrew Bartlett' Cc: Will Gregg; Richard Guthrie; Nick Meier Subject: SAMBA4 Test suite interoperability testing in preparation for the upcoming event. Andrew: As we discussed, the LSAT,LSAD and SAMR Protocol Test suites are complete. Nick has been working the test suite developers to execute the test suite methods against SAMBA4. This is being done using virtual images so that an environment can be readily configured in the EEC lab for the event. One common Issue was identified across all these Protocol methods. This issue is with SAMBA4 Implementation at RPC Layer. The Issue is with Binding RPC Handle with UUID,Endpoint[Named Pipe] & Protosequence. Windows server has functionality to allow binding RPC Handle W/ and W/o UUID.But SAMBA4 does not appear to support binding w/ UUID. Primarily this UUID is optional for RPC Implementers' as per 1.1 section of DCE RPC and In case of SAMBA also I could able to Bind W/ and W/o UUID. The issue occurs when bound with UUID in subsequent Protocol calls at msrpc Layer UUID will be passed on the wire in each call and when this is UUID is present, then SAMBA4 fails all respective Protocol methods. The attached spreadsheet includes a list of the methods currently tested. Are you interested in a summary of requirements as well as network captures and logs? Thanks, Darryl. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
