Nabble - Samba - cifs-protocol

Re: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

2009-12-09T12:31:28Z

Tim - I have verified that Windows 2000 through Windows 2008 R2 & Windows 7 all behave the same way - and return the invalid level DOSError 124. This is definitely by design, as is the omission of WordCount and ByteCount.

What [CIFS] and [MS-SMB] do not detail very well is how error codes are cooked before return.

It is true that the request header.Flags2 field has SMB_FLAGS2_NT_STATUS set - which one would expect to force an NT Status return code. There are cases where this is not going to occur - Trans2SetPathInfo() with an invalid level being one of them.

There are many #defined for constants and macros in cifs.h (from the Windows Driver Kit [WDK-7]) noted in the below description - and I have included the relevant ones below.

Before I can go further with a more global description of SMB error code 'cooking', I will file a TDI to request that.

For the moment, here is what's up with Trans2SetPathInfo():

In this case - an SMB_COM_TRANSACTION2 (and I think as a consequence of the history of SMB) requesting TRANS2_SET_PATH_INFORMATION (0x06) with an invalid level per [CIFS], such as SMB_SET_FILE_END_OF_FILE_INFO (0x104) - our implementation sets the internal SMB Status to STATUS_OS2_INVALID_LEVEL (cifs.h), which is '0xC098F07C'.

This is processed as follows before appearing on the wire:

If the SrvIsSrvStatus(Status) check passes (which it should, in this case, per the included #defines from cifs.h), the error code is truncated using the SrvErrorClass(Status) macro (also from cifs.h), and the error class is set to SMB_ERR_CLASS_DOS (0x1). The SMB_FLAGS2_NT_STATUS bit is cleared in the response header.Flags2 field, and the return context is marked to omit WordCount and ByteCount.

The error equates to '01 00 7C 00' :

DOSError.ErrorClass (0x0001, 1d) : SMB_ERR_CLASS_DOS
DOSError.Error (0x007C, 124d) : SrvErrorCode(STATUS_OS2_INVALID_LEVEL)

[CIFS]
A Common Internet File System (CIFS/1.0) Protocol Preliminary Draft
http://www.microsoft.com/about/legal/protocols/BSTD/CIFS/draft-leach-cifs-v1-spec-02.txt

[WDK-7]
Windows Driver Kit Version 7.0.0
http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00&displaylang=en

[WDKI MSDN]
Windows Driver Kit
http://msdn.microsoft.com/en-us/library/aa972908.aspx

==============================================================================
winerror.h

#define ERROR_INVALID_LEVEL 124L

==============================================================================
cifs.h

#define SrvIsSrvStatus(Status) \
( ((Status) & 0x1FFF0000) == SRV_STATUS_FACILITY_CODE ? TRUE : FALSE )

#define SrvErrorClass(Status) ((UCHAR)( ((Status) & 0x0000F000) >> 12 ))

#define STATUS_OS2_INVALID_LEVEL (NTSTATUS)(SRV_OS2_STATUS | ERROR_INVALID_LEVEL)

#define SrvErrorCode(Status) ((USHORT)( (Status) & 0xFFF) )

#define SMB_ERR_CLASS_DOS (UCHAR)0x01

#define SRV_STATUS_FACILITY_CODE 0x00980000L
#define SRV_SRV_STATUS (0xC0000000L | SRV_STATUS_FACILITY_CODE)
#define SRV_DOS_STATUS (0xC0001000L | SRV_STATUS_FACILITY_CODE)
#define SRV_SERVER_STATUS (0xC0002000L | SRV_STATUS_FACILITY_CODE)
#define SRV_HARDWARE_STATUS (0xC0003000L | SRV_STATUS_FACILITY_CODE)
#define SRV_WIN32_STATUS (0xC000E000L | SRV_STATUS_FACILITY_CODE)
#define SRV_OS2_STATUS (0xC000F000L | SRV_STATUS_FACILITY_CODE)

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Tim Prouty [mailto:tim.prouty@...]
Sent: Wednesday, December 09, 2009 12:24 PM
To: Bill Wesse
Cc: Jeremy Allison; cifs-protocol@...; pfif@...
Subject: Re: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

Thank you Bill. I'm looking forward to hearing the results of your
investigation.

-Tim

On Dec 9, 2009, at 9:13 AM, Bill Wesse wrote:

> Hello Tim - I have created case SRX091209600095 to track this issue.
> My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will
> be testing against Windows 7, Windows Vista, and Windows XP (and
> Windows 2000 if necessary) before proceeding with any product bug
> filings.
>
> Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz
>
> From trans2setpathinfo_against_win7_2.cap in the attached zip (using
> Network Monitor 3.4):
>
> Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET
> + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:
> [00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7]
> + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol =
> TCP, Packet ID = 42077, Total IP Length = 230
> + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445),
> PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566
> + SMBOverTCP: Length = 174
> - Smb: C; Transact2, Set Path Info, Set File EOF Info, Path =
> \testsfileinfo\test_sfileinfo_end_of_file.dat
> Protocol: SMB
> Command: Transact2 50(0x32)
> + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity =
> STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
> + SMBHeader: Command, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID:
> 0x0009
> - CTransaction2:
> WordCount: 15 (0xF)
> TotalParameterCount: 98 (0x62)
> TotalDataCount: 8 (0x8)
> MaxParameterCount: 2 (0x2)
> MaxDataCount: 0 (0x0)
> MaxSetupCount: 0 (0x0)
> Reserved: 0 (0x0)
> + Flags: Do NOT disconnect TID
> Timeout: 0 sec(s)
> Reserved2: 0 (0x0)
> ParameterCount: 98 (0x62)
> ParameterOffset: 68 (0x44)
> DataCount: 8 (0x8)
> DataOffset: 166 (0xA6)
> SetupCount: 1 (0x1)
> Reserved3: 0 (0x0)
> SubCommand: Set Path Info, 6(0x0006)
> ByteCount: 109 (0x6D)
> Pad1: Binary Large Object (3 Bytes)
> - SetPathInfoParameterBlock:
> InformationLevel: Set File EOF Info
> padding: 0 (0x0)
> + PathName: \testsfileinfo\test_sfileinfo_end_of_file.dat
> + EndOfFile: 200
>
> Frame: Number = 40, Captured Frame Length = 102, MediaType = ETHERNET
> + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:
> [00-0C-29-3F-D2-D7],SourceAddress:[00-0C-29-84-0A-41]
> + Ipv4: Src = 10.54.159.10, Dest = 10.54.159.14, Next Protocol =
> TCP, Packet ID = 14043, Total IP Length = 88
> + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=58261,
> PayloadLen=36, Seq=108947765 - 108947801, Ack=2212563008, Win=260
> + SMBOverTCP: Length = 32
> - Smb: R - DOS OS Error, (124) INVALID_LEVEL
> Protocol: SMB
> Command: Transact2 50(0x32)
> + DOSError: DOS OS Error - (124) INVALID_LEVEL
> - SMBHeader: Response, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID:
> 0x0009
> + Flags: 136 (0x88)
> + Flags2: 34819 (0x8803)
> PIDHigh: 0 (0x0)
> SecuritySignature: 0x0
> Unused: 0 (0x0)
> TreeID: 2048 (0x800)
> ProcessID: 22837 (0x5935)
> UserID: 2048 (0x800)
> MultiplexID: 9 (0x9)
>
>
>
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior 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
>
> <Captures.zip.bin>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: Conflicting OIDs

2009-12-09T09:34:59Z

Andrew,

I am taking care of this and will be updating you as soon as I have news.

Best regards,

Edgar

-----Original Message-----
From: Bill Wesse
Sent: Wednesday, December 09, 2009 7:51 AM
To: Andrew Bartlett; Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...; Endi Sukma Dewata
Subject: RE: Conflicting OIDs

Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly.

SRX091209600017 : [MS-ADA3] Conflicting OIDs

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, December 08, 2009 8:44 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...; Endi Sukma Dewata
Subject: Conflicting OIDs

MS-ADA3 2.305 Attribute thumbnailLogo has:

cn: Logo
ldapDisplayName: thumbnailLogo
attributeId: 2.16.840.1.113730.3.1.36

However, this OID is allocated, according to http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to Netscape (now Red Hat), and is used for nsLicensedFor.

It appears the official OID for thumbnailLogo is
1.3.6.1.4.1.1466.101.120.36 according to

http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00

So far, we have found the following OIDs that are allocated to different names between Microsoft's AD implementation and the official
allocations:

#MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
#defaultGroup has a conflicting OID
1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
#thumbnailPhoto has a conflicting OID
2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10
#thumbnailLogo has a conflicting OID
2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11

What I want to know is: What is the full list of OIDs that Microsoft uses in Active Directory that have conflicting allocations between AD and either the OID allocation hierarchy or common practice?

This will assist us as we aim for interoperability, as for each conflict, we must manually remap.

In the long term, we would like to see the AD schema documents annotated with this conflict (both as as summary table and on each attribute), and a process put in place to avoid these kinds of problems in future.

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

2009-12-09T09:24:10Z

Thank you Bill. I'm looking forward to hearing the results of your
investigation.

-Tim

On Dec 9, 2009, at 9:13 AM, Bill Wesse wrote:

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

2009-12-09T09:13:32Z

Hello Tim - I have created case SRX091209600095 to track this issue. My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will be testing against Windows 7, Windows Vista, and Windows XP (and Windows 2000 if necessary) before proceeding with any product bug filings.

Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz

From trans2setpathinfo_against_win7_2.cap in the attached zip (using Network Monitor 3.4):

Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7]
+ Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = TCP, Packet ID = 42077, Total IP Length = 230
+ Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566
+ SMBOverTCP: Length = 174
- Smb: C; Transact2, Set Path Info, Set File EOF Info, Path = \testsfileinfo\test_sfileinfo_end_of_file.dat
Protocol: SMB
Command: Transact2 50(0x32)
+ NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
+ SMBHeader: Command, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009
- CTransaction2:
WordCount: 15 (0xF)
TotalParameterCount: 98 (0x62)
TotalDataCount: 8 (0x8)
MaxParameterCount: 2 (0x2)
MaxDataCount: 0 (0x0)
MaxSetupCount: 0 (0x0)
Reserved: 0 (0x0)
+ Flags: Do NOT disconnect TID
Timeout: 0 sec(s)
Reserved2: 0 (0x0)
ParameterCount: 98 (0x62)
ParameterOffset: 68 (0x44)
DataCount: 8 (0x8)
DataOffset: 166 (0xA6)
SetupCount: 1 (0x1)
Reserved3: 0 (0x0)
SubCommand: Set Path Info, 6(0x0006)
ByteCount: 109 (0x6D)
Pad1: Binary Large Object (3 Bytes)
- SetPathInfoParameterBlock:
InformationLevel: Set File EOF Info
padding: 0 (0x0)
+ PathName: \testsfileinfo\test_sfileinfo_end_of_file.dat
+ EndOfFile: 200

Frame: Number = 40, Captured Frame Length = 102, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-3F-D2-D7],SourceAddress:[00-0C-29-84-0A-41]
+ Ipv4: Src = 10.54.159.10, Dest = 10.54.159.14, Next Protocol = TCP, Packet ID = 14043, Total IP Length = 88
+ Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=58261, PayloadLen=36, Seq=108947765 - 108947801, Ack=2212563008, Win=260
+ SMBOverTCP: Length = 32
- Smb: R - DOS OS Error, (124) INVALID_LEVEL
Protocol: SMB
Command: Transact2 50(0x32)
+ DOSError: DOS OS Error - (124) INVALID_LEVEL
- SMBHeader: Response, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009
+ Flags: 136 (0x88)
+ Flags2: 34819 (0x8803)
PIDHigh: 0 (0x0)
SecuritySignature: 0x0
Unused: 0 (0x0)
TreeID: 2048 (0x800)
ProcessID: 22837 (0x5935)
UserID: 2048 (0x800)
MultiplexID: 9 (0x9)

Regards,
Bill Wesse
MCSE, MCTS / Senior 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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Captures.zip.bin (39K) Download Attachment

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-09T07:56:24Z

Tim, - thanks for the updated smbtorture. I have reproduced the truncated SMB error response - see frames 132 & 133 in the attached capture. I will create a new case for this, and begin debugging today (after verifying whether or not this happens against older Windows versions).

Frame: Number = 133, Captured Frame Length = 102, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress:[00-15-5D-04-7B-09]
+ Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP, Packet ID = 1552, Total IP Length = 88
+ Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152, PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510 (scale factor 0x8) = 130560
+ SMBOverTCP: Length = 32
- Smb: R - DOS OS Error, (124) INVALID_LEVEL
Protocol: SMB
Command: Transact2 50(0x32)
+ DOSError: DOS OS Error - (124) INVALID_LEVEL
- SMBHeader: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID: 0x0008
+ Flags: 136 (0x88)
+ Flags2: 34819 (0x8803)
PIDHigh: 0 (0x0)
SecuritySignature: 0x0
Unused: 0 (0x0)
TreeID: 2048 (0x800)
ProcessID: 30665 (0x77C9)
UserID: 2048 (0x800)
MultiplexID: 8 (0x8)

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Tim Prouty [mailto:tim.prouty@...]
Sent: Tuesday, December 08, 2009 12:55 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

Thank you for your diligence on this Bill and the answers you have
provided. I have some responses inline below.

On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote:

> Is #3 actually correct behavior that other servers should implement?
> If so, can the cases where share modes are not enforced be enumerated
> in the documentation?
>
> Response:
>
> #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
> SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH +
> FileEndOfFileInformation is
> functionally equivalent to a remote call to NtSetInformationFile.
>
> NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the
> file
> system driver in question; this does not involve the usual I/O Manager
> ShareMode checks.

I share the same sentiment as Zach on this behavior, but it is
definitely useful to know how windows handles this. Are there plans
for this to be documented anywhere or does it receive documentation
exemption since this is passthrough-speceific?

> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> Question:
>
> If a client can send a particular info level and windows implements
> it, then we have a compatibility problem if we choose not to support
> it. What I would really like to know is if other SMB implementations
> need to circumvent share-mode checks for this pass through level (and
> maybe others?).
>
> Response:
>
> This should be the case for all supported SMB_INFO_PASSTHROUGH
> levels, as they
> run through the same essential logic.
>
> However, I have additional testing to perform before I can
> completely confirm
> this.

I am interested to know the results of your testing. I believe there
are some tests in RAW-OPLOCKS that use the rename passthrough level to
test oplocks, but implicitly rely on share modes not being enforced
for the rename passthrough. RAW-OPLOCK-BATCH19, 20 and 21 are good
ones to look at.

> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> Question:
>
> 1. Packet 40 appears to have the WordCount and ByteCount truncated,
> making the packet smaller than normal minimum size of 35? Is this
> intended behavior that other servers should implement?
>
> Additionally a DOS Error is returned instead of a standard NT_STATUS
> error. MS-CIFS does say that a DOS error or an NT_STATUS error may be
> returned, but I don't see any indication in the documentation of when
> a DOS error should be returned instead of an NT_STATUS error. Is it
> possible to make this explicit in the docs or is this a case where
> it's purposefully left ambiguous?
>
> Response:
>
> The WordCount/ByteCount truncation against the Dos INVALID_LEVEL
> error problem
> (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce
> with my
> clients (who succeeded against the call).
>
> I have attached a zip file with your trace
> (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace
> (test_trans2setpathinfo_Win7.pcap). Mine does not have that second
> Set EOF call. Do I need a newer build of smbtorture (my current one
> from you is samba.2009.12.01.tar.gz)?

In comparing the pcaps, it does indeed appear that the version of
smbtorture you're running doesn't include the most recent version of
RAW-SFILEIFNO-END-OF-FILE. Packet 54 in your trace corresponds to
packet 33 in my trace which is sending the SNIA CIFS EOF level rather
than the passthrough. Packet 39 in my trace is the setpathinfo EOF
passthrough level that is actually getting the strange error, and
there is no corresponding packet in your trace.

I'll get you the most recent code drop in a private channel.

-Tim

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

my_trans2setpathinfo_R2.pcap (46K) Download Attachment

Re: Conflicting OIDs

2009-12-09T05:51:25Z

Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly.

SRX091209600017 : [MS-ADA3] Conflicting OIDs

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, December 08, 2009 8:44 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...; Endi Sukma Dewata
Subject: Conflicting OIDs

MS-ADA3 2.305 Attribute thumbnailLogo has:

cn: Logo
ldapDisplayName: thumbnailLogo
attributeId: 2.16.840.1.113730.3.1.36

However, this OID is allocated, according to http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to Netscape (now Red Hat), and is used for nsLicensedFor.

It appears the official OID for thumbnailLogo is
1.3.6.1.4.1.1466.101.120.36 according to

http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00

So far, we have found the following OIDs that are allocated to different names between Microsoft's AD implementation and the official
allocations:

#MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
#defaultGroup has a conflicting OID
1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
#thumbnailPhoto has a conflicting OID
2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10
#thumbnailLogo has a conflicting OID
2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11

What I want to know is: What is the full list of OIDs that Microsoft uses in Active Directory that have conflicting allocations between AD and either the OID allocation hierarchy or common practice?

This will assist us as we aim for interoperability, as for each conflict, we must manually remap.

In the long term, we would like to see the AD schema documents annotated with this conflict (both as as summary table and on each attribute), and a process put in place to avoid these kinds of problems in future.

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Conflicting OIDs

2009-12-08T17:44:09Z

MS-ADA3 2.305 Attribute thumbnailLogo has:

cn: Logo
ldapDisplayName: thumbnailLogo
attributeId: 2.16.840.1.113730.3.1.36

However, this OID is allocated, according to
http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to
Netscape (now Red Hat), and is used for nsLicensedFor.

It appears the official OID for thumbnailLogo is
1.3.6.1.4.1.1466.101.120.36 according to

http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00

So far, we have found the following OIDs that are allocated to different
names between Microsoft's AD implementation and the official
allocations:

#MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
#defaultGroup has a conflicting OID
1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
#thumbnailPhoto has a conflicting OID
2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10
#thumbnailLogo has a conflicting OID
2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11

What I want to know is: What is the full list of OIDs that Microsoft
uses in Active Directory that have conflicting allocations between AD
and either the OID allocation hierarchy or common practice?

This will assist us as we aim for interoperability, as for each
conflict, we must manually remap.

In the long term, we would like to see the AD schema documents annotated
with this conflict (both as as summary table and on each attribute), and
a process put in place to avoid these kinds of problems in future.

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

signature.asc (196 bytes) Download Attachment

Re: SMBv1 LockAndX return status on lock conflict

2009-12-08T12:07:33Z

Steven,

LockViolationDelayOffset is the file offset beyond which locks are always issued as delayed locks. Default value is 0xEF000000. Please let us know if you have any more questions.

Thanks!

Hongwei

From: Steven Danneman [mailto:steven.danneman@...]
Sent: Monday, December 07, 2009 9:03 PM
To: Hongwei Sun; cifs-protocol@...; pfif@...
Subject: RE: SMBv1 LockAndX return status on lock conflict

Hey Hongwei,

That’s very interesting and indeed explains the behavior I’ve seen.

I can understand the motivation for delaying a small timeout for locks that the server knows are already held. However, the “Offset >= LockViolationDelayOffset” is strange to me. I don’t understand the usefulness of that condition.

Perhaps this is an Office specific feature, since Office applications take small byte range locks past the end of file range as a primitive IPC mechanism.

Can you tell me what the value of LockViolationDelayOffset is? The smbtorture testing seems to indicate it is Offset > 0xEF000000.

Thanks for your help. I certainly wouldn’t have figured these semantics out on my own.

-Steven

From: Hongwei Sun [mailto:hongweis@...]
Sent: Monday, December 07, 2009 4:03 PM
To: Steven Danneman; cifs-protocol@...; pfif@...
Subject: RE: SMBv1 LockAndX return status on lock conflict

Hi, Steven,

For the error returned when a byte range lock conflicts with an existing lock in SMB, the logic is as follows: If a lock request is above a configured offset, or if a lock request matches a previously failed lock offset, it will change it from “fail immediately” with timeout of 0 to timeout of 250 ms on operation issue. The result is that the lock will be pending for 250ms waiting for lock availability, and if it does not retrieve it, it returns a different error (STATUS_FILE_LOCK_CONFLICT).

Pseudo code of above logic should be something as below:

If (FailImmediately) // Timeout = 0

If Offset == Open.LastFailedLockOffset OR Offset >= LockViolationDelayOffset

Set Timeout = LockViolationDelay // within 250 milliseconds

End If

If Timeout = 0 and Lock Not Acquired

Set LockViolationDelayOffset = (Offset of lock attempt)

return STATUS_LOCK_NOT_GRANTED

Else If Timeout > 0 and Lock Not Acquired after Timeout

return STATUS_FILE_LOCK_CONFLICT

Else

return STATUS_SUCCESS

End If.

With the logic above, you can easily explain what shows in your network trace. We will add the logic to the SMB protocol document. Please let us know if you have further questions regarding this behavior.

Thanks!

--------------------------------------------------------------------

Hongwei Sun - Sr. Support Escalation Engineer

DSC Protocol Team, Microsoft

hongweis@...

Tel: 469-7757027 x 57027

---------------------------------------------------------------------

From: Steven Danneman [mailto:steven.danneman@...]
Sent: Wednesday, November 25, 2009 5:54 PM
To: Interoperability Documentation Help; cifs-protocol@...; pfif@...
Subject: SMBv1 LockAndX return status on lock conflict

Hello,

When requesting a byte-range lock over SMBv1 on a range of a file which is already locked and thus will contend, the error code returned is inconsistent. The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED. Subsequent requests will return STATUS_FILE_LOCK_CONFLICT.

This seems as though it may be an error in the implementation of the SMBv1 protocol as the explanation of the two errors in MS-ERREF implies that STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance:

STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock.

And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED.

I aware this is a well known issue, as the Samba torture test demonstrating this behavior have existed for a number of years, but I haven’t found any Microsoft documentation describing the semantics of this behavior. I’ve looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA.

Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows:

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 – 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be “reset” back to STATUS_LOCK_NOT_GRANTED

I’d like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-08T09:54:35Z

Thank you for your diligence on this Bill and the answers you have
provided. I have some responses inline below.

On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote:

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-08T07:57:17Z

I agree - truncating a file beneath an unshared open is not a good thing to happen.

At this point, my goal is to document how the server works - and I am working on code to exercise the other information classes against SMB_INFO_PASSTHROUGH (one would hope, of course, that FileRenameInformation is rejected). Given the complexity of the SMB code, I will assume nothing.

Once done, I will raise the issue internally as appropriate.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Zachary Loafman [mailto:zachary.loafman@...]
Sent: Tuesday, December 08, 2009 9:27 AM
To: Bill Wesse; Tim Prouty
Cc: pfif@...; cifs-protocol@...
Subject: RE: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

> -----Original Message-----
> From: cifs-protocol-bounces@... [mailto:cifs-protocol-
> bounces@...] On Behalf Of Bill Wesse
> Sent: Tuesday, December 08, 2009 6:08 AM
> To: Tim Prouty
> Cc: pfif@...; cifs-protocol@...
> Subject: Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo()
> FileEndOfFileInformation is not enforcing share modes
>
> 3. Client 2 does a Trans2SetPathInfo() with the undocumented
> pass-through level that also allows setting the
> FileEndOfFileInformation (1020 / 0x3FC). The client specifies that
> it wants to extend the file size to 100. Interestingly, win7 and
> winXP will return NT_STATUS_SUCCESS and successfully extend the
> length of the file. This operation seems to be circumventing the
> share mode enforcement.

[...]
> #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
> SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH +
> FileEndOfFileInformation is
> functionally equivalent to a remote call to NtSetInformationFile.

Thanks for the information on what a Windows server does. You should
consider revisiting this decision, though, as it's a fairly serious data
integrity issue. It's not just the file extension case that you need to
consider - you're saying the client can *truncate* all of the data of
the file without any share mode lock enforcement.

...Zach

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: How to get the expanded group memberships for a user

2009-12-08T07:20:39Z

Metze,

Thank you for your inquiry. Please find below the answers for your questions.

1) When calling DRSGetMemberships to get the user’s group memberships, DRSGetMemberships is not proxied by the DC of COMPUTER-DOM to a DC of USERS-DOM in the cross-forest trust scenario you described.

2) It is by design that the DRSGetMemberships reverse membership derivation only occurs for an object that is local to the DC of COMPUTER-DOM (unlike LookupNames that would be proxied by the DC of COMPUTER-DOM to a DC of USERS-DOM).

3) This explains why you were able to use DRSGetMemberships and lookup memberships for the SID of COMPUTER-DOM\Administrator.

Let us know whether you have further questions on this topic.

Best regards,
Edgar

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Thursday, November 12, 2009 7:47 AM
To: Interoperability Documentation Help; cifs-protocol@...; pfif@...
Subject: How to get the expanded group memberships for a user

Hi,

I'm trying to solve the following problem:

COMPUTERS-DOM has an outgoing forest trust to USERS-DOM.

Samba as a member server in COMPUTERS-DOM want to get fully expanded group memberships of user USERS-DOM\Administrator without knowing the password of USERS-DOM\Administrator.
(The best would be to get the whole PAC structure, which we're getting if the user is authenticated via KRB5 of netr_LogonSamLogon).

With a 2-way forest trust that's no problem.
Samba can ask a DC of COMPUTER-DOM via LookupNames about the SID of USERS-DOM\Administrator.
Then Samba can use it's machine account and ask a DC of USERS-DOM via LDAP about the tokenGroups of the user (That's how Samba currently work).
The second way would be to use S4U2Self to get the PAC via a Krb5 Ticket.

But with a one-way trust only the LookupNames works, as the DC of COMPUTER-DOM will proxy the request to a DC of USERS-DOM using the trust account.

But Samba can't directly talk to a DC of USERS-DOM using it's machine account. So both LDAP and S4U2Self won't work.

I just found that DRSGetMemberships can also get the users groups. I hoped that it would behave like LookupNames and would be proxied by the DC of COMPUTER-DOM to a DC of USERS-DOM. But I'm unable to trigger this.
Is that by design or am I doing something wrong (DRSGetMemberships works fine for the SID of COMPUTER-DOM\Administrator)?

Is there any other way to solve this Problem?

metze

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-08T06:27:16Z

[...]
> #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
> SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH +
> FileEndOfFileInformation is
> functionally equivalent to a remote call to NtSetInformationFile.

Thanks for the information on what a Windows server does. You should
consider revisiting this decision, though, as it's a fairly serious data
integrity issue. It's not just the file extension case that you need to
consider - you're saying the client can *truncate* all of the data of
the file without any share mode lock enforcement.

...Zach
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-08T06:07:55Z

Good morning Tim - here is a summary of my progress to-date concerning your questions.

==============================================================================
Question:

The specific case I'm interested in is the following:

1. Client1 does a CreateFileAndX() on a non-existant file with a share
mode of 0 and holds the file open.

2. Client 2 does a Trans2SetPathInfo() with the level set to
FileEndOfFileInformation (0x104) as documented in the SNIA CIFS
spec. As expected NT_STATUS_SHARING_VIOLATION is returned here.

3. Client 2 does a Trans2SetPathInfo() with the undocumented
pass-through level that also allows setting the
FileEndOfFileInformation (1020 / 0x3FC). The client specifies that
it wants to extend the file size to 100. Interestingly, win7 and
winXP will return NT_STATUS_SUCCESS and successfully extend the
length of the file. This operation seems to be circumventing the
share mode enforcement.

Is #3 actually correct behavior that other servers should implement?
If so, can the cases where share modes are not enforced be enumerated
in the documentation?

Response:

#3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation is
functionally equivalent to a remote call to NtSetInformationFile.

NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the file
system driver in question; this does not involve the usual I/O Manager
ShareMode checks.

==============================================================================
Question:

If a client can send a particular info level and windows implements
it, then we have a compatibility problem if we choose not to support
it. What I would really like to know is if other SMB implementations
need to circumvent share-mode checks for this pass through level (and
maybe others?).

Response:

This should be the case for all supported SMB_INFO_PASSTHROUGH levels, as they
run through the same essential logic.

However, I have additional testing to perform before I can completely confirm
this.

==============================================================================
Question:

I have done some more investigation on this issue, particularly around
doing a Trans2SetPathInfo() with the documented
FileEndOfFileInformation (0x104) level. It returns what I would
expect to be an acceptable error for an unknown info level. I have
attached a trace that shows this being done against a win7 server, but
I have a question about what the server is returning. The packets of
interest are 39/40:

1. Packet 40 appears to have the WordCount and ByteCount truncated,
making the packet smaller than normal minimum size of 35? Is this
intended behavior that other servers should implement?

Additionally a DOS Error is returned instead of a standard NT_STATUS
error. MS-CIFS does say that a DOS error or an NT_STATUS error may be
returned, but I don't see any indication in the documentation of when
a DOS error should be returned instead of an NT_STATUS error. Is it
possible to make this explicit in the docs or is this a case where
it's purposefully left ambiguous?

Response:

The WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem
(trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my
clients (who succeeded against the call).

I have attached a zip file with your trace (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace (test_trans2setpathinfo_Win7.pcap). Mine does not have that second Set EOF call. Do I need a newer build of smbtorture (my current one from you is samba.2009.12.01.tar.gz)?

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Friday, December 04, 2009 12:45 PM
To: 'Tim Prouty'
Cc: pfif@...; cifs-protocol@...
Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

Thanks for the update - my Win7 client is also Ultimate, with no updates.

On another note, I just finished an initial debug on srv.sys; I have considerable analysis to do on the results, specifically tracking down the handles (just to make sure - even though there are no handle failures in either standard or SMB_INFO_PASSTHROUGH FileEndOfFileInformation information level for TRANS2_SET_PATH_INFORMATION).

There are additional functional checks on the information level, when less than SMB_INFO_PASSTHROUGH, which I still need to run down in the documentation.

I doubt I will be able to finish my work today, and do expect to be able to provide some reasonable information early next week.

Of course, this is all about what is supposed to be allowed when a client requests a 'native Windows NT operating system information level' ([MS-SMB] Appendix A note <158>: http://msdn.microsoft.com/en-us/library/cc246806(PROT.13).aspx).

I have thus far not been able to find any specific commentary on this in the WDK documentation (but then, I am not a driver expert).

Thanks for your patience!

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Tim Prouty [mailto:tim.prouty@...]
Sent: Friday, December 04, 2009 12:20 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote:

> I have retested without SmbSecuritySignatures - results were the same.
>
> I will hold off on the WordCount/ByteCount truncation against the
> Dos INVALID_LEVEL error problem
> (trans2setpathinfo_against_win7_2.pcap) for the time being, and work
> on the sharing issue (I expect to be soaking in code for the next
> day or so).

My win7 is a fresh ultimate install with no updates. I'm going to run
windows update to see if I can reproduce it. I'll let you know what I
find out.

-Tim

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Win7Traces.zip.bin (14K) Download Attachment

Re: What elements of the DIT are required for AD to operate? (SRX091208600025)

2009-12-08T05:28:34Z

Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly.

SRX091208600025 : [MS-ADTS] required DIT elements for Active Directory forest

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, December 08, 2009 12:16 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
Subject: What elements of the DIT are required for AD to operate?

G'day,

In the last few months, we have had great success with joining a Window
2008 R2 server into a Samba4 hosted domain. It was a great achievement, and the speed of development we achieved over this difficult area is a testament to the support we received at the plugfest. However, that success was only possible when we have first joined Samba4 to an already operational Active Directory domain, and obtained the full database over DRS replication.

Samba aims for and requires a high standard of interoperability - a standard of 'either Samba or Windows must be able provision/initialise the domain, without clients or other domain controllers seeing the difference'.

However, during the development last week we also found out (by painful experience and in discussion with your developers) that Windows performs very few checks on the incoming replicated data, and is not tolerant of deviations from the expected form. So, to achieve this interoperability, we need to know precisely what things a windows domain controller needs across the directory replication channel, for it to become and operate correctly as a domain controller.

Put another way: what are the required DIT elements for a server to provision to be the initiator of an Active Directory forest?

We do already have many of these elements implemented - things like the Display Specifiers and Schema we were very glad to obtain earlier - but it seem there is much more required. Much of this is in the documentation set - particularly MS-ADTS, but scattered in a way that makes for a great reference, but a poor source for implementation (because it is so easy to miss one).

My hope is that like the schema and display specifiers, that this information (effectively the minimum initial DIT) can also be made available to us in a similar, machine-readable fashion, for each supported functional level.

Thanks,

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

What elements of the DIT are required for AD to operate?

2009-12-07T21:15:55Z

G'day,

In the last few months, we have had great success with joining a Window
2008 R2 server into a Samba4 hosted domain. It was a great achievement,
and the speed of development we achieved over this difficult area is a
testament to the support we received at the plugfest. However, that
success was only possible when we have first joined Samba4 to an already
operational Active Directory domain, and obtained the full database over
DRS replication.

Samba aims for and requires a high standard of interoperability - a
standard of 'either Samba or Windows must be able provision/initialise
the domain, without clients or other domain controllers seeing the
difference'.

However, during the development last week we also found out (by painful
experience and in discussion with your developers) that Windows performs
very few checks on the incoming replicated data, and is not tolerant of
deviations from the expected form. So, to achieve this
interoperability, we need to know precisely what things a windows domain
controller needs across the directory replication channel, for it to
become and operate correctly as a domain controller.

Put another way: what are the required DIT elements for a server to
provision to be the initiator of an Active Directory forest?

We do already have many of these elements implemented - things like the
Display Specifiers and Schema we were very glad to obtain earlier - but
it seem there is much more required. Much of this is in the
documentation set - particularly MS-ADTS, but scattered in a way that
makes for a great reference, but a poor source for implementation
(because it is so easy to miss one).

My hope is that like the schema and display specifiers, that this
information (effectively the minimum initial DIT) can also be made
available to us in a similar, machine-readable fashion, for each
supported functional level.

Thanks,

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

signature.asc (196 bytes) Download Attachment

Re: SMBv1 LockAndX return status on lock conflict

2009-12-07T19:01:56Z

Hey Hongwei,

That’s very interesting and indeed explains the behavior I’ve seen.

Perhaps this is an Office specific feature, since Office applications take small byte range locks past the end of file range as a primitive IPC mechanism.

Can you tell me what the value of LockViolationDelayOffset is? The smbtorture testing seems to indicate it is Offset > 0xEF000000.

Thanks for your help. I certainly wouldn’t have figured these semantics out on my own.

-Steven

Hi, Steven,

Pseudo code of above logic should be something as below:

If (FailImmediately) // Timeout = 0

If Offset == Open.LastFailedLockOffset OR Offset >= LockViolationDelayOffset

Set Timeout = LockViolationDelay // within 250 milliseconds

End If

If Timeout = 0 and Lock Not Acquired

Set LockViolationDelayOffset = (Offset of lock attempt)

return STATUS_LOCK_NOT_GRANTED

Else If Timeout > 0 and Lock Not Acquired after Timeout

return STATUS_FILE_LOCK_CONFLICT

Else

return STATUS_SUCCESS

End If.

Thanks!

--------------------------------------------------------------------

Hongwei Sun - Sr. Support Escalation Engineer

DSC Protocol Team, Microsoft

hongweis@...

Tel: 469-7757027 x 57027

---------------------------------------------------------------------

Hello,

STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock.

And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED.

Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows:

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 – 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be “reset” back to STATUS_LOCK_NOT_GRANTED

I’d like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: SMBv1 LockAndX return status on lock conflict

2009-12-07T16:03:08Z

Hi, Steven,

Pseudo code of above logic should be something as below:

If (FailImmediately) // Timeout = 0

If Offset == Open.LastFailedLockOffset OR Offset >= LockViolationDelayOffset

Set Timeout = LockViolationDelay // within 250 milliseconds

End If

If Timeout = 0 and Lock Not Acquired

Set LockViolationDelayOffset = (Offset of lock attempt)

return STATUS_LOCK_NOT_GRANTED

Else If Timeout > 0 and Lock Not Acquired after Timeout

return STATUS_FILE_LOCK_CONFLICT

Else

return STATUS_SUCCESS

End If.

Thanks!

--------------------------------------------------------------------

Hongwei Sun - Sr. Support Escalation Engineer

DSC Protocol Team, Microsoft

hongweis@...

Tel: 469-7757027 x 57027

---------------------------------------------------------------------

Hello,

STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock.

And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED.

Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows:

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 – 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be “reset” back to STATUS_LOCK_NOT_GRANTED

I’d like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: FW: Group Policy questions

2009-12-04T13:32:23Z

On 04/12/2009 23:00, Sebastian Canevari wrote:
> Hi Matthieu,
>
> Just a clarification to ask you for:
>
> We are discussing with Hongwei and the PGs if it is that you are seeing GPMC "expect" the inheritance to happen OR if it is that you are dumping the ACLs and "seeing" the flags always.
>
>
What I see if when I dump the SD of the files modified by GPMC after it
realize that there was a mismatch between the SD in AD and the SD in the
Policy folder.
Note: it was with XP sp2 as a client.

Matthieu.

> Please clarify because we were under the impression that we had to look into the client tool, but if the latter is what your question means, then we need to look into AD.
>
> Thanks and regards,
>
>
>
> Sebastian Canevari
> Senior 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: sebastc@...
>
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Thursday, December 03, 2009 4:18 PM
> To: 'Matthieu Patou'; cifs-protocol@...; Interoperability Documentation Help; pfif@...
> Subject: RE: FW: [cifs-protocol] Group Policy questions
>
> Hi Matthieu,
>
> We are still actively working on this and I do have the PG engaged.
>
> Please accept my apologies if we are delaying a little longer than expected. I guess we can say that the holidays affected the timing a little without trying to use that as an excuse.
>
> I'll keep you posted as soon as I have news.
>
> Thanks and regards,
>
> Sebastian
>
>
> Sebastian Canevari
> Senior 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: sebastc@...
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
> Sent: Thursday, December 03, 2009 4:05 PM
> To: Sebastian Canevari; cifs-protocol@...; Interoperability Documentation Help; pfif@...
> Subject: Re: FW: [cifs-protocol] Group Policy questions
>
> Hello sebastian
>
>
>> And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED">control in the SDDL ?
>>
>
> Any news on this ?
> More exactly my question is why this flag appear on each ACE ?
>
> Also do you plan to document this in a WSPP document ?
>
> Regards.
> Matthieu.
> On 13/11/2009 02:40, Sebastian Canevari wrote:
>
>> Hi Matthieu,
>>
>>
>> I'll be working with you on these questions.
>>
>> I will keep you updated.
>>
>> Thanks!
>>
>> Sebastian
>>
>>
>>
>> Sebastian Canevari
>> Senior 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: sebastc@...
>>
>>
>> -----Original Message-----
>> From: Hongwei Sun
>> Sent: Wednesday, November 11, 2009 9:35 PM
>> To: Matthieu Patou
>> Cc: cifs-protocol@...; pfif@...; Sebastian Canevari
>> Subject: RE: FW: [cifs-protocol] Group Policy questions
>>
>> Matthieu,
>>
>> I double checked the logic and your assumption is right. The return value for SYSVOL access mask should be assigned to the input value first. For your other questions, since I am out of office , Sebastian will work on them and let you know.
>>
>> Thanks!
>>
>> Hongwei
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>> Sent: Wednesday, November 11, 2009 12:22 AM
>> To: Hongwei Sun
>> Cc: cifs-protocol@...; pfif@...
>> Subject: Re: FW: [cifs-protocol] Group Policy questions
>>
>> Hello Hongwei,
>>
>> I've been working on the translation function, I am getting quite similar ACL right now but I have some remarks and questions.
>>
>> The pseudo code contains this:
>>
>> DSAccessMask as Input;
>> SYSVOLAccessMask as Output;
>>
>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>
>> I have impression that it should be
>>
>> DSAccessMask as Input;
>> SYSVOLAccessMask as Output;
>>
>> SYSVOLAccessMask = DSAccessMask;
>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>
>>
>> Maybe the third line is implied in this kind of pseudo code.
>>
>> Also it seems to me that GPMC is discarding any ACL of type ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID SID_BUILTIN_PREW2K (RU).
>>
>> And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED" control in the SDDL ?
>>
>> Thanks for your answers.
>>
>> Matthieu.
>>
>> On 29/10/2009 05:31, Hongwei Sun wrote:
>>
>>
>>> Matthieu,
>>>
>>> I keep receiving the message from our e-mail server about the undeliverable e-mail to one of the address(cifs-protocol@...), which is in your original e-mail. In order to make sure you receive the email, I just forward it again.
>>>
>>> If you already received it, please let me know if it resolved your issue.
>>>
>>> Thanks!
>>>
>>> Hongwei
>>>
>>>
>>> -----Original Message-----
>>> From: Hongwei Sun
>>> Sent: Monday, October 26, 2009 6:14 PM
>>> To: Matthieu Patou; cifs-protocol@...; pfif@...
>>> Subject: RE: [cifs-protocol] Group Policy questions
>>>
>>> Matthieu,
>>>
>>> Matthieu,
>>>
>>> The attached GPMC log shows the problem of inconsistency between
>>> ACLs of the policy object and that of SYSVOL folders. The log shows
>>> that
>>>
>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>> CGPMGPO::IsAclConsistent():Checking Aces for SID
>>> S-1-5-21-2212615479-2695158682-2101375467-512
>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>> GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff ......
>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>> CGPMGPO::IsAclConsistent(): ACLs not consistent for
>>> SID<S-1-5-21-2212615479-2695158682-2101375467-512>. Mask: Expected
>>> 0x1f01ff, Found 0xf00ff
>>>
>>> The access mask for the ace of Active Directory policy object is 0xf00ff. When the GPMO converts the access mask to a corresponding file system access mask, it expects 0x1f01ff. For SYSVOL, you set the access mask to 0xf00ff. They don't match and that is why inconsistency is declared. In the SYSVOL access mask you set, you missed 0x100000(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES).
>>>
>>> Since AD objects and SYSVOL file/folder objects are different objects, their specific rights in access mask are not one-to-one matched. The following are the definitions of bits for both objects.
>>>
>>> The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows.
>>>
>>> #define RIGHT_DS_CREATE_CHILD 0x00000001
>>> #define RIGHT_DS_DELETE_CHILD 0x00000002
>>> #define RIGHT_DS_LIST_CONTENTS 0x00000004
>>> #define ACTRL_DS_SELF 0x00000008
>>> #define RIGHT_DS_READ_PROPERTY 0x00000010
>>> #define RIGHT_DS_WRITE_PROPERTY 0x00000020
>>> #define RIGHT_DS_DELETE_TREE 0x00000040
>>> #define RIGHT_DS_LIST_OBJECT 0x00000080
>>> #define RIGHT_DS_CONTROL_ACCESS 0x00000100
>>>
>>> The specific rights in access mask for a file or directory object
>>> are defined as
>>> (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx )
>>>
>>> #define FILE_READ_DATA ( 0x0001 )
>>> #define FILE_LIST_DIRECTORY ( 0x0001 )
>>> #define FILE_WRITE_DATA ( 0x0002 )
>>> #define FILE_ADD_FILE ( 0x0002 )
>>> #define FILE_APPEND_DATA ( 0x0004 )
>>> #define FILE_ADD_SUBDIRECTORY ( 0x0004 )
>>> #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 )
>>> #define FILE_READ_EA ( 0x0008 )
>>> #define FILE_WRITE_EA ( 0x0010 )
>>> #define FILE_EXECUTE ( 0x0020 )
>>> #define FILE_TRAVERSE ( 0x0020 )
>>> #define FILE_DELETE_CHILD ( 0x0040 )
>>> #define FILE_READ_ATTRIBUTES ( 0x0080 )
>>> #define FILE_WRITE_ATTRIBUTES ( 0x0100 )
>>>
>>> The generic access rights that are common to all objects are
>>>
>>> #define DELETE (0x00010000L)
>>> #define READ_CONTROL (0x00020000L)
>>> #define WRITE_DAC (0x00040000L)
>>> #define WRITE_OWNER (0x00080000L)
>>> #define SYNCHRONIZE (0x00100000L)
>>> #define STANDARD_RIGHTS_ALL (0x001F0000L)
>>>
>>>
>>> The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL.
>>>
>>> DSAccessMask as Input;
>>> SYSVOLAccessMask as Output;
>>>
>>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>>
>>> if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND
>>> (DSAccessMask& RIGHT_DS_LIST_CONTENTS))
>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY |
>>> FILE_READ_ATTRIBUTES | FILE_READ_EA |
>>> FILE_READ_DATA | FILE_EXECUTE);
>>>
>>> if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY)
>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA |
>>> FILE_APPEND_DATA | FILE_WRITE_EA |
>>> FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE |
>>> FILE_ADD_SUBDIRECTORY);
>>>
>>>
>>> if (DSAccessMask& RIGHT_DS_CREATE_CHILD)
>>> SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY |
>>> FILE_ADD_FILE);
>>>
>>>
>>> if (DSAccessMask& RIGHT_DS_DELETE_CHILD)
>>> SYSVOLAccessMask |= FILE_DELETE_CHILD;
>>>
>>>
>>> Please let me know if this solves your problem. I will file a request to update the document accordingly.
>>>
>>> Thanks!
>>>
>>> Hongwei
>>>
>>>
>>> -----Original Message-----
>>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>>> Sent: Sunday, October 25, 2009 5:48 AM
>>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>>> Documentation Help; pfif@...
>>> Subject: Re: [cifs-protocol] Group Policy questions
>>>
>>> Hello hongwei,
>>>
>>> On 10/20/2009 01:05 PM, Matthieu Patou wrote:
>>>
>>>
>>>
>>>> Hi Hongwei,
>>>> For the moment it's quite clear why we fail as we do not set any ACL
>>>> by default on the sysvol volume.
>>>> I will already fix this + the sDRightsEffective attribute and I'll
>>>> see if it do the job.
>>>>
>>>>
>>>>
>>> I worked a little bit on the ACL and still face "unsynchronized" ACL despite the fact that now our Policy folder are created with the same ACL as in AD.
>>>
>>> Let's take the following
>>> policy:{7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>>
>>> I face the message that the ACL is unconsitent with the one stored in
>>> the AD, after clicking on yes GPMC changed the ACL for
>>>
>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>>> 2
>>> 695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479
>>> -
>>> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26
>>> 9
>>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951
>>> 5
>>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951586
>>> 8
>>> 2-2101375467-512)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;SY)(A
>>> ;
>>> OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001f01bf;;;BA)
>>> (
>>> A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)S:A
>>> I
>>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0
>>> -
>>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367
>>> c
>>> 1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>
>>> Before it was:
>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>>> 2
>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-
>>> 2
>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-
>>> 1
>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDT
>>> S
>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW
>>> O
>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP
>>> C
>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO
>>> R
>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;
>>> ;
>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS
>>> D
>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)
>>> S
>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>>> 1
>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80
>>> 3
>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>
>>>
>>> And if I request the nTSecurityDescriptor for this object in the AD I get:
>>> {7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>>> 2
>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-
>>> 2
>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-
>>> 1
>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDT
>>> S
>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW
>>> O
>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP
>>> C
>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO
>>> R
>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;
>>> ;
>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS
>>> D
>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)
>>> S
>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>>> 1
>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80
>>> 3
>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>
>>>
>>> Which looks like the ACL that were present for the file.
>>> I also made a tcpdump capture (attached to this mail) and it's clear that the nTSecurityDescriptor is like the one just above. (packet 927).
>>>
>>> So what's going on, with an ACL that is the same when stored in the AD, transmitted through LDAP and stored in the file we have at the end GPMC that change the value but it's hard to understand how it construct this ACL.
>>>
>>> I attached also the GPMC log when I clicked on "OK" so that the ACL in AD and ACL for the file are synchronized (well from GPMC point of view).
>>>
>>>
>>>
>>>
>>>
>>>> I will try to use also the same SSDL as in w2k3 to see if I have the
>>>> same resulting delagation or not.
>>>>
>>>> For the moment I have some tests to do before going back to you.
>>>>
>>>> Regards.
>>>> Matthieu.
>>>> On 10/20/2009 03:11 AM, Hongwei Sun wrote:
>>>>
>>>>
>>>>
>>>>> Matthieu,
>>>>>
>>>>> For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set
>>>>> for ControlFlag in Security Descriptor in order to pass the step 2
>>>>> in consistency testing. This is translated to "P" flag in SDDL.
>>>>> With this said, it is normal to have D:PAI since this will indicate
>>>>> that the SE_DACL_PROTECTED bit is set. It seems that your Security
>>>>> Descriptor is right in this regard. We have to get more information
>>>>> to see why the consistency checking fails. Could you enable GPMC
>>>>> logging as described in my previous mail? Please enable VERBOSE for
>>>>> Gpmgmttracelevel.
>>>>>
>>>>> Just for your reference, you can also use ldp.exe to display the
>>>>> security descriptor of a policy object in SSDL string format and
>>>>> parsed display format.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Hongwei
>>>>>
>>>>> -----Original Message-----
>>>>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>>> To: Hongwei Sun
>>>>> Cc: pfif@...; cifs-protocol@...
>>>>> Subject: Re: Group Policy questions
>>>>>
>>>>> Hello Hongwei,Matthieu,
>>>>> Thank you for the answers. I have a few more questions:
>>>>>
>>>>>
>>>>>
>>>>>> After testing, I think that I have some information to help you
>>>>>> resolve all the problems.
>>>>>>
>>>>>> Problem #1:
>>>>>>
>>>>>> As described in the following link
>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 )
>>>>>> , GPMO will check the consistency between ACLs in GPO in Active
>>>>>> Directory and ACLs of policy folders in SYSVOL when a GPO object
>>>>>> is clicked in GPMC. The logic is something like the following:
>>>>>>
>>>>>> 1. Get the security descriptor (SD) for GOP in AD and folders in
>>>>>> SYSVOL
>>>>>>
>>>>>> 2. Check both security descriptors to make sure they are DACL
>>>>>> protected (PD bit in Control flag is set). If not, ACL consistency
>>>>>> check will fail.
>>>>>>
>>>>>> 3. For every permission in AD DACL, there should be the same
>>>>>> permission in SYSVOL DACL. If all permissions have be checked
>>>>>> through in AD ACL and there is still extra permission in SYSVOL
>>>>>> ACL, ACLs are not consistent.
>>>>>>
>>>>>> Looking at the your attached SSDL of the new policy, it doesn't
>>>>>> have PD bit set. (D:PAI means DI bit is set, which is not DACL protected).
>>>>>> This will fail the second step of consistency checking.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> I did an extraction of a W2K3 policy and got the following SDDL:
>>>>>
>>>>> O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064
>>>>> -
>>>>> 746857408-2662927446-512
>>>>>
>>>>> D:PAI
>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662
>>>>> 9
>>>>> 27446-512)
>>>>>
>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662
>>>>> 9
>>>>> 27446-519)
>>>>>
>>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266292
>>>>> 7
>>>>> 446-512)
>>>>>
>>>>> (A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)
>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
>>>>> (A;CI;RPLCLORC;;;AU)
>>>>> (OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
>>>>> (A;CI;RPLCLORC;;;ED)
>>>>> S:AI
>>>>> (OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>>> 1
>>>>> 1d0-a285-00aa003049e2;WD)
>>>>>
>>>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>>> 1
>>>>> 1d0-a285-00aa003049e2;WD)
>>>>>
>>>>> (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)
>>>>>
>>>>> And you say that we should not have AI flag (because it's related
>>>>> to SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because it's
>>>>> related to DE_DACL_PROTECTED aka PD bit) right ?
>>>>> But the above SDDL seems to show the opposite, I can't exclude the
>>>>> fact that we have bugs when reading ACL and/or when converting them
>>>>> into SDDL but before to trying to check this I would like to be
>>>>> sure of which flag we should see.
>>>>>
>>>>> I even tweaked XCACLS.vbs (attached to this email) from
>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to
>>>>> make it show the value of the control and it appear that the ACL
>>>>> for the c:\windows\sysvol has both PD and DI bit sets
>>>>>
>>>>> ie.
>>>>> Directory: C:\WINDOWS\SYSVOL
>>>>>
>>>>> ControlFlags: 37892
>>>>>
>>>>> Do gpmc pass some controls while making its LDAP request because I
>>>>> had a look at the delegated permission through GPMC and through
>>>>> dsa.msc they are really different (a lot of inherited from parents objects).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Problem #2:
>>>>>>
>>>>>> In GPMO, if the attribute sDRightsEffective of selected GPO object
>>>>>> has DACL_SECURITY_INFORMATION bit (0x04) set, users will be
>>>>>> prompted for ACL correction if ACLs inconsistency between AD GPO
>>>>>> and SYSVOL is detected when a GPO node is selected. You should
>>>>>> check the attribute for the GOP object in AD.
>>>>>>
>>>>>> Problem #3:
>>>>>>
>>>>>> This is basically the same logic as in (2). The "Add" and "Remove"
>>>>>> buttons in Delegation dialog are enabled only when the attribute
>>>>>> sDRightsEffective of selected GPO object has
>>>>>> DACL_SECURITY_INFORMATION (0x04) bit set. You should check the
>>>>>> attribute for the GOP object in AD.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Yeah for this it seems that the obvious problem is the lack of
>>>>> sDRightsEffective in SAMBA 4.
>>>>>
>>>>>
>>>>>
>>>>>> Debugging Information:
>>>>>>
>>>>>> By the way, you can follow the instruction in this link
>>>>>> (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx )
>>>>>> to enable GPMC logging, if you want to troubleshoot the issues
>>>>>> related to operations in GPMC. For example, the logging will show
>>>>>> you in which step the consistency checking fails.
>>>>>> You can look for the text "CGPMGPO::IsAclConsistent()" in the logs
>>>>>> generated.
>>>>>>
>>>>>> If you need more information, please let us know.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Matthieu.
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> cifs-protocol mailing list
>>>> cifs-protocol@...
>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-04T09:45:20Z

Thanks for the update - my Win7 client is also Ultimate, with no updates.

On another note, I just finished an initial debug on srv.sys; I have considerable analysis to do on the results, specifically tracking down the handles (just to make sure - even though there are no handle failures in either standard or SMB_INFO_PASSTHROUGH FileEndOfFileInformation information level for TRANS2_SET_PATH_INFORMATION).

There are additional functional checks on the information level, when less than SMB_INFO_PASSTHROUGH, which I still need to run down in the documentation.

I doubt I will be able to finish my work today, and do expect to be able to provide some reasonable information early next week.

Of course, this is all about what is supposed to be allowed when a client requests a 'native Windows NT operating system information level' ([MS-SMB] Appendix A note <158>: http://msdn.microsoft.com/en-us/library/cc246806(PROT.13).aspx).

I have thus far not been able to find any specific commentary on this in the WDK documentation (but then, I am not a driver expert).

Thanks for your patience!

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Tim Prouty [mailto:tim.prouty@...]
Sent: Friday, December 04, 2009 12:20 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote:

> I have retested without SmbSecuritySignatures - results were the same.
>
> I will hold off on the WordCount/ByteCount truncation against the
> Dos INVALID_LEVEL error problem
> (trans2setpathinfo_against_win7_2.pcap) for the time being, and work
> on the sharing issue (I expect to be soaking in code for the next
> day or so).

My win7 is a fresh ultimate install with no updates. I'm going to run
windows update to see if I can reproduce it. I'll let you know what I
find out.

-Tim

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-04T09:19:54Z

On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote:

> I have retested without SmbSecuritySignatures - results were the same.
>
> I will hold off on the WordCount/ByteCount truncation against the
> Dos INVALID_LEVEL error problem
> (trans2setpathinfo_against_win7_2.pcap) for the time being, and work
> on the sharing issue (I expect to be soaking in code for the next
> day or so).

My win7 is a fresh ultimate install with no updates. I'm going to run
windows update to see if I can reproduce it. I'll let you know what I
find out.

-Tim
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: primaryGroupToken

2009-12-04T07:08:54Z

Andrew,

I am looking into this and will keep you updated with my progress.

Best regards,

Edgar A. Olougouna
Sr. SEE, Microsoft DSC Protocol Team

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, December 03, 2009 4:00 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...; Matthieu Patou
Subject: primaryGroupToken

MS-ADA3 2.120 claims:

Attribute primaryGroupToken
This attribute specifies a computed attribute that is used in retrieving the membership list of a group
such as Domain Users. The complete membership of such groups is not stored explicitly for scaling
reasons. For more information refer to [MS-ADTS] section 3.1.1.4.5.11 and [MS-SAMR].

However,
MS-ADTS 3.1.1.4.5.11 claims:

primaryGroupToken
Let TO be the object from which the primaryGroupToken attribute is being read.
The value of TO!primaryGroupToken is the RID from TO!objectSid when there exists C in
TO!objectClass such that C is the group class. Otherwise, no value is returned. That is, if TO is a
group, then the value of this attribute is the RID from the group's SID. If TO is not a group, no
value is returned when this attribute is read from TO.

The behaviour of Window 2008 appears to follow MS-ADTS. That is, the primaryGroupToken appears to be the RID of the objectSID for all groups.

Please advise, clarify or correct,

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: SMBv1 multiple lock cancel behavior

2009-12-03T15:24:50Z

I Steven,

Thanks for your inquiry.

Someone from my team will be contacting you shortly.

Thanks and regards,

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039

"Las Colinas - LC2"

Tel: +1 469 775 7849

sebastc@...

From: Steven Danneman [mailto:steven.danneman@...]
Sent: Thursday, December 03, 2009 4:57 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...
Subject: SMBv1 multiple lock cancel behavior

Hello,

I’ve got yet another byte range locking question.

MS-CIFS (v0.1) states in section 2.2.4.32.1:

“If the Locks vector contains one and only one entry (NumberOfRequestedLocks ==

1) and TypeOfLock has the CANCEL_LOCK bit set, the client is requesting that the

server cancel a previously requested but unacknowledged lock.“

My newly pushed smbtorture4 test, part of RAW-LOCK-ASYNC, shows a W2K8R2 server accepting a request with the CANCEL_LOCK bit set that contains multiple entries in the lock array, ie NumberOfRequestedLocks == 2. The server then seems to cancel the first outstanding lock and return SUCCESS.

From the description in the spec I would expect the server to return an error, something like STATUS_INVALID_PARAMETER in this case. Is this an implementation specific issue to Windows or is the MS-CIFS spec incorrect?

Attached is a pcap showing this behavior. The new test was added to smbtorture in:

http://gitweb.samba.org/?p=samba.git;a=commit;h=48358b3eaa425d8fbfec7bfd8ccf56860b5a1ba0

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

SMBv1 multiple lock cancel behavior

2009-12-03T14:56:02Z

Hello,

I’ve got yet another byte range locking question.

MS-CIFS (v0.1) states in section 2.2.4.32.1:

“If the Locks vector contains one and only one entry (NumberOfRequestedLocks ==

1) and TypeOfLock has the CANCEL_LOCK bit set, the client is requesting that the

server cancel a previously requested but unacknowledged lock.“

Attached is a pcap showing this behavior. The new test was added to smbtorture in:

http://gitweb.samba.org/?p=samba.git;a=commit;h=48358b3eaa425d8fbfec7bfd8ccf56860b5a1ba0

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

multiple_cancel.pcap (12K) Download Attachment

Re: primaryGroupToken

2009-12-03T14:19:03Z

Hi Andrew,

Thanks for your inquiry.

Someone from my team will be contacting you shortly to help you with this.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior 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: sebastc@...

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, December 03, 2009 4:00 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...; Matthieu Patou
Subject: primaryGroupToken

MS-ADA3 2.120 claims:

Attribute primaryGroupToken
This attribute specifies a computed attribute that is used in retrieving the membership list of a group
such as Domain Users. The complete membership of such groups is not stored explicitly for scaling
reasons. For more information refer to [MS-ADTS] section 3.1.1.4.5.11 and [MS-SAMR].

However,
MS-ADTS 3.1.1.4.5.11 claims:

primaryGroupToken
Let TO be the object from which the primaryGroupToken attribute is being read.
The value of TO!primaryGroupToken is the RID from TO!objectSid when there exists C in
TO!objectClass such that C is the group class. Otherwise, no value is returned. That is, if TO is a
group, then the value of this attribute is the RID from the group's SID. If TO is not a group, no
value is returned when this attribute is read from TO.

The behaviour of Window 2008 appears to follow MS-ADTS. That is, the primaryGroupToken appears to be the RID of the objectSID for all groups.

Please advise, clarify or correct,

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: FW: Group Policy questions

2009-12-03T14:18:10Z

Hi Matthieu,

We are still actively working on this and I do have the PG engaged.

Please accept my apologies if we are delaying a little longer than expected. I guess we can say that the holidays affected the timing a little without trying to use that as an excuse.

I'll keep you posted as soon as I have news.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior 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: sebastc@...

-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Thursday, December 03, 2009 4:05 PM
To: Sebastian Canevari; cifs-protocol@...; Interoperability Documentation Help; pfif@...
Subject: Re: FW: [cifs-protocol] Group Policy questions

Hello sebastian

>And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED">control in the SDDL ?

Any news on this ?
More exactly my question is why this flag appear on each ACE ?

Also do you plan to document this in a WSPP document ?

Regards.
Matthieu.
On 13/11/2009 02:40, Sebastian Canevari wrote:

> Hi Matthieu,
>
>
> I'll be working with you on these questions.
>
> I will keep you updated.
>
> Thanks!
>
> Sebastian
>
>
>
> Sebastian Canevari
> Senior 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: sebastc@...
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Wednesday, November 11, 2009 9:35 PM
> To: Matthieu Patou
> Cc: cifs-protocol@...; pfif@...; Sebastian Canevari
> Subject: RE: FW: [cifs-protocol] Group Policy questions
>
> Matthieu,
>
> I double checked the logic and your assumption is right. The return value for SYSVOL access mask should be assigned to the input value first. For your other questions, since I am out of office , Sebastian will work on them and let you know.
>
> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
> Sent: Wednesday, November 11, 2009 12:22 AM
> To: Hongwei Sun
> Cc: cifs-protocol@...; pfif@...
> Subject: Re: FW: [cifs-protocol] Group Policy questions
>
> Hello Hongwei,
>
> I've been working on the translation function, I am getting quite similar ACL right now but I have some remarks and questions.
>
> The pseudo code contains this:
>
> DSAccessMask as Input;
> SYSVOLAccessMask as Output;
>
> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>
> I have impression that it should be
>
> DSAccessMask as Input;
> SYSVOLAccessMask as Output;
>
> SYSVOLAccessMask = DSAccessMask;
> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>
>
> Maybe the third line is implied in this kind of pseudo code.
>
> Also it seems to me that GPMC is discarding any ACL of type ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID SID_BUILTIN_PREW2K (RU).
>
> And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED" control in the SDDL ?
>
> Thanks for your answers.
>
> Matthieu.
>
> On 29/10/2009 05:31, Hongwei Sun wrote:
>
>> Matthieu,
>>
>> I keep receiving the message from our e-mail server about the undeliverable e-mail to one of the address(cifs-protocol@...), which is in your original e-mail. In order to make sure you receive the email, I just forward it again.
>>
>> If you already received it, please let me know if it resolved your issue.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>> -----Original Message-----
>> From: Hongwei Sun
>> Sent: Monday, October 26, 2009 6:14 PM
>> To: Matthieu Patou; cifs-protocol@...; pfif@...
>> Subject: RE: [cifs-protocol] Group Policy questions
>>
>> Matthieu,
>>
>> Matthieu,
>>
>> The attached GPMC log shows the problem of inconsistency between
>> ACLs of the policy object and that of SYSVOL folders. The log shows
>> that
>>
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> CGPMGPO::IsAclConsistent():Checking Aces for SID
>> S-1-5-21-2212615479-2695158682-2101375467-512
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff ......
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> CGPMGPO::IsAclConsistent(): ACLs not consistent for
>> SID<S-1-5-21-2212615479-2695158682-2101375467-512>. Mask: Expected
>> 0x1f01ff, Found 0xf00ff
>>
>> The access mask for the ace of Active Directory policy object is 0xf00ff. When the GPMO converts the access mask to a corresponding file system access mask, it expects 0x1f01ff. For SYSVOL, you set the access mask to 0xf00ff. They don't match and that is why inconsistency is declared. In the SYSVOL access mask you set, you missed 0x100000(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES).
>>
>> Since AD objects and SYSVOL file/folder objects are different objects, their specific rights in access mask are not one-to-one matched. The following are the definitions of bits for both objects.
>>
>> The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows.
>>
>> #define RIGHT_DS_CREATE_CHILD 0x00000001
>> #define RIGHT_DS_DELETE_CHILD 0x00000002
>> #define RIGHT_DS_LIST_CONTENTS 0x00000004
>> #define ACTRL_DS_SELF 0x00000008
>> #define RIGHT_DS_READ_PROPERTY 0x00000010
>> #define RIGHT_DS_WRITE_PROPERTY 0x00000020
>> #define RIGHT_DS_DELETE_TREE 0x00000040
>> #define RIGHT_DS_LIST_OBJECT 0x00000080
>> #define RIGHT_DS_CONTROL_ACCESS 0x00000100
>>
>> The specific rights in access mask for a file or directory object
>> are defined as
>> (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx )
>>
>> #define FILE_READ_DATA ( 0x0001 )
>> #define FILE_LIST_DIRECTORY ( 0x0001 )
>> #define FILE_WRITE_DATA ( 0x0002 )
>> #define FILE_ADD_FILE ( 0x0002 )
>> #define FILE_APPEND_DATA ( 0x0004 )
>> #define FILE_ADD_SUBDIRECTORY ( 0x0004 )
>> #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 )
>> #define FILE_READ_EA ( 0x0008 )
>> #define FILE_WRITE_EA ( 0x0010 )
>> #define FILE_EXECUTE ( 0x0020 )
>> #define FILE_TRAVERSE ( 0x0020 )
>> #define FILE_DELETE_CHILD ( 0x0040 )
>> #define FILE_READ_ATTRIBUTES ( 0x0080 )
>> #define FILE_WRITE_ATTRIBUTES ( 0x0100 )
>>
>> The generic access rights that are common to all objects are
>>
>> #define DELETE (0x00010000L)
>> #define READ_CONTROL (0x00020000L)
>> #define WRITE_DAC (0x00040000L)
>> #define WRITE_OWNER (0x00080000L)
>> #define SYNCHRONIZE (0x00100000L)
>> #define STANDARD_RIGHTS_ALL (0x001F0000L)
>>
>>
>> The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL.
>>
>> DSAccessMask as Input;
>> SYSVOLAccessMask as Output;
>>
>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>
>> if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND
>> (DSAccessMask& RIGHT_DS_LIST_CONTENTS))
>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY |
>> FILE_READ_ATTRIBUTES | FILE_READ_EA |
>> FILE_READ_DATA | FILE_EXECUTE);
>>
>> if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY)
>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA |
>> FILE_APPEND_DATA | FILE_WRITE_EA |
>> FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE |
>> FILE_ADD_SUBDIRECTORY);
>>
>>
>> if (DSAccessMask& RIGHT_DS_CREATE_CHILD)
>> SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY |
>> FILE_ADD_FILE);
>>
>>
>> if (DSAccessMask& RIGHT_DS_DELETE_CHILD)
>> SYSVOLAccessMask |= FILE_DELETE_CHILD;
>>
>>
>> Please let me know if this solves your problem. I will file a request to update the document accordingly.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>> Sent: Sunday, October 25, 2009 5:48 AM
>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>> Documentation Help; pfif@...
>> Subject: Re: [cifs-protocol] Group Policy questions
>>
>> Hello hongwei,
>>
>> On 10/20/2009 01:05 PM, Matthieu Patou wrote:
>>
>>
>>> Hi Hongwei,
>>> For the moment it's quite clear why we fail as we do not set any ACL
>>> by default on the sysvol volume.
>>> I will already fix this + the sDRightsEffective attribute and I'll
>>> see if it do the job.
>>>
>>>
>> I worked a little bit on the ACL and still face "unsynchronized" ACL despite the fact that now our Policy folder are created with the same ACL as in AD.
>>
>> Let's take the following
>> policy:{7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>
>> I face the message that the ACL is unconsitent with the one stored in
>> the AD, after clicking on yes GPMC changed the ACL for
>>
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>> 2
>> 695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479
>> -
>> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26
>> 9
>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951
>> 5
>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951586
>> 8
>> 2-2101375467-512)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;SY)(A
>> ;
>> OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001f01bf;;;BA)
>> (
>> A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)S:A
>> I
>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0
>> -
>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367
>> c
>> 1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>> Before it was:
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>> 2
>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-
>> 2
>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-
>> 1
>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDT
>> S
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW
>> O
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP
>> C
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO
>> R
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;
>> ;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS
>> D
>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)
>> S
>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>> 1
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80
>> 3
>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>>
>> And if I request the nTSecurityDescriptor for this object in the AD I get:
>> {7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-
>> 2
>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-
>> 2
>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-
>> 1
>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDT
>> S
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW
>> O
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP
>> C
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO
>> R
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;
>> ;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS
>> D
>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)
>> S
>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>> 1
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80
>> 3
>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>>
>> Which looks like the ACL that were present for the file.
>> I also made a tcpdump capture (attached to this mail) and it's clear that the nTSecurityDescriptor is like the one just above. (packet 927).
>>
>> So what's going on, with an ACL that is the same when stored in the AD, transmitted through LDAP and stored in the file we have at the end GPMC that change the value but it's hard to understand how it construct this ACL.
>>
>> I attached also the GPMC log when I clicked on "OK" so that the ACL in AD and ACL for the file are synchronized (well from GPMC point of view).
>>
>>
>>
>>
>>> I will try to use also the same SSDL as in w2k3 to see if I have the
>>> same resulting delagation or not.
>>>
>>> For the moment I have some tests to do before going back to you.
>>>
>>> Regards.
>>> Matthieu.
>>> On 10/20/2009 03:11 AM, Hongwei Sun wrote:
>>>
>>>
>>>> Matthieu,
>>>>
>>>> For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set
>>>> for ControlFlag in Security Descriptor in order to pass the step 2
>>>> in consistency testing. This is translated to "P" flag in SDDL.
>>>> With this said, it is normal to have D:PAI since this will indicate
>>>> that the SE_DACL_PROTECTED bit is set. It seems that your Security
>>>> Descriptor is right in this regard. We have to get more information
>>>> to see why the consistency checking fails. Could you enable GPMC
>>>> logging as described in my previous mail? Please enable VERBOSE for
>>>> Gpmgmttracelevel.
>>>>
>>>> Just for your reference, you can also use ldp.exe to display the
>>>> security descriptor of a policy object in SSDL string format and
>>>> parsed display format.
>>>>
>>>> Thanks!
>>>>
>>>> Hongwei
>>>>
>>>> -----Original Message-----
>>>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>> To: Hongwei Sun
>>>> Cc: pfif@...; cifs-protocol@...
>>>> Subject: Re: Group Policy questions
>>>>
>>>> Hello Hongwei,Matthieu,
>>>> Thank you for the answers. I have a few more questions:
>>>>
>>>>
>>>>> After testing, I think that I have some information to help you
>>>>> resolve all the problems.
>>>>>
>>>>> Problem #1:
>>>>>
>>>>> As described in the following link
>>>>> (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 )
>>>>> , GPMO will check the consistency between ACLs in GPO in Active
>>>>> Directory and ACLs of policy folders in SYSVOL when a GPO object
>>>>> is clicked in GPMC. The logic is something like the following:
>>>>>
>>>>> 1. Get the security descriptor (SD) for GOP in AD and folders in
>>>>> SYSVOL
>>>>>
>>>>> 2. Check both security descriptors to make sure they are DACL
>>>>> protected (PD bit in Control flag is set). If not, ACL consistency
>>>>> check will fail.
>>>>>
>>>>> 3. For every permission in AD DACL, there should be the same
>>>>> permission in SYSVOL DACL. If all permissions have be checked
>>>>> through in AD ACL and there is still extra permission in SYSVOL
>>>>> ACL, ACLs are not consistent.
>>>>>
>>>>> Looking at the your attached SSDL of the new policy, it doesn't
>>>>> have PD bit set. (D:PAI means DI bit is set, which is not DACL protected).
>>>>> This will fail the second step of consistency checking.
>>>>>
>>>>>
>>>>>
>>>> I did an extraction of a W2K3 policy and got the following SDDL:
>>>>
>>>> O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064
>>>> -
>>>> 746857408-2662927446-512
>>>>
>>>> D:PAI
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662
>>>> 9
>>>> 27446-512)
>>>>
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662
>>>> 9
>>>> 27446-519)
>>>>
>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266292
>>>> 7
>>>> 446-512)
>>>>
>>>> (A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
>>>> (A;CI;RPLCLORC;;;AU)
>>>> (OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
>>>> (A;CI;RPLCLORC;;;ED)
>>>> S:AI
>>>> (OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>> 1
>>>> 1d0-a285-00aa003049e2;WD)
>>>>
>>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>> 1
>>>> 1d0-a285-00aa003049e2;WD)
>>>>
>>>> (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)
>>>>
>>>> And you say that we should not have AI flag (because it's related
>>>> to SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because it's
>>>> related to DE_DACL_PROTECTED aka PD bit) right ?
>>>> But the above SDDL seems to show the opposite, I can't exclude the
>>>> fact that we have bugs when reading ACL and/or when converting them
>>>> into SDDL but before to trying to check this I would like to be
>>>> sure of which flag we should see.
>>>>
>>>> I even tweaked XCACLS.vbs (attached to this email) from
>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to
>>>> make it show the value of the control and it appear that the ACL
>>>> for the c:\windows\sysvol has both PD and DI bit sets
>>>>
>>>> ie.
>>>> Directory: C:\WINDOWS\SYSVOL
>>>>
>>>> ControlFlags: 37892
>>>>
>>>> Do gpmc pass some controls while making its LDAP request because I
>>>> had a look at the delegated permission through GPMC and through
>>>> dsa.msc they are really different (a lot of inherited from parents objects).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Problem #2:
>>>>>
>>>>> In GPMO, if the attribute sDRightsEffective of selected GPO object
>>>>> has DACL_SECURITY_INFORMATION bit (0x04) set, users will be
>>>>> prompted for ACL correction if ACLs inconsistency between AD GPO
>>>>> and SYSVOL is detected when a GPO node is selected. You should
>>>>> check the attribute for the GOP object in AD.
>>>>>
>>>>> Problem #3:
>>>>>
>>>>> This is basically the same logic as in (2). The "Add" and "Remove"
>>>>> buttons in Delegation dialog are enabled only when the attribute
>>>>> sDRightsEffective of selected GPO object has
>>>>> DACL_SECURITY_INFORMATION (0x04) bit set. You should check the
>>>>> attribute for the GOP object in AD.
>>>>>
>>>>>
>>>>>
>>>> Yeah for this it seems that the obvious problem is the lack of
>>>> sDRightsEffective in SAMBA 4.
>>>>
>>>>
>>>>> Debugging Information:
>>>>>
>>>>> By the way, you can follow the instruction in this link
>>>>> (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx )
>>>>> to enable GPMC logging, if you want to troubleshoot the issues
>>>>> related to operations in GPMC. For example, the logging will show
>>>>> you in which step the consistency checking fails.
>>>>> You can look for the text "CGPMGPO::IsAclConsistent()" in the logs
>>>>> generated.
>>>>>
>>>>> If you need more information, please let us know.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Matthieu.
>>>>
>>>>
>>> _______________________________________________
>>> cifs-protocol mailing list
>>> cifs-protocol@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>
>>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: FW: Group Policy questions

2009-12-03T14:04:50Z

Hello sebastian

>And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED">control in the SDDL ?

Any news on this ?
More exactly my question is why this flag appear on each ACE ?

Also do you plan to document this in a WSPP document ?

Regards.
Matthieu.
On 13/11/2009 02:40, Sebastian Canevari wrote:

> Hi Matthieu,
>
>
> I'll be working with you on these questions.
>
> I will keep you updated.
>
> Thanks!
>
> Sebastian
>
>
>
> Sebastian Canevari
> Senior 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: sebastc@...
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Wednesday, November 11, 2009 9:35 PM
> To: Matthieu Patou
> Cc: cifs-protocol@...; pfif@...; Sebastian Canevari
> Subject: RE: FW: [cifs-protocol] Group Policy questions
>
> Matthieu,
>
> I double checked the logic and your assumption is right. The return value for SYSVOL access mask should be assigned to the input value first. For your other questions, since I am out of office , Sebastian will work on them and let you know.
>
> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
> Sent: Wednesday, November 11, 2009 12:22 AM
> To: Hongwei Sun
> Cc: cifs-protocol@...; pfif@...
> Subject: Re: FW: [cifs-protocol] Group Policy questions
>
> Hello Hongwei,
>
> I've been working on the translation function, I am getting quite similar ACL right now but I have some remarks and questions.
>
> The pseudo code contains this:
>
> DSAccessMask as Input;
> SYSVOLAccessMask as Output;
>
> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>
> I have impression that it should be
>
> DSAccessMask as Input;
> SYSVOLAccessMask as Output;
>
> SYSVOLAccessMask = DSAccessMask;
> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>
>
> Maybe the third line is implied in this kind of pseudo code.
>
> Also it seems to me that GPMC is discarding any ACL of type ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID SID_BUILTIN_PREW2K (RU).
>
> And last but not least question, it seems that GPMC whats to have OI and CI flags on every ACL entries is it due to the presence of the "SDDL_AUTO_INHERITED" control in the SDDL ?
>
> Thanks for your answers.
>
> Matthieu.
>
> On 29/10/2009 05:31, Hongwei Sun wrote:
>
>> Matthieu,
>>
>> I keep receiving the message from our e-mail server about the undeliverable e-mail to one of the address(cifs-protocol@...), which is in your original e-mail. In order to make sure you receive the email, I just forward it again.
>>
>> If you already received it, please let me know if it resolved your issue.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>> -----Original Message-----
>> From: Hongwei Sun
>> Sent: Monday, October 26, 2009 6:14 PM
>> To: Matthieu Patou; cifs-protocol@...; pfif@...
>> Subject: RE: [cifs-protocol] Group Policy questions
>>
>> Matthieu,
>>
>> Matthieu,
>>
>> The attached GPMC log shows the problem of inconsistency between
>> ACLs of the policy object and that of SYSVOL folders. The log shows
>> that
>>
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> CGPMGPO::IsAclConsistent():Checking Aces for SID
>> S-1-5-21-2212615479-2695158682-2101375467-512
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff ......
>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>> CGPMGPO::IsAclConsistent(): ACLs not consistent for
>> SID<S-1-5-21-2212615479-2695158682-2101375467-512>. Mask: Expected
>> 0x1f01ff, Found 0xf00ff
>>
>> The access mask for the ace of Active Directory policy object is 0xf00ff. When the GPMO converts the access mask to a corresponding file system access mask, it expects 0x1f01ff. For SYSVOL, you set the access mask to 0xf00ff. They don't match and that is why inconsistency is declared. In the SYSVOL access mask you set, you missed 0x100000(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES).
>>
>> Since AD objects and SYSVOL file/folder objects are different objects, their specific rights in access mask are not one-to-one matched. The following are the definitions of bits for both objects.
>>
>> The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows.
>>
>> #define RIGHT_DS_CREATE_CHILD 0x00000001
>> #define RIGHT_DS_DELETE_CHILD 0x00000002
>> #define RIGHT_DS_LIST_CONTENTS 0x00000004
>> #define ACTRL_DS_SELF 0x00000008
>> #define RIGHT_DS_READ_PROPERTY 0x00000010
>> #define RIGHT_DS_WRITE_PROPERTY 0x00000020
>> #define RIGHT_DS_DELETE_TREE 0x00000040
>> #define RIGHT_DS_LIST_OBJECT 0x00000080
>> #define RIGHT_DS_CONTROL_ACCESS 0x00000100
>>
>> The specific rights in access mask for a file or directory object
>> are defined as
>> (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx )
>>
>> #define FILE_READ_DATA ( 0x0001 )
>> #define FILE_LIST_DIRECTORY ( 0x0001 )
>> #define FILE_WRITE_DATA ( 0x0002 )
>> #define FILE_ADD_FILE ( 0x0002 )
>> #define FILE_APPEND_DATA ( 0x0004 )
>> #define FILE_ADD_SUBDIRECTORY ( 0x0004 )
>> #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 )
>> #define FILE_READ_EA ( 0x0008 )
>> #define FILE_WRITE_EA ( 0x0010 )
>> #define FILE_EXECUTE ( 0x0020 )
>> #define FILE_TRAVERSE ( 0x0020 )
>> #define FILE_DELETE_CHILD ( 0x0040 )
>> #define FILE_READ_ATTRIBUTES ( 0x0080 )
>> #define FILE_WRITE_ATTRIBUTES ( 0x0100 )
>>
>> The generic access rights that are common to all objects are
>>
>> #define DELETE (0x00010000L)
>> #define READ_CONTROL (0x00020000L)
>> #define WRITE_DAC (0x00040000L)
>> #define WRITE_OWNER (0x00080000L)
>> #define SYNCHRONIZE (0x00100000L)
>> #define STANDARD_RIGHTS_ALL (0x001F0000L)
>>
>>
>> The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL.
>>
>> DSAccessMask as Input;
>> SYSVOLAccessMask as Output;
>>
>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>
>> if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND
>> (DSAccessMask& RIGHT_DS_LIST_CONTENTS))
>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY |
>> FILE_READ_ATTRIBUTES | FILE_READ_EA |
>> FILE_READ_DATA | FILE_EXECUTE);
>>
>> if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY)
>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA |
>> FILE_APPEND_DATA | FILE_WRITE_EA |
>> FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE |
>> FILE_ADD_SUBDIRECTORY);
>>
>>
>> if (DSAccessMask& RIGHT_DS_CREATE_CHILD)
>> SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY | FILE_ADD_FILE);
>>
>>
>> if (DSAccessMask& RIGHT_DS_DELETE_CHILD)
>> SYSVOLAccessMask |= FILE_DELETE_CHILD;
>>
>>
>> Please let me know if this solves your problem. I will file a request to update the document accordingly.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>> Sent: Sunday, October 25, 2009 5:48 AM
>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>> Documentation Help; pfif@...
>> Subject: Re: [cifs-protocol] Group Policy questions
>>
>> Hello hongwei,
>>
>> On 10/20/2009 01:05 PM, Matthieu Patou wrote:
>>
>>
>>> Hi Hongwei,
>>> For the moment it's quite clear why we fail as we do not set any ACL
>>> by default on the sysvol volume.
>>> I will already fix this + the sDRightsEffective attribute and I'll
>>> see if it do the job.
>>>
>>>
>> I worked a little bit on the ACL and still face "unsynchronized" ACL despite the fact that now our Policy folder are created with the same ACL as in AD.
>>
>> Let's take the following policy:{7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>
>> I face the message that the ACL is unconsitent with the one stored in
>> the AD, after clicking on yes GPMC changed the ACL for
>>
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2
>> 695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-
>> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269
>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515
>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515868
>> 2-2101375467-512)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;SY)(A;
>> OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001f01bf;;;BA)(
>> A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)S:AI
>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-
>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c
>> 1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>> Before it was:
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2
>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2
>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1
>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTS
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S
>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>>
>> And if I request the nTSecurityDescriptor for this object in the AD I get:
>> {7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2
>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2
>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1
>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTS
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S
>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>
>>
>> Which looks like the ACL that were present for the file.
>> I also made a tcpdump capture (attached to this mail) and it's clear that the nTSecurityDescriptor is like the one just above. (packet 927).
>>
>> So what's going on, with an ACL that is the same when stored in the AD, transmitted through LDAP and stored in the file we have at the end GPMC that change the value but it's hard to understand how it construct this ACL.
>>
>> I attached also the GPMC log when I clicked on "OK" so that the ACL in AD and ACL for the file are synchronized (well from GPMC point of view).
>>
>>
>>
>>
>>> I will try to use also the same SSDL as in w2k3 to see if I have the
>>> same resulting delagation or not.
>>>
>>> For the moment I have some tests to do before going back to you.
>>>
>>> Regards.
>>> Matthieu.
>>> On 10/20/2009 03:11 AM, Hongwei Sun wrote:
>>>
>>>
>>>> Matthieu,
>>>>
>>>> For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set for
>>>> ControlFlag in Security Descriptor in order to pass the step 2 in
>>>> consistency testing. This is translated to "P" flag in SDDL. With
>>>> this said, it is normal to have D:PAI since this will indicate that
>>>> the SE_DACL_PROTECTED bit is set. It seems that your Security
>>>> Descriptor is right in this regard. We have to get more information
>>>> to see why the consistency checking fails. Could you enable GPMC
>>>> logging as described in my previous mail? Please enable VERBOSE for
>>>> Gpmgmttracelevel.
>>>>
>>>> Just for your reference, you can also use ldp.exe to display the
>>>> security descriptor of a policy object in SSDL string format and
>>>> parsed display format.
>>>>
>>>> Thanks!
>>>>
>>>> Hongwei
>>>>
>>>> -----Original Message-----
>>>> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>> To: Hongwei Sun
>>>> Cc: pfif@...; cifs-protocol@...
>>>> Subject: Re: Group Policy questions
>>>>
>>>> Hello Hongwei,Matthieu,
>>>> Thank you for the answers. I have a few more questions:
>>>>
>>>>
>>>>> After testing, I think that I have some information to help you
>>>>> resolve all the problems.
>>>>>
>>>>> Problem #1:
>>>>>
>>>>> As described in the following link
>>>>> (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 ) ,
>>>>> GPMO will check the consistency between ACLs in GPO in Active
>>>>> Directory and ACLs of policy folders in SYSVOL when a GPO object is
>>>>> clicked in GPMC. The logic is something like the following:
>>>>>
>>>>> 1. Get the security descriptor (SD) for GOP in AD and folders in
>>>>> SYSVOL
>>>>>
>>>>> 2. Check both security descriptors to make sure they are DACL
>>>>> protected (PD bit in Control flag is set). If not, ACL consistency
>>>>> check will fail.
>>>>>
>>>>> 3. For every permission in AD DACL, there should be the same
>>>>> permission in SYSVOL DACL. If all permissions have be checked
>>>>> through in AD ACL and there is still extra permission in SYSVOL
>>>>> ACL, ACLs are not consistent.
>>>>>
>>>>> Looking at the your attached SSDL of the new policy, it doesn't
>>>>> have PD bit set. (D:PAI means DI bit is set, which is not DACL protected).
>>>>> This will fail the second step of consistency checking.
>>>>>
>>>>>
>>>>>
>>>> I did an extraction of a W2K3 policy and got the following SDDL:
>>>>
>>>> O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-
>>>> 746857408-2662927446-512
>>>>
>>>> D:PAI
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629
>>>> 27446-512)
>>>>
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629
>>>> 27446-519)
>>>>
>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927
>>>> 446-512)
>>>>
>>>> (A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
>>>> (A;CI;RPLCLORC;;;AU)
>>>> (OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
>>>> (A;CI;RPLCLORC;;;ED)
>>>> S:AI
>>>> (OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>>>> 1d0-a285-00aa003049e2;WD)
>>>>
>>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-1
>>>> 1d0-a285-00aa003049e2;WD)
>>>>
>>>> (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)
>>>>
>>>> And you say that we should not have AI flag (because it's related to
>>>> SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because it's
>>>> related to DE_DACL_PROTECTED aka PD bit) right ?
>>>> But the above SDDL seems to show the opposite, I can't exclude the
>>>> fact that we have bugs when reading ACL and/or when converting them
>>>> into SDDL but before to trying to check this I would like to be sure
>>>> of which flag we should see.
>>>>
>>>> I even tweaked XCACLS.vbs (attached to this email) from
>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to
>>>> make it show the value of the control and it appear that the ACL for
>>>> the c:\windows\sysvol has both PD and DI bit sets
>>>>
>>>> ie.
>>>> Directory: C:\WINDOWS\SYSVOL
>>>>
>>>> ControlFlags: 37892
>>>>
>>>> Do gpmc pass some controls while making its LDAP request because I
>>>> had a look at the delegated permission through GPMC and through
>>>> dsa.msc they are really different (a lot of inherited from parents objects).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Problem #2:
>>>>>
>>>>> In GPMO, if the attribute sDRightsEffective of selected GPO object
>>>>> has DACL_SECURITY_INFORMATION bit (0x04) set, users will be
>>>>> prompted for ACL correction if ACLs inconsistency between AD GPO
>>>>> and SYSVOL is detected when a GPO node is selected. You should
>>>>> check the attribute for the GOP object in AD.
>>>>>
>>>>> Problem #3:
>>>>>
>>>>> This is basically the same logic as in (2). The "Add" and "Remove"
>>>>> buttons in Delegation dialog are enabled only when the attribute
>>>>> sDRightsEffective of selected GPO object has
>>>>> DACL_SECURITY_INFORMATION (0x04) bit set. You should check the
>>>>> attribute for the GOP object in AD.
>>>>>
>>>>>
>>>>>
>>>> Yeah for this it seems that the obvious problem is the lack of
>>>> sDRightsEffective in SAMBA 4.
>>>>
>>>>
>>>>> Debugging Information:
>>>>>
>>>>> By the way, you can follow the instruction in this link
>>>>> (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx )
>>>>> to enable GPMC logging, if you want to troubleshoot the issues
>>>>> related to operations in GPMC. For example, the logging will show
>>>>> you in which step the consistency checking fails.
>>>>> You can look for the text "CGPMGPO::IsAclConsistent()" in the logs
>>>>> generated.
>>>>>
>>>>> If you need more information, please let us know.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Matthieu.
>>>>
>>>>
>>> _______________________________________________
>>> cifs-protocol mailing list
>>> cifs-protocol@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>
>>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

primaryGroupToken

2009-12-03T14:00:11Z

MS-ADA3 2.120 claims:

Attribute primaryGroupToken
This attribute specifies a computed attribute that is used in retrieving the membership list of a group
such as Domain Users. The complete membership of such groups is not stored explicitly for scaling
reasons. For more information refer to [MS-ADTS] section 3.1.1.4.5.11 and [MS-SAMR].

However,
MS-ADTS 3.1.1.4.5.11 claims:

primaryGroupToken
Let TO be the object from which the primaryGroupToken attribute is being read.
The value of TO!primaryGroupToken is the RID from TO!objectSid when there exists C in
TO!objectClass such that C is the group class. Otherwise, no value is returned. That is, if TO is a
group, then the value of this attribute is the RID from the group's SID. If TO is not a group, no
value is returned when this attribute is read from TO.

The behaviour of Window 2008 appears to follow MS-ADTS. That is, the
primaryGroupToken appears to be the RID of the objectSID for all
groups.

Please advise, clarify or correct,

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

signature.asc (196 bytes) Download Attachment

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-03T10:04:54Z

I have retested without SmbSecuritySignatures - results were the same.

I will hold off on the WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) for the time being, and work on the sharing issue (I expect to be soaking in code for the next day or so).

Thanks for all your help with samba4/smbtorture (I am still having problems with gz on my Ubuntu client, so I unpacked it on my Windows client & cloned the tree to Ubuntu). No problems at all with the build.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Thursday, December 03, 2009 12:32 PM
To: 'Tim Prouty'
Cc: 'pfif@...'; 'cifs-protocol@...'
Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

Good morning Tim. I have successfully reproduced the share problem with Trans2SetPathInfo() FileEndOfFileInformation, using smbtorture (RAW-SFILEINFO-END-OF-FILE ) against both Windows 2008 R2 and Windows 7. This, of course, will allow me to dig deeper into the problem.

Interestingly, WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my clients (who succeeded against the ); the only significant difference I see in the traces you sent and my test traces is that my Win7/R2 targets were using SmbSecuritySignatures (your Win7 client did not).

I have attached my network captures (in both Wireshark tcp dump & Netmon 3.x format).

I will retry with security signatures disabled and get back to you with the results.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-12-03T09:31:34Z

Good morning Tim. I have successfully reproduced the share problem with Trans2SetPathInfo() FileEndOfFileInformation, using smbtorture (RAW-SFILEINFO-END-OF-FILE ) against both Windows 2008 R2 and Windows 7. This, of course, will allow me to dig deeper into the problem.

Interestingly, WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my clients (who succeeded against the ); the only significant difference I see in the traces you sent and my test traces is that my Win7/R2 targets were using SmbSecuritySignatures (your Win7 client did not).

I have attached my network captures (in both Wireshark tcp dump & Netmon 3.x format).

I will retry with security signatures disabled and get back to you with the results.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Test.zip (37K) Download Attachment

Re: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

2009-12-02T16:00:25Z

Hongwei,

I see the behavior clearly specified in MS-SMB2 3.3.5.14.1. Thanks for your help!

-Steven

From: Hongwei Sun [mailto:hongweis@...]
Sent: Wednesday, December 02, 2009 3:33 PM
To: Steven Danneman; cifs-protocol@...; pfif@...
Subject: RE: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

Steven,

I completed the investigation on the behavior described in your e-mail. It is a normal behavior that has been documented in the MS-SMB2 document. The following is the explanation:

The server processing logic is described in details in “3.3.5.14 Receiving an SMB2 Lock Request”. You are right that the both unlock and lock requests cannot be mixed in the same SMB2_LOCK request. The server processes the Locks array in SMB2_LOCK request as either a series of locks or a series of unlocks based on if the initial SMB2_LOCK entry has SMB2_LOCFLAG_UNLOCK bit set or not. Any combination of unlocks and locks in the same SMB2_LOCK request will fail with STATUS_ INVALID_PARAMETER.

As per 3.3.5.14.1, when the lock array in SMB_LOCK is considered as a series of unlocks, for any SMB2_LOCK entry, if either SMB2_LOCKFLAG_SHARED_LOCK or SMB2_LOCKFLAG_EXCLUSIVE_LOCK is set, the server MUST fail the request with STATUS_INVALID_PARAMETER and stop processing further entries in the Locks array, and all successfully processed unlock operations will not be rolled back.

For the network traffic you mentioned, we can see that

1) Packet 27-28: A single lock request succeeding on range 0-10.

ANS: Single lock succeeded as expected.

2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with INVALID_PARAMETER.

ANS: Since the initial SMB2_LOCK in the locks array has SMB2_LOCKFLAG_UNLOCK bit set, server MUST process the lock array as a series of unlocks.(3.3.5.14) and the logic in 3.3.5.14.1 will be applied. Because the second lock in the Locks array has SMB2_LOCKFLAG_SHARED_LOCK set, the server fails with STATUS_INVALID_PARAMETER. But the first unlock request has been processed and will not be rolled back.

3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding, showing that the previous request, though it returned an error, succeeded in unlocking.

ANS: This is expected since the unlock for range (0-10) succeeded in 2).

If you have further questions regarding this behavior , please let us know.

Thanks!

--------------------------------------------------------------------

Hongwei Sun - Sr. Support Escalation Engineer

DSC Protocol Team, Microsoft

hongweis@...

Tel: 469-7757027 x 57027

---------------------------------------------------------------------

From: Steven Danneman [mailto:steven.danneman@...]
Sent: Monday, November 30, 2009 5:58 PM
To: Interoperability Documentation Help; cifs-protocol@...; pfif@...
Subject: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

Hello,

I’ve come across another SMB2 locking issue that I can’t find explicit documentation for in MS-SMB2 (v18.0).

My first question, is whether a single SMB_LOCK request can contain both unlock and lock requests as the LockingAndX command type in SMBv1 could? The MS-SMB2 document hints that the answer to this question is “no” but it doesn’t seem to explicitly state it anywhere.

Section 2.2.26 states: “The SMB2 LOCK Request packet is sent by the client to either lock or unlock portions of a file.”

This statement is ambiguous as to whether the “or” is inclusive or exclusive.

In my testing, sending both lock and unlock requests in a single SMB2 locking request returns a STATUS_INVALID_PARAMETER. However, if the requests are ordered such that a unlock structure come first, the unlock request seems to succeed.

The attached pcap, against W2K8R2 shows:

1) Packet 27-28: A single lock request succeeding on range 0-10.

2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with INVALID_PARAMETER.

3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding, showing that the previous request, though it returned an error, succeeded in unlocking.

It seems to me the server behavior should be to return STATUS_INVALID_PARAMETER without completing any of the lock/unlock requests when they are mixed. Both the fact that this isn’t allowed, and the W2K8R2 behavior deviation should be documented.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

2009-12-02T15:33:23Z

Steven,

I completed the investigation on the behavior described in your e-mail. It is a normal behavior that has been documented in the MS-SMB2 document. The following is the explanation:

For the network traffic you mentioned, we can see that

1) Packet 27-28: A single lock request succeeding on range 0-10.

ANS: Single lock succeeded as expected.

2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with INVALID_PARAMETER.

3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding, showing that the previous request, though it returned an error, succeeded in unlocking.

ANS: This is expected since the unlock for range (0-10) succeeded in 2).

If you have further questions regarding this behavior , please let us know.

Thanks!

--------------------------------------------------------------------

Hongwei Sun - Sr. Support Escalation Engineer

DSC Protocol Team, Microsoft

hongweis@...

Tel: 469-7757027 x 57027

---------------------------------------------------------------------

Hello,

I’ve come across another SMB2 locking issue that I can’t find explicit documentation for in MS-SMB2 (v18.0).

Section 2.2.26 states: “The SMB2 LOCK Request packet is sent by the client to either lock or unlock portions of a file.”

This statement is ambiguous as to whether the “or” is inclusive or exclusive.

The attached pcap, against W2K8R2 shows:

1) Packet 27-28: A single lock request succeeding on range 0-10.

2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with INVALID_PARAMETER.

3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding, showing that the previous request, though it returned an error, succeeded in unlocking.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: Structure of prefixMap over LDAP

2009-12-02T14:26:24Z

Hi Andrew:
Just an update. We are still working on this issue and I'll be in touch as soon as I have an answer for you.

Regards,
Obaid Farooqi
Sr. Senior Support Escalation Engineer | Microsoft

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, November 10, 2009 6:39 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@...; pfif@...
Subject: Structure of prefixMap over LDAP

MS-ADA3 2.115 describes the prefixmap:

Attribute prefixMap
The prefixMap attribute is for internal use only.

However, it is exposed over LDAP, and I don't see a description of it's format in MS-ADTS. With ldp I see only: 'binary blob'. With ldbsearch, I see:

bin/ldbsearch -H ldap://win2k3-2.ad.naomi.abartlet.net -s base -b CN=Schema,CN=Configuration,DC=ad,DC=naomi,DC=abartlet,DC=net
-Uadministrator prefixMap

# record 1
dn: CN=Schema,CN=Configuration,DC=ad,DC=naomi,DC=abartlet,DC=net
prefixMap::
BwAAAFkAAADUEQcAKoZIikEBBcsTCAAqhkiB/xcBBbZuCAAqhkiBzBEBBVBvCAAqhk
iCugUBBesFCAAqhkiB8xcBBZQGBwAqhkiJHQEFzwYHACqGSNMFAQU=

(and our --show-binary option does not know how to parse this).

It was in the past assumed that this attribute was not available over LDAP, but as it is, could you please describe the format?

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: SMBv1 LockAndX return status on lock conflict

2009-12-02T11:37:07Z

Hello Hongwei,

Yes, I used the Samba4 smbtorture program to exercise this behavior. The test that best shows the many strange permutations is RAW-LOCK-ERRORCODE.

For the pcap I sent I pruned that test down to a few specific operations. If you run that full tests you’ll see many more locking requests.

-Steven

From: Hongwei Sun [mailto:hongweis@...]
Sent: Tuesday, December 01, 2009 4:13 PM
To: Steven Danneman; Interoperability Documentation Help; cifs-protocol@...; pfif@...
Subject: RE: SMBv1 LockAndX return status on lock conflict

Steven,

I am now working on this issue. I am wondering what program you ran to create the network trace attached in your e-mail. Is it Samba smbtorture ? If we can duplicate the behavior, it may be easier for us to debug it.

Thanks!

Hongwei

Hello,

STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock.

And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED.

Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows:

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 – 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be “reset” back to STATUS_LOCK_NOT_GRANTED

I’d like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

2009-12-02T07:58:13Z

Hello Tridge - just checking in to see how things are going.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Friday, November 13, 2009 1:14 PM
To: 'tridge@...'
Cc: 'cifs-protocol@...'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

Hello again - glad to see you're back. Resending the below, FYI... Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Monday, October 26, 2009 1:35 PM
To: 'tridge@...'
Cc: 'cifs-protocol@...'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

Good morning Tridge! As I previously noted, Domain Controller LDAP Ping handling will ignore anything in the filter other than the documented elements ([MS-ADTS] 7.3.3 LDAP Ping): DnsDomain, Host, User, AAC, DomainSid, DomainGuid and NtVer.

Concerning [MS-ADTS] 7.3.3.2 (Domain Controller Response to an LDAP Ping), the statements about the DS_DNS_CONTROLLER_FLAG, DS_DNS_DOMAIN_FLAG & DS_DNS_FOREST_FLAG bits have been removed, since they are not (and have never been) set in our implementation.

Please see the attached '[MS-ADTS]_Changes.pdf'; there are several other changes pending in 7.3.3.2.

We have no plans to change LDAP Ping response behavior; this is not unexpected, since there is no guarantee that a given server deployment would have any applicable hotfix or service pack installed. So the flag bits would be undependable.

Of course, the 'complete' DOMAIN_CONTROLLER_INFO can be obtained via DsGetDcName as well as the IDL_DRSDomainControllerInfo method (links are included below for the sake of completeness).

Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation.

==============================================================================
References:

http://msdn.microsoft.com/en-us/library/ms675983.aspx
DsGetDcName Function

http://msdn.microsoft.com/en-us/library/ms675912.aspx
DOMAIN_CONTROLLER_INFO Structure

[MS-DRSR]: Directory Replication Service (DRS) Remote Protocol Specification
4.1.5.3 Examples of the IDL_DRSDomainControllerInfo Method
4.1.5.3.3 Server Response
http://msdn.microsoft.com/en-us/library/cc228357.aspx

4.1.5.1.11 DS_DOMAIN_CONTROLLER_INFO_FFFFFFFFW
http://msdn.microsoft.com/en-us/library/cc228351.aspx

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Monday, October 19, 2009 10:44 AM
To: 'tridge@...'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

Good morning Tridge - just an FYI - LDAP Ping handling will ignore anything other than the documented elements (([MS-ADTS] 7.3.3: elements: DnsDomain, Host, User, AAC, DomainSid, DomainGuid and NtVer).

The response to the TDI is still pending. I will advise you as details are available.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Tuesday, October 13, 2009 10:15 AM
To: 'tridge@...'
Subject: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

Good morning Tridge. My findings indicate that LDAP Ping handling on the DC will consider only the documented elements ([MS-ADTS] 7.3.3: elements: DnsDomain, Host, User, AAC, DomainSid, DomainGuid and NtVer).

I am still waiting for a response on the TDI.

Please note I am out of the office for the next several days, due to illness. I will keep current on any incoming email from you, as well as developments on the TDI. If needed, we can temporarily reassign the case to someone else on my team.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: Bill Wesse
Sent: Monday, October 05, 2009 10:11 AM
To: 'tridge@...'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

You're welcome - I expect to begin a debug on 2008 R2 concerning this later today, or tomorrow; I can't predict whether or not modifying the search filter to would influence the result (I will look into a modified test to check this). Certainly, one would expect the DS_DNS_FOREST_FLAG to be set in the response, since DnsForestName is present (and so on).

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----
From: tridge@... [mailto:tridge@...]
Sent: Friday, October 02, 2009 5:05 PM
To: Bill Wesse
Subject: Re: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

> Regardless, we definitely have something missing in the LDAP Ping > documentation concerning these flag values. I will keep you advised > as information is available.

Thanks Bill!

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)

2009-12-02T07:55:29Z

Hello Tridge – just checking in to see how things are going.

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

From: Bill Wesse
Sent: Friday, November 13, 2009 1:11 PM
To: 'tridge@...'
Cc: 'cifs-protocol@...'; 'hyc@...'
Subject: Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)

Hello Tridge. Here is what I have (pending the proposed changes for [MS-ADTS]:

The length of a delete-mangled RDN may indeed exceed rangeUpper, due to the additional delete-mangle decoration.

I should first note that the delete-mangled RDN format contains a ‘\0A’ character - not a ‘\0’. Perhaps this is a typo in your email?

\0A is a character not allowed in Active Directory names, per [MS-ADTS] 3.1.1.5.1.2 – and is certainly a handy way to verify whether or not a name has been mangled (a.k.a. strchr(pszRDN, (int)0x0a) ).

The format is, of course, noted in [MS-ADTS] 3.1.1.5.5 , like "objectName\0ADEL:dashed_string_objectGUID". As noted in [MS-ADTS] 3.1.1.5.1.2. the maximum RDN length is 255; it is further constrained to 64 ([MS-ADA1] 2.110 Attribute cn, rangeUpper: 64).

That said, the length of a delete-mangled RDN can be up to 105 characters (not including the terminating NUL character): {rangeUpper:64} + {0x0A:1} + {'DEL:':4} + {dashed-string-Guid:36}.

[MS-ADTS] 3.1.1.5.1.2 also notes that "Naming constraints are not enforced for replicated updates.", so the additional length of a delete-mangled RDN will replicate properly.

I have filed a TDI against [MS-ADTS] section 3.1.1.5.5 Delete Operation to have this annotated.

References:

[MS-ADTS]: Active Directory Technical Specification

3.1.1.5.1.2 Naming Constraints

During an originating update of the Add, Modify, and Modify DN operations, the server validates the following naming constraints. Unless otherwise specified, the server returns LDAP error namingViolation if a naming constraint is not met.

o The RDN must not contain a character with value 0xA.

o The RDN must not contain a character with value 0x0; otherwise, the server SHOULD return LDAP error invalidDNSyntax. However, if the DC functional level is DS_BEHAVIOR_WIN2000, the server will not return an error.

o The DN must be compliant with [RFC2253].

o The RDN size must be less than 255 characters.

Naming constraints are not enforced for replicated updates.

3.1.1.5.5 Delete Operation

...

In most cases, upon deletion, a tombstone, deleted-object, or recycled-object is moved into the Deleted Objects container of its NC; for exceptions see section 3.1.1.5.5.6. The RDN of the object is changed to a "delete-mangled RDN"—an RDN that is guaranteed to be unique within the Deleted Objects container. If O is the object that is deleted, the delete-mangled RDN is the concatenation of O!name, the character with value 0x0A, the string "DEL:", and the dashed string representation ([RFC4122] section 3) of O!objectGUID. A "delete-mangled DN" is a DN such that the leaf RDN is a delete-mangled RDN.

==============================================================================

Question:

From: tridge@... [mailto:tridge@...]

Sent: Monday, November 09, 2009 6:58 PM

To: Hongwei Sun

Cc: cifs-protocol@...; hyc@...

Subject: RE: limits on rDN size in AD ?

Hi Hongwei,

We're back to the old question of rDN size limits again!

I just got a DRS replication reply from w2k8-r2 with a CN that has a length larger than 64. So I suspect that things are a bit more complex than what we'd discussed before.

The object was:

CN=89532b80-09fe-445e-afef-965c0d7f7d15\0ADEL:462902b4-1824-4f02-8956-9f934f64fa01,CN=Deleted Objects,CN=Configuration,DC=vsofs8,DC=com

which gives a length of 80.

Are we perhaps supposed to interpret the \0 as a termination character for the purposes of this length constraint? (note that this is a \ followed by a 0, not a nul byte).

Or perhaps deleted objects are special in their constraints in some way?

Cheers, Tridge

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

From: Bill Wesse
Sent: Thursday, November 12, 2009 9:44 AM
To: 'tridge@...'
Cc: 'cifs-protocol@...'; 'hyc@...'
Subject: Re: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)

Good morning Tridge! Since Hongwei is out of the office, I have created case SRX091112600056 to track our work against your question about rDN size / deleted object rDN.

I expect to be able to begin work on this tomorrow, and will keep you updated!

Regards,
Bill Wesse
MCSE, MCTS / Senior 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

-----Original Message-----

From: Hongwei Sun

Sent: Thursday, November 12, 2009 12:56 PM

To: 'tridge@...'

Cc: cifs-protocol@...; hyc@...; Edgar Olougouna; Sebastian Canevari

Subject: RE: limits on rDN size in AD ?

Tridge,

The RDN of Deleted Objects container is a little different from the normal RDN. The following information in MS-ADTS 3.1.1.5.5 describes the composition of RDN for objects in Deleted Object container:

"The RDN of the object is changed to a "delete-mangled RDN"—an RDN that is guaranteed to be unique within the Deleted Objects container. If O is the object that is deleted, the delete-mangled RDN is the concatenation of O!name, the character with value 0x0A, the string "DEL:", and the dashed string representation ([RFC4122] section 3) of O!objectGUID."

It looks like to me that for the Delete Objects container, the size constraint should be dependent on the combination of the each sub component. Since I am out of office, I will ask one of my team member to investigate and confirm the behavior.

Thanks !

-----Original Message-----

From: tridge@... [mailto:tridge@...]

Sent: Monday, November 09, 2009 6:58 PM

To: Hongwei Sun

Cc: cifs-protocol@...; hyc@...

Subject: RE: limits on rDN size in AD ?

Hi Hongwei,

We're back to the old question of rDN size limits again!

I just got a DRS replication reply from w2k8-r2 with a CN that has a length larger than 64. So I suspect that things are a bit more complex than what we'd discussed before.

The object was:

CN=89532b80-09fe-445e-afef-965c0d7f7d15\0ADEL:462902b4-1824-4f02-8956-9f934f64fa01,CN=Deleted Objects,CN=Configuration,DC=vsofs8,DC=com

which gives a length of 80.

Are we perhaps supposed to interpret the \0 as a termination character for the purposes of this length constraint? (note that this is a \ followed by a 0, not a nul byte).

Or perhaps deleted objects are special in their constraints in some way?

Cheers, Tridge

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol